I Love the Web. Or how the Web changed my life, forever.

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!

Posted via email from ruidlopes' postground

Unfocused Groups

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.

Posted via email from ruidlopes' postground

How far can we stretch the notion of Web browsers and Web apps?

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.

Posted via email from ruidlopes' postground

Measuring User Experience — Initial Forays

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.

Posted via email from ruidlopes' postground

Beyond Usability - User Experience

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 :)

Posted via email from ruidlopes' postground

Developers deserve a good UX, too

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!

Posted via email from ruidlopes' postground

Some notes on UX

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:

Some notes on UX

View more presentations from Rui Lopes.

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

Posted via email from ruidlopes' postground