As mentioned in my first post, the purpose of leveraging existing design patterns is to make your designs approachable and as simple as possible to intuit by users. By that same token, if you take a pre-defined feature or interaction pattern and change the way it behaves then you are intentionally teaching your users to no longer trust that interaction. Thereby introducing doubt on any further uses of that feature by the user, in yours or other applications. Additionally, failing to use the feature or guideline correctly limits your options when implementing features. In this case there is a specific instance I want to discuss. The Navigation Bar.

iOS Human Interface Guidelines – Navigation Bars

Avoid crowding a navigation bar with additional controls, even if there appears to be enough space. The navigation bar should contain no more than a view’s current title, the back button, and one control that manages the view’s contents.

Accounts List (Correct Use)

The HIG here tries to be clear about the navigation bar, but at times companies ignore some or all of these guidelines. I want to focus on two in particular.

View’s Current Title
A common abuse of the navigation bar begins with marketing. Like any stake holder in a company, marketing wants to have a say in the design of an applications, and that usually entails making sure that the company brand is upfront and in people’s faces as long as possible to cement the product.  The effectiveness of this tactic is debatable in other platforms or web applications, but for iOS specifically this technique is unnecessary and intrusive. Step back for a moment and think about how your user reaches the screen in question.

1. Lauch App Store by finding icon and tapping it. 2-3 seconds.
2. Tap Search. 1 second.
3. Enter in the name of the application. 5-10 seconds.
4. Wait for list of results. 3-5 seconds.
5. Scroll through list of results. 3-5 seconds.
6. Select application from the list. 1 second.
7. Tap Install icon. 2-3 seconds.
8. Wait for application to download. 2-10 minutes.
9. Tap application icon.
10. See opening screen.

Total Time: 2:17-10:17 minutes

By the time the user sees the branding or logo in the navigation bar they have already invested a great deal of time to get there. The user knows the name of your company or product pretty well by then. Each additional use of your logo in the title bar of the application only serves to reduce the usefulness of the screens it appears on, as you can no longer display the view’s current title. This is the mobile equivalent of screaming your companies name at your customer as they walk in the door of your store, and every few minutes after that. It is not necessary. Using the above example when talking to stake holders can help to combat this requirement. It is not necessary for every screen to bare the burden of selling the product or brand to the user. To the contrary by the time the user has the app in hand, you’ve already succeeded at selling them. Now it’s time to keep them through rewarding and intuitive interaction.

Additional Controls
The second common mistake when dealing with navigation bars centers around the use of the additional control. Referring back to the HIG the additional control is intended be contextual, and directly connected to the view’s state and purpose. What that means is that the upper right hand control is always a direct action to start or end a task or a flow. For for sending an email, or adding a note. These buttons are directly relevant to the task at this very moment.

Logoff is not relevant to managing alerts (Wrong use)

In the example here we see a screen deep into a flow of the application related to managing a user’s alerts. The navigation bar in this case is being abused in two ways, as it is missing a title and has a button that is irrelevant to the task at hand. Not only is it difficult to identify the purpose of this screen without a title, but it’s not clear how we proceed of effectively complete this task.

Now it might be argued that Log Off is a relevant action at all times because the user must be able to disconnect from their banking session at any time. While I admit that it is imperative that users be able to disconnect. The placement of that functionality should be at the top level of each main task listed in the tab bar, because at the top level the user is not in a flow, or in the middle of a task. Additionally if the application is written appropriately then not only should pressing the home button end the session, but also the power button and, a timeout. Putting a log off button at the top of every screen is the mobile equivalent of welcoming your customer, and showing them the door at every opportunity, instead of trying to help them accomplish the task they came in for. Use that space effectively, instead of crippling your application by reserving that space for a single unrelated task.

Conclusion

When building an application there are often many stakeholders, each trying to make sure their considerations are being heard and addressed. Sometimes it takes time to explain why certain design considerations are made, but above all it’s important to remember that every departure from accepted and expected interface patterns leaves your user in the dark as to how to proceed, and negatively trains them to second guess their own expectations when it comes to your application. Use the navigation bar effectively and as intended to maximize it, and your applications usefulness.

So let’s get started. SEO or Search Engine Optimization is a practice by which a site is designed so that it makes crawling and categorization easy for a search engine. Google especially has many rules and techniques it uses to distill your site and its pages down to quantifiable keywords that can then be searched. What SEO attempts to do is get the highest context for your coding effort, but when used over judiciously you reduce the effectiveness and simplicity of your design. In this instance I was told that to make sure all the metadata about an item was properly categorized it HAD to be visible on the page. This made the page bloated and complex.

The problem here is that first and foremost your user needs to be your focus, not a search engine. By coding a site for a search engine you begin to make certain design compromises that reduce the simplicity of your site and run the risk of losing that user.

Things to do when taking SEO into account

- Not every piece of information about an item must be visible at all times. Use CSS and some interface to effectively hide element when not needed, but keep them clearly defined and visible in you pages HTML.

- Include proper meta tagging and keywords in the page. If your site stores and serves up content that is user produced then provide a facility for effective tagging by the user.

- Design for the user, and they will come. If your service is looking to fill a niche in the market, then make it usable and enjoyable to interact with. Word of mouth will spread, and usership will increase. If you merely expect incoming traffic from searches than your product focus is misplaced.

- Make your own sites search engine robust. You know your business and data better than Google, so make sure that finding the content through your own site is the best experience.

Conclusion

You are defined by your content, not Google. Users will come if your site is focused, simple and effective. And if bad UI is necessary to propel or protect your business interests, then you don’t understand your customer. The sooner your competitors come up to speed with a better experience, you’re gonna lose your niche.

1. Is registration necessary to get started making use of the site?

As I discussed in my last post, do not force new users into registering to get a good feel for what your site has to offer. Allow a new user to search, browse, take a tour, etc. Offer them a taste of what being a registered user is like, and it will insure that their invested energy will be rewarded. I see large companies often requiring registration to access demos or videos of products on their sites, and obviously this is so that someone in sales can then hound the person later, but it’s generally a bad way to get someone interested in your product. The more freely available information the better.

2. Is this field necessary?

Once you’ve decided to go through with creating a registration flow how much do you really need to know up front? To get a user sufficiently authenticated in a system the littlest you should need is E-Mail and password. Anything other than that should have an immediate and perceivable value to the user. Fields that can fall under that category all depend on the purpose and focus of the site. For example, if your site has a strong user interaction component you’ll probably want to add a Username and a custom user icon. By contrast you should hardly ever have to capture a users phone number, mailing address, credit card, gender, birthdate, or other contacts to complete registration unless that data will be immediately used after the registration is complete.

3. How does filling this field help the user?

What will the field do in your system later, and how it will affect the users interaction with your site? For example uploading a custom user icon will help the user differentiate themselves from each other and creates a greater sense of community and interaction. Where as being required to enter your zip code may not immediately translate to a better user experience. Your registration flow should contain only those fields that will be of immediate usefulness.

4. How often will you use the data in this field?

Consider that if you will only use the information once or twice in that users history then perhaps it is superfluous. For example if you ask for birthdate merely to send the user a special offer once a year perhaps you could retune that to send the user a special offer after a period of inactivity to bring them back, or after certain purchasing activity. Sometimes marketing will demand that things like gender be a part of the registration so that profiling data can be extracted and trends determined.

5. Can you intuit this information another way?

When requiring a user to enter things like address what are the necessary fields for your needs or the users? Is it important to have their exact street address, or will a zip code suffice? Once you have the street address and zip code do you really need a user to enter a City and State, or even a phone number area code? Can you infer anything from the information your requiring be entered, or from any other future activity?

6. Is there a drawback to postponing the entry of this information?

Registration should be a quick in and quick out procedure. If your site is an online store for example and the registration is not being done as part of the ordering process then postpone the entry of things like delivery address and credit card information. Once registered your user will go straight to shopping, and once the checkout process has begun then ask for that information.

7. Does the format of this information have to be strict?

Once you’ve added a field into the registration flow you want to look into how you’re asking for this information. Phone numbers and addresses are notorious for this. For example a phone number doesn’t require anything apart from numbers. So forcing a format such as xxx-xxx-xxxx or (xxx) xxx-xxxx or separating each section into a separate field is just more infuriating to a user. Many browsers now do form autofilling, and Safari for instance uses the format that I specify in my International settings and my address book so numbers get filled in like xxx.xxx.xxxx and often registration process will balk at that. Addresses as well should be as freeform as possible, allowing users to enter addresses in whatever way they see fit and the code should be able to parse that at any time to determine things like City, State, Zip, etc. You’ll find that 10 extra minutes spent on the back end will save your users time and frustration.

Final things to consider

Confirming the user as human.

A little girl holds a stuffed bear.

Many sites use a scrambled text algorithm to ensure that whatever is going through the registration flow is in fact human. This is sadly just another blocker, and a tough one at that. At times the scrambled text is mistaken for something else, forcing a retry and increasing frustration levels. And determined parties will always be working on a better detection algorithm, and thus the cycle never ends. What’s gone untapped here are the myriad of other ways to test for humanity. Seeing as computers at the moment cannot understand concepts, it should be those that we can test against. For example, you see a photo of a little girl hugging a bear, and the challenge question is “This girl loves her ______”. Not only can the computer not recognize the girl, bear, or the concept of love as depicted there is no way for it to be able to fill in that field and continue.

Frogs of every color

Another example, you see a photo of differently colored frogs, some red, yellow and green, here the challenge question is “How many yellow ducks are pictured here?”. Obviously the answer would be zero. But a computer cannot tell a frog from a duck and even if it were looking for only yellow items it would see that there are some yellow entities in the photo and match those.

Untimely fate for this balloon?

Another example, you see a photo of a balloon and a hand with a pin about to pop the balloon, here the question is “How many balloons are about to be popped?”. Just as before the computer cannot recognize the shape as a balloon and even if it could, would not understand the concept that a hand and pin might end with that balloon popping. Now you’ll never keep spammers or hackers from registering accounts manually and then latching their software onto the profiles, but at least in this method the challenge response is less frustrating and complex to a user because it exercises a core part of our brain and requires little energy to solve.

Conclusion

User registration is an unfortunate necessity, but there is no reason it cannot be simple and rewarding to complete. Keep your required questions short and concise and let the user enter data in a quick and freeform a way as can be afforded. Leave the inquisition out of it and intuit information where possible.

A blocker in action

Take for instance our last example from Slideshare.net. In this example we have already logged in and clicked the ‘Favorite’ button on a slideshow. That is our invested energy, and so our return should be a “Favorited” item. Instead our return is another panel that requires a further investment of energy. Therefore the simplicity of this interaction is 2:1. And the more interactions on your site that require more energy than they give will begin to frustrate the user and quite possibly could lose that user.

Apple Store - Share requires a sign-in

Another perfect example of a blocker is the “surprise sign-in”. Certain sites have searches or actions that should not require a valid user account, but when clicking on those actions you are immediately taken to a sign-in page or a registration page. This is the quickest way to lose a user who may not already be a member of your site or at the very least lose the users interest in that interaction.

Now that we understand what a blocker is we can start to look at ways of removing those blockers.

Click Counting

Click counting is the method of counting how many clicks it takes a user to get from point A to point B. The lower the better. Just be careful not to trade clicks for confusion.

Ratio

Follow the formula above to determine the energy to return ratio, but be wary to not overdo the return to energy ratio either.

User Testing

Also don’t hesitate to put the interface or interaction in front of a user who has never seen the site and ask them to explain to you how to accomplish certain tasks. Your design should be intuitive and self explanatory.

Conclusion

A block can come in many forms but in each you risk confusing and alienating your user. The site design and interaction should flow effortlessly from action to action so keep an eye on each button and element. And don’t forget to test and test again until it is smooth for someone with zero experience with the site.

Now leveraging in the tech and design worlds is just a word that means you’re taking advantage of pre-existing information. What’s important to remember is that as a designer it is not always necessary to recreate something new. In fact some of the most well received products and services are things that share a common thread with something we as the user are already familiar with. This seems like an easy concept but so often companies fall short of this when building a web application.

I have a feeling I’ll be coming back to the iPod often but stay with me.

Image taken from iPod interface patent.

The original iPod and every subsequent iPod (excluding the iPhone and iPod Touch) follow this very simple hierarchical navigation.

Music->Artists->Artist->Albums->Songs

Music->Genres->Artists->Artist->Albums->Songs

Music->Albums->Songs

By now I assume this navigation is familiar to you and I shouldn’t have to explain the simplicity of how well it works. The click wheel makes it easy to zoom through this navigation and find what you what. Now lets say for example that you are about to introduce a new feature into the iPod that will require navigation. It makes little sense to attempt to create a new interface for navigation. The user has already learned and become an expert at the navigation you have created. Leveraging that implicitly learned skill is paramount.

A screenshot of the iPod application from the iPhone & iPod Touch

Now lets take the iPod interface of the iPhone (and iPod Touch) into account. The addition of the tab bar at the bottom of this interface takes your second level of navigation from the former example and creates starting points for them, and adds the ability to customize those starting points. The bottom tab bar is used in multiple applications throughout the iPhone so its not particularly necessary to use the same navigation. Take Clock for instance where each tab is a separate time related task. But the idea here is that at least with the iPhone when it comes to navigating a library of content, it is in an application developers best interest to mirror that pre-existing interface conventions and leverage that experience. Your application will carry the air of a first class iPhone citizen and your users will not be shaken by having to learn a new navigation scheme. This increases simplicity across the board.

So now that we have that concept in hand lets look at another example.

“Favoriting”

I realize it’s a made up word but it has become prevalent enough that I’m totally willing to accept it as a proper verb. Moving on … ”Favoriting” something is a perfect example of an interaction people use on a regular basis across sites and it has a very expected interaction.

1. Find Favorite button
2. Click Favorite button
3. Item is “Favorited”

Favorite?

Sites that share this interaction such as YouTube, Flickr, Digg (login is usually required to favorite) all leverage that interaction and thus overall simplicity is maintained. However sites that make this interaction difficult such as SlideShare lose all that pre-existing knowledge and thus create complexity and difficulty for a user. In this image we see what happens when a logged in user clicks the Favorite button. They are immediately presented with the option to add tags to the content. Now I see nothing wrong with adding tags, tags are good (but that’s another post). But here we are halted from our original action. Not only that but we are unsure if we even successfully “Favorited” the item. Here only by clicking “Save” do we get the action we were initially going for, requiring one more action. Also as an aside its interesting to note that there is no apparent area to add tags to content on Slideshare without “favoriting” a piece of content.

Conclusion

Leverage simple pre-existing design and interaction concepts. Your site (product, service, etc.) is not in a world unto itself and therefore has the opportunity to leverage pre-existing behaviors that users have already invested energy in learning. When introducing a feature look at other examples of that feature, and for where you can leverage others designs. Your users will thank you.

The story behind the name “Agent of Simplicity” is a simple one. One sunny April day in 2008 I had an epiphany about life and all of its interactions, and that epiphany was that simplicity was the answer to all the drama and problems that we as people encounter in our lives. Humans strive in everything to convert complexity into simplicity and get very real satisfaction when they achieve that goal. Not only that but humans also derive pleasure from experiencing simplicity, whether it be in a product, service or personal interaction. Take the iPod for example. The iPod converts the complex task of managing a large music library into a simple task. That formula follows for pretty much all Apple products (at least in intention) and other companies who follow that model are very successful (ie: Google, YouTube, Flickr, WordPress, etc). So I became an agent of this force, not a master of it, at least not yet.

So what I will be sharing with you is examples of sites that follow the simplicity model, and more importantly sites that need improvement and have forgotten some of the key rules of web design and development.

Please stay tuned for more.