Hacker News new | comments | show | ask | jobs | submit login
Tasty Labs' product: human.io, a way to build easy mobile participation (human.io)
45 points by joshu 1623 days ago | hide | past | web | 25 comments | favorite



This lets you build tiny little microapps and distribute them to a mobile client. The code runs on your server, but the UI runs on the device. The events are gatewayed back and forth.

The ultimate vision is to make a way for passive audiences into active participants.

We combined things we love: Mobile, Mechanical Turk, MapReduce, and Twilio.


Interesting concept. I haven't wrapped my head around what this is most useful for yet, but it seems like it has potential.

I played around with your API and I was actually kind of amazed at how easy it was to get going. (The sample apps helped a lot.) Writing a little bit of code, then right away seeing it show up in the app and user interactions show up in the console is really cool.


Imagine that they are more-functional notifications that can be broadly (rather than specifically) targeted?

What could we do better on the API? Were there widgets that you would like that are missing?


I'm confused as to what this is, can someone help explain?

For example, what is a micro-app? How does it differ from just an app?

It says you can: "Engage with your fans and users by creating micro-apps that allow you to interact in a much richer way than tweets, ads, or email." It's lightweight but enables a richer communication experience. How? Do you have some examples?


micro-apps are small, limited functionality things you get users to code. You couldn't really write a game in this.

Compare it to, say, an SMS. Instead of a bit of text, you get a bit of text, two buttons, a camera button, etc etc etc. So it's richer than a notification, but only by a little.


This really needs a showcase of internally built use cases for human.io that I can play with right now.

I assume that: developers can create a micro-app with a dead simple API ... users run and discover these micro-apps from within the human.io mobile application.

An example micro-app would be where I create a bookmarklet that grabs an image, it sends it to human.io with the text "please identify this shirt" and then a human.io user can choose to run and solve that "micro-app"

It's confusing because micro-app implies repetition, whereas they are more like tasks: they have a "completion." This is a more powerful, easier to use, mechanical turk where the turks are on mobile.


This is correct.

We were hoping for a quiet soft-launch so we could get more API feedback before a real launch (including use-cases like you suggested.)


None of the "things you can do" lend themselves to justify me having to host the micro-app - eg, they do not tell a story of needing to pull in additional application logic: was it a conscious decision not to build an IDE and hosting environment for human.io so I could just jump straight into building micro-apps?


We built the assembly language; the ide/hosting/etc would be a layer above that.

The events are pushed back to a webserver[1], and you decide what to do there. If you already have an application and data storage etc already, this is basically the easiest thing to do. We felt this flexibility would lead to the most interesting initial apps; additionally, the vast majority of early adopters would probably not love being sandboxed.

[1] we also have a hanging HTTP api; call /next_event and it hangs until it has events for you. this lets you talk to the system without having a public open port.


This is a tough platform sell because you have to tell people to install some other app to run/participate in your app. I've been through this, and it's tough to get other people to be your distribution channel. I created somewhat similar functionality into Notifo to do mobile surveys (but never launched it publicly). This looks like a much more fully-featured and flexible version of that idea, it will just be a tough concept for people that this lives inside another wrapper app.

EDIT: unless i'm misunderstanding completely, and you guys (tasty labs) will be driving the installs so as to create a mobile mechanical turk force... in which case, this could be communicated better in the copy. Now I'm just confused.


It's a mix. We might do white-box installs (ie, add a library to push tasks to your already installed application.)

We're trying to make the the environment ridiculously easy to use. There are lots of organizations with large audiences but limited tech skills that can take advantage of something like this.

I hope you check out the API - I'd been meaning to reach out to you at some point.


Cool, I'll check it out. Happy to talk about it anytime... email/gchat/coffee/whatever


uh oh, i didn't write down my developer creds when I created them and can't find a way to see them again... help?


just create another account for now.


Can the micro-apps only run on the human.io app through your UI? If so, is the benefit you guys provide the fact that you aggregate captive audiences of mobile users and allow companies/developers to filter that audience by things like interest/location/phone ability?

Monetization isn't mentioned anywhere for now, but presumably eventually users will earn $ for each task they accomplish, and human.io is the platform that allows companies and individual workers to transact?

Looks cool! Just trying to get a few ideas clarified.

Edit: Would it be accurate to think of you guys as a mobile Mechanical Turk? A marketplace for lightweight, mobile-based tasks?


That's correct.

We don't really want to be Turk per se - micropayments for microtasks is neat, but we're aiming for something wider. The activites are much broader (not just do work, but look up relevant information, or whatever) and the motivation similarly broad: eaderboards, or affinity to an organization, or money, or whatever, there are dozens of reasons that people do things. I don't want to just pick one of those and only allow a limited set of motivations.


Also I would love feedback about what part of this is confusing. We are still struggling with how to explain this crisply...


For starters, micro-app might be what you're preferring to call it, but as a reader (even with a tech background), I couldnt understand what it meant. I think you should put the use cases way up top on the page -- and probably provide one elaborate use case to help the reader better understand. Plus, i think the description needs to be completely reworded: 'Engage with your fans and users by creating micro-apps that allow you to interact in a much richer way than tweets, ads, or email' gives me no insight into what it does and how.


Yeah. We're struggling to describe it. We've got a bunch of different lines that come close.

"micro-app" is a (probably poor) compromise. It sortof hints what they might do better than Activities or whatever...


Why would I be a user of the app. I get being a company, but not the user.


This is just the developer preview. I think the companies will have to provide reasons to do the activities, either by being useful or providing other motivation (monetary, leaderboards, points, etc, whatever their system does.)

We'll build more tools for user motivation in the future. For now I just wanted to make sure that the actual things that people can build are interesting enough.


joshu - your #1 use case caught my attention (check restaurant wait time). We're doing a lot of that at waitscout.com - can we chat?


Drop me a line. joshua or contact@tastylabs.com


Anyone else notice the (somewhat hilarious) typo in the leftmost image?


Sigh




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: