It was circa 1996 that I started interacting with a new medium: the Web. By then, images were already woven into the fabric of Web sites, which resulted on a rich experience. Hours and hours were spent browsing, jumping from link to link, very close to the way thoughts spread in a brain. I was in awe.

And then, something magic happened. Right-click, view source. My life changed forever.

I already had some experience with computers and programming, since the early age of 10. DOS and (Turbo) Pascal were my two best buddies for long nights. But the possibilities of creating something out of a simple text editor, and deploying it to the World... oh boy, that was a game changer.

Fast forward a nice bunch of years. My short(-ish) research scientist carrier at the University of Lisbon has been fully centred on the Web and the way people use it: hypertext processing, accessibility, usability. At the same time, my creative roots and need for "that feeling of accomplishment" led me to invent and experiment with the more practical side of the Web.

And an opportunity of a lifetime emerged. I'm blogging sitting in my bed in California, where I'll be working for the next years at a pretty nice company.

I'll be spending most of my time tinkering on Web front-end technologies, applying all the knowledge I've gathered in the past 11 years at the University, pursuing the goal of improving the user experience on one of the Web's principal gateways.

Let the fun begin!

Permalink

Have Focus Groups Had Their Day? Asks Neil Perkin.

Excellent question. I've had a background process running in my mind for almost a year now, waisting brain cycles on thinking about Focus Groups, from results of some experiments we did with regards to UX on smart phones. And the more I think about it, the more I tend to agree with Neil.

Yes, it's always been said that focus groups should be handled with extreme care. It's easy to have bad results from these studies or, at best, a few incremental improvements to existing problem spaces. But even with a good facilitator, this research method leads to the appearance of Alpha individuals amongst participants, thus quickly skewing the main goals of such studies.

Instead, to attain the goals of focus groups, I'd suggest two complementary approaches: Ethnography — thus studying what users do and say, in their own context, as well as what they don't do and don't say — and Design thinking — a thought process of understanding user-faced problems and finding appropriate solutions.

This way, one will deeply understand the setup and constraints imposed to and by users interacting with a given system, and disrupt it without relying on biases introduced by users' personal experiences.

Permalink

After a great week at the W4A 2011 and WWW 2011 conferences, I've been thinking a lot about the true meaning of a Web browser and a Web app, particularly triggered by a great W4A keynote speech by Bebo White and an insightful dinner chat with him, Simon, and Markel afterwards.

We, as a Web community, often perceive Web browsers as really concrete applications: Internet Explorer, Mozilla Firefox, Apple Safari or Google Chrome, and Web apps as the wet dream of thin-client lovers. But, in reality, things are much more blurry than that.

The initial propostal for the World Wide Web elicites the following definition of a Web browser:

is a native application program running on the client machine:

• it performs the display of a hypertext node using the client hardware & software environment. For example, a Macintosh browser will use the Macintosh interface look-and-feel.
• it performs the traversal of links. For example, when using a Macintosh to browse on CERNVM FIND it will be the Macintosh browser which remembers which links were traversed, how to go back etc., whereas the CERNVM server just responds by handing the browser nodes, and has no idea of which nodes the user has visited.
• it performs the negotiation of formats in dialog with the server. For example, a browser for a VT100 type display will always negotiate ASCII text only, whereas a Macintosh browser might be constructed to accept PostScript or SGML.

Basically, a Web browser is a client application that knows about links (represented by URIs) and communicates with Web servers. Indeed, the formal specification for the Architecture of the World Wide Web does support this assertion.

Actually, Web browsers are nothing more than fancy specialisations of the concept of user agent (which should identify themselves in adequate HTTP headers). A user agent is, indeed, one of the main axioms of the Web's architecture:

Browsers and Email programs are user agents. This isn't just a formal long term for them, it is an important issue. They are programs which act on behalf of, and represent, the user.

However, I couldn't find a formal definition for the term Web app. My experience, and from all the reading and discussions I've seen in the past, a Web app can be loosely defined by the following three major characteristics:

1. It is accessed via the Web (i.e., through HTTP);
2. It interacts with Web resources;
3. It is built on top of existing Web technologies (e.g., HTML, CSS, Javascript).

Any given combination of these characteristics results in a different flavour for a Web app, such as:

• A simple HTML Web app (combining 1. and 3.);
• A complex HTML Web app that interacts with several Web resources (combing all characteristics);
• A Flash-based Web app (combining 1. and 2.).

Now, onto modern Web-centric development. Several of the contemporary services and applications deployed on the Web provide API binding points, upon which accessing applications and added-value services can be built.

Case in point: the Twitter ecosystem.

At a fundamental level, the Twitter Web site behaves as a Web app: it is accessed via the Web (through a Web browser), it interacts with Web resources (via the Twitter API), and it is built on top of existing Web technologies. [ed. note: the discussion between the blurry lines between Web pages and Web apps is off-topic in this post]. The same reasoning can be applied onto other third-party Web apps such as HootSuite and TweetDeck (I leave as an exercise to the reader the reasoning over the TweetDeck Chrome app).

Now, here's the catch that Bebo made (and which got me thinking): how close are we to think about native apps as a hybrid between user agents and Web apps? Here are some possible reasons on this, using the Twitter iPhone app as the lab rat:

• It is, definitely, accessed via the Web: the actual app is available through a URI (okay, installed might be a more adequate term, but then we get onto the discussion about whether or not Chrome apps are Web apps or not);
• It interacts with Web resources: not much case on this, since it operates on top of the Twitter API (via HTTP);

While as a native iPhone app it is implemented in Objective-C, it could definitely be implemented with Web technologies such as PhoneGap.

• It performs the display of a hypertext node using the client hardware & software environment: a tweet, a user profile, a tweet stream, all are uniquely available as hypertext nodes (i.e., represented by URIs);
• It performs the travessal of links: this happens in different situations, such as embedded links, retweets, @usernames. All of them follow the link travessal metaphor;
• It performs the negotiation of formats in dialog with the server: the Twitter API does interpret the Accept HTTP header, where data is transmitted e.g. in JSON, instead of the more traditional HTML version.

So, it seems that this app indeed suits all requirements to be classified both as a Web browser and Web app. Should we, then, start thinking more broadly about the consequences of this conceptual shift?

• What is the meaning of inter-app linking? How can it be achieved at the fundamental level of the Web?
• Should APIs stop existing and being nothing else than different content representations (i.e., 100% REST services) ?
• What common treats of classical Web browsers should be ported to apps?

Food for thought.

Permalink

My previous post on this blog delved on usability and user experience, with an initial argument that, while user experience is intrinsic to each product or service, there are several objective ways to measure it, and that these metrics can be replicated across different products and services.

While my gut feeling already figured out some ways to measure user experience that do not comprise archetypal usability metrics, i.e., measuring effectiveness and task completion success, I informally surveyed some community members at the Quora and UXExchange Q&A forums about this, to find out some clues on this. Indeed, I was pointed out some insightful answers, was pointed to previous discussions and essays on this subject. And, as an academic exercise, a paper presented by some Google UX Researchers at CHI 2010 on this exact topic.

So, it seems, I might be on the right track.

Without going too much into detail about the pros/cons of each answer (which is fodder to forthcoming posts, I guess), here's an unordered list of possible ways to measure user experience:

• Analytics – average time of stay, return rates, aggregate data representation of multiple people
• A/B testing
• Task goals – registration completion, contact form submission, path to purchase
• Customer support responsiveness
• Customer satisfaction evaluation – quantitative and qualitative
• Social sensing – Facebook likes, retweets, google trends
• Experience monitoring – qualitative, representation of a single session
• Mindshare goals – qualitative measures such as awareness, branding effectiveness
• Loyalty
• Net Promoter Score

I must point out that this list has some caveats: it can be unreasonable to apply some of these metrics in particular scenarios, and all of them have to be tackled from the perspective of the ultimate goals of the product or service they are applied to. In sum, the context they are applied serves as the basis for all measurements. This means that there's an additional variable when comparing the user experience of two products or services.

Permalink

A couple months ago, my fellow researcher on Accessibility, User Experience (UX), and other Human Factors stuff, Simon Harper, blogged about UX and its misconceptions, as well as challenges for the future of this research field. Simon details, with some very very heaving backing from a really important paper from CHI 2009 (please do read its full text, it's a must), that UX might lay outside of current Human Factors practices due to being less generalisable. The community was questioned about reflecting on UX matters, their meaning, their goals.

I agree that UX practices are less likely to be generalised, in comparison to the more traditional, systematic User Centred Design discipline. What works in one instance, one product, one service, might not work in all others. Their essence, reflected in users' experience with a product or service, is often unique.

But I do like to take big challenges.

In the last couple of months I've been thinking hard about all of this. UX get thrown a lot in blogs, interviews, and all that fluff surrounding the latest crop of stuff coming out of technology. People are using it as the next coming of Jesus and solver of all problems in Human-Computer Interaction. Totally not true!

Furthermore, when people start talking about UX in a more practical, less fluffy way, they often misconcept it with a portion of its concerns, i.e., Usability. And the same goes between User Experience Design (UxD) and User Centred Design (UCD). Again, the latter is indeed a subset of the former. I often see the UxD process being used when people actually meant UCD. I would argue that UCD's goals is to create and study the effectiveness of UIs for their target audience, whereas UxD goes beyond that towards engagement and pleasureness.

For now, I won't be dissecate and dissertate too much on the actual definition of UX. Heck, if the top experts cannot agree on this, who am I to take the ultimate stake at its definition? Let us stay at a phylosophical, ontological definition for it: the property of being capable to provide a good experience to users.

However, what can actually be talked about is that ideed UX can be measured, directly or indirectly; individually or collectively. And by having the proper metrics, UxD can be leveraged towards the constant improvement of products and services. And this can, I argue, be replicated and generalised across products and services.

This is the kick-off on a series of blog posts I'll be writing in the forthcoming months. I'll delve into different forays on measuring UX, specially beyond the early phase focus of traditional UCD, or effectiveness benchmarks from usability studies. Worst case scenario, I'll learn a lot!

Fun times ahead, stay tuned :)

Permalink

When developers, designers, startups, etc. think about User Experience, they often imagine simple GUIs, great graphical design, gratifications, bells and whistles and whatnots. Basically, all things that would guide end users towards getting revenue (or other goals). For the sake of this post, let's call it these UX features part of the User Land (UL).

A lot of times, what is delivered in a UL product or service caters to their creators' needs, mindset, etc. A mix of catering to their own pain points and their own expertise. This can result in amazing results, true. But, more often that not, they scratch a single person's own itch.

These concepts can also be applied to an oft forgotten place: Developer Land (DL).

Software, nowadays, is highly complex. It's a mix of creativity, off-the-shelf components and libraries, glued together in a perfect (dis)harmony. The high-burden and error-prone process of creating applications leads to reusing – and correctly so – existing components and libraries. The humungous landscape that is the software libraries world (frameworks, classes, generators, development environments, etc.) can be daunting for a lot of developers.

But several developers create libraries to cater to their own pain points, and believe other developers have the same expertise. While this can result in a good software library, things can get pretty messy easily. Hence, DL end users (i.e., those using software libraries in their own applications) face the same problems as UL end users. Confusion, insatisfaction, not meeting their goals. That is, developers also experience bad UX in DL.

So, without further ado, here's a small list of best practices to provide a good UX in Developer Land:

1. Proper APIs: whenever possible, classes, functions, parameters, data types, and any other identifiable naming schemes, should have clear, concise names, including clear naming in REST-style APIs. Even further, they should be self-documented, so that even seasoned developers don't need to RTFM every single time they need to use a particular feature.
2. Documentation: it's never enough to stress this point. Documentation provides detailed explanations not just on how to use each class, function call, etc. (although proper APIs partially fullfil this requirement), installation, configuration, building instructions, etc. must be sane and descriptive. Developers shouldn't assume that everyone knows every tiny bit detail about library X that should existing in path location Y, in order to have something working.
3. Tutorials/Guides: when software libraries are more complex than a Hello World, in can be (it usually is!) daunting to dive right into APIs and reference documents. This is where tutorials and guides appear. They provide easy, step-by-step instructions on how to use libraries, i.e., step by step examples on creating something useful. These positive reinforcement activities do allow for better learning experiences.
4. Examples: while tutorials and guides exemplify usage, they cannot cover every single detail about using all the features provided by a software library. Hence, proper APIs should be complemented with example usage – not just a piece of code, but a detailed, explained step by step usage of each feature.
5. Error handling: let's face it, errors do happen. Even when software is correctly implemented (i.e., bug-free), it can fail due to external stimuli. Thus, software libraries shouldn't fail silently, nor crash abhorrently. Error handling should be built from the ground up, and exposed in a graceful way: less of the C's function-return-error-value, and more of the errors-are-exceptions-on-control-flow.
6. Sandboxes: when libraries really do get complex and tricky, developers are less confident on trying out their features. This gets even worse when libraries handle information-sensitive features (e.g., posting messages to social networks), or which can trigger payment activities. In these cases, developers should provide safe environments – sandboxes – where DL end users can try, test, tweak, and fail on using libraries without penalties.
7. Gratifications: the oft-forgotten realm of inside jokes embedded in software code, comments, etc. They don't offer anything practical, regarding their stated purpose (i.e., functions, etc.). But they do provide a sense of accomplishment – and good laughs – to those who delve and inspect the source code.

And, that's it for now. Happy coding!

Permalink

I've just finished my talk for Portugal's GTUG (Google Technology User Group), entitled Some Notes on UX. On this talk, I shared ideas about User Experience (mostly on the Web) in 3 domains: demystification, inspiration, and guidance. Please find below the slides:

I hope to be fortunate on sharing and discussing these ideas with you (this presentation will always be a work in progress).

Permalink

So, today I've launched a new service, TLD.hack.

According to Wikipedia, a top-level domain hack is:

an unconventional domain name that combines domain levels, especially the top-level domain (TLD), to spell out the full "name" or title of the domain. Well-known examples include blo.gs, del.icio.us, cr.yp.to, e.xplo.it, retou.ch, and goo.gl.

For bad or for worse, TLD hacks are part of the Web. They open the way to registration of new domains that can be memorable - if a bit confusing, sometimes. Since, as of today, there are more than 250 TLDs, it can be a bit cumbersome to test if a specific hack exists.

Let there be TLD.hack to the rescue, hope you enjoy it!

Permalink

Last week Codebits 2010 was held, once again, in Lisbon. As usual, this event/fest/party/hackathon was full of awesome. I'm not going to review it deeply, just search for #codebits2010 in Twitter, in order to get a gist of what happened there during those 3 days.

I gave a talk at the event, on one of my (serious) hobbies, Javascript, entitled Human-powered Javascript Compression for Fun and Gummy Bears. Basically, the talk centred on bending Javascript to your will, knowing what to do with this extremely plastic language, and also what not to do. And, if you didn't attend the talk, you will feel extremely unlucky, since I distributed 2 packs of gummy bears for the audience. Please find below the slides:

Furthermore, since the talk was so much focused as a hands-on experience on tweaking and pushing Javascript around, I made available all the code (HTML+JS) for free at github. Explore it, clone it, change it, experiment.

As a bonus side, I participated in the coding contest, where we developed a multiplayer game development kit for iOS. We were extremely fortunate to finish at 4th place. Stay tuned for more developments on this front, too.

Permalink

I've just read a post entitled The Addictive Allure of Instagram, describing how Instagram, a photo taking application/social network for the iPhone hits the nail on providing its users with a fine, detailed UX.

It's all about pain points, simple UI, less choices, seamless integration with other services. But more importantly, it brings back the emotions of taking, seeing, and sharing photos.

A must read. And a must use, for the app itself.

(via Daring Fireball)

Permalink

But multiplying this presence capability by the billions of people that are online can be cumbersome.

Hence, being easily discoverable is a key point. And a key point in discoverability is username/alias consistency among online communication channels. If a single username is used throughout different services, one can potentiate his own profile/persona.

In tune with this line of thought, check if you have the same username in: email, website, twitter, linkedin, etc. If not, change that, if I may suggest.

In the light of this post, I have eaten my own dogfood. You can now find me at ruidlopes.com, and this blog also reflects these corrections as well.

Permalink

Permalink

My blog, which has been hosted on Blogspot for several years, found a new home at Posterous with the URL http://ruidlopes.posterous.com.

Why? Simplicity.

If you follow my irregular posts by RSS or even directly in the old URL, no change is required. I configured everything so that Blogspot automatically gets all the new posts. Nevertheless, please do feel free to update your feeds accordingly.

Permalink

This week on UX will be particularly focused on Accessibility.

HTML5 and Accessibility

This post discusses the fact that HTML5 is not a panacea for accessibility (nor it should be). Sandi correctly states that, without WCAG and other inclusive design practices, the accessibility experience of a Web site is definitely not guaranteed.

Working Group Decision on ISSUE-30 (longdesc)

For those who might not know about this, longdesc is an HTML attribute for the img element, that aims at providing a thorough description of images. While the alt attribute serves as a quick description/caption of the image, longdesc is critical for situations where an image has a lot of information, such as graphs or paintings.

So, without further ado, longdesc has been removed from the current HTML5 draft. A lot of ink has already flowed around the Web. I'm against this action by the HTML5 Working Group, despite the fact that it is a rarely used attribute, severely used in wrong ways when actually used. aria-describedby is not a solution for many cases where longdesc fits purpose.

A really interesting follow up on this question can be read at a properly entitled blog post How do we save longdesc?. The comments provide a lot of insights and opinions on this issue, as well as several links to more information about it. Please do read it.

Web accessibility for cognitive disabilities and learning difficulties

This blog post at Dev.Opera defines a small, useful set of recommendations on how to make content accessible for people with cognitive disabilities: consistency, structure, focus, readability, transformability, and content. Really interesting read.

bonus point: following these recommendations, your Web site will definitely have a better usability to everyone and, ultimately, provide a better experience for all users.

For completeness, read a 4-years old formal objection to WCAG 2.0 claims on the inclusion of requirements, guidelines, and criteria for making Web content accessible to people with cognitive disabilities.

that's it for now. next week I'll definitely have more to share! meanwhile, if you haven't read previous posts, or would like to re-read them here are the links for all chapters: IV III II I

(this is part of an experiment on posting some links I found around the Web centred on UX topics. most of them come from my shared feed of UX blogs. thanks for reading this post!)

Permalink

Using Multiple Data Sources and Insights to Aid Design

But the best way to grasp this is through the combination of several techniques. This article at inspireUX delves into this problem, through the definition of a framework to help practitioners selecting appropriate approaches. Sometimes, adding just one more cost-friendly technique will deeply broaden the spectrum of insights that one can grasp – which takes us to our second post of the week.

Creative Ways to Use Unmoderated User Research

A recurring proposal, and once again stressed on this article at UXmatters, is to complement usability tests with a low-cost alternative, unmoderated user research. Putting users in their own context, interacting with the software for long periods of time, is a key aspect of this kind of studies. Gathering log data, diaries, etc., complement the technique, and allow for a bigger picture on how people use the software's UI.

Complementarly, a blog post at UX Magazine discusses how to apply remote user research effectively.

Card sorting is dead- long live card sorting

Once again, and keeping up with the spirit of this week's Chapter, the authors stress the fact that card sorting, by itself, most probably won't generate enough useful information from users, and that the time taken for post-it analysis might not be worth the effort. But they do say that it's yet another technique in the UX belt that, complemented with other techniques (e.g., for already deployed Web sites, Web analytics is a paramount helper), provide a better insight on the results from card sorting sessions.

Opinions vs. Data

This article at ignore the code discusses how preconceived ideas can be incredibly wrong. A short discussion about Gmail's latest UI changes that introduce a new, awkward, UI element – a hybrid between a checkbox and a dropdown list – despite how strange it might appear, has usability data backing its effectiveness by a broad range of users. The quantitative beat the qualitative.

that's it for now. next week I'll definitely have more to share! meanwhile, if you haven't read previous posts, or would like to re-read them here are the links for all chapters: III II I

(this is part of an experiment on posting some links I found around the Web centred on UX topics. most of them come from my shared feed of UX blogs. thanks for reading this post!)

Permalink

Chapter III, 7th August 2010 - 13th August 2010

Avoid Being Embarrassed by Your Error Messages

However, several times, UIs provide dead ends when faced with an erratic behaviour. It becomes significantly troublesome to cope with such issues, e.g., cryptic error messages, error numbers, etc. No amount of inference by a human being (other than the programmer who coded it) will be able to discern the problem conveyed on most error messages. This article on UX Matters discusses some of these behaviours of software. The key message from this article is: Think about error messages as part of a conversation with users.

Visualizing Fitts’s Law

This introductory article at Particletree describes thoroughly the properties of Fitts's law, how it can be applied in a 2D scenario (since it was originally devised just for one dimension), and all with the aid of interesting and appealing pictures.

Whether you are a novice or an expert in the UX field, I strongly recommend you to read this article. Well written, straight to the point (pun intended), and it even discusses a bonus point: screen edges (spoiler alert: it's all in the infinite dimensions).

Choices should always be limited to 7+/-2

It's not enough to stress this fact once. It should be repeated ad nauseum. By having lists presented visually, sighted users do not need to (and will not) memorise them, since their affordance is immediate.

Even for blind people, who depend greatly on short-term memory when interacting with information, can cope with big lists of information if they are familiar with the subject (citation needed, but it comes from several observations on usability studies we performed with blind and partially sighted users.).

The $5 Guerrilla User Test

This kind of tests challenge the myth that all usability tests are hard to make, require a lot of users, expensive equipment such as 10000€ eye-trackers, etc. With the right conditions and proper planning, guerrilla usability tests can provide several answers about the UX of a software, and keeps people from skewing their actions for being inside an etheral usability lab.

The fun (dare I say, awesome) side of this article lays at a particular insight: Drunk people are a pretty accurate mimic of distracted, indifferent people.

(that's it for now. next week I'll definitely have more to share.)

Permalink

Chapter II, 31st July 2010 - 6th August 2010

Guidance on Style Guides: Lessons Learned

Hence, Style Guides come to help maintaining consistency after UX design. In this article on the STC Usability SIG Newsletter discusses some key points to be taken when creating a Style Guide.

Complementarily to this post, this week's readings also focused on more things about style guides:

• A List Apart's advice on writing style guides, as well as their own style guide;
• BBC's revamp of their CMS;
• UX Booth's guide to content strategy.

Nondiscrimination on the Basis of Disability

This article at the Federal Register delineates the strategy for updating USA's laws on this subject, specifically centred on how to legislate the requirement for Websites that provide information and services to the public.

One of the biggest eye-openers in the proposal is that they are aiming not just to governmental agencies and offices, but also at enforcing accessibility on privately-owned services that provide public services, such as online shopping.

I really really wish that this kind of hands-on governmental initiatives are pushed forward and enforced throughout the world.

Micro-Interactions vs. Macro-Interactions

Markus delves into discussing several macro properties of UIs, such as consistency among screens (or pages), among navigation, etc., by means of task analysis, wireframing, information architecture, and other common practices of the User Experience Design process. So far so good.

But he correctly points out that, despite of the macro, the details of the micro are oft left out of UxD. I agree with him when he states that describing micro interactions, such as widgets' behaviours, are really difficult to attain with wireframes, storyboards, or even textual descriptions. His proposal of the micro is to delve into small usable prototypes which can be interacted with.

The gist that comes from this post: It's all in the details.

Five Indispensable Skills for UX Mastery

While a really interesting read, I'd have to add a 6th indispensable skill: writing. It's embedded in the entire UxD process, and as important as sketches. I'd dare to say that acquiring proper writing skills is tougher than four of the five original skills. Mastering the presenting skill is probably the toughest of all, since it encompasses a bit of all other skills, as well as the writing one.

Still, all of them come from practicing, reading, thinking, and willing to learn. In this spirit, here's two more articles related to these questions:

• Does Language Influence Culture? This provocative article from the WSJ discusses the profound issues of language and culture, and how they are intertwined. It is a must read, if you do user research, especially when cross-cultural;
• How to Read Body Language. This article at wikiHow centres on learning to understand people just by watching them (both actively and passively). These techniques are really fashionable now due to the Lie to me TV series, but they do oft make different in UX, particularly when facilitating in user interviews and usability tests: the body speaks more truths than what the user says.

Permalink

Chapter I, 24th July 2010 - 30th July 2010

Ethnography in UX

Context is everything. Understanding the situational surroundings, in-situ culture, etc. is as important as everything else. This article by UX matters discusses the usage of ethnography as another tool on the UX expert's belt.

On a side note, I had the pleasure of reading Contextual Design: Defining Customer-Centered Systems as part of my undergrad formation. It goes deep into the issues of using ethnography as the centre of designing usable systems. I strongly recommend you to read it too, but here's the Wikipedia gist on Contextual Design as a first peek into these concepts.

Psychological Study of Web Designs

Nevertheless, practical outcomes of psychology are applicable when designing software. This article at Abduzeedo discusses some of psychology that can boost the Return on Investment of a Website, such as trust or colour.

A Real Web Design Application

Provocative, I'm sure. But there might be a business opportunity for like-minded software developers to enter into the reign of Adobe. A happier Web designer will certainly deliver better designs.

(Be sure to read the post and the comments section too)

Interviewing Users

It's latest article discusses the pros and cons of interviewing users in the context of usability studies. While these practices are essential, they cannot be taken lightly. Starting from how questions are formulated, and passing through the lack of results from singled-out focus groups, Nielsen's advice finishes with the triangulation of studies as the best solution.

Recent studies we've done centred around using expert analysis, usability tests, and focus groups as complementary techniques to ensure a high quality usability study of a software. I can attest that it sure does work.

What's in a Name?

The best advices from this article are: to put a glossary of UX terms in your proposals, including descriptive images for each one (when possible); and decide on a common lingo to be used inside your team.

(that's it for now. next week I'll definitely have more to share.)

Permalink

Ok, disclaimer done, onto the analysis itself.

First Contender

The main reasons that made me delve into the iPhone concern two things: the user experience that Apple craves for in all their products, and their immense applications catalogue App Store. For me, these two reasons have kept me a very very happy user for these two years. But here's a more detailed analysis of each one.

User Experience

First focus: hardware. My iPhone is currently two years old. In terms of longevity, that would make this phone almost a dinosaur. But it certainly doesn't feel like one. Of course, being the first gen iPhone, the speakers aren't that great. The lack of 3G (only GPRS used outside of wifi) does make me aware of the bloat of some (most?) Web sites - almost better than using YSlow :) The 16GB tend to fill up real quickly, since I have the bad habbit of listening to full discographies. It would also be nice to rely on real GPS, instead of the poorer grade A-GPS. Mind me, all of these issues have been solved in more recent versions of the iPhone.

So, even with all these limitations, I feel extremely happy with the phone, even after two years. I believe that this is due to a non-quantifiable property of the device itself (hardware+software): it's tangible. The way one holds the device and interacts with it just feels natural. And, for me (and a lot of people), that's more important. Not everything is about a buttload of features.

Second focus: software. The iPhone OS plays a crucial role on meeting users' expectations. It's stability allows for little room for failure (after all, it's a UNIX-ish operating system). The constant upgrades on the firmware provided a game-changing approach to mobile phones, where user experience is improved at each cycle: new features appear, old bugs are squashed, performance is improved, battery life is extended. This alone has extended the lifetime of the phone.

Another thing that the software plays a crucial role on the phone's tangibility concerns animations. Yes, animations can be (and often are) crappy, and deeply disturb the peace (i.e., experience) of all users, from novice to experts. But these animations play a significant role on the experience. Icons, buttons, pages, etc., all UI elements feel right, almost real, without laying at a UI-ish uncanny valley. The same factor applies to the soft keyboard. It's pure magic. It works way much better than what I would expect (and subsequent firmware upgrades have greatly improved its responsiveness), but the lack of a self-learning auto-completion dictionary is a very bad design choice.

Since I'm discussing a phone, ultimately I have to talk a bit about that part of the experience. Good address book, good phone interface (I just love its proximity sensor thingy), excellent SMS (that's texting for you americans) capabilities - esp. its conversational look, just like IM. One thing that I personally miss - and it does bother me a lot - is the lack of SMS sending status (i.e., delivered, pending, failed).

But there's more: bundled apps are great (read: the out-of-the-box experience is good from the ground start).

Using the Web with my fingers is, to say the least, an insightful experience. Mobile Safari nails it. Even in non-tailored Web pages, the "desktop"-ish Web becomes tangible, just like a (physical!!!) piece of paper. E.g., it became natural to me (read: part of my daily routine) to read the news while commuting in the subway. Furthermore, the ability of bookmarking Web sites to the phone's home screen is a win. With the ever growing (infinite?) tailoring of Web sites to the constraints imposed by the phone, several Web sites and Web applications are part of my home screen (esp. thanks to Google!). On a side note, not having Flash nor Java is a killer feature.

Being a descendant of the iPod, it's music playing abilities are also up to the expected. Tip: do not forget to turn off "shake to shuffle", otherwise music will skip while you're walking (bad default). Overall, the experience is as good as expected. However, while it's possible to listen to music while interacting with other apps (take that, you no-multitasking-pointing-fingerers!), I'd love to have the ability to scrobble my tracks directly to last.fm. Well, technically I'm doing that, but I had to jailbreak the phone first.

The maps application plays it role pretty well too. Even with A-GPS, it locates me accurately. Couple with Google's instructions on directions it has saved me a lot of time. Now I have zero excuses for getting lost somewhere.

Youtube. One of the holly grails of Internet-centric procrastination. Its barebones approach to the user interface provides a better UX compared to the Web version: straight-to-the-point controls, full-screen, and zero hormone-induced teenager-fuelled comments.

Using the Mail app, well, is less optimal than desired (it's crappy, really), to say the least. Having ported all my mail to Gmail, and having a complex mail configuration at my lab, the bundled Mail application acts funny, just like its desktop counterpart. Coupled with the inability of tagging Gmail messages, I ported my e-mail experience to Google's Gmail on the Web (optimised for smart phones) and it feels great. One less point to Apple for this, but half added to Mobile Safari. (Actually, this experience with desktop/mobile mail clients would provide enough fodder for an in-depth blog post. I hate them all with a passion.)

Finally, the camera. It's crappy and slow. Enough for twitting and facebooking, I say. Others believe that its limitations foster creativity.

App Store

But having a walled garden like the App Store is often beneficial to users' experience with the device. Yes, users are dumb and often click (tap?) where they shouldn't and then, bam! their devices become part of botnets.

My phone is jailbroken and I only take advantage of the aforementioned last.fm scrobbling capability. I guess it says something about the urge of (not!) having a more open approach to the App Store.

Another thing that I believe the App Store pretty much hit the nail concerns their App acceptance policy. Despite being draconian sometimes, it imposes a quality level on the App's UX which is often just encountered in gaming consoles online stores. The App Store is well organised (despite suffering from some growing pains) and all applications provide a good explanation and screenshots to convey the experience they want to convey to their potential customers.

Despite all of this mumbo-jumbo, I have expanded and extended my experience with the phone with a motherload of Apps that I use on an almost daily basis. Games (e.g., Traffic Rush, Orba), utilities (e.g., AccuWeather, Cine SAPO, GuitarToolkit), social networking on steroids (e.g., Pond, Facebook, Foursquare), and news reading (e.g., Publico, New York Times), InstaPaper).

Overall, the "there's an app for that" moniker is really true. And overall, apps do provide a great user experience. Just look at some examples.

Second Contender

But first, an obvious remark: I have been using the Nexus for just 2 weeks now, which is close to 100x less time. This fact single-handedly undermines the comparison in a couple of things: the tangible metaphors provided by both systems differ, thus I often make some mistakes while interacting with the Nexus. These type of issues will not have a role for discussion on which is the best device. But the experience on using a tangible device for two years now, yes, that will have a role in the discussion. /endofdisclaimer Now, onto the analysis itself.

User Experience

The phone also feels very fast. Actually it feels a lot faster than my iPhone (not sure about its speed comparison with the 3GS, though). This single fact poses significant implications on the quality of the UX of the device. A faster CPU does imply the capability to improve the UX.

Another feature touted by iPhone killers concerns having a memory card slot. The Nexus accomplishes this with a standard microSD slot, with a bundled 4GB card. Less than the memory of the iPhone, but expandable to a theoretical 128GB. This will be great to carry my entire music library and still have some space left for pictures.

The Nexus' physical buttons provide a different UX to interact with the phone. One, which I call "the nipple" is similar to Blackberry's trackball. I loathe it and wished that HTC and Google's industrial designers hadn't had the chance to include it. It's too imprecise, feels like an afterthough, too little gripe. (tip: do NOT use it to "click".) But hey, I suppose they wanted to cater to Blackberry customers, providing a shorter path for conversion. Nevertheless, the trackball also acts as a LED, blinking when a notification appears. I like this a lot!

The other four buttons (back, menu, home, search) are touchable buttons, almost like software buttons, and provide physical feedback through vibration (loved this part). In time, I have quickly grasped their usage through the daily interaction with the phone. Different from the iPhone, not better nor worse. Regarding pure soft keys (i.e., touch keyboard), I'm not sure about its effectiveness while typing. The auto-completion is better than the iPhone's, but the smaller spacing between keys is a big no-no for my somewhat fat fingers.

Which brings me to the biggest gripe wrt to the touch screen. Yes, I can confirm it's less imprecise than the iPhone's, just like others have extensively previously tested. I have found one particular issue with this touch screen: it fails A LOT (and by that I mean almost always!) with moisturised hands... Impossible to type, to hit buttons, etc. Pretty unusable. Other than that, it's more than good (after all, it's capacitive).

Still on the hardware side, the Camera is absolutely better than my iPhone's. Faster, more responsive, with a better lens (do not care about megapixels, that's a crappy way to compare camera quality). Loving it. Multimedia-wise, this hardware analysis finishes with a heads up to the speakers: great quality coming out of these babies!

Now onto software.

By being based on the Linux Kernel (also UNIX-ish), the Android platform started great. Applications run inside a VM, Dalvik. Despite of this, I do not feel any sluggishness on running apps. By having it coupled with the leveraging of the Java platform for development, it's a winning recipe for success.

Going up a couple of layers in the OS, I reach the user interface. Most of the interaction metaphors feel natural, tangible. The inclusion of the "back" button in the phone provides to be useful especially when getting lost in seesmic-twitter-detail-link-Web page hyperspaces.

As a phone, it provides the same UX as the iPhone. Contacts, calling, and SMS, all function perfectly for my daily usage without any burden. And they provide me with SMS notifications. Yay! (Hear that, Apple?)

One of the things that have impressed me in the Nexus, and I already expected something like this, concerns its integration of Google services. You log-in into your user account and everything is setup and working: Mail, calendar, chat. Despite the fact that Gmail labels aren't coloured as they should (they're all blue!), Gmail is one killer app on Android. Almost as good as its mobile Web version.

Which brings me into the next topic: Web. They have exceeded their expectations. The Nexus is an awesome device to interact with the Web. The speedy CPU coupled the excellent V8 virtual machine provide a great experience, even with JS-heavy Web pages. Substantially better than in the iPhone. One particular aspect they have catered to more powerful users is the ability to hook features into the browser, such as providing support to InstaPaper. This is one of the cases where under-hooking the OS provides added values.

The same applies to listening to music: since the OS is more open to applications, last.fm scrobbling works seamlessly.

However, UX-wise, I feel that sometimes the Nexus is more akin to engineering than to experiencing. More is more, contrary to the "less is more" adagio. Things such as:

• "Stricter" animations (i.e., more stiff, less smooth, and more sluggish) kill some of the expected tangible properties.
• Several Yes/No confirmation dialogs, contrary to usability guidelines.
• Insensible defaults, such as leaving the chat open, even when you kill the Gtalk application. I had to figure out I had to logout of the chat for this to stop.
• Background apps is a neat feature, theoretically. However it drains too much battery, makes the system a bit more sluggish, and task management becomes a burden the user has to handle. I wished there was a toggle to make this more iPhone-ish...
• Did I mention it takes 9 freaking touches to kill an application? (Yes, this is a case where "there's an app for that" diminishes the issue, but doesn't solve it UX-wise).
• There's no way to disable Data communication. I just reached the limits of my pre-paid data plan real quickly thanks to this. (Yes, this is also a case where "there's an app for that" diminishes the issue, but doesn't solve it UX-wise).

Android Market

This leaves open just a small breach of applications. Coupled with the less tight rules for publishing applications, the overall quality of the Android Market is less than optimal. The usual suspects are there (e.g., Facebook even comes pre-installed, seesmic, etc.). Unfortunately I have noticed that most of the applications have a lower quality (features, UX), when compared to their iPhone counterpart.

However, it leaves too much out. I mentioned previously that App Store's ability to cater to my expectations has a significant role on the tangibility of the device. It's not a phone, nor a Web browser. It's all of that and much more.

Final thoughts

Competition is great! Having a ground-breaking device such as the iPhone has put a lot (A LOT) of companies on their toes wrt Internet, Web, phone calling, game platforms, application developers, mobility, pervasiveness. Companies started touting their newer phones as iPhone killers, particularly by having more features (not by having a better UX - mind that).

Google also did that with the Nexus, but keeping a keen eye on the UX. Despite some of its awkwardnesses, I believe Google will further improve Android's UX, since they are strong advocates of Iterative Design techniques. Ultimately, I expect the Nexus to become par with the current state of the iPhone UX-wise.

But Apple will keep feeling the pressure of the Android platform, and will push forward the boundaries of tangible UX on smart phones. Unfortunately I am not so sure whether the Android Market will catch up with the App Store, both in quantity and quality terms. I predict that, if that doesn't happen, Google (and other contenders) will lose this war. Even if Apple doesn't get its head straight wrt its Web strategy.

I'm carrying both in my pocket, every day. I interact with both all the time (sometimes at the same time - no roll tongue intended). Let's see what the future will say for both devices and how that will change the experience I'm having.

Permalink

It has already a kickass community doing a lot of experimenting with it: media servers, backup servers, or even home automation stuff. I fell in love with it - its potential -, and its price ($99 + dementia-rated customs overheads in Portugal. tip: around the same amount of extra taxes. ouch).

I have read a lot about what can (not) be done with a plug computer, and I'm eager to start working with it. But first things first. The development environment has been created mostly for linux. And I'm running OS X. Thus I've downloaded VirtualBox and I'm currently in the process of installing Ubuntu on it, just to have a proper development environment kicking.

The next post about SheevaPlug will talk about the installation process of the development kit and getting something visible to boot.

Permalink