Design Guidelines for Touch Screen Interfaces

Touch screens are no longer a novelty interface in the field of human computer interaction. They have infiltrated consumer products as well as enterprise ones; they are used not only in mobile devices, but also the most stationary of devices. Due to direct manipulation, touch screens are independent of most of the tools we thought we could never part with: keyboard, mouse, stylus, etc.

However, this sacrifice does come with tradeoffs. Traditional keyboards provide tactile feedback and allow people to type at speeds much greater than touch screen keyboards. Mice move pointers at accelerated rates that mimic our own visual saccades; whereas with a touch screen interface, we are limited by having to traverse full physical distance with our hand.

These limitations are actually the result of, or rather the evidence of, the infancy of the touch screen interface. Once this specialized interface is optimized for our own cognitive and physical abilities and limitations, the touch screen interface may flourish. In this article, I attempt to provide guidelines taking into account some of the factors I have already mentioned.

1. The Finger

Points of interaction must be large enough to be pushed by a finger. This is best done by a graphic-rich icon. There should be enough clearance on all sides to prevent accidental touches but at the same time the hot spot should be well placed. Precision should not be taken for granted, such as with mouse, point-and-click activities.

2. Text

Text should be used as a label and rarely, if ever, used as a hyperlink. Since touch screens are used up close, even closer than computer screens, text does not need to be significantly enlarged or magnified.

3. Information

These interfaces should solely be used for quick retrieval of bite-sized information easily accessible through efficient navigation. Devices that employ touch screens leave the user most often in an uncomfortable state (standing in front of a kiosk with neck bent, holding a mobile device in one hand while interacting with the device with the other hand). Due to these awkward positions, one should assume and design interfaces that do not afford reading long passages.

4. Navigation

Navigation and action buttons should be laid out in consistent areas of the screen. At the top level screens, designs can and should be more flexible and creative in style, placement, and size. In deeper level screens, navigation should be laid out on the top or side portions first with action buttons better suited to the left or center portions (depending on availability of screen space).

Interview: Erik Hersman (WhiteAfrican.com)

Erik Hersman is the Cornucopia of compelling Africa-oriented web content. He has offered insightful anecdotes and perspectives on the place "where Africa and technology collide" for years (quote from Erik's blog).

He has experience in Web strategy as a technologist, and experience with the juxtaposition of "developed" and "developing" regions--as a past or present resident in both.

This combination makes him an ideal spokesman for The UI Thread's ongoing inquiry into the 'how' and 'why' of Bespoke UI for Developing Regions.

Erik was kind enough to answer our questions over email, offering a tenured voice and interesting perspective.

Interview with Erik Hersman

UIT - The topic has to do with the current state of affairs of 'home grown' User
Interfaces for Africa. Everyone knows there's lots of hype around mobile these
days...but there are surprisingly few stories about local African innovation
with mobile systems.

We are trying to assess the need for more attention being given to 'home grown' solutions. E.g., are 'Western' systems sufficient for the largest anticipated user base in the world??

We've read some discussions on your blog about a similar topic (i.e. web
development coming out of Africa).

As a Web Technologist, how do you cope with the fact that less than 4% of Africans have Internet access?

Erik - I see this as a starting point. It’s not as if that percentage is ever going to decrease, we’ll continue to see greater adoption. We have to think of the future with a long-term perspective on integration into everyday African’s lives.

We also have to weigh the value of traditional computer-based internet access versus mobile forms. As more developers think creatively on how to get information and data to the mass amounts of mobile users in Africa, the need for internet access via computer will decrease for certain functions. I think there is a huge area of growth that is lying virtually untapped in the mobile market right now.

At the same time, I think we need to distance ourselves from the thought process of mobile versus PC. We’re basically talking about data flow and personal interactivity. Creating applications and services that work equally well on both platforms is where we should be placing our focus.

UIT - Who is better suited to develop interactive systems for Africa: Africans or non-Africans? Why?

Erik - Africans generally speaking, or if non-Africans, then ones that have lived significantly long enough in Africa so that they can understand the cultural nuances. This goes across Africa too, there’s no one “right way” for all of Africa. It’s too diverse.

Though there are many features and standardized practices found around the world, I still wouldn’t expect to see too many of the top web apps in the US built by people not from the US. This applies to Africa as well. Indigenous people, whether in Europe, the US or Africa, have a better handle on their culture and what types of services and features are needed.

UIT - Do you think "Western" developed software should be localized for African users beyond language, or is translation enough? (E.g. McDonald's doesn't only simply translate their menu, they adapt their food offerings to be culturally sensitive.)

Erik - It looks like I jumped ahead and answered this question in the one above. Basically, translation is not enough. There are certain platform features that can be standardized across cultures, but thought has to be given to cultural norms and sensitivities when the detail work is being put into an application.

UIT - When do you think Africans will shift from primarily SMS based systems to richer interactivity offered by e.g. Java or mobile web browsers?

Erik - Interesting question, and one that I’ve been thinking a lot about lately. I don’t have a source to back it up, but I was at a conference this summer in Kenya where a couple people mentioned that the penetration of Java enabled mobile phones in Africa was around 30%.

That’s not critical mass by any means, but I believe it’s a trend. We’ll continue to see the use of SMS as the primary means of communication, but as more companies build rich Java applications that are actually useful and save people time and/or money, the number of adopters will increase.

So, if I’m making a mobile phone application for Africa starting today, I would seriously think about making it a Java app.

However, something that needs to be discussed is the level of service and bandwidth capabilities for data on the mobile phone networks right now. In some countries there are some serious limitations in that area.

UIT - Given unlimited resources, which single technology would you deploy alongside or within mobile phones and why?

Erik - This is the part where I get to dream right?  Okay, I would build a Java-based application that decreases communication costs and provides for greater interactivity than is generally available through SMS-only phones. I would likely use an open-source solution that allows for lower cost initial outlay and scalability.

UIT - Which features on your current mobile phone would likely need adaptations if to be used by the "masses" in, e.g., Nairobi, Kenya?

Erik - I use an iPhone, so that’s a bit harder to answer. It doesn’t have some of the features that I’d really like it to have, like the ability to load 3rd party applications.

UIT - What are the 3 biggest road blocks encountered when trying to innovate from a typical developer or designer in Africa?

Erik -

• Funding – everything tends to be done out of the developers pockets on their own time. Few non-Africans will fund any African technology initiative, incorrectly thinking that it’s too risky and that it wouldn’t make enough money. Too few wealthy Africans will fund projects like this either, or if they do, the developer is left with no meaningful equity.

• “Old Boys Club” – young innovators come along all the time. Many of them smash into the opposition of some entrenched bureaucrat or Big Co. executive who knows the right people and squashes the innovation. Or, more likely, the big company ends up stealing the idea and making the money while the young innovator gets nothing.

• Bandwidth – as more and more development projects deal with data flowing across the web and mobile networks, there is a real need to increase the bandwidth provided in most African countries. Any real popular mobile phone application that requires data to flow constantly could quickly run up against a bandwidth wall that is not quickly overcome.

UIT - How do you think developers, designers, etc., can best help non-literate "users" of ICT in Africa?

Erik - For any text-based application on a mobile phone, you have to have some type of literacy. As user-friendly as you can make the device’s interface, people still need to be able to communicate using it. If they’re communicating primarily via text, then a basic requirement is that they need to be able to read at a certain level.

However, there are still some ways around the traditional text user-interface that could be done. Use of icons and voice could open up some communications areas that allow a broader audience to participate.

Follow-up message from UIT:

We thank Erik for shedding light on the under-explored domain of interactive systems in Africa. We appreciate Erik's sensitivity to segmentation within the African market. Africa is hugely diverse, and different people will find different information useful through different delivery mechanisms. This will definitely drive innovation in delivering culturally and regionally accessible information services and applications.

The UI Thread team has synthesized a simple Venn diagram illustrating an important concept of technology harmonization. Such harmonization, when developing services and applications for Emerging Markets, is critical to mobile information accessibility. The UI Thread will introduce more thoughts on harmonization later, but for now, here's the simple Venn diagram:



For more on Erik Hersman, the Cornucopia of compelling content, we highly recommend you visit whiteafrican.com or afrigadget.com or any other one of Erik Hersman's other sites.

Interview: Ken Banks (FrontlineSMS)

The Friday, 20 April 2007 BBC News headline read:

"Texts monitor Nigerian elections"

"Anyone trying to rig or tamper with Saturday's presidential elections in Nigeria could be caught out by a team of volunteers armed with mobile phones."

"NMEM is using a free system called Frontline SMS, developed by programmer Ken Banks, to keep track of all of the texts." (source)

We at The UI Thread came across Ken's story, and FrontlineSMS, at ShareIdeas.org. (The website is dedicated to 'positive' uses of mobile technology.)

After learning more about Ken's application--which has enabled numerous organizations' communicative robustness--we took an opportunity to inquire about its history and User Interface.

Ken was kind enough to engage in an email-based interview over a period of a couple of weeks. (We hope to talk in person some time!)

Interview with Ken Banks:

UIT - How are people finding out about this application and how to use it?

Ken - "When FrontlineSMS was released to the world towards the end of 2005, I had no marketing plan (or experience), and hardly any contacts who could help promote it (and no money). So initially it was just graft getting it discussed on news sites and blogs. One of the breakthrough contacts was Mike Grenville at 160Characters, who put news of its release in his newsletter (it is widely distributed). Other than that, news about the software has been entirely viral. I must confess to being a pain in the butt (but in a proactive way!) by not letting a single opportunity go by where I felt I could shout about it. It’s now been picked up and reported on in a number of reports (such as the MobileActive series), another time in a Gates Foundation report, and more recently in an as-yet unpublished paper from Acumen Fund. There are actually more Google hits for “FrontlineSMS” than there are for “kiwanja.net”, which is interesting. In terms of finding out how to use it, the website is clear on set up and configuration issues (the fact I get so few technical support questions is proof to me of how clear it is). The software has a built-in HTML help system, but it’s intuitive enough, I believe, for most people to be able to start using it quite quickly. The screens generally have a ‘flow’ about them, and being a user myself, and having spent a lot of time with colleagues in developing countries and knowing a little bit about how they got on with computers (I trained some of the Nigerian staff while I was working at a primate sanctuary there – two years before I wrote FrontlineSMS). Again, I have not heard of any issues in usability"


UIT - How do people perceive FrontlineSMS in terms of a new system they weren't exposed to?

Ken - "FrontlineSMS has been received so incredibly well I think in part down to the project’s aims and objectives, and the overall work ethic (i.e. trying to empower, not dictate, and free software and free support, and a genuine interest in the work of non-profits and what they’re trying to achieve, and experience working where they work in many cases). I think this, above everything, has been a major factor in the contacts I’ve been getting, and the requests to use the software. The general vibe of the project stands above the software itself, in a way (does that make sense?). So, when users get hold of FrontlineSMS they are already excited and captivated by it. I get numerous mails telling me how great it is and thanking me for developing it BEFORE the users even get to use it. So, when they are finally exposed to it I think they’re just grateful for it being there for them, and none have made any critical comments or suggestions on how it can be improved. This may be in part to their lack of knowing what to expect. Also, mobile is such an exciting area for most people, many are just grateful for being able to do something in the space"


UIT - In terms of FrontlineSMS usage for the Nigerian elections, which environmental conditions made FrontlineSMS an attractive choice for users?

Ken - "I think, for the Nigerians, it was attractive because it was “written for them” in the sense of the NGO approach (so there were no concerns about being taken for a ride financially), and that it’s use in developing countries has been widely reported. It was also quite likely the only solution out there for them (I don’t know of anything else which quite does was FrontlineSMS does, although I may be wrong). The Nigerians had a minimal budget, little experience of setting up a telecoms service, and little time. They wouldn’t have known how to deal with their local operators to get short codes, for example, and there would have been big time and cost implications for them. Also, having the software run on a local machine, rather than being web-based, meant that they had a sense of “ownership” of it, I suspect. You know, it’s their system and their data and their effort. I think that, more widely speaking, this sense of ownership is a key element in ICT software development when you talk about it in a developing country context. At the end of the day, I think people just “get” FrontlineSMS – you know, the whole thing about putting software on THAT laptop and then connecting A phone to it. It’s a very visual solution"


UIT - What were the alternatives to completing the task FrontlineSMS was used for in Nigeria?

Ken - "As I mentioned, I don’t think there’s really much else out there. The NMEM team could have maybe gone to an operator and tried to get a deal with an access number, or a short code or something. They could have also perhaps just tried to use a smarter phone, and tried to save the messages somewhere (this would have been difficult with 10,000+ replies). They may have also looked at some of the commercial systems out there. I think their situation conspired against them in all these cases – particularly in terms of the technical and financial challenges it would have created"


UIT - When designing FrontlineSMS, how did you explore cultural and regional considerations for the User Interface (e.g. if you knew many people in developing regions would be using it)?

Ken - "In short, I didn't have time to do any of that. I've developed a number of systems before, and generally have a good grasp of what users like and don't like. So FrontlineSMS has no hugely thought-out UI design, although I have received positive comments on the whole, and no-one has experienced problems in using it. 2.0 will have multi-language support"


UIT - In general, how did you go about designing the User Interface? ( E.g. did you apply any design heuristics, usability methods or leverage any ethnographic data?)

Ken - "As mentioned above, I didn't plan it too much. I only had 5 weeks to develop it, so there wasn't a lot of lead time. I'd be interested in hearing your thoughts, though! =) "


UIT - Will the forthcoming version of FrontlineSMS include any substantial changes at the GUI level, or user interactions? If so, what elicited the changes?

Ken - "I do not anticipate too many changes in the UI in the new version, since there doesn’t seem to be a call for any. A couple of things I have picked up on need doing, such as moving the phone settings from a main screen into a menu somewhere, but there really isn’t much. To be honest, a lot of the current screen design only turned out the way it did because it was the only way I could make everything fit. In the first version I wanted to give the user everything they needed at once, rather than expect them to find a configuration menu somewhere else. From my experience of users in developing countries, not being able to configure the phone, for example, on the same screen as the messages are sent, would be counter-intuitive. The screens are being built in the new version in such a way that they can be changed easily – the open source community will be free to do any of this – and the screen text will be held in central files to allow for the support of multiple languages in the future"


UIT - SMS is the killer app in Africa. When will that change?

Ken - "The Mobile Web will probably change that, but SMS will always have a place in the mobile universe. Handsets in developing countries – rural areas in particular - won't be able to handle anything other than SMS as data for another few years, is my guess. Read my http://www.blogspot.kiwanja.net/2007/09/digital-divider.html for a better review"


UIT - Why will that change?

Ken - "SMS has obvious limitations (message length, literacy issues, cost – it's very expensive if you think about the actual amount of data being sent). There are others but I'll need to think a little more…"


Follow-up message from UIT:

As UI-oriented people, we're obligated to hold UI methodologies in high esteem. However, UI design is not simply GUI design--a common oversight.

Effective UI designers know the importance of User-Centered Design (UCD) and wouldn't be worth their screen-flows without it.

Ken Banks and FrontlineSMS exist in the exciting and evolving domain of social-driven mobile applications. (We've coined an aspect of this domain "OpenUCD" which identifies a need for User-Centered Design in F/OSS, as much as the practice of it.)

FrontlineSMS goes beyond effective GUI because it, as an interactive system, is backed by substantial user research, understanding and a consumer-targeted approach. Evidenced by Ken's responses to our questions, this mobile interactive system is a product of ad-hoc ethnography as much as rapid-prototyping.

In fact, perhaps without realizing it, Ken has done a commendable job at UCD by making UI choices in response to actual user needs. For that he has been rewarded (by the rapid uptake of his application).

Our praise of Ken's work, however, is balanced by the recognition that many social-oriented projects may not have the good fortune of in-depth user research or domain expertise.

So we at The UI Thread put forth a call to action for those wishing to develop interactive-systems on shoe-string budgets:

Embody "OpenUCD." Find ways to follow UCD methodologies the best you can.

Ask for help if you feel you need it.
(e.g. http://groups.google.com/group/openucd)

For more on Ken Banks' initiatives, and FrontlineSMS, please visit Ken's website Kiwanja.net.

Learn about his background and experiences at this ShareIdeas.org Webinar.

Thanks Ken!

- UIT

Bespoke UI for Developing Regions?

The continent of Africa is experiencing an unprecedented growth in mobile interactive systems.

Most people should consider that a good thing. Mobile interactive systems--specifically information-oriented systems--are attributed with progression in the fields of

• Civic engagement
• Economic empowerment
• Education
• Environment
• Health and safety
• Humanitarian relief
  source
  

Naturally, the better a person can leverage the information-oriented system, the more benefit they should experience because of it.

If you disagree, stop Googling until you're convinced. (By the way, try not to take Googling for granted. You're actually quite privileged.)

As a UI Designer for Nokia, I design UIs which are meant to leverage the features of a mobile phone. The features are intended to address the needs of painstakingly researched consumer segments. We design for segments, because one size doesn't necessarily fit all.

It turns out that it's very difficult to design "globally" in many cases.

"To achieve culturally sensitive, successful global access to UIs provides many design challenges in the UI development process."

(Understatement courtesy of Aaron Marcus' chapter in The HCI Handbook.)

So if such an emphasis is placed on segmenting markets, spending money on consumer research, designing for sub-populations (e.g. 18 - 24 year-olds, technology enthusiasts, business people) and running usability tests on representative samples of the population, why are huge percentages of populations having such difficulty accessing information??

I believe the problem is lack of bespoke UI design, and supporting infrastructure, by product of innovative contextual design.

(Bespoke + UI = User Interfaces tailored to specific needs [of a user or user group].)

In a Nigerian survey on the obstacles to use of mobiles in rural areas among market traders it was found that:

"42% had difficulty understanding the phone menus"
(source)

The so called "Developing World" is apparently in possession of "hand-me-down" systems that just don't quite fit.

If the systems don't fit the needs of the users, as mentioned above, the harder the system is to leverage and the less beneficial it becomes.

Ergonomics, Systems Analysis, Usability, various branches of HCI, etc. have been tried and tested and proven to be effective in improving accessibility to interactive systems. For reasons not completely clear to me, these sets of methods and techniques are not being heavily used in bringing Information Communication Technology (ICT) to the so called "Next Billion" users.

I think it's time to change that. Some prominent academics also seem to think so.

EQO Mobile (part 3): Offline Mode

I noticed something peculiar when comparing two different EQO warning/error messages. One message was much better designed than the other.

Heuristic: Help users recognize, diagnose, and recover from errors

Bad: The first had a vague and technical reference to some mysterious error code "A0002."

Good: The second had a friendly and informative tone. "Please allow EQO Mobile to access the internet..." (by the way, EQO, 'internet' is a proper name and should be capitalized like so: 'Internet').

Despite the 'Bad' message, the real peculiarity was the 180-degree shift in tone. Who wrote the tone of the first message, and why was such a tone chosen? Was the author a software developer? Who authored the tone of the second message? Is it safe to assume they were different people because the messages were completely inconsistent? It surely seems so, as the two messages convey a completely different tone to the recipient.

vs.

Heuristic: Consistency

Bad: The aforementioned textual tone discrepancies are somewhat bad in terms of consistency. The difference in ambiguous/technical vs. friendly textual tones reduces the overall cohesiveness of the EQO error handling interactions.

Bad: On top of the textual tone discrepancy, I noticed another. Both messages are within the Phonebook and called "Connection Message." Each has a 'main' action available via the middle selection key and an 'ancillary' action available via the right selection key. So why does the position of "Exit" change from one screen to the other? There might be a good reason for this, but I am unable to presume it.

Heuristic: User control and freedom

EQO has chosen to develop their JAVA application with 2 keys in mind. I am using the application on a Nokia device with 3 keys, so the labels for the keys show up in the middle and on the right. Users of different phone manufacturers might find their selection key labels show up on just the left and right (as no middle selection key is actually available). EQO doesn't always have control of where their selection key labels show up, but when they do, they would be wise to take full advantage of keys. Why? Because limiting the selection keys limits the functionality of the application in Offline Mode (possibly limiting user satisfaction).

Case in point: when scrolling between the 3 core features of the application--Phonebook, Messages and IM Services--the right selection key completely disappears.

Phonebook:

Messages:

IM Services:

Why isn't the most common user task 'bubbled up' to the 'main' action on the middle selection key and "Options" moved over to the ancillary spot on the right selection key (as we've seen in other examples of EQO UI)?

EQO Mobile (part 2): Offline Mode

Version: 1.0.5
Phone: Nokia 6260

EQO is primarily a communications application. It seems reasonable to conclude that most features require some kind of network connectivity.

Fortunately for the users of EQO, the application creators have taken into consideration the benefits of, and the need for, a functional Offline Mode.

Heuristic: User control and freedom

Good: The sign in screen for EQO gives the user a chance to avoid immediately connecting to the network. The user can uncheck the checkbox "Start in Online m[ode]". Assuming that the most typical use case is to use the network to call, IM or email, EQO has made the right choice in checking this box by default.







Heuristic: Consistency/User control and freedom

Bad: Once the user selects "OK" EQO launches and attempts to connect to the network anyway.

Fortunately the Nokia 6260 prompts the user to allow EQO to connect before they get charged for any network costs...given the clear intention was to sign in offline mode instead of online mode. (Is it possible "m..." stands for something else?)

To remain offline, the user selects "No"



Heuristic: Help users recognize, diagnose, and recover from errors

Good: EQO does a decent job of informing the user they are in Offline Mode, even if the message does look a lot like an error...rather than a subtle or inviting entry to Offline Mode.

Pressing the Middle Selection Key (MSK) allows the user to "Use Offl[ine]". This doesn't result in another attempt to connect, rather defaults to EQO's central 'home screen.'

From the 'home screen,' the offline functionality is mostly as described in the EQO Mobile (Part 1) post.

Heuristic: Flexibility and efficiency of use

Good: The "Options" menu varies depending on which of the three features the user is in. This helps the user access the functions they need during the right context.

From the phone feature, the following options are available in Offline Mode:

1. My Contacts
2. EQO Status
3. My Account
4. Settings
5. Exit

Pleasantly, each item is selectable in Offline Mode, and all but EQO Status provide unambiguous and useful feedback/function. My Account is particularly useful in Offline Mode, because it keeps a running tally of data usage, down to the Byte, for users who would like to keep track. (Although not necessarily Bad, this My Account screen is also where EQO has stuck the "About EQO Mobile:" information. I don't really see how this is related to My Account. Fortunately, this information is 'below the fold.' It's just slightly awkward though and doesn't really do any harm.)

Heuristic: Visibility of system status

Bad: EQO Status is one of the 5 option items from the list. The user would likely expect EQO Status to show the current status of EQO. For some reason, this isn't what happens. Rather, the user is prompted to change the status of EQO from Offline to Online.

Selecting Online prompts the user to connect to the network again (done by the same Nokia prompt).

Selecting Minimize didn't seem to have any immediate affect. EQO, if you're still out there, please inform us as to what EQO Status is really intended to be doing...



Heuristic: User control and freedom

Good: One of the Offline Mode settings is to change the default behavior back to the presumably more common use case of starting EQO in online mode. This saves the user from having to make that selection again each time, and implies EQO is keeping track of what the user wants. Starting in offline rather than online mode can really help the user manage connectivity issues, while maintaining control over when they really want to access the network.

For a data-conscious user, this flexibility should be nice. Once again, EQO has overall done a decent job of enabling Offline Mode usage. With a few UI tweaks here and there, this application wins...at least in Offline Mode.

More to come...

Offline Mode: designing for mobility

Mobility has tremendous, albeit obvious, advantages. However, these advantages come at a hidden cost—paid with devotion by mobile application creators.

Mobile applications are subject to a multitude of ‘hiccups’ during normal use cases.

For example
- incoming phone calls
- inconsistent network coverage
- signal degradation
- limited battery life
- highly interrupted usage (mobile behavioral patterns)

Application creators need to design their applications to handle such interruptions (and elegantly recover from any of them).

To add to the challenges of mobile application use, network carriers tend to offer varied—and occasionally ambiguous—data consumption price packages. Often, this means users may have little understanding of how much money mobile application usage will cost them.

The combination of network data charges and interrupted usage suggests a mobile application should avoid network connectivity whenever possible.

Although a network connection like GPRS may be necessary for core tasks, an application's UI should try to offer as many functions as possible in an "offline" mode.

And so was born the UI Thread’s analyses of applications' Offline Mode…

EQO Mobile (part 1)

EQO Mobile is a J2ME application that allows you to use your data and local calling plan to make international calls. See EQO's How it Works page for details.

Version: 1.0.5
Phone: Nokia 6260

EQO's website recognized my phone as I visited their download page with my phone's mobile browser. That's a very nice thing, and expected in this day and age. I accessed the same mobile download page, get.eqo.com with my other phone and was prompted with a cumbersome selection flow. (I had to first select my manufacturer from a drop-down list, and then the model number from a loooong list of radio buttons, with no apparent way to skip to my specific model number.)

Heuristic: Visibility of System Status

Representation of System Status is extremely important in HCI. Users quickly become very frustrated and distrustful of a system that doesn't constantly show what it is doing. This is especially true for time-consuming interactions, or interactions that result in a critical outcome (such as deleting files, or making a data connection).

EQO seems to do some of this well, but some of it not as well.

Good: The "Offline" text under the "EQO Mobile" header clearly lets me know I'm not online. The accompanying black & white 'offline' EQO logo to the right does the same thing.

Bad: I have no indication other than the fact that the Right Selection Key (RSK) says "Cancel" that anything is actually happening. The "Offline" text should change to "Connecting..." and there should be some kind of visual/graphical animated feedback. If there are any important distinctive stages in the EQO connection process, each stage should be represented by the text and animation.

Update July 10th, 2007
EQO Customer Evangelist, Chris, commented in reference to the "Bad" entry above. An excerpt from his comment follows.

"...you should see a "Connecting..." at the top of the screen when connecting"

I am happy to report I tested this with a Nokia 6233 to find Chris was correct. In fact, not only did the text update, but the EQO logo slowly blinked from gray to colored (to indicate the process of connecting). That turns the "Bad" into "Good" for the UI Thread.

There may be software bugs that prevented the text/icon being updated on the Nokia 6260, but the UI design seems to have been on par.

Thank you Chris and EQO for letting us know!

Good: Of the three top icons: the phone, the envelope, and the chat cloud, the phone is visually distinctive. This indicates I'm in the phone function, and maps to the sub-header, "Phonebook."

Bad: It's not really clear what I can do with the phone...especially if I'm offline and seem to be in the middle of an unknown operation.

Heuristic: Consistency and Standards

Consistency is a very solid design principle, enabling a UI to become intuitive and easy to navigate. Textual consistency--the mapping of labels to actions--is essential when building user's expectations about how the system will work.

Bad: Mobile UIs often use small icons corresponding to characters on the handset's keypad. In EQOs case, "#" is used as a supporting icon for "Dial Number." This doesn't actually correspond to the "#" on the keypad, and therefore goes against consistent standards.

This icon should have been incorporated into the object zone somehow, or not used at all. Perhaps even stylizing the icon so it didn't look like the standard keypad mapping icon would also improve on the problem.

Bad: The "Dial Number" object appears to be highlighted. However, there isn't a Selection Key (SK) that consistently maps to the action of dialing a number. The closest thing is the Right Selection Key (RSK) "Call."

It's quite unclear what this key would do, given the fact that no number has been entered.

Although not a consistency issue per se, it's also important to mention that "Options" should not be the most prominent default action in most cases. Let's see which options are available...

Heuristic: Efficiency of Use

A self-explanatory heuristic, Efficiency of Use is admittedly difficult to achieve on mobile devices. This is due, mostly in part, to limited screen space and potential many functions. EQO seems to have taken the easy way out of this challenging design problem, and put everything under an "Options" list.

Bad: "My Contacts" and "EQO Status" aren't truly options in the UI sense of the word. Options are usually settings related, or sometimes groups of actions. "My Account," "Settings" and "Exit" fit a bit better in this context.

"My Contacts" would seemingly be built in to the UI in the appropriate places, at the appropriate times. For example, during a call initiation interaction or message composing.

If EQO Status is what it sounds like it is, it should be obvious in the UI itself. (Once again, Visibility of System Status.)


A far worse example of breaking the Efficiency of Use heuristic is preventing simple navigation.

Users should never have to drill down into options menus for something as simple as backing up.

This touches on the Consistency and Standards heuristic again as well. Selecting "Back" actually brings the user back to the 'home page' of the Phonebook, which would show available contacts.
More to come...