Designing Search for Rooms
This is one of many stories we could tell about designing Rooms. While search is a seemingly straight-forward piece of UI with tons of examples to reference, I wanted to expose the whole process: from deciding if we even needed to build search, to fully fleshing out details for internationalization.
When Rooms launched last October, one of the biggest bets we made was not starting with any type of discovery. We believed that what was important for new rooms were dedicated founding members, and that the path to a successful online community required quality content before being exposed to high volume of traffic — especially on launch day (aka tech press deluge). We predicted that if we launched with search, there would be many rooms that eventually die because:
- the founders would be people who were just trying the app
- the content within most of the rooms would be of low quality (e.g. “testing”).
Instead, we wanted every room to have a solid foundation — built by a motivated founder who could recruit people they already had loose connections with. We guessed that this would increase the chances of having a dedicated founding group and a successful room.
On QR invites
The promise of the internet was meeting people you couldn’t meet in real life and connect with them over mutual interests and passions. Our vision for Rooms was to enable those connections to form in today’s mobile-dominant world — and in this mobile world, images are the easiest things to share (as opposed to copy/pasting a link). A “visual URL” could enable fast sharing in messaging/social networks, from a computer screen to a phone, and even between two phones in real life (like Snapchat’s latest friending feature).
We thought the invites could spread via existing networks — and it did for a couple of our strongest rooms like Kendama (where people showed off tricks on the Japanese skill toy) and Emulators (where gamers discussed emulation on iOS). Kendama bootstrapped heavily off an existing Facebook group, and Emulators from the iEmulators website.
Time for search
Around three months before we initially launch Rooms, we had a changeup in our design team. Cemre Güngör, who had come with me from the Branch acquisition, transitioned to the News Feed team. Andy Chung swapped places with him and joined us in London for a sprint with the engineering team. After we launched, Andy pushed for us to explore search — we finally had a number of rooms that could populate search results and helper apps were cropping up. Josh Miller (PM, also via Branch) and I had doubts about whether we were ready to do search, but we decided to spend some design time whipping up a prototype to see what sort of results we could get.
Hooray for Parse~
Rooms is built on Parse, which has some handy REST endpoints I used to quickly get a hacky regex-based search prototype running in a day.
It was capable of partial string matches within both the title and description of the rooms, and fetched some metadata that I hoped could help us decide how to rank results.
Parse supports regex based searches for individual columns. I just sent an XMLHttpRequest and appended params to do two separate searches for matches in titles and descriptions, and merged the two responses with underscore.js:
var query = ‘Kendama’;
var classUrl = “https://api.parse.com/1/classes/Room?"
var regex = “(^” + query + “$)|(^” + query + “[.,!/$ ])|([.,!/$ ]” + query + “$)|([.,!/$ ]” + query + “[.,!/$ ])”;var nameParams = “where=” + JSON.stringify({‘name’: {“$regex”: regex, “$options”: “i”}});
var detailParams = “where=” + JSON.stringify({‘details’: {“$regex”: regex, “$options”: “i”}});
var nameResponse = openRequestWith(classUrl + encodeURIComponent(nameParams));
var detailResponse = openRequestWith(classUrl + encodeURIComponent(detailParams));var response = _.uniq(_.union(nameResponse, detailResponse), false, function(item){ return item.objectId; });
The results were actually pretty promising. I was able to find some decent rooms for two interests — climbing and Super Smash Brothers:
Iterating on the search logic with engineering
After we had convinced ourselves that there were enough rooms to search, we started to try and ground the prototype in reality. There were two big questions:
- Could we actually do scalable search in production
- How would we display the results?
For the first question, as soon as we showed the prototype to engineering, they said a partial string match was probably unfeasible for the time frame we wanted to ship in. However, they proposed that we move to a “tag-based” system, where we would convert every discreet word in room titles and descriptions into a tag. With this suggestion, I tweaked the prototype to their proposal, and it still returned solid results:
As for displaying the results, I thought the post previews would be the most informative, but they required more engineering time that we wanted. Ranking based on member count and post count made the most sense — other metrics I tried, like time spent or comments per user, all mapped to member and post count.
Fleshing out the in-app execution
The next step was to bring this feature to a more visually realistic and interactive stage. At this point, Explore was already in the app: a hand-curated collection of rooms that we had vetted for quality. It made sense for search to live within that view and reuse the designs.
I also looked up the top 10,000 words in English and used it to prototype autocomplete, designing in code along the way:
A key part of the design process at Facebook is fully fleshing out a feature in high fidelity. I personally took to Quartz Composer + Origami since I joined a year ago, and quickly built a motion prototype to show the entry points, table view transitions, and segues to other views:
One particular interaction I spent extra time trying out variations was what transition happened when you opened a room you’ve joined:
Living with it, and iterating
At Facebook we spend a decent amount of time living with a feature and improving it before we release it. This was especially true for a product like search. With my personal queries I found some interesting rooms, but we wanted to see if search was helpful for a broader set of people. Along with this validation, we also began to discover edge cases, like supporting dynamic type, and localizing with longer strings.
One thing in particular I iterated on was the layout of the result cells. The design I fleshed out above had the join/open buttons vertically aligned and taking up a whole column, but that meant on smaller screens the descriptions were heavily truncated (especially in French, where the join button was almost half the width of the cell). With some suggestions from one of our engineers, I ended up with a layout that allowed full width descriptions, and switched to an arrow to represent “Open”:
In addition to living with the built feature ourselves, Omid Farivar, our researcher, also found some people unfamiliar with Rooms to come into the NY office. One major point of confusion was the previous animation after you joined a room that we designed for the launch of explore — an invite would appear for a few seconds, and transform to the room (to reinforce the concept of invites). However, in the new world of search, it made sense to strip out the concept of the invite, and roll with a simpler, faster animation:
Try it out
After a month of work, Rooms 1.3 is out in the app store. Check it out and see if you can find that room you’ve been looking for.
If you were into the iterative prototyping, Facebook is hiring in New York, London, Seattle, and the bay area.
Thanks to Alex Akers, Hermes Pique, Andrei Gheorghe for dealing with me in building search; Matt Galloway, Stephan Diederich, Robyn Morris, Alex Fortunato, Alan Cannistraro, Laurie Mueller, Caroline Hudack and the rest of the Rooms team for being cool.
