Ideas —especially in consumer software— tend to be worthless. As is well-known, execution, distribution, and lots of other prosaic factors are decisive. Being realistic about competitive landscapes, model necessities, and market forces is hard when you’re excited about a product idea, but as the man said: the better part of valor is discretion. That’s why, earlier this year, we at Mokriya decided not to proceed with developing a chat app we called Rooms. Today, Facebook launched a chat app called Rooms, and it gave us a big kick, so we thought we’d share the story.

We had been interested in creating useful, persistent spaces in which people could gather and chat. Twitter has in some cultural senses supplanted IRC, but it’s done a poor job at replacing it. Most of us still retreat to private chats in order to interact freely —as public performance necessarily brings public judgment— but these spaces often don’t serve our needs. They’re difficult to manage; you have to invite members and manage membership, and the formalization of relationships is burdensome.

We wanted

  • ad-hoc spaces that could be organized around a group (just me and my friends), a topic (SF Cyclists), or a place (a park, a bar, a store)
  • spaces that could be public or private
  • optionality on identity and anonymity for all users, but also easy blocking / reporting so no one has to deal with abuse
  • optimized for mobile

Our model was the real-world: how and where do people gather at their most happily social? Well: parties with friends; bars; events which typically have topics (sports events, conventions, meetups, festivals); and certain locations.

We wanted to mirror the ease of choosing, navigating, and enjoying those spaces as much as possible, so we started playing around with some designs for an app we code-named… Rooms!


Fig. 1: Initial ideation for Rooms. Please forgive all of the stupidity everywhere; I was just messing around to think some things through.

In terms of visual, UI, and UX design, these early Rooms sketches were purely derivative of Vine, Facebook Messenger, and Path Talk. I like some interface ideas in all three, and was especially impressed with efforts to improve the ease of communication on mobile with additional input methods; similar efforts have been undertaken by Apple with iOS 8. In any event, the purely imitative look of these sketches reflects a standard technique: when thinking through a semi-novel product design, use borrowed or standard visual and UI design elements as much as possible so you can stay focused on the product experience.

Fig. 2: Again, apologies to Vine for the theft. Had development continued, we’d have developed our own visual and UI style and design language.

As you can see, we were unsure of many details; we were still thinking through issues around how to allow rooms to be self-governing without the clunky use of “moderators” or “admins.” We also hadn’t resolved how to handle rooms with hundreds (or more) people posting all at once, or whether we should cap room sizes.

Fig. 3: We imagined that Rooms would offer auto-generated usernames when you joined a new room, rather like Secret: hence “Blue Boat.”

Above, note the reference to “text / bubble opacity face to 0”: anything said in Rooms would fade away at some rate we’d not decided. We discussed allowing ephemerality to be set on a per-room basis, but again: a priority was to avoid moderation, administration, or room management beyond the minimum needed. We hoped that ephemerality + ad hoc arrangements + flexible identity + ease of inputs would make for the most realistic instantiation of casual social interactions on mobile.

Rooms never made it past design ideation and discussion. For one, we felt pretty confident that Twitter would launch a group DM app, and I thought with their non-real-name / semi-topic-graph structure, they’d be in an organically strong position to do it well. They know how to pursue real-time at scale, and they’re working hard on many of the relevant issues an app like this will entail. Their brand is sensibly aligned with it, too, and they can probably launch a cross-platform solution that would be hard for a small studio to match.

But also, as a social product, Rooms needed to built in a way that would have been hard for us: above all, the design and development processes would have to be organized around learning, around seeing what actual users do in volume in the wild. The timeline for iteration would be long, but iterations would need to be high-speed, constant. Give the constraints we faced, we just didn’t think we could give it all that it deserved; after all, these in-house products are side-projects from the point of view of our client work!

As it happens, it’s Facebook who made it to market first, and although I’m mystified by the addition of QR codes into the app —I can’t think of anything they do that couldn’t be done better with another solution— I’m eager to use Rooms more with friends. The Internet needs a place where people can create their own spaces for real time public or private conversations easily, a place where they can make their own Cheers, their own Algonquin Round Table, their own family-reunion, their own coffee shop, and so on.

While there are many places that seem like they serve this purpose, that most require heavy meta-organization, have permanent posting, and are organized around a graph one doesn’t control means there’s room for a solution, pun regretfully intended. Twitter should be most concerned about possible successes in the private communication category, because a primary effect of any growth in this area will be to decentralize Twitter, to take lots of content and interaction currently posted to Twitter and put it in channels off of Twitter. They need to hurry with their group messaging app.

Mills Baker