Written by Brian Cray on January 26th, 2010
I wrote this article to give you insight into the complete design process for the redesign of Nearby Tweets. Web app developers and entrepreneurs will hopefully gain some ideas or reinforce their own processes. Users may find it interesting to see what goes into the design of a complex UI. I'd love your ideas, feedback, and thoughts at the end of this article! Enjoy.
Start at the beginning
In the beginning there was the first iteration of Nearby Tweets, a simple way to connect with local people and businesses on Twitter.
But in product development there is no such thing as perfection, only iterative design—and customers hold all the answers to a better product. So I reached out to my users as soon as I had a chance with Uservoice. Through Uservoice, my users could vote on features they wanted see in the Nearby Tweets redesign, and vote they did.
Top user requested changes to Nearby Tweets
- Default location
- Saved keywords and locations
- Pullout drawer was annoying
- Manual directory
- Mobile version
- Auto-refresh tweets
- Block users
- Block locations
- Follow feature
Choosing which features to implement
While all user requests are valid opportunities, I had to give some thought to my own resources and agenda before to make the right decisions about which requests to accept.
Sorry mobile version, but you'll have to wait
Since I already had a web presence and I have not completely aligned Nearby Tweets' web presence with my goals, I am holding off on the mobile version, because that requires many resources and a new round of considerations, which would set me back and throw me off.
Sorry manual directory, but you're for someone else
There are plenty of apps out there doing manual Twitter directories. I don't have the reputation to compete them in that space, but the auto geolocation space is still mine, and that's where I'll stay for now. (See Twellow, WeFollow, and just tweet it)
The rest of you, come with me
The rest of the user-requested features fit within my current agenda for the web platform, which I'd have to also define more clearly before I started in on the UI design.
Narrowing my design scope
In order to keep myself on track, I laid out three design scope requirements for the Nearby Tweets redesign:
- Address user concerns. I released the first version of Nearby Tweets quickly with little user feedback, just to quietly hit the market with a fun, useful project. With this redesign I wanted to garner as much user feedback during the design process as possible. I did so through Twitter, Uservoice, as well as a private and public beta.
- Make Nearby Tweets more powerful. Although the focus of the first version was an advantage, it was very basic with no extended functionality. This time Nearby Tweets would supplement its core functionality with user preferences, and advanced search features.
- Maintain Nearby Tweets' simplicity and focus. All the while I would retain the simplicity of Nearby Tweets and make any effort to further simplify the Nearby Tweets experience.
Then I came up with my design goal
Allow users to watch nearby tweets without any work, but allow users to tweak Nearby Tweets when ready.
Turning concepts into UI design
To keep Nearby Tweets simple while adding advanced functionality I decided to utilize two UI design concepts: Progressive disclosure and lazy registration.
Implementing progressive disclosure in the UI
Progressive disclosure defers advanced or rarely used features to a secondary screen, making applications easier to learn and less error-prone. - Jakob Nielsen
It should be noted that a second screen could be interpreted as hidden functionality that displays on the same screen on demand. That's one of the ways I interpreted it anyway, as you'll see.
The primary focus of each tweet is what's said and who said it, so I kept each tweet to just that.
However, users have specifically requested the option to follow people, block people, and block locations. This advanced functionality needs to be available without cluttering each tweet with options used by a minority of the users. In comes progressive disclosure. As a user moves their mouse over each tweet, options to follow people, block people, and block locations becomes available.
Location and keyword change popups
The primary focus of an initial visit to Nearby Tweets was to simply watch the Nearby Tweets stream. So the only heading on the home page reads: "Tweets nearby xxxxx about yyyyy." Simple enough.
But what about when people decide to search a new location or keyword? You'll notice that the location and keyword look like links. When the user moves to click the location or keyword to change it, an in-place popup reveals the potential for more functionality.
To present the user with a search box and everything else for searching would be too much for people just casually moving their mouse across the screen, so without clicking the user simply sees a button to "Change." Clicking on that button further reveals full search capability. The whole box is actually clickable to increase the user's click area.
One thing you'll notice on the location popup is a "use the map" button. The map is another area of the UI that has two purposes: Give the user a sense of location and provide advanced search functionality through progressive disclosure.
Location searches using an interactive map
At first glance the map just sits behind the Nearby Tweets stream and provides the user a visual context for their location, with a translucent white circle indicating the search radius.
When users search locations, the Nearby Tweets stream slides away and reveals the map as search controls fade in.
This UI allows the map to take the backseat as a simple, relevant visual background to the Nearby Tweets steam while it's not in use, but provide a very powerful search interface on demand.
As a classic example of progressive disclosure, users can add saved locations, keywords, and more in the user preferences, which provides the user with the power to make Nearby Tweets work better for them.
Speaking of user preferences, let's talk about how it works.
Implementing lazy registration in the UI
A user could never touch the user preferences screen, but still get nearly all of its advantages. How? Lazy registration is a growing UI trend wherein information about the user is stored to make a later registration simpler to complete by auto-completing known information.
Although Nearby Tweets has no registration per say, it does have a preferences page that allows a user registration-like advantages. The "lazy" part includes all the preferences the user sets without explicitly setting preferences there.
- Locations are automatically saved each time the user switches locations
- Keywords are automatically saved each time the user searches a location
- The main UI allows users to block people and locations
Although the user can manually set a default location for Nearby Tweets in user preferences, this isn't always necessary. Nearby Tweets attempts to find the user's location automatically, making the UI completely passive unless the user chooses to further customize Nearby Tweets.
Addressing user requests
Nearby Tweets doesn't always find the user's location, so users wanted to manually override the UI with whatever default location they chose. I thought about several ways to achieve this, such as adding a "set to default" checkmark beside each saved location, but I thought this would add a lot of links for a misunderstood function without being too verbose.
I settled on keeping the option to set a default in the user preferences. There I would have the space to make it clear how to set a default location. Each saved location can be set as the default location simply by checking the column marked "default."
Saved keywords and locations
I chose to use "recent" instead of "saved" because it more closely reflects the storing behavior of the "saved" locations and keywords. Keywords and locations are permanently saved like bookmarks, but rather they work like a browser's history.
The refresh rate of new tweets was something I had a difficult time with. I had to fight between several competing factors: If I make it too slow people will think that Nearby Tweets isn't working; If I make it too fast people won't be able to read the tweets, thus eliminating usefulness. After tweaking the auto-refresh rate and testing it with a few users, I found the balance to be 3 seconds, which is now the default.
Since not everybody reads at the same rate or thoroughness, the auto-refresh rate can be set in user preferences. Based on analytics the most common times after 3 seconds include 30 seconds, 10 seconds, 5 seconds, and 1 second.
I also had a difficult time deciding how to implement blocked locations, which works by comparing the tweeter's location against the blocked location. The problem arises when a user blocks the location "Columbus, Ohio" and the tweeter's location is "Columbus." Although a person can clearly see the two locations are the same, "Columbus, Ohio" is not equal to "Columbus" to a computer.
The question then is do I assume that the user intends to only block exact matches for "Columbus, Ohio" or all tweets in "Columbus"? To make the software intelligent, I developed it to extract the city name automatically. However, this is an issue when you have the same city name in two locations, such as Columbus, Ohio and Columbus, Georgia. Anyone in Columbus, Georgia who wants to blocks tweets only from Columbus, Ohio will block tweets from any city named incidentally named Columbus. I guess I'll have to keep my ears open to user complaints on this issue if it really becomes an issue at all.
Intended behaviors vs. Actual behaviors
It's one thing to influences behaviors through design, it's another to see what really happens. In my redesign of Nearby Tweets I took some questionable, albeit well thought out, usability risks by not following standard UI patterns.
I've found that Google Analytics is actually the best way to track user behavior, if you know what to do. I've setup my Google Analytics to individually track almost every user interaction with the UI. For example, I can see whether people are using typed locations, saved locations, or mapped locations. I can tell how many people set default locations, or delete saved locations. I can see it all.
As the above stats show, people are using the UI I built. 44% of the people that visit the site use some part of the UI, excluding visits to other pages. I'd like to increase that to at least half. Other people may be simply visiting the site and watching the Nearby Tweets stream, which is sufficient for me for now.