DotNeil.com

Here’s an example of the sort of user experience decisions a Web start-up founder will need to consider on a daily basis. The example may seem trivial to some, but if you’re pinning your hopes on creating a Web service people will return to every day, these finer details are incredibly important, and should not be hastily delegated to the people who write the code. These decisions determine how potential customers will view and use your product, or why they might prefer a competitor’s offering (Why I Plurk, Again).

In SoIndustry, people post status updates, other people reply to them. There are two obvious routes[1] for enabling this interaction in a Web-based user interface;

1) Threaded replies: I click ‘Reply’, a form pops in to view, and I can post my reply underneath the status update. This is how SoIndustry works (among a handful of other status update orientated apps).

SoIndustry | Posting a reply underneath a status update

SoIndustry | All replies threaded underneath the status update

2) @replies: I click ‘Reply’, my mouse cursor is focused on the form through which the status update was posted, and I post my reply there. This is how Twitter works.

Twitter and @replies

And here are just a handful of the user-interface implications you now need to consider, based on your choice of Threaded-reply, or @replies, for your ‘reply system’ implementation;

• With threaded-replies, my reply is tucked underneath the status update, and may - or may not - be published at the top of the timeline. With @replies, I wouldn’t expect anything less than to have my reply published at the top of the timeline (otherwise, where is it going?).
• Threaded-replies create hierarchy between status updates and replies, @replies don’t.
• Threaded-replies let people track all replies to a status update (they’re aggregated underneath in the form of a thread), @replies don’t (if you want to know why they don’t, try implementing threaded @replies in your own application, or ask the creator of Quotably).
• Threaded-replies make it easy to implement ‘group’ permissions, because status updates and replies can be assigned differing levels of authority (e.g. I, as an ‘Admin’ can post a status update in my group timeline - you, as a lowly ‘Member’, can’t - but perhaps you’re authorised to post a threaded reply underneath any status updates in the group). @replies don’t, because people are always expecting to see a form through which they can post an @reply, and the @reply should always go to the top of the timeline, rather than being aggregated underneath a status update.
• Threaded-replies steer you towards keeping replies out of timelines altogether (otherwise you’re posting replies underneath a status update and then watching the same reply up at the top of a timeline, too), making it less likely that people can continue to follow a thread (as the status update is pushed further down the timeline), unless sufficient email notification options are implemented. @replies always bring the latest content to the top of the timeline, be it a status update or a reply.

Confused yet?

If not, do you have a preference of a threaded-replies or @replies convention? Or have you and navigated a similar blue-pill/red-pill path in your own start-up endeavors?

[1] I’m working on the third, and it’s brain-frazzlingly complex from a UI perspective.