I like 37signal’s Design Decisions posts, which explain the thinking behind seemingly small details in their apps. It makes sense: building the core functionality of most web apps is relatively straightforward, the real quality (and, ultimately, most of the effort) is in the details. So, here’s my take on Feedvolley‘s design.
I’m not aware of any site that does the quite same thing as Feedvolley, so the first challenge is to get users to understand what it’s about and how to use it. My favorite way to learn to use something is to play around with it (not recommended with firearms, bikes and similar BTW), so the goal was to make Feedvolley’s interface invite users to do just that. That means making it as easy as possible to accomplish something, and then make it rewarding to keep playing with what was created.
To make starting out easy, the homepage is a minimal form with fields for feed or HTML page URL (one of the features that make RSS/Atom a good Web API is the fact it’s often auto-discoverable) and email (more about that in a moment). A default theme is pre-selected.
Another way to create a page is by clicking the “Create a page like this” link located on top of every user-created Feedvolley page. This lets users start with an existing page and modify the content and HTML to their needs. That’s one of my favorite web app buttons – it invites a viewer to become participator, and lets users start with something similar to what they want, and just modify it as they learn the system.
You might have noticed there is no registration step here. Personally, I hate having to register to a website in order to do anything. Feedvolley (like Notifyr) uses email as its user authorization system. Each user gets an edit link with a unique token string. This token is also kept in a cookie, so users aren’t forced to go to their email in order to start editing. “Create a page like this” also serves as backup for this system. In case a user lost the edit link, she can simply go to her page, create a duplicate and continue editing that.
This may not be perfect, but seems optimal for most users. If some users ask for a more rigid authorization system, we can always add it later on as an option.
As far as design goes, I’m with the “it’s done when there’s nothing more to remove” (as opposed to “nothing more to add”) school. So, I’m pretty happy with the result in Feedvolley. Some challenges remain: how to make it more obvious that a page can be customized once it’s created, for example. It’s not perfect yet and we’ve already incorporated some user feedback into it – if you have any comments or requests, please leave them here or email me directly: email@example.com.