I've built a product that tracks team mood that is based almost entirely on email. Instead of having a team of 10 developers each make their own accounts, there is just one account for the manager - who manages the list of the team's emails. The team members record their mood by clicking one of three links in the email, no complicated forms or sliders. Usage and adoption rates have been beyond my expectations (~70% response rate to daily emails) and I think the use of email is a major factor.
Email-first is very constraining - but ultimately constraints help spur creative and elegant solutions.
I find this very interesting. What made you want to avoid use a slider?
Personally, I really dislike such limiting options. Good, meh, bad? It doesn't let me express if I'm a little better than good or somewhere between Good and Meh. I'd often have to truncate my true expression.
For myself, I would love a single simple slider. It would let me express myself with any degree of accuracy I want. Very specific, or just rough.
Am I an exception from the average user?
Because this bugs me in so many places. So many things are in or out. I want them to be a floating point value between 0 to 1. Website favourites. I wish I could favourite them by any amount between 0 to 1, etc. (Then you could do all sorts of things like display the higher-ranked items larger, or filter displaying only >= 0.75 items). Same goes for app/movie rankings. Why do I have to truncate my feelings to 1-5 stars instead of just dropping a slider to where I feel like?
I don't want answering the question "how is your day going?" to take more than the 2 seconds it takes to move your mouse to the link.
The problem with the slider is that you have you interface with it. So the workflow would be: get an email, click a link, move a slider (compared to get an email, click one of 3 links). I know I'd want to avoid the extra step as a user, so that's why I opted for that approach.
There is also an option for the user to enter an anonymous comment after they have logged their mood - so if you want to express why today is bad or add note that it is an especially excellent day you can do that.
At a higher level view, I think the value in this particular app is not a scientifically rigorous computation of a teams mood, but rather as a conversation starter ("why has there been a few 'bads' this week? let's talk about it") and a general trend indicator ("morale is down since we moved to the new office, what's up with that?").
It's a good point that you can't do a slider in email, I didn't think of. Unless email allows embedding an html form that you can submit? I've never seen anything more than static html in my email so I guess it must not be possible.
Anyway, thanks for your explanation, it makes sense. I think I'll make myself a 0-1 floating point favourites tracker and see how I like using it.
Thanks for the feedback, I appreciate it.
I built a political survey app once, and we started out using sliders to measure both (1) issue importance and (2) agree/disagree. It was way too fiddly, and no one cared about degree of accuracy. Every iteration of the UI we gave the user fewer choices. By the end I was pushing for just "agree" and "disagree" or even "agree" and "next question," but we never took it quite that far.
This is where I really love the Token Authenticatable module in Devise (for Rails).
Your rails app can start by just collecting emails. As your app grows, you can then turn that table into a Devise User model. Turn on token auth. and your emails can now include links that auto-login users.
show up in browser history
can be pasted accidentally somewhere
are send usually unencrypted via email
Don't get me wrong, I play with the idea of login-links as well, but they have some drawbacks that one should at least be aware of.
I did a similar thing when launching BugMuncher - I bought a template from Themeforest, built a very minimal PHP backend, and put a paypal subscription button on to the website.
When ever anyone signed up, I'd get a notification from PayPal, at which point I'd manually add the user's details into my database, and manually send them a welcome email. There was no where for users to log in an amend their account, instead they had to email me with the required changes, and I'd action it.
This meant I could build the first version of BugMuncher very fast, and once I had my first 10 paying customers I felt it was validated enough for me to build the full, automated system.
So in short, MVP's rock
They are actually moving to email-first-and-now-a-bit-more tomorrow - from tomorrow onwards, there won't even be any email, as the data they're providing will go straight into another system through an API. From email-first to not-even-email.
I was manually going through mails both from project owners and helpers.
Now it's more or less automated (and about to relaunch after a period of silence) but it was good to get validation easily.This was exactly how I started http://www.weekendhacker.net
Now it's more or less automated (and about to relaunch after a period of silence) but it was good to get validation easily.
Other startups that could have started as emails
From wikipedia: "Craig Newmark began the service in 1995 as an email distribution list of friends, featuring local events in the San Francisco Bay Area, before becoming a web-based service in 1996 and expanding into other classified categories. It started expanding to other U.S. cities in 2000, and currently covers 50 countries."
It uses Mailgun for email management and in my experience it works flawlessly.
I started it out of Melbourne, Australia and we've gone to 10 cities across the US, Europe and Asia Pac within a year. :)
Surprisingly: 2 of the 6 marketing directors interviewed said "Email" was the most underrated technique.
There could be something to this email-first idea.
In particular they really are quite good at simplifying the parsing of inbound emails, which lets you get going quickly.
We expand more upon this idea in the following post: http://www.tinylever.com/building-an-audience-before-or-para...
Surprises me how many people though tell me we should build and sell an App instead. Which market would you rather gain traction in - people with smartphones or people with an email address?
That said, here's how I think users respond to daily content delivered via email vs. an RSS feed:
-- A handful of RSS feed updates a day: That's cool.
-- A TON of RSS feed updates a day: Still cool. I'll get to 'em when I get to 'em.
-- A handful of email newsletters a day: That's cool.
-- A TON of email newsletters a day: Not cool, man. If I have time, I'll filter them. Otherwise, time to unsubscribe.
So, yeah, right now, email might be a good medium ... but there is a saturation point.
Long term it'll continue to be too, just as with anything else. There are only so many magazines, newspapers, TV channels, Web sites, foods, restaurants, drinks, etc, that we can cope with/consume each day too, but new ones come along and knock others out of business without breaking the tolerance for the medium (luckily!) :-)
To focus on the people you care about
His product is (well, will be) to offer this as a service to others: http://convertkit.com/