User Interface: customize or not - that is the question

In my blog post Customizing iOS app interface elements, a guy wrote me his view on the matter:

"I am a fan of integration with the OS and not having apps that differ strongly from the core experience."

Customizing iOS application look is a very common practice among iOS developers. Apple seems  at ease with that too judging from applications being currently on the App Store. For a small overview of application user interface custom designs, here is a summary look at Designs I like on Posterous, a visual blog of iOS app designs that beg to differ from Apple Human Interface Guidelines. 

There are so many iOs apps with custom user interface designs

Apple's Humain Interface Guidelines (HIG) are... guidelines. If we read these thoroughly, we can find many references to Apple's own design choices in order to explain a point of view or give an example. Those are in fact, guidelines, not rules. Why you may ask? Because there is no final answer to a user interaction problem. One question and you can get a thousand answers. To me, Apple's own builtin applications serves two purposes: answer a basic need of the user of the iOS device and express a statement of how an iOS application should behave for a specific task or context. This is in no way a final answer. I'm pretty sure Apple's designers are submerged with many hundred design choices that they review before making a final decision.

If customizing a user interface element like a UITabbar with a different background for example might be a good thing as long as the basic behaviour and design are still there, I don't see a problem with that and I hope Apple doesn't too. From the user stand point, the behaviour being the same, there behavioural knowledge is still valid. From the iOS developer and designer point of view, this is a way to be on the edge by being special and different, just a bit.

Great example of custom design of standard UI elements

A UITabbar, a UINavigationBar are basic blocks of construction for me in iOS user interface visual and behavioural language. One can paint a UITabbar or UINavigationBar in a different colour and this is still in line with Apple's HIG. Being just exactly the same as Apple's core application is being kind of dull and at some point is not really a good thing if, as developers or designers, we want to stand out. Looking at many examples like Gift Plan is a very good way to understand how being different from the core can be quite a good thing for the user experience with the application and a very good thing for the developers as they are very successful.

Gift Plan app is a very successful custom design of standard UI elements

Finally, I think to some degree that having a way to express variations of a basic UI element is a sign of life of the platform. iOS is pretty young and there is so much to be done from a UI point of view. I look carefully at many apps and I find sometimes that most of the apps limit themselves so much on basic user interaction vocabulary. This is so obvious on the iPad: with that kind of screen space, much more could be done with gestures. Some apps are very unique in that respect, Reeder is one of them. Try it, you'll quickly notice what I'm talking about. This desire to create new ways of interacting with our devices like the iPhone makes new things possible and widely successful. Another example of this is the famous "Pull to refresh" action that many application with list content can be refreshed just by pulling and releasing it. A very subtle gesture with no visual overloading of the user interface. 

So, what do you think? what are your thoughts on this?

Customizing iOS app interface elements

I've been quite busy recently working on the next release of Ultimate Password Manager, version 3.0. Right now I'm doing a lot on user interface element customization. My goal was to make the app a little bit more appealing by creating a custom look.

The interface elements I've been working on are:

1. UITableViewCell - I'm using a subclass of UITableViewCell to customize its background in a plain UITableView. I'm also adding a hidden UIView in order to create the red and yellow stripes for expired or expiring password safe entries. Those were made in Pixelmator 1.6.1.
2. UINavigationBar - I'm doing a UINavigation category to replace the drawRect method added to the App Delegate .m file. the UIImage was done in Pixelmator 1.6.1.
3. UITableView section header views - I'm using custom UIViews that I'm return with the standard viewForHeaderInSection. The UIView is built in interface builder.
4. UITabbar - Made a subclass of UITabbarController in order to replace the viewDidLoad method. The image was done in Pixelmator 1.6.1.
5. UITableView - I'm adding gradient to the top and bottom cells of the plain UITableView. The gradient is done programmatically. This is done with a subclassing of UITableView with a subclassed layoutSubviews. 

For example, here is the process to create the new UITabbar background.

Create a picture with a 320 x 48 pixels.

Add a gradient

Add a noise texture

Save and export as .png and import in Xcode

And the final result. How do like this?

Great resources at unexpected places

Do you know Bjango? Bjango is a software maker that has many applications already available for the Mac, iPhone and iPad like Consume, iStat Menus, etc. But, they also have a great Articles section on their web site. For an iOS developer looking for tips on iOS app user interface design and many other great articles, this is a very enlightening place to go!

A very nice piece of iOS software

As you may know, I'm maintaining a blog on Posterous (http://buildingiphoneapps.posterous.com) that gets updated every once in a while with screen shots of applications that I really like. Today I came across Airbnb. This app lets "Rent a place to stay" as they say on their web site. I felt in love with its design and I post here a few screen shots.

Read more on Posterous. 

Tap & Hold: how do we tell the users?

Here is an interesting user interface design question.

As application designers,  if a UITableView supports "Tap and Hold" gesture on its cells to apply an action on that specific cell, should we say so visually? If the application designer decide to answer yes to this question, the next one is: how does the application convey this "feature"? Otherwise, if the answer is no, could the user miss important application functionalities?

As software developers, not as designers, we tend to be wordy or base our decisions on anxiety: what if the user cannot see that? OK, I'll tell him! What if the user cannot see that? I'll make it bigger and with a different colour. What if... well, you get the idea. I call this design based on anxiety.

Let's look at an example. Osfoora: in this Twitter client, a user can tap and hold a cell in order to apply an action on a twitter message. There is no place where the user is invited to do this gesture. Is this an Apple sanctioned user interface design choice? I cannot remember any standard iPhone app made by Apple with this user interface interaction model. A similar issue also applies to swiping a table cell. Apple seems to be on the wordy side with the App Store Genius feature as shown on the following screen shot ("swipe to remove an item").

There are plenty of places on the web with "detecting tap and hold on uitableview" on a table cell. So there is a real need for this. What are the options for telling the user about this gesture availability?

1. An header of footer with text could be included.
2. The first or last cell of the table could include a mention of this capability.
3. A dummy section title could include a mention of this capability.
4. A mention in the background of the table

Scenario 1 - header or footer.
In the case, visually this is cool for the first time user: they get to know quickly that this application supports "tap and hold" on a cell for specific features. But, over time, experienced users don't need to be reminded very time he or she uses the application. So this table header or table footer becomes useless and take visual space. On the technical side, this implementation is very easy to do as UITableView provides a way to set the header or footer from a UIView.

Scenario 2 - in-table cell.

In this scenario, which seems to be very close to the previous one is only a technical implementation choice. And this is a bad implementation choice because it makes things harder to manage when presenting table content. We need to take into account a specific row that isn't a real one. Scenario 1 is better technically speaking.

Scenario 3 - table section.
In this scenario, we don't have to make any special treatment for a dummy table cell with explanation text. We only have to set a title for a section and we're all set. Visually, this could look better as the section title stays always at the top position of the table when the user scroll the table content. But, this become again an artifact and make this implementation a bad choice too.

Scenario 4 - table background text.
This one is kind of a compromise. When the table is empty, the user sees an explanation text that says "hey, you will be able to tap any cell and hold it in order to bring new features applied to that cell". As the table content grows, the users won't see this text forever because the table content will be over the explanation text. Technically, this is very simple to implement.

The final word is this: the "tap and hold" gesture on table cells becomes more and more available in applications. It doesn't seems to be an Apple sanctioned way of interacting with table but like "pull to refresh", users will start to try this gesture and see if the application react or not.

What are your thoughts? How did you implement "tap and hold" in your apps?

Icon designs - come on guys!

I'm currently writing a big post a prototyping tools for developers and designers. While searching in the App Store, I came across what seems to be a general trend: very bad icon designs. Besides bad colour choices or actual bad graphical design with no attention to details, one of the thing that I cannot stand is those icons with text. Take this for example:

Dear icon designers whoever you are, these icons sucks big time! They really do. They are awful. On an iPhone home screen, they become even more ugly. We can't read the text on them! And we don't have to! So remove it! Don't repeat the application name in the icon itself! You know what? Look at Apple's featured apps, they rarely choose apps with bad icon design like this!

Now, look at these icons:

Can you see the difference? If you can't then I'm afraid you doing the wrong job. Ask a real designer. If you can't pay for a real designer, then keep it simple and just don't put text on icons!

iOS app designs that I like - a summary view

A few days ago I wrote a blog about a different way of saying what I really like. This was all about iOS apps designs that I like or love very much. A different way of saying what I really like

If you want to see a consolidated view of designs that I'm talking about, beside going to http://buildingiphoneapps.posterous.com, you can go on flickr at http://www.flickr.com/photos/buildingiphoneapps/

A different way of saying what I really like

As an iOS developer, I spend quite some time in iOS applications as a user. Many apps are very ugly but a lot are also very nicely done from a user interface design point of view. These applications are a source of inspiration to me.

Recently I was looking for ways to gather screen shots of these applications. As you may already know (if you had a look at my page "Tools that I'm using"), I'm using Little Snapper to gather lot of graphical stuff: part of web pages, part of screen design, widgets, etc. So I started to gather iOS app screen shots taken from my iPhone and put into Little Snapper library.

Today, I decided to publish these screen shots accompanied with a brief description of the things that I like in those designs. I wanted to tell you, iOS developers, what I like about these apps from a user interface graphical design point of view. Also, each post will be tagged with different keywords describing the elements that I'm referring to in these shots.

Where can you find these posts? On Posterous at http://buildingiphoneapps.posterous.com. You notice new posting by following me on Twitter at @jfmartin67 as each post will appear as "I like {insert application name here}. Here is why" tag line. If you are a Posterous user, you could also follow the blog directly from the service or finally by subscribing to the Building iPhone Apps Posterous RSS feed. Right now, there is already many posts that you can peek at.

Meanwhile, here is the look of this my new Posterous blog.

Finally, recently I started to work part time on a "secret project" of another iOS app. I will need design inspiration. I will need to explain to a graphical designer what I like about iOS apps for UI design. These shots will eventually be used for a presentation to a graphic designer about my user interface design tastes.

So, what do you think of all this? Do you have nice design that you want to share? Send me your screen shots and I'll see if these fit my own personal taste and could be published as well as a result.

Using others artworks - bad idea?

I've been using extensively artworks from different sources for Ultimate Password Manager. Tabbar icons, in-cell left-side icons we're mostly taken from free resources on the web:

• www.glyphish.com: very well done tabbar icons. Free. Many App Store application are using one or many of these icons. 
• www.app-bits.com: nice icons too. This web site is so gorgeous. So are the icons. 

Problem is, what to do when we want to have Retina Display versions of these icons? We are pretty much in a bad situation as the authors may not have a version updated for higher resolution display. I know about glyphish.com which create a lot of new icons but for old one, they are not all Retina Display ready. This leaves me the task of rebuilding myself all my icons. This is not cool because, I'm not a graphic designer. 

What's wrong with GoodReader for iPad

Since the launch of the iPad, one of the most talked about application is GoodReader for iPad. Right now, as I write this blog post, it is currently in #1 position in the Canadian App Store. Apple even made promotion on it!

It seems that people loves the software judging by the reviews:

But, is this software that good? I myself bought the software for my iPad as I need a good PDF reader and I was curious to see if customer reviews were in line with the software quality.

First, on the functionality side, I find it to be effectively good as it allows to fetch documents from an URL or allow syncing those in wifi or with the new File Sharing support for iPad. But, sometimes, good functionality can be easily overshadowed with really bad user interface design. GoodReader for iPad is one of those. Here is why.

First, GoodReader user interface is too wordy. As this is shown in the following option panel.

Also, we shouldn't use table section names to tell the users what to do or what's for.

I feel the developer of the application is not sure of the effectiveness of the user interface design so he tries to explain it everywhere he can in the application. To me, this is some kind of design failure as the application user interface look and feel should speak for itself.

The preview of PDF documents is at the very least confusing. On the following screenshot, at the top right there is a toggle switch that seems to activate the preview functionality. At the bottom there is a button (ugly button, non standard if you ask me) to kind of turn off the preview. This is awkward. Why not give the users the preview option but only in the application settings.

Also, the application is designed with table on the right that shows functions which is not the best way for me. The worst is when selecting "Manage files" where a bunch of buttons will appear if the user select a document on the right. Again, the wordy elements: 1 item selected, no item in the clipboard. This should all be obvious. If the Paste button is disabled it should be because the clipboard is empty. Right? The grouping of the buttons is visually bad and way too crowded.

So GoodReader for iPad is right on functionalities but very bad in user interface design. Users seems to not care about that and this make me sad.

A final note: iBooks 1.1 will include PDF reader functionality. Having a single application for book reading and PDF reading is a plus for me. And, iBooks is much more well designed than GoodReader. Unless they make bold moves in the coming months, I don't really see a bright future for this app on my iPad. Sorry.