tag:blogger.com,1999:blog-35704206339478180242024-03-14T06:00:30.564+00:00The UI Threadjdmoorehttp://www.blogger.com/profile/09904056047758608518noreply@blogger.comBlogger16125tag:blogger.com,1999:blog-3570420633947818024.post-66213413478629693922008-05-15T15:19:00.000+01:002008-05-15T23:18:06.067+01:00Design Guidelines for Touch Screen Interfaces<span class="Apple-tab-span" style="white-space: pre;"> </span>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. <div><br /></div><div><span class="Apple-tab-span" style="white-space: pre;"> </span>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.<div><br /></div><div><span class="Apple-tab-span" style="white-space: pre;"> </span>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.</div><div><br /></div><div style="text-align: left;"></div><blockquote style="color: rgb(0, 0, 0);"><div style="text-align: left;">1. <span class="Apple-style-span" style="font-weight: bold;"><span class="Apple-style-span" style="font-style: italic;">The Finger </span></span></div><div><br /></div><div>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.</div></blockquote><div style="color: rgb(0, 0, 0);"></div><div style="color: rgb(0, 0, 0);"><br /></div><div style="text-align: left; color: rgb(0, 0, 0);"></div><blockquote style="color: rgb(0, 0, 0);"><div style="text-align: left;">2. <span class="Apple-style-span" style="font-weight: bold;"><span class="Apple-style-span" style="font-style: italic;">Text </span></span></div><div><br /></div><div>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.</div></blockquote><div style="color: rgb(0, 0, 0);"><br /></div><div style="text-align: left; color: rgb(0, 0, 0);"></div><blockquote style="color: rgb(0, 0, 0);"><div style="text-align: left;">3. <span class="Apple-style-span" style="font-weight: bold;"><span class="Apple-style-span" style="font-style: italic;">Information</span></span></div><div style="text-align: center;"><span class="Apple-style-span" style="font-style: italic; font-weight: bold;"><br /></span></div><div style="text-align: left;">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 (<span class="Apple-style-span" style="font-style: italic;">standing</span> in front of a kiosk with neck <span class="Apple-style-span" style="font-style: italic;">bent</span>, <span class="Apple-style-span" style="font-style: italic;">holding</span> a mobile device in <span class="Apple-style-span" style="font-style: italic;">one</span> hand while <span class="Apple-style-span" style="font-style: italic;">interacting</span> with the device with the <span class="Apple-style-span" style="font-style: italic;">other</span> hand). Due to these awkward positions, one should assume and design interfaces that do not afford reading long passages.</div></blockquote><div style="text-align: left; color: rgb(0, 0, 0);"></div><div style="text-align: left; color: rgb(0, 0, 0);"><br /></div><div style="text-align: left; color: rgb(0, 0, 0);"></div><blockquote style="color: rgb(0, 0, 0);"><div style="text-align: left;">4. <span class="Apple-style-span" style="font-style: italic;"><span class="Apple-style-span" style="font-weight: bold;">Navigation</span></span></div><div style="text-align: left;"><br /></div><div style="text-align: left;">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).</div></blockquote><div style="text-align: left;"></div><div><br /></div><div><br /></div></div>sumedh.jigjinnihttp://www.blogger.com/profile/16972964047202401841noreply@blogger.com343tag:blogger.com,1999:blog-3570420633947818024.post-67676397271791947312008-04-07T20:50:00.015+01:002008-04-10T13:37:13.642+01:00Interview: Erik Hersman (WhiteAfrican.com)<a style="font-family: trebuchet ms;" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://lh5.google.com/ui.thread/R_qOFkwUAwI/AAAAAAAAAB0/zL590xRG240/erik_hersman_sm.jpg"><img style="margin: 0pt 10px 10px 0pt; float: left; cursor: pointer; width: 200px;" src="http://lh5.google.com/ui.thread/R_qOFkwUAwI/AAAAAAAAAB0/zL590xRG240/erik_hersman_sm.jpg" alt="" border="0" /></a><span style="font-family:trebuchet ms;">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).<br /></span><br /><span style="font-family:trebuchet ms;">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.<br /><br />This combination makes him an ideal spokesman for The UI Thread's ongoing inquiry into the 'how' and 'why' of <a href="http://uithread.blogspot.com/2007/10/bespoke-ui-for-developing-regions.html">Bespoke UI for Developing Regions</a>.<br /></span><br /><span style="font-family:trebuchet ms;">Erik was kind enough to answer our questions over email, offering a tenured voice and interesting perspective.<br /></span><span style=";font-family:trebuchet ms;font-size:180%;" ><br />Interview with Erik Hersman<br /></span><br /><span style="font-weight: bold;font-family:trebuchet ms;" >UIT</span><span style="font-family:trebuchet ms;"> - The topic has to do with the current state of affairs of 'home grown' User</span><br /><span style="font-family:trebuchet ms;">Interfaces for Africa. Everyone knows there's lots of hype around mobile these</span><br /><span style="font-family:trebuchet ms;">days...but there are surprisingly few stories about local African innovation</span><br /><span style="font-family:trebuchet ms;">with mobile systems.<br /></span><br /><span style="font-family:trebuchet ms;">We are trying to assess the need for more attention being given to 'home grown' </span><span style="font-family:trebuchet ms;">solutions. E.g., are 'Western' systems sufficient for the largest anticipated user base in the world??<br /></span><br /><span style="font-family:trebuchet ms;">We've read some discussions on your blog about a similar topic (i.e. web</span><br /><span style="font-family:trebuchet ms;">development coming out of Africa).<br /></span><br /><span style="font-family:trebuchet ms;">As a Web Technologist, how do you cope with the fact that less than 4% of Africans have Internet access?<br /></span><br /><span style="font-weight: bold;font-family:trebuchet ms;" >Erik</span><span style="font-family:trebuchet ms;"> - 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.<br /></span><br /><span style="font-family:trebuchet ms;">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.<br /></span><br /><span style="font-family:trebuchet ms;">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.<br /></span><br /><span style="font-weight: bold;font-family:trebuchet ms;" >UIT</span><span style="font-family:trebuchet ms;"> - Who is better suited to develop interactive systems for Africa: Africans or non-Africans? Why?<br /></span><br /><span style="font-weight: bold;font-family:trebuchet ms;" >Erik</span><span style="font-family:trebuchet ms;"> - 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.<br /></span><br /><span style="font-family:trebuchet ms;">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.<br /></span><br /><span style="font-weight: bold;font-family:trebuchet ms;" >UIT</span><span style="font-family:trebuchet ms;"> - 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.)<br /></span><br /><span style="font-weight: bold;font-family:trebuchet ms;" >Erik</span><span style="font-family:trebuchet ms;"> - 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.<br /></span><br /><span style="font-weight: bold;font-family:trebuchet ms;" >UIT</span><span style="font-family:trebuchet ms;"> - When do you think Africans will shift from primarily SMS based systems to richer interactivity offered by e.g. Java or mobile web browsers?<br /></span><br /><span style="font-weight: bold;font-family:trebuchet ms;" >Erik</span><span style="font-family:trebuchet ms;"> - 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%.<br /></span><br /><span style="font-family:trebuchet ms;">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.<br /></span><br /><span style="font-family:trebuchet ms;">So, if I’m making a mobile phone application for Africa starting today, I would seriously think about making it a Java app.<br /></span><br /><span style="font-family:trebuchet ms;">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.<br /></span><br /><span style="font-weight: bold;font-family:trebuchet ms;" >UIT</span><span style="font-family:trebuchet ms;"> - Given unlimited resources, which single technology would you deploy alongside or within mobile phones and why?<br /><br /></span><span style="font-weight: bold;font-family:trebuchet ms;" >Erik</span><span style="font-family:trebuchet ms;"> - 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.<br /></span><br /><span style="font-weight: bold;font-family:trebuchet ms;" >UIT</span><span style="font-family:trebuchet ms;"> - Which features on your current mobile phone would likely need adaptations if to be used by the "masses" in, e.g., Nairobi, Kenya?<br /></span><br /><span style="font-weight: bold;font-family:trebuchet ms;" >Erik</span><span style="font-family:trebuchet ms;"> - 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.<br /></span><br /><span style="font-weight: bold;font-family:trebuchet ms;" >UIT</span><span style="font-family:trebuchet ms;"> - What are the 3 biggest road blocks encountered when trying to innovate from a typical developer or designer in Africa?<br /></span><br /><span style="font-weight: bold;font-family:trebuchet ms;" >Erik</span><span style="font-family:trebuchet ms;"> -<br /></span><ul style="font-family:trebuchet ms;"><li><span style="font-weight: bold;">Funding</span> – 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.</li></ul><ul style="font-family:trebuchet ms;"><li><span style="font-weight: bold;"> “Old Boys Club”</span> – 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.</li></ul><ul style="font-family:trebuchet ms;"><li> <span style="font-weight: bold;">Bandwidth</span> – 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.</li></ul><span style="font-weight: bold;font-family:trebuchet ms;" >UIT</span><span style="font-family:trebuchet ms;"> - How do you think developers, designers, etc., can best help non-literate "users" of ICT in Africa?<br /></span><br /><span style="font-weight: bold;font-family:trebuchet ms;" >Erik</span><span style="font-family:trebuchet ms;"> - 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.<br /></span><br /><span style="font-family:trebuchet ms;">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.<br /></span><span style=";font-family:trebuchet ms;font-size:180%;" ><br />Follow-up message from UIT:<br /></span><br /><span style="font-family:trebuchet ms;">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.<br /></span><br /><span style="font-family:trebuchet ms;">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:<br /></span><br /><a style="font-family: trebuchet ms;" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://lh3.google.com/ui.thread/R_qT_EwUAxI/AAAAAAAAACY/xKOgQgPKO3c/venn_3_fixed.png"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 400px;" src="http://lh3.google.com/ui.thread/R_qT_EwUAxI/AAAAAAAAACY/xKOgQgPKO3c/venn_3_fixed.png" alt="" border="0" /></a><br /><br /><span style=";font-family:trebuchet ms;font-size:180%;" >For more on Erik Hersman</span><span style="font-family:trebuchet ms;">, the Cornucopia of compelling content, we highly recommend you visit </span><a style="font-family: trebuchet ms;" href="http://www.whiteafrican.com/">whiteafrican.com</a><span style="font-family:trebuchet ms;"> or </span><a style="font-family: trebuchet ms;" href="http://www.afrigadget.com/">afrigadget.com</a><span style="font-family:trebuchet ms;"> or any other one of Erik Hersman's other sites.<br /><br /><br /></span>jdmoorehttp://www.blogger.com/profile/09904056047758608518noreply@blogger.com17tag:blogger.com,1999:blog-3570420633947818024.post-62545444395370552282008-02-14T20:13:00.005+00:002008-02-14T20:38:02.963+00:00Don't make elevators into Jerks!<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://upload.wikimedia.org/wikipedia/commons/thumb/2/2f/Ponderosa_elevator.JPG/296px-Ponderosa_elevator.JPG"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 200px;" src="http://upload.wikimedia.org/wikipedia/commons/thumb/2/2f/Ponderosa_elevator.JPG/296px-Ponderosa_elevator.JPG" alt="" border="0" /></a><br /><br /><span style=""><span style="font-family:arial;">I just stumbled onto a blog written by a fellow named David Louis Edelman by way of a three-part article that caught my eye called ‘Building the Perfect Interface’.</span> <span style="font-family:arial;">From <a href="http://www.davidlouisedelman.com/technology/building-the-perfect-user-interface-part-2/">Edelman</a>:</span><br /></span><blockquote><span style="">"</span><span style="color: rgb(102, 102, 102);">Take the standard elevator. Elevators are extremely dumb machines. They spend large amounts of time sitting on the wrong floor. When you walk up to the elevator, the only interface you’ve got is a simple two-button panel that asks whether you’re going up or down. People often end up piling into multiple elevators that are going to the same destinations, requiring all of the elevators to stop at multiple floors. The buttons for opening and closing the doors once you’re in there are a bad joke — by the time you find them, it’s either too late to stop the doors or just an unnecessary extra redundancy. </span><p><span style="color: rgb(102, 102, 102);">How come the elevators don’t </span><em style="color: rgb(102, 102, 102);">know</em><span style="color: rgb(102, 102, 102);"> where you’re going already? If you’re in a strange building, that’s understandable — but why should you have to push the same button for your apartment or office every day? Couldn’t the building automatically sense that someone’s waiting for the elevator via motion detectors? And couldn’t it automatically sense which floor you’re heading to by reading an RFID chip in your key? Hell, the elevator should start making decisions about which elevator to send and when as soon as I enter the parking garage."</span></p></blockquote><p></p> <p style="margin: 5pt 0.5in;"></p><span style=";font-family:Arial;font-size:12;" >David Louis Edelman brings up some very good points and some very bad ones here in the same breath. I think it’s helpful for us interface designers to recognize the well-supported insights offered by enthusiasts (Edelman himself is a programmer and a novelist- not a user interface designer), while at the same time being able to quickly point out areas of caution.<br /><br /></span><span style=";font-family:Arial;font-size:12;" >Elevators are indeed extremely dumb machines. They are like traffic lights in that they don’t make use of much intelligence, and people generally accept the way they are because they use them so often and really only pay any attention to them when they behave particularly poorly.<br /><br /></span><span style=";font-family:Arial;font-size:12;" >However, the author treads into dangerous territory when he suggests that elevators should not force us to make decisions and tell it where to go every day- that the elevator should be the one that makes the decisions. After all, the technology is available for the elevators to be smart enough to do this for us, right?<br /><br /></span><span style=";font-family:Arial;font-size:12;" >Right…if you’re one of those kinds of people whom enjoy being predictable and having no say in where your body is moved about through this physical world of ours.<br /><br /></span><span style=";font-family:Arial;font-size:12;" >The truth is, people like not having to worry about the small stuff. But in order for the small stuff to be completely accounted for by technology, it needs to be done very well- and account for exceptions. The elevator that ‘knows’ where you want to go and takes you there automatically is very presumptuous- almost a bit rude. Although it might seem great at first that you are forever free from pressing that damn button every damn day (which can be disburdened many other ways), you will quickly change your mind about it the one time you carelessly decide to leave your apartment to head up to you’re friend’s place on the 14<sup>th</sup> floor and the elevator smugly guides you to your car in the basement. Was it your fault you didn’t let the elevator know ahead of time to divert from the usual path? Now we’ve introduced another set of stuff you have to worry about…Wasn’t the point to rid yourself of effort and thought?!<br /><br /></span><span style=";font-family:Arial;font-size:12;" >I think at this point in time, we really need to concern ourselves with aiding people’s decision making skills, and not making decisions for them. And when I say decisions, I mean larger and personal ones like where to go, and not teensy or impersonal ones like organizing your online movie library into genre taxonomies. After all, people like to make decisions about things that are important to them. Control is desirable.<br /><br /></span><span style=";font-family:Arial;font-size:12;" >The elevator should be smart enough to know all sorts of information about our usage patterns, where we live or work in the building (as long as we want it to know that!), and what floors we are probably going to be visiting given the day and time…However, this information needs to be used to do things like prepare and suggest- not to assume and decide. That’s <span style="font-weight: bold; font-style: italic;">our</span> job! It reminds me of some of the points made by Don Norman in his latest book, “<a href="http://www.amazon.com/Design-Future-Things-Donald-Norman/dp/0465002277/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1203021073&sr=8-1">The Design of Future Things</a>”. To be honest, I wasn’t a big fan of the book in light of his other big sellers, but it did offer sound advice on people trying to design the next wave of intelligent products and services.<br /><br /></span><span style=";font-family:Arial;font-size:12;" >All in all, Edelman did have some good ideas. I do think it would be handy for an elevator to be present (or quickly on its way) depending on when you’ve arrived and gotten out of your car. But I think things like emphasizing floors by remembering the person’s previous decisions and/or their RFID info might be more helpful rather than kidnapping them and taking them there without asking first. These, in addition to improving the interface by way of adhering to proper design principles of proximity and cognitive load, would be a huge improvement. Of course some caveats that would still need to be worked out though:<br /></span><ol><li><span style=";font-family:Arial;font-size:12;" >How do we make decisions about what we want the elevator to know about us?</span></li><li><span style=";font-family:Arial;font-size:12;" >How do we handle multiple people in one elevator with conflicting goals, locations, and privacy preferences?</span></li><li><span style=";font-family:Arial;font-size:12;" >How do we design these so-called intelligent elevators differently depending on whether the users are frequent or infrequent (e.g. office buildings vs. hotels)?</span></li></ol><span style=";font-family:Arial;font-size:12;" >In conclusion, I’d like to leave off with this sentiment; half of the time, I don’t even know what I want. So, how could a machine? We should encourage caution when allowing machines to pretend they really do…at least for the next few decades…right?<br /><br /></span>codyfrewhttp://www.blogger.com/profile/04348704324523246224noreply@blogger.com186tag:blogger.com,1999:blog-3570420633947818024.post-73707790696146401282008-01-27T23:02:00.000+00:002008-01-28T00:13:40.926+00:00Interview: Erik Pukinskis (OLPC, AbiWord)<div style="text-align: justify;"><div style="text-align: left;"><span style="font-size:100%;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://lh6.google.com/innergyzer/R50R0ahPECI/AAAAAAAABmY/YnKgH5SpTWs/Write.png"><img style="margin: 0pt 10px 10px 0pt; float: left; cursor: pointer; width: 320px;" src="http://lh6.google.com/innergyzer/R50R0ahPECI/AAAAAAAABmY/YnKgH5SpTWs/Write.png" alt="" border="0" /></a>Erik Pukinskis is currently a PhD student in the Distributed Cognition and Human-Computer Interaction Lab in the Cognitive Science department at the University of California in San Diego.</span><br /><br /><span style="font-size:100%;">He previously had an opportunity to work on the interface of an ambitious project: One Laptop Per Child (<a href="http://laptop.org/">OLPC</a>). </span><br /><br /><span style="font-size:100%;">His focus was on re-working the user interface of the open-source word processor, <a href="http://www.abisource.com/">AbiWord</a>, with the tagline, "Word Processing for Everyone."</span><br /><br /><span style="font-size:100%;"> "<a href="http://wiki.laptop.org/go/Write">Write</a>" was the derivative application, aimed at introducing school children in developing regions to perhaps their first-ever word processing experience.</span><br /></div><br /><span style="font-size:100%;"><span style="font-size:180%;">Interview with Erik Pukinskis</span></span><br /><br /><span style="font-size:100%;"><span style="font-weight: bold;">UIT</span> - Hi Erik.</span><br /><br /><span style="font-size:100%;">The UI Thread is most interested in your experiences relating to the challenges you faced re-designing a UI for such a diverse group of users.</span><br /><br /><span style="font-size:100%;">AbiWord is an AbiSource project known for its cross-platform functionality, portability and localization potential. In you opinion, why was AbiWord the best editor for the job?</span><br /></div><div style="text-align: justify;" class="Ih2E3d"><span style="font-size:100%;"><br /></span></div><div style="text-align: justify;"><span style="font-size:100%;"><span style="font-weight: bold;">Erik</span> - I don't know all of the reasons why OLPC chose AbiWord, but I can make some guesses. It's small and light, which is important given the XO has very little storage space and processing power. I think there was already some inertia towards using GTK for OLPC software. And RedHat was doing the software, and their engineers are very familiar with GNOME technologies.</span><br /></div><div style="text-align: justify;" class="Ih2E3d"><span style="font-size:100%;"><br /><span style="font-weight: bold;">UIT</span> - How well do you think AbiWord would have served the needs of the target-users had no thought been given to re-designing the UI?<br /><br /></span></div><div style="text-align: justify;"><span style="font-size:100%;"><span style="font-weight: bold;">Erik</span> - You know, I wonder about this. A lot of work is going into redesigning these apps for what we think the target kids will need, but no one is really researching how the kids live, and even if they did, no one can predict what they'll do with the machines. Sometimes I think they should just throw Ubuntu on there and let the kids figure it out. Children are just bursting with ingenuity.</span><br /><br /><span style="font-size:100%;">That said, there's great potential for harm. The laptops might cause serious social problems. It's just impossible to predict. As my friend Lilly smartly asked, "Could it be the new skolt lapp parable?"</span><br /></div><div style="text-align: justify;" class="Ih2E3d"><span style="font-size:100%;"><br /><span style="font-weight: bold;">UIT</span> - How did you go about discovering and defining your individual target-user groups?<br /><br /></span></div><div style="text-align: justify;"><span style="font-size:100%;"><span style="font-weight: bold;">Erik</span> - I basically read the press releases coming out of OLPC and RedHat and everyone, and then I pecked at Chris Blizzard for as many details about the rollout plan as I could.</span><br /></div><div style="text-align: justify;" class="Ih2E3d"><span style="font-size:100%;"><br /><span style="font-weight: bold;">UIT</span> - The target-users you were designing for were very far away, and very dispersed. How did you address that challenge and inform your design with useful data?<br /><br /></span></div><div style="text-align: justify;"><span style="font-size:100%;"><span style="font-weight: bold;">Erik</span> - I went to people who know more than me. I got some good guidance from a professor of mine, Eden Medina, who has has a lot of knowledge about South America. And I interviewed professors at the University I was at (Indiana University) who were knowledgeable about Brazil and Nigeria and other launch countries and had visited or lived in those countries.</span><br /><br /><span style="font-size:100%;">It was really wonderful, talking to people who could say "this is what school is like for these kids" and who knew, because they had been there and lived it.</span><br /></div><div style="text-align: justify;" class="Ih2E3d"><span style="font-size:100%;"><br /><span style="font-weight: bold;">UIT</span> - What were the top 5 design modifications needed for AbiWord?<br /><br /></span></div><div style="text-align: justify;"><span style="font-size:100%;"><span style="font-weight: bold;">Erik</span> - It's hard to say what was "needed". I had some ideas of what I thought would be a good place to start... making it usable by people who can't read was a big one. Getting it to work on a small screen was another one. Trying to make it engaging for kids was probably a third. As for four and five... well, you can only have so many design goals. :)</span><br /></div><div style="text-align: justify;" class="Ih2E3d"><span style="font-size:100%;"><br /><span style="font-weight: bold;">UIT</span> - Can you tell us about any opportunities you had for user research or user testing before, during, or after the design process?<br /><br /></span></div><div style="text-align: justify;"><span style="font-size:100%;"><span style="font-weight: bold;">Erik</span> - I'm sort of embarrassed to say it, but I didn't do any user testing! It's not easy getting access to kids to do user testing. And I was traveling while working that summer, so I was mostly limited to desk work.</span><br /></div><div style="text-align: justify;" class="Ih2E3d"><span style="font-size:100%;"><br /><span style="font-weight: bold;">UIT</span> - Given you experience with OLPC, what would you recommend to a UI designer embarking on a multi-national UI design for developing regions?<br /><br /></span></div><div style="text-align: justify;"><span style="font-size:100%;"><span style="font-weight: bold;">Erik</span> - If I were doing it, I'd try to get volunteers from lots of different countries who know what the target environment is like, and can do user testing. If you do iterative design with a team like that, I'd think a good result would be almost inevitable.</span><br /></div><div style="text-align: justify;" class="Ih2E3d"><span style="font-size:100%;"><br /><span style="font-weight: bold;">UIT</span> - The Sugar UI is very unique. How did it influence you during your design process?<br /><br /></span></div><div style="text-align: justify;"><span style="font-size:100%;"><span style="font-weight: bold;">Erik</span> - I spent a good deal of time just figuring out how to conform to their design ideas, which was a little different than previous design projects. In school, you have massive amounts of freedom, and you're trying to design something very forward-looking. In this case, I was just trying to help AbiWord fit in.</span><br /></div><div style="text-align: justify;" class="Ih2E3d"><span style="font-size:100%;"><br /><span style="font-weight: bold;">UIT</span> - Which aspects of your background and education do you felt you drew on most while working on the re-design?<br /><br /></span></div><div style="text-align: justify;"><span style="font-size:100%;"><span style="font-weight: bold;">Erik</span> - My skills in user research and prototyping from design school came in useful. And I certainly had to draw on programming experience from my Computer Science undergraduate days.</span><br /></div><div style="text-align: justify;" class="Ih2E3d"><span style="font-size:100%;"><br /><span style="font-weight: bold;">UIT</span> - Overall, how did you find the project and what would you do differently given the chance?<br /><br /></span></div><div style="text-align: justify;"><span style="font-size:100%;"><span style="font-weight: bold;">Erik</span> - It was a great project! I don't think I'd do anything differently if I could go back, because that was who I was, and I like who I am now... but if I were to do a similar project again, I would focus much more on working with children. I'd make finding children for user testing my first priority and try to do iterative design with them. Iterations make the world go round.</span><br /></div><div style="text-align: justify;" class="Ih2E3d"><span style="font-size:100%;"><br /><span style="font-weight: bold;">UIT</span> - Our compliments to you for working on such an interesting project! Thanks again for your time.<br /><br /></span></div><div style="text-align: justify;"><span style="font-size:100%;"><span style="font-weight: bold;">Erik</span> - Thanks for your interest!</span><br /><br /><span style="font-size:100%;"><span style="font-size:180%;">Follow-up message from UIT:</span></span><br /><br /><span style="font-size:100%;">Erik's suggestion of engaging end-users more for future projects is a wonderful idea. Sometimes this can cost a lot of money and Free/Open Source Software projects usually don't have a lot.</span><br /><br /><span style="font-size:100%;">However, creative designers should be able to find affordable means. In fact, something tells us children would participate for lollipops.</span><br /><br /><span style="font-size:100%;">We at the UI Thread care a great deal for F/OSS in general--especially projects aimed at bridging the so-called "Digital Divide." However, despite the best of intentions, it seems that Open Source initiatives are still lagging behind private-market firms when it comes to enunciating the mantras of user-centered design.</span><br /><br /><span style="font-size:100%;">Hopefully with more people like Erik Pukinskis getting involved, this will change. After all, F/OSS is about community design and development. Projects such as <a href="http://www.ubuntu.com/">Ubuntu</a> seem to be on the right track.</span><br /><br /><blockquote><span style="font-size:100%;">"Ubuntu is an African word meaning 'Humanity to others', or 'I am what I am because of who we all are'. The Ubuntu distribution brings the spirit of Ubuntu to the software world." - (ubuntu.com)</span></blockquote><br /><span style="font-size:100%;"><span>So we at The UI Thread put forth a <span>call to action</span> for those wishing to develop interactive-systems on shoe-string budgets:</span><br /><span style="font-size:100%;"><span></span></span><br /><span style="font-size:100%;"><span>Embody "OpenUCD."<span> </span>Find ways to follow <a href="http://en.wikipedia.org/wiki/User-centered_design">UCD methodologies</a> the best you can.</span><br /><span style="font-size:100%;"><span></span><br /><span style="font-size:100%;"><span>Ask for help if you feel you need it.<span> </span></span></span><br /><span style="font-size:100%;"><span>(e.g. <a href="http://groups.google.com/group/openucd">http://groups.google.com/group/openucd</a>)</span><br /><br /><span style="font-size:180%;">For more on </span><span style="font-size:100%;"><span style="font-size:180%;">Erik Pukinskis'</span> initiatives, visit his blog <a href="http://snowedin.net/blog/about/">SnowedIn.net</a>.</span><br /></span></span></span></span></div><br /><span style="font-size:100%;"><br /><br /><span><span style="font-size:180%;"></span></span></span>jdmoorehttp://www.blogger.com/profile/09904056047758608518noreply@blogger.com1tag:blogger.com,1999:blog-3570420633947818024.post-30621539087367180162007-12-06T03:14:00.000+00:002007-12-06T06:02:43.033+00:00Why Goals and Tasks are the Same Thing (part 3)<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://farm3.static.flickr.com/2279/2090799860_65c0eaef94.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 400px;" src="http://farm3.static.flickr.com/2279/2090799860_65c0eaef94.jpg" alt="" border="0" /></a><br />In <a href="http://uithread.blogspot.com/2007/08/why-goals-and-tasks-are-same-thing-part.html">Part 1</a> of this long post series, I discussed goal-directed design and the more customary way to view goals and tasks, along with their commonly noted distinctions. In <a href="http://uithread.blogspot.com/2007/10/why-goals-and-tasks-are-same-thing-part.html">Part 2</a>, I laid down my claim about the true nature behind these conceptual tools, in attempt to both confuse the matter and also clarify it at the same time.<br /><br />In Part 3, presumably the final part, I will attempt to address the implications drawn from my claim, supposing how we may use my rants to further us in our ways of general hierarchical thinking and in our more specific instances of user-centered design methodology.<br /><br />I'd like to note that the main conclusions in the claim and resulting discussion lie mostly in the realm of communicating about goals and tasks effectively with team members, as well as thinking about them for yourself. In other words, I am not advocating full-blown changes to the way you acquire and analyze user data or even necessarily in the way you design goal-directed solution.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://farm1.static.flickr.com/22/31414294_3506d4e652.jpg?v=0"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 320px;" src="http://farm1.static.flickr.com/22/31414294_3506d4e652.jpg?v=0" alt="" border="0" /></a><br />My aim is to get you to think and communicate with <span style="font-weight: bold; font-style: italic;">flexibility</span> about user modeling.<br /><br /><br /><br />I've heard of (and been part of) many squabbles in the confines of meeting rooms where UCD professionals are forced to argue over what constitutes a goal and what constitutes a task in order to establish a common ground of discussion and documentation. And establishing these common grounds is so important to effect collaboration- whether you are a 2 person team or a multi-departmental corporation. The thing is; these types of arguments will always plague the said team time and time again because the division between the two concepts is not <span style="font-weight: bold;">prescriptive</span>. Thus, they will have to revisit the same argument every time, albeit with different activities in question.<br /><br />It's like having to compromise (and often disagree) on rules for a pickup football game every single time you play (even though it's the same group of people). If you could all agree on the basic nature of the game in the first place, then you could establish any rules you want and follow them to your heart's content- as long as you are all happy with how the game is being played.<br /><br />Similarly, instead of discussing whether or not changing the music in the car is a goal or a task, and then having to have the same discussion about finding a destination on a dashboard navigation system, you should just realize that you are wasting your time and efforts! By putting your time into establishing a more flexible and effective process, with a basic underlying acceptance of the continuous nature of goals and tasks, you can be more effective.<br /><br />If you can accept the claim that tasks and goals (and other variants of the terms, like activities, objectives, etc.) are really inherently the same concept and differ only in their relativity and global scope, then you will be able to appreciate some consequential implications:<br /><ol><li>Your team communication and process establishment will potentially benefit.</li><li>You can easily increase and decrease your scope of attention by simply asking why and how, respectively.<br /></li><li>You can realize that just because a goal is 'higher' doesn't always mean that it is more important than a task. If you design a product or service that behaves abhorrently at lower levels (say, the visual feedback of button pressing, or a customer service interaction), then the goal no longer matters to the user experience! After all, a person may never even be cognizant of a high level goal if they are immerse in an appropriately scaled task. See <a href="http://en.wikipedia.org/wiki/Flow_%28psychology%29">Flow Theory</a>.</li><li>The methods you use to identify goals can be employed to identify tasks as well- and vice versa. So, if you have an established way of recognizing people's tasks in an observed workflow, but need to identify their subtasks and/or goals for accomplishing the tasks you find, you don't have to use a different process.</li><li>It's all about finding the sweet spot. Using a flexible goal/task diagram technique, you can quickly identify the top boundary (when the user no longer knows or cares <span style="font-weight: bold;">why</span> they do something) and the bottom boundary (when the user no longer cares or knows <span style="font-weight: bold;">how</span> they do it). Identifying the boundaries can be very powerful for understanding exactly what level of scope your product should cater to and how to go about planning your UCD project.</li><li>Actor goals found in <a href="http://en.wikipedia.org/wiki/Use_cases#Actors">use cases</a> are not a different kind of goal from the ones found in goal/task hierarchies created by UCD proffesionals. They are just usually lower is scope than the goals found typical hierarchies (the ones that specify why the use cases are being accomplished in the first place).<br /></li><li>Lastly, goal/task hierarchies and the concepts they represent are NOT prescriptive. They are descriptive guidelines, imperfect by nature, and requiring the interpretation and discussion of qualified professionals.</li></ol>As my boss put it after a long discussion, goal/task diagrams are kind of like research <span style="font-weight: bold; font-style: italic;">heuristics</span>, in parallel with design heuristics. They are malleable guidelines that you can use to research users and hopefully design useful and usable solutions.codyfrewhttp://www.blogger.com/profile/04348704324523246224noreply@blogger.com0tag:blogger.com,1999:blog-3570420633947818024.post-61388142794711677232007-11-20T20:33:00.000+00:002007-11-21T07:48:09.413+00:00Interview: Ken Banks (FrontlineSMS)<span style="font-family:arial;">The <a href="http://news.bbc.co.uk/1/hi/technology/6570919.stm">Friday, 20 April 2007 BBC News headline</a> read:<br /><br /></span><span style="font-size:180%;">"Texts monitor Nigerian elections"</span><br /><br />"<span style="font-weight: bold;">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</span>."<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://www.frontlinesms.kiwanja.net/images/SCPreview.jpg"><img style="margin: 0pt 10px 10px 0pt; float: left; cursor: pointer; width: 320px;" src="http://www.frontlinesms.kiwanja.net/images/SCPreview.jpg" alt="" border="0" /></a><span style="font-family:arial;">"NMEM is using a free system called Frontline SMS, developed by programmer Ken Banks, to keep track of all of the texts."</span> <span style="font-family:arial;"> (<a href="http://news.bbc.co.uk/1/hi/technology/6570919.stm">source</a>)</span> <span style="font-family:arial;"><br /><br />We at The UI Thread came across Ken's story, and <a href="http://www.frontlinesms.kiwanja.net/">FrontlineSMS</a>, at <a href="http://shareideas.org/index.php/Main_Page">ShareIdeas.org</a>. (The website is dedicated to 'positive' uses of mobile technology.)<br /><br />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.</span><br /><br /><span style="font-family:arial;">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!)</span><span style=";font-family:Trebuchet MS;font-size:85%;color:black;" ><span style=";font-size:10;color:black;" ></span></span><br /><span style="font-family:arial;"><br /><span style="font-size:180%;">Interview with Ken Banks</span></span>:<br /><br /><span style="font-family:arial;"><span style="font-weight: bold;">UIT </span>- How are people finding out about this application and how to use it?</span><br /><br /><span style="font-family:arial;"><span style="font-weight: bold;">Ken </span>- "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"</span><br /><br /><br /><span style="font-family:arial;"><span style="font-weight: bold;">UIT</span> - How do people perceive FrontlineSMS in terms of a new system they weren't exposed to?<br /><br /></span><span style="font-family:arial;"><span style="font-weight: bold;">Ken</span> - "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"</span> <span style="font-family:arial;"><br /><br /><br /><span style="font-weight: bold;">UIT</span> - In terms of FrontlineSMS usage for the Nigerian elections, which environmental conditions made FrontlineSMS an attractive choice for users?</span> <span style="font-family:arial;"><br /><br /><span style="font-weight: bold;">Ken</span> - "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"</span> <span style="font-family:arial;"><br /><br /><br /><span style="font-weight: bold;">UIT</span> - What were the alternatives to completing the task FrontlineSMS was used for in Nigeria?</span><br /><br /><span style="font-family:arial;"><span style="font-weight: bold;">Ken</span> - "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"</span> <span style="font-family:arial;"><br /><br /><br /><span style="font-weight: bold;">UIT</span> - 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)?</span><br /><br /><span style="font-family:arial;"><span style="font-weight: bold;">Ken</span> - "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"</span> <span style="font-family:arial;"><br /><br /><br /><span style="font-weight: bold;">UIT</span> - 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?)</span> <span style="font-family:arial;"><br /><br /><span style="font-weight: bold;">Ken</span> - "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! =) "</span> <span style="font-family:arial;"><br /><br /><br /><span style="font-weight: bold;">UIT</span> - Will the forthcoming version of FrontlineSMS include any substantial changes at the GUI level, or user interactions? If so, what elicited the changes?</span> <span style="font-family:arial;"><br /><br /><span style="font-weight: bold;">Ken</span> - "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"</span> <span style="font-family:arial;"><br /><br /><br /><span style="font-weight: bold;">UIT</span> - SMS is the killer app in Africa. When will that change?</span><br /><br /><span style="font-family:arial;"><span style="font-weight: bold;">Ken</span> - "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 <a href="http://www.blogspot.kiwanja.net/2007/09/digital-divider.html">http://www.blogspot.kiwanja.net/2007/09/digital-divider.html</a> for a better review"</span> <span style="font-family:arial;"><br /><br /><br /><span style="font-weight: bold;">UIT</span> - Why will that change?</span><br /><br /><span style="font-family:arial;"><span style="font-weight: bold;">Ken</span> - "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…"</span> <span style="font-family:arial;"><br /><br /><br /><span style="font-size:180%;">Follow-up message from UIT:<br /><span style="font-size:100%;"><br /></span></span></span><span style=";font-family:arial;font-size:100%;" >As UI-oriented people, </span><span style=";font-family:arial;font-size:100%;" >we're obligated to hold UI methodologies in high esteem. However, UI design is not simply GUI design--<span style="font-style: italic;">a common oversight</span>.<br /><br />Effective UI designers know the importance of User-Centered Design (UCD) and wouldn't be worth their screen-flows without it.<br /><br /></span><span style=";font-family:arial;font-size:100%;" >Ken Banks and FrontlineSMS exist in the exciting and evolving domain of social-driven mobile applications. (We've coined an aspect of this domain "</span><span style=";font-family:arial;font-size:100%;" ><span>OpenUCD" </span>which identifies a <span style="font-style: italic;">need </span>for User-Centered Design in <a href="http://opensource.mit.edu/what_is_os.html">F/OSS</a>, as much as the <span style="font-style: italic;">practice </span>of it.)<br /><br />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.</span><span style="font-size:100%;"><br /></span><span style="font-size:100%;"><br /></span><span style=";font-family:arial;font-size:100%;" >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). </span><span style="font-size:100%;"><br /></span><span style=";font-family:arial;font-size:100%;" ><br />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.<br /><br />So we at The UI Thread put forth a <span>call to action</span> for those wishing to develop interactive-systems on shoe-string budgets:<br /><br />Embody "OpenUCD."<span> </span>Find ways to follow <a href="http://en.wikipedia.org/wiki/User-centered_design">UCD methodologies</a> the best you can.<br /><br />Ask for help if you feel you need it.<span> </span><br />(e.g. <a href="http://groups.google.com/group/openucd">http://groups.google.com/group/openucd</a>)<br /><span style="font-size:180%;"><br />For more on Ken Banks</span>' initiatives, and FrontlineSMS, please visit Ken's website <a href="http://www.kiwanja.net/">Kiwanja.net</a>.<br /><br /></span><span style="font-family:arial;"><span style="font-size:100%;">Learn about his background and experiences at this ShareIdeas.org <a href="http://lemill.net/content/applying-mobile-technology-in-the-global-conservation-and-development-effort">Webinar</a>.<br /><br />Thanks Ken!<br /><br />- UIT</span><br /></span>jdmoorehttp://www.blogger.com/profile/09904056047758608518noreply@blogger.com87tag:blogger.com,1999:blog-3570420633947818024.post-43559575609896545812007-11-16T06:48:00.001+00:002008-04-20T11:13:15.430+01:00A Scientific Method of Designing<ol id=""><li>Finding Need in the Market<br /></li><li>Targeting a Customer Segment<br /></li><li>Identifying Use Cases of Ideal Solution<br /></li><li>Prioritizing via Functional Limitations <br /></li><li>Creating an Information Architecture<br /></li><li>Modularize Layout of UI<br /></li><li>Designing Efficiency of Interaction<br /></li></ol><br />Let me cut you off right there. You are correct. There is no hard science behind design. However without some framework, design is downright impossible. Let’s leverage the best practices of business, engineering, and visual arts to deliver the richest experience to our end-user.<br /><div><br /><div style="text-align: center;">A <span style=""><span class="Apple-style-span" style="font-weight: bold;">Seemingly</span></span> Useless Epiphany<br /></div><div style="text-align: center;"><br /></div><span style="font-style:italic;"><div style="text-align: center;">People need a place to live.<br /></div></span><div><br /></div> Let’s face it. We encounter so many problems every day. Technology hasn’t made us less stressed or happy; rather, it has given us higher expectations of what the world should deliver. Lucky for us designers, technology only creates more opportunities for innovation. There is no shortage of problems and neither is there a shortage of ideas. Thus, finding a need in the market is really a matter of identifying a single group of issues that can be met with an innovative, elegant solution from technology.<br /><br /><div style="text-align: center;">A <span class="Apple-style-span" style="font-weight: bold;">Need</span> in the Market<br /></div><div style="text-align: center;"><br /></div><div style="text-align: center;"><span class="Apple-style-span" style="font-style: italic;">People need to be able to find a place to live.<br /></span></div><span class="Apple-style-span" style="font-style: italic;"><br /></span> More than likely, you’ll find almost everyone can benefit to a solution to the problems you encountered. Well due to evolution or some higher power, we are not all created equal but somehow we fit into nice groups we can call demographics. Each demographic has it’s own constraints, whether financially, technically, or even accessibly. By “discriminating,” you now have the ability to target a niche. Thus you have the upper hand to compromise less and deliver the highest utility to the select rather than compromise completely and deliver a lower utility to everyone. All in all, your goal is to compromise the least in order to provide that rich experience to as many users as possible.<br /><br /><div style="text-align: center;">A Customer <span class="Apple-style-span" style="font-weight: bold;">Segment</span><br /></div><div style="text-align: center;"><br /></div><div style="text-align: center;"><span class="Apple-style-span" style="font-style: italic;">American technical 20-somethings need to be able to find a place to live.<br /></span></div><span class="Apple-style-span" style="font-style: italic;"><br /></span> Now it’s time to think big. You must identify all the circumstances and objectives you can satisfy with your innovation. By targeting a customer segment, you have the ability to cater to their needs and wants. At this point, you should not get bogged down in the details but instead identify objectives, features, and other consumer-friendly uses of your ideal solution. Remember, for each problem you solve, consumers will want to reach that solution more efficiently and effectively.<br /><br /><div style="text-align: center;"><span class="Apple-style-span" style="font-weight: bold;">Use Cases</span> of an Ideal Solution<br /></div><br /><div style="text-align: center;"><span class="Apple-style-span" style="font-style: italic;">These people want to be able to access an online tool </span></div><div style="text-align: center;"><span class="Apple-style-span" style="font-style: italic;">to find a place to live optimized for their </span></div><div style="text-align: center;"><span class="Apple-style-span" style="font-style: italic;">finances, activities, locations, fun, and overall happiness.</span><br /></div><br /> Then, it hits you. You remember you’re still living in the blossoming present, not the rosy future. (Municipal Wi-Fi is still five years away like it was five years ago.) The use cases you identified are what your target customer wants. Since you have a target customer, his or her use cases are not a result of any compromise yet. Instead, you have the ability to prioritize the use cases based on functional limitations. Not everything can be done with the technology of today. However by prioritizing what you know what you can deliver today, you have essentially identified what you may be able to better deliver tomorrow. By now you have created a matrix of use cases, ordered by importance to the user coupled with the roadmap of when you can deliver on those solutions.<br /><br /><div style="text-align: center;"><span class="Apple-style-span" style="font-weight: bold;">Prioritizing</span> via Functional Limitations<br /></div><div style="text-align: center;"><br /></div><div style="text-align: center;"><span class="Apple-style-span" style="font-style: italic;">There is no measure of happiness but there is a measure of finances </span></div><div style="text-align: center;"><span class="Apple-style-span" style="font-style: italic;">e.g. personal online banking information.</span><br /></div><br /> With a fixed set of use cases, you can figure out the most efficient paths for users to achieve their end result. By crawling into the mind of our target user, we can trace the steps he or she would take. Many of the use cases will have common steps and lead toward a complex web of information. By creating a hierarchy of these steps and connecting commonalities, information architecture will follow.<br /><br /><div style="text-align: center;"><span class="Apple-style-span" style="font-weight: bold;">Information Architecture</span> from Prioritized Use Cases<br /></div><div style="text-align: center;"><br /></div><div style="text-align: center;"><span class="Apple-style-span" style="font-style: italic;">Housing > Finances > What I can afford > With Loans > With Interest<br /></span></div><div style="text-align: center;"><span class="Apple-style-span" style="font-style: italic;">vs<br /></span></div><div style="text-align: center;"><span class="Apple-style-span" style="font-style: italic;">Housing > What I can afford (with loans with interest)</span><br /></div> <br /> Here’s the tricky part. A path for a common use case may have a long series of steps. If you were to directly map the information architecture into a hierarchy-based UI, your user would be very inefficient in achieving this task. One solution is to minimize this issue, by providing a “shortcut” to this action (or actions via a group). Each of these shortcuts take away from the organized structure you tried to map from your information architecture. However, these shortcuts are a necessary evil. By modularizing your UI, you can properly distinguish your shortcuts (and groups of shortcuts) from your hierarchy to help users gain quick access to solutions to common use cases while at the same time providing a logical path to other solutions.<br /><br /><div style="text-align: center;"><span class="Apple-style-span" style="font-weight: bold;">Modularization</span> of the UI<br /></div><div style="text-align: center;"><br /></div><div style="text-align: center;"><span class="Apple-style-span" style="font-style: italic;">Hierarchy: Optimize finance, Optimize activities, Optimize distance<br /></span></div><div style="text-align: center;"><span class="Apple-style-span" style="font-style: italic;">Shortcuts: Automatically optimize everything based on my online information</span><br /></div><br /> Just by segmenting the layout of the UI, the interaction does not automatically become optimized for efficiency. This is where usability and benchmarking takes place. Obviously, we are not the target customers so we should not take our own wisdom as the final say. Getting target users involved early in the process leads to more user-centered design. This prevents usability “fixes” and supports an elegant solution from the beginning.<br /><br /></div><div><br /><div style="text-align: justify;"><span class="Apple-style-span" style="font-style: italic; ">Each of these six topics may deserve their own blog post but at the same time, it is necessary to have a general yet clearer idea of the issues that must be considered in design. By communicating a process, I hope to initiate discussion of the larger topics that fit into each step. This framework may be referenced in future threads as a starting point for further discussion. </span><br /></div><br /></div>sumedh.jigjinnihttp://www.blogger.com/profile/16972964047202401841noreply@blogger.com11tag:blogger.com,1999:blog-3570420633947818024.post-43584430963546650432007-10-31T16:11:00.001+00:002007-10-31T18:10:33.890+00:00Why Goals and Tasks are the Same Thing (part 2)<span style="font-family:georgia;">In </span><a style="font-family: georgia;" href="http://uithread.blogspot.com/2007/08/why-goals-and-tasks-are-same-thing-part.html">Part 1</a><span style="font-family:georgia;"> of this post series, I discussed goal-directed design and the more customary way to view goals and tasks, along with their distinctions. In Part 2, I will lay down my claim about the true nature behind these conceptual tools. And in Part 3, the final part, I attempt to address the implications drawn from my claim, supposing how we may use my rants to further us in our ways of general thinking and in our more specific instances of user-centered design methodology.</span><br /><br /><span style="font-family:georgia;">To continue my discussion, I'll get the ball rolling with my slightly blunt contention- which is; the only difference between what constitutes a goal and what constitutes a task is the relationship between two. To put it another way, Albert Einstein was right when he said it was all relative- it all depends on how you look at the goal or task in question.</span><br /><br /><span style="font-family:georgia;">In Part 1, I listed out several typical assumptions about the differences between goals and tasks. Here, I will list them again and provide perhaps some more clarifying rebuttals to the statements.</span><br /><ol style=";font-family:georgia;font-size:12pt;"><span style="font-size:100%;"><br /></span><li style="padding-bottom: 0px; padding-top: 0px;"><span style="font-weight: bold;font-size:100%;" >Goals are high-level; Tasks are low-level.</span><span style="padding-left: 10px;font-size:100%;" ><br />While globally true, this is more of a descriptive and subjective accusation and is not objectively prescriptive for labeling across multiple goal/task analyses.<br /></span></li></ol><ol style=";font-family:georgia;font-size:12pt;"><li style="padding-bottom: 0px; padding-top: 0px;"><span style="font-weight: bold;font-size:100%;" >Goals are abstract; Tasks are physically observable (concrete).</span><span style="padding-left: 10px;font-size:100%;" ><br />This is a tough one- after all it is a pretty easy way to think about it. However, it requires a vigorous exploration into what it means to be abstract in order to see that abstraction is extremely difficult to classify and most likely exists as some type of graded continuum- not an either/or. But I’ll save the philosophy for a different time and place! Often times, tasks are fully or partially abstract as well. And sometimes sub-tasks are not fully observable.</span><span style="font-size:100%;"><br /></span></li><span style="font-size:100%;"><br /></span><li style="padding-bottom: 0px; padding-top: 0px;"><span style="font-weight: bold;font-size:100%;" >Goals are something a user has; Tasks are something a user does.</span><span style="padding-left: 10px;font-size:100%;" ><br />This is simply a property of the terminology you are using. Only once you call something a goal does it make sense for you to “have” it, as opposed to “doing” it. Once again, it is not a prescriptive way to deal with entities which could be called either tasks or goals.</span><span style="font-size:100%;"><br /></span></li><span style="font-size:100%;"><br /></span><li style="padding-bottom: 0px; padding-top: 0px;"><span style="font-weight: bold;font-size:100%;" >Goals do not change; Tasks do change.</span><span style="padding-left: 10px;font-size:100%;" ><br />This is simply not true. It’s a close approximation, but fatally false. Goals do in fact change. The difference is that high level goals change MUCH more slowly and less frequently than do low level tasks. Once you understand the continuous scoping nature of goal/task hierarchies, it will be easy to see that statement number 4 is an oversimplification.</span><span style="font-size:100%;"><br /></span></li><br /></ol><span style="font-family:georgia;">If you don't remember my common goal/task diagram </span><a style="font-family: georgia;" href="http://uithread.blogspot.com/2007/08/why-goals-and-tasks-are-same-thing-part.html">example from Part 1</a><span style="font-family:georgia;">, now would be a good time to reference it. Let's take a look at my revised goal/task diagram:</span><br /><br /><div style="text-align: center; font-family: georgia;"><a href="http://lh5.google.com/codyfrew/Ryir1VVbeUI/AAAAAAAAAxc/oxbPVfYf4-U/goals_and_tasks.jpg?imgmax=512"><img style="width: 466px; height: 310px;" src="http://lh5.google.com/codyfrew/Ryir1VVbeUI/AAAAAAAAAxc/oxbPVfYf4-U/goals_and_tasks.jpg?imgmax=512" border="0" /></a></div><br /><div style="text-align: left;"><br /><span style="font-family:georgia;">Now, allow me to make some claims about goals and tasks that I think are better suited for accuracy which follow from the above diagram:</span><br /><br /><br /><span style="font-weight: bold;font-family:georgia;font-size:130%;color:black;" >Goals and Tasks aren't qualitatively distinct.</span><br /><span style=";font-family:georgia;font-size:100%;" >Give me a task and I'll show you how it's really a goal for another set of subtasks. Conversely, you can provide me with a goal, and I'll show you that it's really a task that exists to reaching some higher-yet goal. The thing that makes the two different is the state in which you view it relevant to another. At any one point in time, the entity under inspection could be a goal or a task depending on how you view it.</span><br /><br /><span style="font-weight: bold;font-family:georgia;font-size:130%;color:black;" >Goals and Tasks are relevant to each other.</span><br /><span style=";font-family:georgia;font-size:100%;" >A task is only a task if it is subordinate to a goal. Likewise, a goal can only be considered a goal if it is composed of one or more tasks. Otherwise, it too is just a task...Another way to put this is that if a goal doesn't have a reason for being accomplished or desired that satisfies some lower steps to get there, then it doesn't have the right to be called a goal.</span><br /><br /><span style="font-weight: bold;font-family:georgia;font-size:130%;color:black;" >Goals and Tasks can be mapped onto a continuum.</span><br /><span style=";font-family:georgia;font-size:100%;" >Create a goal/task diagram that extends as many hierarchical levels as you'd like. Now, recognize that you cannot draw any straight line that separates concrete physical tasks from abstract ones. Instead of creating false categories, it is more accurate to map them onto a continuum where at the top lie MORE abstract, higher-level, slowly changing goals and where at the bottom lie MORE concrete, lower-level, often-changing tasks.</span><br /><br /><span style="font-weight: bold;font-family:georgia;font-size:130%;color:black;" >Goals and Tasks change over time, albeit at different rates.</span><br /><span style=";font-family:georgia;font-size:100%;" >While tasks at lower levels can change very quickly and often, higher level goals can change very slowly or seemingly not at all. Think about it- while you may always have the semi-constant goal of getting your coffee in the morning, the way in which you go about getting your coffee may vary from making it yourself, to your loved one making it, to going to a coffee shop on the wya to work, to grabbing some at work. While I may at age 40 decide that coffee is no longer my drink of choice due to stomach ulcers or some sleep somnia, my lower level tasks that lead to my acquiring coffee change much more rapidly (every other day compared to almost 20 years from now).</span><br /><br /><span style="font-weight: bold;font-family:georgia;font-size:130%;color:black;" >Ask WHY to traverse to a Goal, and ask HOW to see it's respective task(s).</span><br /><span style=";font-family:georgia;font-size:100%;" >At any node in a goal/task hierarchy, one may ask why it is being performed. The answer you get is a goal or a set of goals. Likewise, if you ask how a particular node is performed, the answer you get is a task or set of tasks. This is actually pretty basic, but the cool thing is that you can ask these questions for ANY node in a goal.task hierarchy! In fact, once you apply this practice to a range of nodes in a hierarchy, it really becomes clear that goals and nodes are really only relative terms.</span><br /><br /><span style="font-family:georgia;">Another cool thing is that these questions act as arbiters for the top and bottom boundaries of a goal/task diagram. It is at the point when one no longer cares why or knows why that the top of the boundary is fully identified. Alternatively, when one no longer knows how a task is performed, or cares how it is performed, we see the bottom boundary.</span><br /><br /><br /><span style="font-family:georgia;">If you feel my claim is misguided, ridiculously time-wasting, or just plain wrong, please feel free to comment and explain your side. Otherwise, please ponder the argument above. I hope to explain the usefulness from these points in my next post, along with some interesting implications that they draw.</span><br /><br /><br /><span style="font-family:georgia;">Until Part 3...</span><br /><br /></div>codyfrewhttp://www.blogger.com/profile/04348704324523246224noreply@blogger.com250tag:blogger.com,1999:blog-3570420633947818024.post-60685624420285688072007-10-18T20:20:00.000+01:002007-10-18T23:59:18.680+01:00Bespoke UI for Developing Regions?<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://lh5.google.com/innergyzer/RxfSbkTn5gI/AAAAAAAAAag/occwXPlAvhk/UI_Africa.gif"><img style="cursor: pointer; width: 400px;" src="http://lh5.google.com/innergyzer/RxfSbkTn5gI/AAAAAAAAAag/occwXPlAvhk/UI_Africa.gif" alt="" border="0" /></a><br /><br />The continent of Africa is experiencing an unprecedented growth in mobile interactive systems.<br /><br />Most people should consider that a <span style="font-weight: bold;">good thing</span>. Mobile interactive systems--specifically information-oriented systems--are attributed with progression in the fields of<br /><ul><li> <a href="http://shareideas.org/index.php/Category:Civic_engagement" title="Category:Civic engagement">Civic engagement</a> </li><li> <a href="http://shareideas.org/index.php/Category:Economic_empowerment" title="Category:Economic empowerment">Economic empowerment</a> </li><li> <a href="http://shareideas.org/index.php/Category:Education" title="Category:Education">Education</a> </li><li> <a href="http://shareideas.org/index.php/Category:Environment" title="Category:Environment">Environment</a> </li><li> <a href="http://shareideas.org/index.php/Category:Health_and_safety" title="Category:Health and safety">Health and safety</a> </li><li> <a href="http://shareideas.org/index.php/Category:Humanitarian_relief" title="Category:Humanitarian relief">Humanitarian relief<br /></a><a href="http://shareideas.org/index.php/Main_Page"><span style="font-style: italic;">source</span></a><br /></li></ul>Naturally, the better a person can leverage the information-oriented system, the more benefit they should experience because of it.<br /><br />If you disagree, stop Googling until you're convinced. (By the way, try not to take Googling for granted. You're actually <span style="font-style: italic;">quite </span>privileged.)<br /><br />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 <a href="http://www2.acnielsen.com/pubs/2003_q4_ci_behavior.shtml">consumer segments</a>. We design for segments, because one size <span style="font-style: italic;">doesn</span>'t necessarily fit all.<br /><br />It turns out that it's very difficult to design "globally" in many cases.<br /><blockquote>"To achieve culturally sensitive, successful global access to UIs provides many design challenges in the UI development process."</blockquote>(Understatement courtesy of <span class="author">Aaron Marcus' chapter in <a href="http://books.google.com/books?id=u9zFGT8GrV4C&dq=%22global+ui+design%22">The HCI Handbook</a>.)</span><br /><br />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??<br /><br />I believe the problem is lack of bespoke UI design, and supporting infrastructure, by product of innovative contextual design.<br /><br />(<a href="http://en.wikipedia.org/wiki/Bespoke">Bespoke </a>+ <a href="http://en.wikipedia.org/wiki/User_interface">UI</a> = User Interfaces tailored to specific needs [of a user or user group].)<br /><br />In a Nigerian survey on the obstacles to use of mobiles in rural areas among market traders it was found that:<br /><blockquote>"<span style="font-weight: bold;">42% had difficulty understanding the phone menus"<br /></span>(<a style="font-style: italic;" href="http://www.blogspot.kiwanja.net/2007/07/hidden-library.html">source</a>)<span style="font-weight: bold;"><br /></span></blockquote><span style="font-weight: bold;"></span>The so called "Developing World" is apparently in possession of "hand-me-down" systems that just don't quite fit.<br /><br />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.<br /><br />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 (<a href="http://www.google.co.uk/search?hl=en&q=define%3A+ICT&btnG=Google+Search&meta=">ICT</a>) to the so called "Next Billion" users.<br /><br />I think it's time to change that. Some prominent academics also seem to <a href="http://research.ihost.com/iui4dr/iui">think</a> so.jdmoorehttp://www.blogger.com/profile/09904056047758608518noreply@blogger.com1tag:blogger.com,1999:blog-3570420633947818024.post-90709319861544316662007-09-16T18:57:00.001+01:002007-10-18T21:25:41.027+01:00EQO Mobile (part 3): Offline ModeI noticed something peculiar when comparing two different EQO warning/error messages. One message was much better designed than the other. <p><span style="font-weight: bold;font-size:100%;" >Heuristic</span><b>: Help users recognize, diagnose, and recover from errors</b> </p><p><strong>Bad:</strong> The first had a vague and technical reference to some mysterious error code "A0002." </p> <p><strong>Good:</strong> 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'). </p> <p>Despite the '<strong>Bad</strong>' 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. </p> <p><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://lh5.google.com/innergyzer/Ru1tw4QQfiI/AAAAAAAAAW4/fh-j-MjWn7o/Drawing1.jpg"><img style="cursor: pointer; width: 200px;" src="http://lh5.google.com/innergyzer/Ru1tw4QQfiI/AAAAAAAAAW4/fh-j-MjWn7o/Drawing1.jpg" alt="" border="0" /></a> vs. <a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://lh5.google.com/innergyzer/Ru1tw4QQfjI/AAAAAAAAAXA/kQelui-KKXE/Drawing2.jpg"><img style="cursor: pointer; width: 200px;" src="http://lh5.google.com/innergyzer/Ru1tw4QQfjI/AAAAAAAAAXA/kQelui-KKXE/Drawing2.jpg" alt="" border="0" /></a></p><p><span style="font-weight: bold;font-size:100%;" >Heuristic</span><b>: </b><b>Consistency</b></p> <p><strong>Bad:</strong> 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.</p> <p><strong>Bad:</strong> 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.</p> <p><span style="font-weight: bold;font-size:100%;" >Heuristic</span><b>: </b><b>User control and freedom</b></p> <p>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).</p> <p>Case in point: when scrolling between the 3 core features of the application--Phonebook, Messages and IM Services--the right selection key completely disappears. </p> <p>Phonebook:<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://lh5.google.com/innergyzer/Ru1tw4QQfkI/AAAAAAAAAXI/K5ybS_O7fzk/Drawing3.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 200px;" src="http://lh5.google.com/innergyzer/Ru1tw4QQfkI/AAAAAAAAAXI/K5ybS_O7fzk/Drawing3.jpg" alt="" border="0" /></a></p> <p>Messages:<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://lh6.google.com/innergyzer/Ru1txIQQflI/AAAAAAAAAXQ/QxTNBq15FwM/Drawing4.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 200px;" src="http://lh6.google.com/innergyzer/Ru1txIQQflI/AAAAAAAAAXQ/QxTNBq15FwM/Drawing4.jpg" alt="" border="0" /></a> </p> <p>IM Services:<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://lh6.google.com/innergyzer/Ru1txIQQfmI/AAAAAAAAAXY/aOJye-_a1_4/Drawing5.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 200px;" src="http://lh6.google.com/innergyzer/Ru1txIQQfmI/AAAAAAAAAXY/aOJye-_a1_4/Drawing5.jpg" alt="" border="0" /></a> </p> <p>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)?</p>jdmoorehttp://www.blogger.com/profile/09904056047758608518noreply@blogger.com103tag:blogger.com,1999:blog-3570420633947818024.post-74000948518104187112007-08-24T17:51:00.001+01:002007-08-24T17:52:47.745+01:00Why Goals and Tasks are the Same Thing (part 1)<p>This is an exploration into human intention/behavior structure, what we know about it, and how we communicate about it in order to design and engineer products and services that humans can use effectively. </p><p> </p><p>Here is a prototypical goal/task diagram: </p><p><img style="margin: 0px 0px 0px 60px;" src="http://farm2.static.flickr.com/1090/1223368337_8802eb6f5c.jpg?v=0" /> </p><p> </p><p>The terms “goal” and “task” are household terms, meaning that they are not necessarily esoteric linguistic tools. However, if you’re in the field of <a href="http://en.wikipedia.org/wiki/User-centered_design" target="_blank">user-centered design</a>, these terms no doubt carry higher significance in their usage and in their implications to your work. Chances are you have a pretty good notion of what these things are and how they are framed with regard to their subtle differences, namely; </p><p>1) Goals are high-level. Tasks are low-level. </p><p>2) Goals are abstract. Tasks are physically observable. </p><p>3) Goals are something a user has. Tasks are something a user does. </p><p>4) Goals do not change. Tasks do change. </p><p> </p><p>Originating from the encouragement of <a href="http://en.wikipedia.org/wiki/Alan_Cooper" target="_blank">Alan Cooper</a>, many practitioners follow Goal-Directed Design, which has its basic tenants on the idea that you should begin building a product or service by first understanding users and their goals, and then design for those goals, and not necessarily for their tasks. </p><p> </p><p> </p><p>For example, Veronica the [insert role and persona information here] is playing music in her Lexus. We know that she wants to eject a CD from her stereo deck, from within a CD changer that holds several CDs. What she does that is physically observable though is she presses a sequence of buttons on the stereo interface, necessarily in that order, and waits several seconds for the desired CD to emerge from the thin slot it once had entered. </p><p> </p><p><img src="http://farm2.static.flickr.com/1188/1224228644_c6350460ee.jpg?v=0" align="right" height="216" width="343" /> </p><p>Following the objective of Goal-Directed Design (and if we were savvy), we would design for the goal- which is to retrieve that specific CD. We would <strong><u>NOT</u></strong> want to design for the task, <strong>which would consist of things like the following</strong>: </p><p>1) make the buttons she needs to access closer to her in proximity so that she does not have to ergonomically exert herself and take her focus off of her driving </p><p>2) make the buttons bigger and easier to press </p><p>3) have them light up and “click” when they are pressed to provide ample feedback for a successful press </p><p> </p> <p>Instead, we would re-evaluate why she needs to press these buttons, in that order, in the first place. It will be much better to rethink and validate the high-level needs and interactions for extracting her CD. Goal-Directed Design is a great way to run user-centered processes. It allows a team of designers to keep the user in mind and facilitates creativity and out-scoping so that the team will be less likely to be pigeonholed in one way to do something.</p> <p> </p> <p>In other words, Goal-Directed Design protects a designer from putting lipstick on the pig. </p><p> </p> <p>The only questions are- <strong>How do we know that Veronica’s goal is to extract a CD? Did we assume it? Did we ask her? And if we asked her, can we be sure that she is rightfully aware of her intentions and reasons? Even if we were extremely confident that her goal was indeed to ‘get’ her CD, how do we know that she doesn’t have an even higher goal?</strong> What if her goal was to change the music that is playing by putting in the Carrie Underwood CD where her Sugar Hill Gang CD used to be in her disc changer? In that case, extracting Carrie Underwood is only a means to an end. Then, shouldn’t we be designing for that goal- switching music, which supersedes extraction? </p><p> </p> <p>Or, what if there is an even higher goal- to change moods? Is that what we should aim for? And if so, what does that make our original goal- <strong>a task</strong>?? </p><p> </p> <p>Stay tuned for Part 2, where I’ll explain more… </p>codyfrewhttp://www.blogger.com/profile/04348704324523246224noreply@blogger.com7tag:blogger.com,1999:blog-3570420633947818024.post-56687026981300797272007-07-18T22:30:00.000+01:002007-10-18T21:26:36.971+01:00EQO Mobile (part 2): Offline ModeVersion: 1.0.5<br />Phone: Nokia 6260<br /><br /><a href="http://www.eqo.com/">EQO</a> is primarily a communications application. It seems reasonable to conclude that most features require some kind of network connectivity.<br /><br />Fortunately for the users of EQO, the application creators have taken into consideration the benefits of, and the need for, a functional Offline Mode.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://lh5.google.com/innergyzer/Rp6NprVM71I/AAAAAAAAAK4/xgEkCjd7z7Q/eqo_signin.JPG"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 200px;" src="http://lh5.google.com/innergyzer/Rp6NprVM71I/AAAAAAAAAK4/xgEkCjd7z7Q/eqo_signin.JPG" alt="" border="0" /></a><span style="font-weight: bold;font-size:100%;" >Heuristic</span><b>: </b><strong>User control and freedom<br /><br /></strong><span style="font-weight: bold;">Good:</span> 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.<br /><br /><span style="font-weight: bold;"><br /><br /><br /><br /><br /><br /></span><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://lh6.google.com/innergyzer/Rp6Np7VM72I/AAAAAAAAALA/O5-ehoTJaOc/eqo_allow_network_access.JPG"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 200px;" src="http://lh6.google.com/innergyzer/Rp6Np7VM72I/AAAAAAAAALA/O5-ehoTJaOc/eqo_allow_network_access.JPG" alt="" border="0" /></a><span style="font-weight: bold;font-size:100%;" >Heuristic</span><b>: </b><span style="font-weight: bold;">Consistency/</span><strong>User control and freedom</strong><br /><span style="font-weight: bold;"><br /></span><span style="font-weight: bold;">Bad:</span> Once the user selects "OK" EQO launches and attempts to connect to the network anyway.<br /><br />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?)<br /><br />To remain offline, the user selects "No"<span style="font-weight: bold;"><br /><br /><br /></span><span style="font-weight: bold;"><br /></span><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://lh6.google.com/innergyzer/Rp6Np7VM73I/AAAAAAAAALI/8REjr8VOhbM/eqo_use_offline.JPG"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 200px;" src="http://lh6.google.com/innergyzer/Rp6Np7VM73I/AAAAAAAAALI/8REjr8VOhbM/eqo_use_offline.JPG" alt="" border="0" /></a><span style="font-weight: bold;font-size:100%;" >Heuristic</span><b>: </b><strong>Help users recognize, diagnose, and recover from errors</strong><br /><span style="font-weight: bold;"><br /></span><span style="font-weight: bold;">Good:</span> 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.<br /><br />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.'<br /><br />From the 'home screen,' the offline functionality is mostly as described in the <a href="http://uithread.blogspot.com/2007/07/eqo-mobile-part-1.html">EQO Mobile (Part 1)</a> post.<br /><br /><span style="font-weight: bold;font-size:100%;" >Heuristic</span><b>: </b><strong>Flexibility and efficiency of use</strong><br /><br /><span style="font-weight: bold;">Good:</span> 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.<br /><br />From the phone feature, the following options are available in Offline Mode:<br /><ol><li>My Contacts</li><li>EQO Status</li><li>My Account</li><li>Settings</li><li>Exit</li></ol>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 <span style="font-weight: bold;">Bad,</span> 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.)<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://lh5.google.com/innergyzer/Rp6YOrVM76I/AAAAAAAAALg/H9LYqtoPNH8/eqo_status_online.JPG"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 200px;" src="http://lh5.google.com/innergyzer/Rp6YOrVM76I/AAAAAAAAALg/H9LYqtoPNH8/eqo_status_online.JPG" alt="" border="0" /></a><span style="font-weight: bold;font-size:100%;" >Heuristic</span><b>: </b><strong>Visibility of system status</strong><br /><span style="font-weight: bold;"><br />Bad:</span> 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 <span style="font-style: italic;">change</span> the status of EQO from Offline to Online.<br /><br />Selecting Online prompts the user to connect to the network again (done by the same Nokia prompt).<br /><br />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...<br /><br /><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://lh6.google.com/innergyzer/Rp6Np7VM75I/AAAAAAAAALY/eFvjzAXNIjo/eqo_email_settings.JPG"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 200px;" src="http://lh6.google.com/innergyzer/Rp6Np7VM75I/AAAAAAAAALY/eFvjzAXNIjo/eqo_email_settings.JPG" alt="" border="0" /></a><span style="font-weight: bold;font-size:100%;" >Heuristic</span><b>: </b><strong>User control and freedom</strong><br /><span style="font-weight: bold;"><br />Good: </span>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.<br /><br />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.<br /><br />More to come...jdmoorehttp://www.blogger.com/profile/09904056047758608518noreply@blogger.com7tag:blogger.com,1999:blog-3570420633947818024.post-21933760055786893192007-07-18T21:12:00.000+01:002007-07-18T22:26:26.411+01:00Offline Mode: designing for mobility<p class="MsoNormal">Mobility has tremendous, albeit obvious, advantages. However, these advantages come at a hidden cost—paid with devotion by mobile application creators. </p> <p class="MsoNormal">Mobile applications are subject to a multitude of ‘hiccups’ during normal use cases.</p> <p class="MsoNormal" style="margin-left: 0.5in; text-indent: -0.25in;">For example<br /><span style=""><span style="">-<span style=""> </span></span></span><!--[endif]-->incoming phone calls<span style=""><span style=""><br />-<span style=""> </span></span></span><!--[endif]-->inconsistent network coverage<br /><span style=""><span style="">-<span style=""> </span></span></span><!--[endif]-->signal degradation<br /><span style=""><span style="">-<span style=""> </span></span></span><!--[endif]-->limited battery life<br /><span style=""><span style="">-<span style=""> </span></span></span><!--[endif]-->highly interrupted usage (mobile behavioral patterns) </p> <p class="MsoNormal">Application creators need to design their applications to handle such interruptions (and elegantly recover from any of them).</p> <p class="MsoNormal">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.<br /></p> <p class="MsoNormal">The combination of network data charges and interrupted usage suggests a mobile application should avoid network connectivity whenever possible.</p> <p class="MsoNormal">Although a network connection like <a href="http://en.wikipedia.org/wiki/GPRS">GPRS</a> may be necessary for core tasks, an application's UI should try to offer as many functions as possible in an "offline" mode. </p><p class="MsoNormal">And so was born the UI Thread’s analyses of applications' Offline Mode…</p><p class="MsoNormal"></p>jdmoorehttp://www.blogger.com/profile/09904056047758608518noreply@blogger.com0tag:blogger.com,1999:blog-3570420633947818024.post-27602581249478424122007-07-16T04:56:00.000+01:002007-07-16T21:22:43.689+01:00Giving Your Money to the Gas PumpYears ago, gas stations made a big move towards efficiency when they began to encourage quick and easy payment options via electronic machines located near or on the pumps. This gets more customers through the station quicker and puts less stress on staff.<br /><br />However, many of them threw usability out the window along with over-the-counter payment requirements.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://farm2.static.flickr.com/1173/718882830_fcb64260a0.jpg?v=0"><img style="margin: 0pt 10px 10px 0pt; float: left; cursor: pointer; width: 320px;" src="http://farm2.static.flickr.com/1173/718882830_fcb64260a0.jpg?v=0" alt="" border="0" /></a><br />A popular method of payment for gas these days is the credit card. While using mine, I instantly recognized the standardized swipe-slots with which to swipe my plastic. However, I ran into a problem when I couldn't find the screen that typically gives you instructions on what to perform next. I saw the big one at the top of the pump- that was easy to find. But it was a dedicated output only showing the cost and gallons!<br /><br />The correct screen (indicated at the bottom-right of this picture) was not immediately recognized for several reasons:<br /><ol><li>Proximity- the card swiper is not spatially beside the info screen that references it, as it should be.</li><li>Visual Continuity- the card swiper and the info screen are visually separated by the vertical line created by the two panels of the interface. This creates a semi-conceptual barrier that subconsciously indicates non-relatedness.<br /></li><li>Most people are right-handed. Since the card swiper is on the left-hand side, it is easy to see that most people would actually stand to the left of the swiper in order to make the action of swiping easier. This means the person is standing even further away form the info screen! This problem is exacerbated even more when...</li><li style="font-weight: bold;">The info screen has blinders on it! <span style="font-weight: normal;">So, while it's not entirely apparent from the picture above, the blinders actually occlude most of the screen from the user's visual angle if he/she stands to the left!</span></li></ol>While the interface actually has many aspects that could be improved for user experience, probably the most important is the function that it serves on the most very basic level- <span style="font-weight: bold; font-style: italic;">allow users to quickly and easily pay for their gasoline. </span><br /><br />If I had to do a quick fix, I would remove the blinders from the info screen. These exist to shield the user's pin number from suspicious prying eyes. However, pumps are typically spaced out enough laterally so that it is already fairly difficult to see one's pin number being pressed. If paranoid, one may just as easily use their hand to block the number pad as they press it- at least they could find the info area right away in that case<br /><br />But if we want to stay on the side of privacy and security, it would be best to either only have them around the number pad (specific to the function it serves), or to have them on the sides of the pump itself (general but non-intrusive). Both of these solutions would avoid falsely occluding features that don't need to be protecting from suspicious eyes. Hiding the info screen from the user seems like a dirty trick if you think about it long enough.<br /><br /><br /><span style="font-weight: bold;font-size:130%;" >Lessons Learned:</span><br /><ul><li>Design for efficiency, but...</li><li>Keep input areas simple and intuitive</li><li>Make sure 'features' do not negate the usability of the product/service. They are better left out than invading the appropriate functional interaction...<br /></li></ul>codyfrewhttp://www.blogger.com/profile/04348704324523246224noreply@blogger.com82tag:blogger.com,1999:blog-3570420633947818024.post-58709537750922641462007-07-08T22:08:00.000+01:002007-10-18T21:27:14.773+01:00EQO Mobile (part 1)<a href="http://www.eqo.com/index.php">EQO Mobile</a> is a J2ME application that allows you to use your data and local calling plan to make international calls. See EQO's <a href="http://www.eqo.com/getting_started.php">How it Works</a> page for details.<br /><br />Version: 1.0.5<br />Phone: Nokia 6260<br /><br />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, <a href="http://get.eqo.com/">get.eqo.com</a> with <a href="http://www.nokia.co.uk/link?cid=PLAIN_TEXT_78433">my other phone</a> 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.)<br /><br /><span style="font-weight: bold;font-size:100%;" >Heuristic</span><b>: </b><span style="font-weight: bold;">Visibility of System Status<br /><br /></span><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://lh3.google.com/innergyzer/RpFXsv_fo5I/AAAAAAAAAJ8/aOM2xEynqcs/eqo_rep_sys_stat.JPG"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 200px;" src="http://lh3.google.com/innergyzer/RpFXsv_fo5I/AAAAAAAAAJ8/aOM2xEynqcs/eqo_rep_sys_stat.JPG" alt="" border="0" /></a>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).<br /><br />EQO seems to do some of this well, but some of it not as well.<span style="font-weight: bold;"><span style="font-weight: bold;"><br /></span><br />Good</span>: 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.<br /><br /><span style="font-weight: bold;">Bad</span>: 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.<br /><span style="font-style: italic; font-weight: bold;font-size:85%;" ></span><blockquote style="color: rgb(102, 102, 102);font-family:verdana;"><span style="color: rgb(102, 102, 102);font-size:85%;" ><span style="font-weight: bold;">Update </span>July 10th, 2007</span><span style="font-size:85%;"><br />EQO Customer Evangelist, Chris, commented in reference to the "Bad" entry above. An excerpt from his comment follows.<br /><blockquote style="font-weight: bold;">"...you should see a "Connecting..." at the top of the screen when connecting"</blockquote>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 "<span style="font-weight: bold;">Good</span>" for the UI Thread.<br /><br />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.<br /><br />Thank you Chris and EQO for letting us know!<br /></span></blockquote><span style="font-style: italic;font-size:85%;" ></span><span style="font-weight: bold;">Good</span>: 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."<br /><br /><span style="font-weight: bold;">Bad</span>: 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.<br /><br /><span style="font-weight: bold;font-size:100%;" >Heuristic</span><b>: </b><span style="font-weight: bold;">Consistency and Standards<br /><br /></span><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://lh3.google.com/innergyzer/RpFXsv_fo7I/AAAAAAAAAKM/zOIHkH4f5pg/eqo_call_not_dial.JPG"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 200px;" src="http://lh3.google.com/innergyzer/RpFXsv_fo7I/AAAAAAAAAKM/zOIHkH4f5pg/eqo_call_not_dial.JPG" alt="" border="0" /></a>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.<br /><br /><span style="font-weight: bold;">Bad</span>: 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.<br /><br />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.<br /><br /><span style="font-weight: bold;">Bad</span>: 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."<br /><br />It's quite unclear what this key would do, given the fact that no number has been entered.<br /><br />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...<br /><br /><span style="font-weight: bold;font-size:100%;" >Heuristic</span><b>: </b><span style="font-weight: bold;">Efficiency of Use<br /></span><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://lh6.google.com/innergyzer/RpFgef_fo9I/AAAAAAAAAKc/WJfDD-YaZa4/eqo_all_functions_opts.JPG"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 200px;" src="http://lh6.google.com/innergyzer/RpFgef_fo9I/AAAAAAAAAKc/WJfDD-YaZa4/eqo_all_functions_opts.JPG" alt="" border="0" /></a>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.<br /><br /><span style="font-weight: bold;">Bad</span>: "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.<br /><br />"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.<br /><br />If EQO Status is what it sounds like it is, it should be obvious in the UI itself. (Once again, Visibility of System Status.)<br /><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://lh6.google.com/innergyzer/RpFgef_fo8I/AAAAAAAAAKU/kcrIK1DocbU/eqo_buried_back.JPG"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 200px;" src="http://lh6.google.com/innergyzer/RpFgef_fo8I/AAAAAAAAAKU/kcrIK1DocbU/eqo_buried_back.JPG" alt="" border="0" /></a>A far worse example of breaking the Efficiency of Use heuristic is preventing simple navigation.<br /><span style="font-weight: bold;"><br /></span>Users should never have to drill down into options menus for something as simple as backing up.<br /><br />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.<br />More to come...jdmoorehttp://www.blogger.com/profile/09904056047758608518noreply@blogger.com13tag:blogger.com,1999:blog-3570420633947818024.post-33789771775440153122007-07-07T09:40:00.000+01:002007-07-07T09:45:25.142+01:00Welcome to the Initiation of The UI Thread!<div style="margin: 1ex;font-family:arial;"><div> <span style="font-size:100%;">The UI Thread is a manifestation of the thoughts and efforts of JD Moore and Cody Frew, two designers trained in the arts of user interface principles and interaction techniques.</span><br /><p><span style="font-size:100%;">Here, you will be able to experience our thoughts in the realm of consumer electronics, software interfaces, and other interesting interactive systems that may or may not by computer-related. </span><br /></p> <p><span style="font-size:100%;"><span style="font-weight: bold;">Our writings will come in 4 delicious flavors:</span> </span></p> <ul><ol type="1"><li><span style="font-size:100%;">In-depth heuristic evaluation</span></li><li><span style="font-size:100%;">Single feature discussion and redesign proposal</span></li><li><span style="font-size:100%;">Abstract thoughts on usability and/or design as found in the ‘real world’</span></li><li><span style="font-size:100%;">Rants on design methodology practices and their implications</span></li></ol></ul><p><span style="font-size:100%;">We trust that by providing these 4 different types of content, you will be stimulated and engaged- no matter what your personal blog-style preference is!</span><br /></p> <p><span style="font-size:100%;">It is our mission to learn all we can about technology and its utility in the mind of the human, as well as its context within culture. It is our hope that you, the reader, will learn as much- if not more- about the important topics we will address and share our passion for <a href="http://en.wikipedia.org/wiki/User-centered_design">user-centered design.</a></span></p> </div> </div>codyfrewhttp://www.blogger.com/profile/04348704324523246224noreply@blogger.com0