Users don’t read (more than 18%)

About 2 years ago Jakob Nielsen wrote an “Alertbox” titled How little do users read?. His research suggests that users will read only 18% of your content. Given that I spend a few minutes editing each sentence I write, that’s pretty deflating.

Since I reread this article a few days ago, I’ve been more sensitive to my own reading habits on the Web. And I’m just another statistic. I find that I read the first couple of paragraphs before I get distracted and scroll down for a call to action.

How to increase time on page?

Then I thought, what strategies can I apply to increase that number from 18%? How can I get my users to read more?

My solution is to set user expectations upfront with an estimated reading time for my articles. My hope is that I can influence users to interrupt article abandonment with the thought “well I know it’s only going to be 1 more minute to finish reading this thing, so I’ll just finish.”

Implementation of estimated reading time with PHP

I developed a PHP snippet that basically divides word count by 200 (avg. words per minute) to output minutes and use the remainder to calculate seconds. After adding this code, you’ll output something like, “Estimated reading time: 1 minute, 30 seconds”

1
2
3
4
5
6
7
8
9

<?php
$mycontent = $post->post_content; // wordpress users only
$word = str_word_count(strip_tags($mycontent));
$m = floor($word / 200);
$s = floor($word % 200 / (200 / 60));
$est = $m . ' minute' . ($m == 1 ? '' : 's') . ', ' . $s . ' second' . ($s == 1 ? '' : 's');
?>
 
<p>Estimated reading time: <?php echo $est; ?></p>

Making light of your website’s usability

After using this code on my own site, I was surprised to see my article’s average reading time was around 2 minutes and 30 seconds. So if I can increase my time on site to around that time, I’m doing pretty well. You might want to check your own analytics and compare against your article’s reading time s against time on site.

But if you do, beware of outliers—in this case people who leave your website open & bounces—that skew your time on site metric because most analytics calculate mean, not median.

Results

I’m still monitoring the implication of this design change on my own website. If you’re interested in an update when I know more, be sure to follow me on Twitter.

*UPDATE*

After testing my estimated time theory on nearly 3,000 visits, I have some results. Showing an estimated time improved time on site by 13.8%. What’s more interesting though—people either followed me, subscribed to my blog, or retweeted my articles 66.7% more often.

Related posts:

1. The more I know, the less I need: Thoughts on web design
2. Blog design best practice: Scrollbars not sidebars
3. Rethinking website navigation design

Lack of features, but not lack of success

Look at products like the iPod and the Flip. They are industry icons because they removed features and focused on simply solving the single, most important problem in their respective categories. For the iPod, Apple focused on the experience of listening to your own music. For the Flip, Pure Digital Technologies focused on the experience of recording movies. Every feature that didn’t address those problems directly was removed from the end product.

Benefits of removing features

Simplifies strategy translation

Each person on your team—from your product manager to your web developer—must apply a consistent strategy to their own roles to ensure that everybody is creating the same thing. If your team can’t easily define what that strategy is, how will your customers?

Simplifies marketing communications

Why does every brand try to encapsulate its differentiated value into a single slogan? Because users don’t have time to figure out complicated products or cryptic messages. To say “We solve XYZ problem better than anyone else” is the clearest and most compelling message possible. Feature lists on the other hand require that which a user is not willing to give: time to find the few features that apply to their own scenario and read the explanations of unknown features.

Reduces scope

Features are easier to cook up than they are to implement correctly, which requires not only resources for implementation, but a critical look at how new features will impact the architecture of the whole product. Just a few feature diversions and you may find yourself far from the original idea.

Decreases time to market

Simply put, features take extra time to build. Are you letting your competition get ahead?

Decreases support costs

If you’ve ever worked in customer support, you know the dread of being asked about a new or forgotten feature. Features add training costs and resource costs associated with handling additional call volume.

How to be a problem solver, not a feature inflator

Talk to your customers

Run your ideas by potential or existing customers. Get their feeling on your ideas. Find out whether they think your feature would help them solve a problem. Focus the conversation on their problem and not on your solution, which may falsely seem viable because they think it “sounds cool.” Look for an “a-ha” moment on your customer’s face.

• Survey your users with Survey Monkey or survey.io
• Run some usability tests with UserTesting or Silverback App
• Get design feedback with Usabilla or fivesecondtest
• Go to online forums, industry networking functions, and other places where your customers are talking about themselves.

Start with a minimum viable product

Minimum viable products contain only the features required by users to solve their problem. Everything else is trimmed off.

• What is the minimum viable product?
• 10 examples of a minimum viable product
• Minimum Viable Product: a guide
• The iPhone as a Minimum Viable Product Archetype

Conclusion

An actual user problem is a launch pad for innovation. Identifying and solving an actual user problem is the quickest path to a marketable product. But adding features because the technology looks shiny leads to product bloat and complication. To make sure you’re on the path of product enlightenment, talk to your customers, and concentrate on giving them the best solution to their biggest unsolved problems.

Related posts:

1. 9 compelling reasons to build a single-purpose website
2. Getting your clients to pay more for web services
3. Why some web apps are successful and others aren’t

A query string is the stuff after the question mark in URLs.

Why remove query strings?

In short: viral potential. Let me explain.

As many of you know, social sharing sites like delicious give URLs a “score,” whether it’s based on # of bookmarks, # of reviews, or whatever.

The important thing is that higher “scores” usually result in increased traffic to your site. For example: enough delicious bookmarks will eventually get you onto delicious.com/popular.

But query strings mess up things. On many social sharing sites, if I share http://briancray.com/ and someone else shares http://briancray.com/?query, the score will be attributed to two unique URLs instead of being recognized as the same URL.

Let’s see what happens when this unique URL problem is applied to delicious bookmarks:

Before the .htaccess hack

Delicious bookmarks are being attributed to two different URLs, even though they are the same page. Result: Not reaching delicious.com/popular despite having sufficient bookmarks

After the .htaccess hack

Query strings are removed from automatically so all bookmarks point to the exact same URL. Result: delicious.com/popular reached, traffic surge.

How to remove your query string with .htaccess

RewriteEngine On
RewriteCond %{QUERY_STRING} !="" #if there is a query string
RewriteCond %{QUERY_STRING} !^p=.* #wordpress users: allow post tempalinks
RewriteCond %{REQUEST_URI} !^/wp-admin.* #wordpress users: don't break admin
RewriteRule ^(.*)$ /$1? [R=301,L] #remove query string

Warnings

• THIS WILL BREAK ANY FUNCTIONALITY THAT DEPENDS ON QUERY STRINGS
• WordPress users: Put this code before the line # BEGIN WordPress in .htaccess
• This will break Google campaign tagging (the benefit out weighs the cost for me)

Conclusion

As most of you know, I don’t recommend writing articles purely to go viral. But if you’re writing good content like Jin Yang, Janko Jovanovic, or Antonio Lupetti, then you deserve all the credit that comes at you.

Related posts:

1. How to remove a specific value from a javascript array
2. Delicious.com loses its holy grail
3. Remove NULL values from PHP arrays with 1 line

Tailing blogging’s mainstream ascent were blogging templates, inspirational and roundup posts, and crap.

Everyday I see more crap clogging my Twitter stream and delicious iGoogle boxes. “Top 10 things widgets for your website.” “5,000 ways to do __________ in jQuery.” Well, it all wasn’t crap at one time. At one time it was somebody’s hard original work. But after the 50th article rounding up the same damn thing it’s suddenly crap.

When I visit an article that actually looks worthwhile I often think I’m looking at NETTUTS+ until I look at the header and see NETTUTS+ replaced by “Design insert cool word here.” WTF? I’ll tell you WTF. Clones with no original content.

Is there hope?

Yes. When I see articles by Paddy Donnelly, Dustin Curtis, and others spreading originality I get hopeful.

These bloggers understand what Steve Jobs understood when he was forcing his designers to trim buttons from window frames: What the user wants is inside the window and not the window itself. In other words, content is the experience for blog readers, and those who build great experiences around the content won’t be fly by nights.

But if your blog is just a clone that does roundups all month slapped on someone else’s design, you may be big today, but you’ll be forgotten tomorrow.

Related posts:

1. 10 signs of professional web design (Or why you should drop your amateur web designer)
2. Blogging Essentials: Why Do People Care What You Have To Say?
3. Blogging Essentials: 5 Tips For Better Readability

Design constraints

How does fitting dishes into cabinet space have parallels to web design? For starters it has the same design constraints: space and content. Somehow the dishes need to fit into limited cabinet space.

My cabinet organization design has users, too, and if my design isn’t working my kids put dishes on the wrong shelf. After a time the shelves turn into a chaotic mess filling what seems like a shrinking space.

Website designs are subject to the same problems. Somehow you have to fill website space with content in such a way that it “just works” for users. If your design isn’t a natural fit for its users, they won’t do what you want them to.

Iterative design

Because the design constraints of kitchen cabinet organization are more limiting than website design, I am forced to go through small iterative designs. I can’t make big design changes because I’m working with the same dishes in the same cabinet space. Should the beer mugs go with the tall glasses (both used to drink cold drinks) or should they go with the coffee mugs (both have handles)?

As I said earlier, website design is not much different. With each redesign we’re usually working with the same content in the same screen real estate. Unfortunately & fortunately, there’s a lot more design freedom with website design than there is with fitting dishes and cabinet space. Fortunately because using websites can be more engaging than grabbing dishes from a cabinet. Unfortunately because web designers tend to ignore the concept of iterative design.

Getting to the best website design for your users

About a month ago I finally found a cabinet organization that works. How do I know? Because my kids put away the dishes in the right place without my guidance. How’d I get there? Because of my design constraints I was forced to make small design changes over time with sufficient testing time. If I just randomly moved around dishes—the equivalent of a full website redesign—my kids would probably throw dishes at me when I entered the room.

To end at the most fitting website design you have to follow the same iterative process. Small design changes that are tested and measured. Don’t piss your users off by changing everything around. Improve.

Related posts:

1. 10 signs of professional web design (Or why you should drop your amateur web designer)
2. Needs assessment: the most important process in web design
3. Rethinking website navigation design

Bounce rate’s simplicity is both its greatest strength and its greatest weakness. Simplicity gives it the strength to be easy to read and measure over time. Its weakness is that it makes people lazy.

So lazy in fact that people are failing to ask the most important strategic question about measurement: Are my methods of measurement relevant?

Is bounce rate relevant?

In order to “knock bounce rate down a peg or two” we need to first clearly define it: Bounce rate is the percentage of users that leave on the first page they visit.

“The first page they visit.” Therein lies the problem.

Consider these 3 questions in which the bounce rate is actually counter-productive:

1. What if user engagement has nothing to do with multiple page views?

Let’s use a blog as a case in point. About a month ago I used Survey Monkey to survey my readers. The survey revealed that approximately 90% of my visitors came for one thing: to read an article. While this may not be the same in every case, I don’t think far from the center of the proverbial bell curve.

If users come to read an article, doesn’t it make sense that the time they spend reading the article is the correct form of measuring engagement? How many times do you read more than one article?

Sure, ideally content pulls visitors further into your site, but pull them in by understanding and designing to their intentions first. Otherwise you’re firing at the wrong target.

2. What if your conversion leads them to another site?

Many small to midsize ecommerce and micropayment sites use PayPal or Google Checkout to handle payments. Most web analytics software—including Google Analytics—only measure additional page views on your site, but isn’t checking out with PayPal a conversion?

Or what if you have a microsite designed for a specific campaign and you want visitors to jump to your brand’s main website. That jump, while a desirable effect on the surface, is reporting as a bounce! Oh no! You’ve been fooled!

3. What if you’re successfully converting users on the first page they visit?

Online support systems still rely on phones at the least as a last resort support function. Would you rather pay the support cost to take a phone call or lose a customer? Hopefully you’re in the latter group and make it easy for people to call you for support. And if your support is good, you’ve just built brand loyalty. But your bounce rate will tell you you’ve just lost a user. Oh no! Fooled again!

There are more examples of online calls to offline actions. What if you want your users to print out a coupon and/or visit your brick and mortar?

How to prevent being mislead by the bounce rate

Don’t let the bounce rate tell the story for you.

First, consider your website objectives and what your users intend to do. Hopefully those two compliment each other. Second, ask yourself how users will actually fulfill your objectives through a website. Finally, find metrics that measure user behavior that is relevant.

Related posts:

1. My secret to finding the best long-tail SEO keywords with web analytics
2. The more I know, the less I need: Thoughts on web design
3. Guidelines for highly effective Websites

The most important SEO factor in blogging is the title of your posts.

There, I said it.

Is it true? Yes. A post’s title is where everything good in this world starts—awareness, then popularity, then the mother load: keyword-rich inbound links. Yummy.

How to choose a good post title for SEO

Start with the right SEO keywords

What you think are the best SEO keywords for your blog post may not reflect what people are actually searching. Luckily, Google offers a tool called Google Insights for Search, in which you search for a keyword—like “SEO“—and it returns common & popular searches based on that keyword.

Here’s how to use Google Insights for Search to find the right SEO keywords:

1. Choose a topic for your post (if you usually miss this step for your own blog, just stop blogging).
2. Search the topic on Google Insights for Search to see popular keywords & searches related to that topic. For example, are people searching “blog SEO“? No. They’re actually searching “WordPress SEO.”
3. Write down all of the popular searches for that topic, filtering by geographic region if it’s relevant.
4. Google those keywords. Narrow down searches from the list created in step 3 that are a) relevant, b) popular, and c) the least competitive (don’t try to compete against the big boys if you can avoid it).

Front-load SEO keywords

Having the right keywords in your post titles is very important. Furthermore, you will increase your search engine ranking if you can front-load those keywords, which is a fancy way of saying, “put those keywords as the first words in your post title.”

Because web users usually scan the first few words of headlines, front-loaded keywords also gain the attention of qualified traffic that are scanning for keywords. Pre-qualified traffic usually provides a higher ROI.

Keep your post title under 65 characters

Over 65 characters and Google may cut off your post title with a masterful ellipsis (…), which makes you look bad in the search engine results pages (SERPs). Keeping your post title under 65 characters ensures people can see your full post title when they’re Googling.

Bad (full title cut off):

Good (full title displayed):

If you need a quick tool for testing your post title lengths, paste your draft title into Twitter’s tweet box and see if you have at least 75 characters still available in your tweet.

Set beginning of your <title> to the post title

While this is slightly off track from choosing the right post title, this plays a significant role in qualifying search engine traffic and increasing your search engine ranking.

Bad: <title>Brian’s blog | My good blog title</title>

Good: <title>My good blog title | Brian’s blog</title>

Best: <title>My good blog title</title>

SEO benefits of a good blog title

Good blog titles attract people

The more people that come to your blog, the increased opportunity that others will link to you. Plain & simple.

Good blog titles increase external link keyword density

Many external links to your blog posts will contain your post title, and keyword-focused anchor text from external links is the most important ranking factor.

Good blog titles increase search engine visibility

Using keywords based on actual searches increases your search engine visibility in natural long-tail searches, which comprises probably around 80% of your inbound search engine traffic.

Conclusion

In the past year I’ve gone from 100 monthly search engine visits to about 10,000 monthly search engine visits on this blog. How I’ve written my blog titles have played a significant role in that leap.

This post will be part of a new series on my blog, SEO for bloggers. Stay tuned if you like what you see. =)

Related posts:

1. My secret to finding the best long-tail SEO keywords with web analytics
2. Delicious.com loses its holy grail
3. 3 Detrimental Assumptions About Your Blog Readers That You Probably Make

What I’m learning may shock some of you, and it may confirm ideas for others. It’s not far from what I’ve blogged about in the past: Supplemental navigation is, in most cases, visual junk.

Breakdown of link clicks by area

Interpreting the chart data

As you can see, supplemental navigation—including related posts, historical post navigation, popular posts, most commented posts, sidebars, etc—has accounted for about only 10% of the navigation on my site during several design variations. Of that 10%, historical navigation and related posts alone accounted for about 99%. The rest? Fluff. Garbage.

On the other hand, navigation inside the content area accounted for approximately 70% of clicked links on my site. Header navigation, including menu, logo, search, accounted for 30%.

Design implications of data

In short: less is more.

If you visit almost any blog today, you’ll be bombarded with 5,000 sidebar widgets, gadgets, and gizmos that are there to do what? Lower the bounce rate by increasing page views? Is that an actionable metric? No.

Blogs should be especially ashamed of these design practices, because the user’s goal is clear in 99% of the time: Read an article.

And the conversions are clear: subscribe, comment, share.

Those conversions are getting lost in too much choice and information overload. Do you want your users to subscribe, or do you want them to get lost in a sea of sidebar gadgets?

If the Paradox of Choice has taught us anything, it’s that how many choices you provide to users is a serious issue you should confront with every design decision.

Actionable design recommendations

1. Start tracking exactly how your users are navigating your site. If you don’t know how, here’s a good place to start.
2. Apps like Readability and WriteRoom exist for a reason: Distractions suck. Eliminate low performing navigation options to increase the performance of effective navigation and user goal completion rates.
3. Integrate important navigation into your content. Don’t leave it off to the side where it’s unnatural for people to look.
4. Focus on what you want your design to achieve. Don’t focus on inflating your stats and ego with page views or lower bounce rates.

Conclusion

Using information to make design decisions is something that should be practiced more in the web design community. In this case, a little data has provided a significant argument against a common blog design practice. What else could we be doing wrong or could we improve?

I think we’ll also find what works better for our users, also works better for our conversion rates. Please share your thoughts or data on the subject.

Related posts:

1. Rethinking website navigation design
2. Blog design best practice: Scrollbars not sidebars
3. Estimated reading time in web design

“Code, code, code, blah, blah, blah.”

Two people, one a web analytics professional, the other a web developer, awkwardly sip coffee across from each other at a small cafe table that feels like a vast expanse. Their professional focuses seem not to hit any harmonious tones.

Then it happens. The internet marketer asks the question: “Do you know what an API is by any chance?”

“Yea, sure. Why?”

“I was reading about new stuff in Google Analytics, things like being able to track things other than page views, like when a user plays a video. Apparently you can also build user segments in real-time. But it said something about an API, and I gave up. Maybe I’ll look at it later when I have the time.”

“Well, I know how to use APIs, maybe I could help!” Relieved, the web developer realizes they do have something in common.

Over the next few hours they pour over the tracking API documentation together and realize the potential of their combined skill sets as they discuss advanced campaign tracking, event tracking, and real-time visitor segmenting.

A month later the company knows more about its online customers and their behaviors/preferences than they could have imagined. A year later they are numero uno in their industry.

This is a classic problem between engineering and marketing. They can do so much together if they could just focus on outcomes instead of differences.

Promote interdisciplinary dialogue in your company. Get people to open up and share what they know across disciplinary lines.

Get your customer service reps talking to your copywriters. Get your social media marketers talking to your web analytics folks. Hell, get your direct mail marketers talking to your web developers. Truly innovate.

Related posts:

1. Diving deep into user behavior with Google Analytics, Event Tracking, and jQuery
2. Does your website add features or solve problems?
3. Is your Google Analytics missing page views? Introducing Asynchronous Tracking

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

1. Default location
2. Saved keywords and locations
3. Pullout drawer was annoying
4. Manual directory
5. Mobile version
6. Auto-refresh tweets
7. Block users
8. Block locations
9. 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:

1. 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.
2. 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.
3. 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.

Tweet options

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.

User preferences

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.

Passive preferences

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

Default location

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

Default location

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.

Auto-refreshing tweets

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.

Block users

Block locations

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.

Follow feature

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.

That’s it!

I hope you enjoyed this little run down of my redesign process of Nearby Tweets. Please share your ideas, thoughts, and feedback. How would you have done things differently? Has this helped you do anything different in the future?

And if you haven’t already, be sure to pay Nearby Tweets a visit and share it with your Twitter network

No related posts.