Rui Lopes' blog:ground

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

2011-10-02T03:22:00.001+01:00

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

2011-09-03T19:28:00.001+01:00

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?

2011-04-05T11:02:00.001+01:00

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:

It is accessed via the Web (i.e., through HTTP);
It interacts with Web resources;
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

2011-03-17T15:18:00.001Z

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

2011-02-25T00:39:00.001Z

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

2010-12-13T23:12:00.001Z

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:

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.
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.
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.
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.
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.
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.
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

2010-11-30T19:43:00.001Z

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

TLD.hack launched!

2010-11-19T23:07:00.001Z

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!

Posted via email from ruidlopes' postground

Codebits 2010: talk, gummy bears, et al.

2010-11-15T22:29:00.001Z

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:

Human-powered Javascript Compression for Fun and Gummy Bears

View more presentations from Rui Lopes.

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.

Posted via email from ruidlopes' postground

A fine example of a good UX

2010-10-30T14:05:00.001+01:00

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)

Posted via email from ruidlopes' postground

On username consistency

2010-10-27T00:21:00.001+01:00

Being online nowadays is pretty much a common thing. Wether on social networks, blogs, homepages, and whatnots, an online presence can potentiate growth.

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.

Posted via email from ruidlopes' postground

Some weeks of UX: Closure

2010-10-26T21:49:00.001+01:00

Some of the previous posts in this blog concerned a weekly analysis of UX related news, blog posts, and other miscellanea community activities. You may have noticed that the burst of posts ended abruptly some weeks ago. While an interesting and always important exercise, the weekly rate format proved to be a cumbersome, complex task involving reading a lot, analysing, thinking, and rethorical discourses. Hence the stop (right before I went on vacations, too). I'm sure I'll return with a new format on this blog that tackles the UX community blurb and fluff. Stay tuned. Meanwhile, please do continue following and reading posts from my shared feed of UX blogs.

Posted via email from ruidlopes' postground

A New Home

2010-10-26T16:39:00.001+01:00

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.

Posted via email from ruidlopes's postground

This week on UX: Chapter V

2010-08-27T22:10:00.000+01:00

Chapter V, 21st August 2010 - 27th August 2010

This week on UX will be particularly focused on Accessibility.

HTML5 and Accessibility

The newest version of HTML5 is being praised all over the Web. With new features like Canvas and offline cache, it sure provides a solid foundation to create HTML-based applications, running on the Web browser, available on the Web.

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)

Which brings us to the biggest discussion this week on accessibility blogs, mailing lists, twitter, and other forums. 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

The oft perceived bastard child of accessibility, due to its immense spectrum of related disabilities and lack of knowledge on how to cope with them. Cognitive disabilities are also, probably, the most difficult to be taken into account on design phases, usability testing, etc.

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

This week on UX: Chapter IV

2010-08-21T00:20:00.002+01:00

Chapter IV, 14th August 2010 - 20th August 2010

Using Multiple Data Sources and Insights to Aid Design

Studying how people use software is not a trivial task. UX practitioners have their own preferred techniques: usability studies, ethnography, or even CPM-GOMS. However, most of the time, people tend to use one or two techniques, depending on time, knowledge, budget, etc.

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

Doing large usability tests, covering different user profiles, is one of the best ways of understanding how usable a software is. But the price and time tags for such studies limits their application more often than not.

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

Oh boy, this title could surely raise flame wars between UX practitioners. But rest assured – spoiler alert – at the end of this article at cimex, it is mentioned that Card sorting is not dead, far from it.

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

Final post for this week. And, once again, talking about the same subject: having a one-sided view of UX analysis can lead to misleading (no pun intended) assumptions.

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

This week on UX: Chapter III

2010-08-14T01:44:00.000+01:00

(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.)

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

Avoid Being Embarrassed by Your Error Messages

This week's first instalment begins with an often forgotten issue with software: the usability of software gone wrong. Let's face it: all non-trivial software has bugs. And humans are more than accustomed to live with unexpected situations: it's what cognitive psychologists call inference.

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

Fitts's law. The golden treasure of Usability. One of the few mathematical formulas than can quantify a usability property. For those who don't know or recall what this law states, it's explained in a few simple terms: the smaller the clickable area, the more difficult it becomes to reach it with the mouse quickly.

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

This meta article on UX Myths provides several links to the discussion and debunking of one of the greatest myths in usability: the one that states that since people are only able to memorise few things in their short-term memory, they should be presented with lists with limited size.

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

It seems that this week's articles are particularly focused on classical usability/UX topics. This last one discusses guerrilla usability testing: stop at a caffee and ask someone if they can help you with a small set of tasks.

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

This week on UX: Chapter II

2010-08-06T13:15:00.000+01:00

(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.)

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

Guidance on Style Guides: Lessons Learned

When defining the UX of a software product, stopping at wireframes or graphical mockups is not enough. Content is King. Having a great UI with poor, inappropriate content, designed UXs will fail miserably. Extensibility is Desired. Especially on the Web side, the extremely dynamic growth of software implies extending UIs to cope with new features.

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

Access to information without barriers is a Human Right. Consequently, most countries have legislation to enforce it, ranging from non-discrimination in work, to barrier-free buildings, and accessible Web sites.

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

A rogue blog post discussing a particularly interesting aspect of UX: how user gratification is reached by taking into account the macro and the micro in available 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

The last article I will discuss in this post concerns a UX skill set that every UX designer must learn, master, and bend: sketching, storytelling, critiquing, presenting, and facilitating. Jared goes into detail in his latest instalment at UIE Brain Sparks, for each one of these skills.

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.

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

This week on UX: Chapter I

2010-07-31T00:55:00.000+01:00

(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.)

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

Ethnography in UX

Usability (and user experience, by extension) does not rely just on the skills and proficiency of user experience designers on creating good software. At the same time, when interacting with end users through the many, well known techniques - card sorting, interviews, etc. - it is insufficient to have them sit at your office.

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

When creating things for people, psychology is a key factor for success. While deep analysis with theoretical cognitive models such as GOMS and ACT-R are applicable in Human-Computer Interaction situations, they are often too complex to be used on a daily basis.

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

Designing a Web site aims at providing a good user experience for its target audience. And this is done with the aid of miscellaneous tools, ranging from graphical design to hand coding HTML. However, the landscape of powerful tools to aid Web designers is worse than desired (talking about eating your own dog food...) In this article, Jason Santa Maria puts out his own frustrations on designing Web sites, and what would be the ideal tool for this task.

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

Nielsen's bi-weekly column is frequently filled with good insights and lessons into usability processes.

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?

This was probably the most significant and most interesting read I had this week. UX Magazine's article provides us a detailed analysis of UX's meta level: keywords, jargon, names, and how it influences interaction with clients and co-workers.

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

A personal take on the UX of two smart phones

2010-04-05T19:22:00.000+01:00

(Yes, the title does not talk about the iPhone and the Nexus One, but this post discusses my recent experience with both devices. I've dismissed the sensationalistic headline as an anti-self-promotion statement.)

Ok, disclaimer done, onto the analysis itself.

First Contender

Almost two years ago (that's April 2008), I acquired an iPhone, first generation, 16GB, through some friends in the US. The immediate experience I had with the phone was that of awe, while attending the WWW 2008 conference. Free wifi meant that over 50% of the time I was interacting with the Web and e-mail seamlessly, without having my laptop in, well..., my lap. My mobility during the entire conference had greatly changed. Heck, I even could make calls through wifi using Fring, with an exceptional sound quality and low ping - and I was behind the Great Firewall of China while at the conference. So far, so good.

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

For those who don't know me that well, I'm currently a researcher on the HCIM Lab. Therefore, I focus a lot of my work and attention to everything related with user experience (UX).

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

Yes it's a walled garden. I think Apple should provide a semi-complex (but legal) way to install non-verified applications, to cater to their power users (are these users their main audience?).

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

I had the pleasure to be given a Nexus One, the oft desired Android phone created by Google, touted as the iPhone killer. Due to my extensive usage with the iPhone, as you can tell from the excessive number of paragraphs above, I had to compare both devices.

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

Being a Google fan myself (Search, News, Gmail, Calendar, and Reader used recurrently on a daily basis), my expectations for this device were high. The first thing I noticed is the gorgeous, impressive, beautiful AMOLED screen. Putting this device side-by-side with the iPhone, the latter pales. A lot.

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

The first issue that arose concerns the availability of paid apps. Since I'm located in Portugal, Google says it's a no-no in this place. Oh, Google...

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

(I'm pretty sure I have forgot to mention things about my experience with both phones. But probably that means that those things aren't that important for me...)

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.

Experimenting with SheevaPlug: prologue

2009-07-18T01:50:00.004+01:00

Recently I've received my brand new SheevaPlug Development Kit. What is this exactly? Basically, it's a plug computer that runs on a low-power ARM (I think) CPU, has 512MB RAM, 512 flash, USB 2.0 and GigaBit. It only lacks a video/sound out (hopefully just to trigger creativity from all of us ;).

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.

The new old school DIY

2009-07-18T01:13:00.006+01:00

I have a need to express myself. Lately I've been interested in exploring the DIY culture. That is, "Do it yourself". With so many things explored on the Web, lots and lots of ideas have sprout out of my mind. Some already implemented, others only on the paper, and others still kept in the back of my head.

So, I like computers, music, and I'm not afraid of getting my hands dirty with software/hardware (especially a mix of both). Thus, these ideas express my thinking and eagerness of really doing something myself, just for the kicks. As technological progress has been keeping its pace, we're not stuck with HAM Radio stuff. Moore's law is a blessing in the 21st century DIY movement too. Smaller hardware + better software = faster prototyping. Welcome to the new old school DIY.

Enough talk. Here's what I've been up to as of now (July 18th 2009):

Software-based sound generation machines:
- an interactive tweet (as in bird chirp) generator, a beep pattern creator (kind of a drum machine, but with beeps), and a pretty configurable noisebox, all implemented in Processing;
- an iPhone accelerometer-based theremin.

An arduino Mega is already waiting for some junk to be plugged, in order to transform the sound generation machines into something more physical.

Just got a SheevaPlug to hack some media server things, as well as some home automation stuff.

Hacking a bit with javascript something that could remotely resemble with Demoscene things.

experimenting with multi-touch + processing.js (yes, javascript) interactive art on the iPhone.

Since I'm lazy, none of these projects have been made publicly available, yet. Ping me if you feel like contributing to some (or all) of these ideas, even if they stay at the vaporware level :)

Stay tuned, 'cause I'll be posting about these projects (whenever I feel like blogging). And that's all for a 1:48am Saturday rant.

P.S. sorry for not posting for so long, but you can keep the pace of my musings on my twitter account

whit.me: the Whats, the Whys, and the Hows.

2008-12-15T15:24:00.004Z

Well, not so long ago, I've launched a service for URL shortening, whit.me. If you don't know that much about URL shorteners, please head to Wikipedia for a crash course. The canonical (and most famous) example for this type of services is TinyURL.

Thorough reviews on URL shortening services can be found elsewhere on the Web. This begs for the question: why another URL shortener, since they appear like mushrooms? Lets start by analysing what does whit.me has in common with all of them:

Short URLs: well, it's the main purpose of the service. whit.me's have a typical length of 21 chars (e.g., http://whit.me/XXXXXX), but they can be reduced to a 16 chars count;

Automatic redirection: by default, following a whit.me URL will automatically redirect to the linked Web page;

Manual redirection: to prevent URL obfuscation (which can lead to annoyances such as spamming or rick-rolling);

Custom aliases: to help making short URLs more user-friendly;

Bookmarklet: always useful, to lower the entry barrier on interacting with URL shortening services;

APIs: JSON (and JSONP) APIs provide simple endpoints to help flourishing an ecosystem built on whit.me's shoulders.

Now, why might (should?) you change from your preferred/favourite URL shortening service to whit.me? Some highlights:

High availability: whit.me sits on top of Google App Engine, which ensures a high quality of service for whit.me and, consequently, ensures that whit.me short URLs will not suffer from link rot, or even service unavailability;

Multiple URLs: few services allow linking to multiple Web pages. It has often been one of the key problems with the Web, on-to-many links (in comparison with other hypertext systems);

Annotation: additionally to the URLs, one can add a simple text note to enrich the context of the linked Web pages;

Integration in Web sites: By embedding a script into any Web page, existing whit.me URLs become active, by displaying a drop-down menu in-situ with all the URLs (view example);

iPhone-friendly: URL redirection pages also have an iPhone friendly user interface, which can be used e.g. for the creation of start pages for Web navigation (and properly bookmarked to the Home screen).

Such a simple service can, of course, be further expanded with other features (some present in competing services) such as spam detection, link analytics, personal link management, etc. (in no relevant order) Naturally, whit.me will evolve in the future to cover these features. I have planned several other features (not present in any URL shortening service, as far as I can tell), which will increase its value from the perspective of all users (those who create/manage URLs, and those who just click on them). If all goes as expected, whit.me will be much more than simply URL shortening, but indeed a nice platform for information/navigation management for the Web-savvy. More on this later on (you're free - and more than welcome - to follow me in twitter to get updates on this as soon as they come out).

Developing this type of services is really simple, since there's no special magic or voodoo required to master. This was quickly hacked with a set of technologies: Google App Engine, Python, jQuery, and, of course, all outputting and manipulating the ubiquitous HTML+CSS Web combo. Some (probably) interesting tidbits/hacks in Python and App Engine's APIs have given rise to a nice simple framework that someday might be extracted and refactored into a small stand-alone project on itself.

However, reaching the sweet spot on User Experience is a difficult task. Keeping the user interface (UI) simple and attractive is not a trivial task, since whit.me supports more features than the common URL shortener. I believe that, after some iterations, it has reached UI stability. From now on, all features added to whit.me will probably take a while to be launched, to ensure that User Experience is maintained or, ideally, improved.

Stay tuned!

Writing Workflow for Scientific Articles

2008-06-03T15:42:00.012+01:00

I'm a researcher. An important part of my work concerns writing peer-reviewed scientific papers, in order to expose my work in different scientific venues, such as symposiums, conferences, journals, and books.

Having an excellent research work, with excellent results and findings, is insufficient to have a paper accepted. An important part of this process relates to exposing your ideas, your results. And writing papers is really hard task. It's a mix of sweating to find the proper words and to put them in the proper places, with a fluid sequence of ideas and explanations. It's almost an art form, despite some fairly dogmatic (common-sense?) items that must be present, such as state-of-the-art review, introduction and conclusions, etc.

To achieve a an accepted quality in the writing process (assuming that the actual content is scientifically relevant, of course), I typically perform a well-defined set of tasks: research on existing (and relevant) state-of-the-art work (hand-in-hand with the development of the research work and results gathering/analysis), organise high-level ideas into concepts, drill, cite work, read, annotate, and iterate until reaching the desired result (or, more often than not, reaching the deadline).

This fairly complex and exhausting process can be leveraged a bit by using the right tools at the right time, in order to shift my focus towards Getting Things Done. That is, not worrying about crashing document editors, text formatting, citing format, print+comment+rectify/improve. Just focus on structure on my ideas and write them in a coherent way.

Furthermore, the sheer amount of research work that is published every year in related venues makes it increasingly difficult to find needles in haystacks. That is, find that research article in the piles of paper sitting in the desk, unorganised or, at best, stored in shelves. Obviously, this process doesn't scale. It's an evident role for digital technologies, specially for bibliography and citation management tasks.

I think that several researchers can relate to these scenarios. Hence, all of this blabber leads to my suggestion of a workflow optimised for scientific articles writing tasks, tailored to the best software I could find. On OS X. I'm not sure if some of the software I'll be talking about in the rest of this post has counterparts in other platforms. If so, please feel free to comment and contribute with some thoughts and links.

LaTeX

No researcher in her/his own mind writes scientific articles with other software (unless it's specifically prohibited). LaTeX, a set of extensions to the TeX typing system, where one focuses just on document structure (i.e., abstract, sections, etc.) and on content itself. LaTeX files are plain text files. They are parsed and processed with LaTeX software through one of the several flavours wildly available on the Web, resulting on either a PostScript document (.PS) or a universally accepted PDF.

Despite some problems of LaTeX, such as (oft) lack of WYSIWYG software (due to its typesetting compiler-alike nature), the results are of high-quality and WYSIWYP (What You See Is What You Print). Add that to the almost ubiquitous availability of LaTeX templates on conference/journal websites, a really good automatic bibliography formatter (BibTeX), coupled with an almost dauntingly comprehensive number of utilities, and you've got yourself a must-have typesetting software for scientific papers.

There are several LaTeX distributions at one's disposal, for every platform. My preferred choice on OS X goes to MacTeX, since it is geared toward OS X's look&feel on supportive tools, as well as correct integration with the OS (read: it just works out-of-the-box).

So, LaTeX will be the centre on which the rest of my software choices gravitate around.

Papers

As explained earlier, managing state-of-the-art and other relevant sources of information can be daunting. Either at a physical level (stacks of real printed paper) or at the digital (folders), managing and searching through all papers to find that particular one you're looking for (and with a paper submission deadline lurking in the corner) is just cumbersome.

Papers will help you on this (too obvious name for a software!) It's a really good software to manage, organise, and usefully leverage your entire collection of PDFs laying around in the hard drive. It integrates with well-known scientific digital libraries, including ACM, IEEE Explore, arXiv, among many many others (and it's plugin based for repositories integration).

Despite the fact that one has to pay a license to use it (€29, not that expensive), trust me on this one, it's worth the money. With Papers I can tag (i.e., multi-category), annotate, and search through my own repository within the program, as well as through Spotlight.

One more thing. It affords exporting papers' metadata into the BibTeX format. This way, I can manage everything related to what I have to cite in a single program. It is the right hammer to the right nail.

Scrivener

At some point is time to put thoughts, ideas, and results into words. As I previously said, it's not easy. Almost no one can write a paper top to bottom, from the first word to the last. It's an iterative process that starts invariantly with organising ideas in a coherent line of thought. That's when Scrivener comes to help.

Scrivener is a tool targeted to all writers that exploits the typical workflow of drafts, loose notes, and combining them into a consistent piece. It's fairly similar to scientific writing, minus some issues that I'll describe later on. One of its killer features is the full-screen editing mode. I've written an essay before about the benefits of full-screen applications, ergo Scrivener fits perfectly into this line of thought. It hides all other apps, animations, popups, and everything that might stand in the way of the writing process. This way, one focuses just on what's supposed to be done: writing that paper.

This software also supports researching tasks (lato sensus), including searching the Web, bookmarking Webpages, as well as annotating text drafts. I do not advise performing all of these tasks within Scrivener. To put it simple: use it just to organise your ideas, structure your text in different drafts, and that's it. Papers and other software listed in this essay will streamline research and annotating tasks in a better way.

Oh, and did I mention that Scrivener exports into the LaTeX file format?

TextMate, Skim, and pdfsync

After having the core texts for the paper converted to LaTeX, one has to delve into details and typeset it. Editing it in a generic brand or non-specialised text editor is something from the last century. With the current days of syntax highlighting and IDEs, a lot of choices are available.

Furthermore, LaTeX is a command line oriented software package. And that's how it should (continue to) be. However, one typically wastes too much time opening a shell and running a set of commands to typeset LaTeX documents.

To complete the workflow I've described earlier, this detailing and improving process includes annotating the paper with comments, highlights, strikes, underlines, etc. Since I'm talking about an all-digital workflow, the process of annotating and editing must be as simple as possible, mimicking the print-annotate-edit traditional process.

All of this can be easily avoidable with a tailored LaTeX text editor plus some useful tools.

While other choices are available, my personal belief is that the workflow is better supported and streamlined with TextMate.

TextMate is an all purpose text editor mostly targeted to programming tasks. It was popularised by the Ruby on Rails guys, as a simple, lightwight, and GTD-friendly text editor (I strongly agree with this opinion.) It also provides a comprehensive support for different programming languages and, as you surely have figured out, supports LaTeX out-of-the-box.

Through a bunch of keystrokes , the typeset tasks are instantly launched, and a user-friendly window presents possible errors and warnings that might occur. Citations are easily managed, and syntax highlighting provide visual cues to LaTeX keywords.

Within the iterative process of improving the paper one's writing, the back and forth reading, annotating, and editing process can be really tiresome. Therefore, to mitigate such problem, two other tools can help getting back on track on the main task: finishing the paper. These tools are pdfsync (which is already bundled in LaTeX distributions) and Skim.

pdfsync provides the core support for swinging between the typeset PDF and the LaTeX source (with a fairly good granularity). Setting it up just requires adding a \usepackage{pdfsync} on your LaTeX preamble. After typesetting, a marker will appear on the PDF, representing the position your cursor is located within the LaTeX source.

Vice versa, Skim supports the other direction (PDF towards LaTeX), since OS X's default PDF reader does not afford this functionality. Skim is supported by TextMate, which can be setup with just two mouse clicks.

As a bonus, Skim has built-in PDF annotation tasks just like Adobe products, with the added bonus of being free (as in beer) and really lightweight.

OmniGraffle

The last thing I'll be talking about in this essay concerns creating vector-based figures. One of the beauties of PDF (and PS, for that matter) is that it's a vector-based file format. It means that it's resolution independent. Consequently, it is desirable that, whenever possible, all figures embedded into the paper are vector-based as well.

My preference for creating figures is OmniGraffle. It's a lightweight and easy-to-use piece of software, that provides intelligent guides to create vector-based figures that are coherently aligned, dimensioned, and eye-candy. Remember that a good figure can be worth one thousand words. A poor quality figure (e.g., misaligned shapes) conveys an amateurish approach to the work, which can be negatively reflected in the peer reviewing process. High quality graphics do help improving the paper's overall quality. After using it, you'll be constantly reminded that it's an excellent piece of software when you have to use Microsoft Visio or any other diagram software of lesser quality.

Add to that fact that it supports 100% vectorised PDF exporting - which can be directly embedded into LaTeX files, and you've got a high quality research paper ready to be submitted, peer-reviewed and, hopefully, accepted!

Ending remarks

I hope this info will help you lowering the burden on the logistics of writing scientific papers. While I'm not an expert on all of these topics, all of this comes from my 4 to 5 years of experience working as a researcher. Once again, this is not an exhaustive list of software and workflow. It's just my own experience being described.

I'm sure there is a lot of things that I may have missed, and better software out there. I'm still missing two significant pieces of software that can integrate seamlessly into my workflow: WYSIWYG table and equation editors, and integrated into TextMate. It would be great to select a table or an equation, and edit it without having to know a bunch of macros.

Therefore, please feel free to comment, and make corrections and suggestions. I believe it's important that researchers spend their time on researching, not wasting it on avoidable pitfalls in the writing process.

And now, back to that pesky paper I'm writing...

On open data from research experiments

2008-05-27T17:42:00.005+01:00

Open data. In the spirit of my instalments on opening data on social networks (part one, two, and three), I've actively promoted some data I've gathered in the context of a paper published at W4A.

The raw data concerns an accessibility assessment of nearly 8000 Web pages, and is licensed under a Creative Commons Attribution License. While this data is provided in CSV format, I'm currently working on making these type of assessments readily available as linked data, thus allowing (hopefully) more insightful discoveries of Web accessibility at large scales.

You can find the data, software, and associated publications list - side by side with some descriptive texts - in my PhD's work Web page. Use the data at your will, but do not forget to give credit where due :)

Back from WWW2008

2008-04-30T10:40:00.003+01:00

It happened once again. The most important conference on the Web was hosted in Beijing, China.

Fortunately, I was able to attend it once again, but only after an entire week on vacations. I have to say that I loved China. A huge country, filled with great, kind people. I had the chance of having three buddies with me on this trip, which was great!

Shanghai. For those who know (and like) New York City, you will feel comfortable in Shanghai. A very cosmopolite city, filled with skyscrapers. Lots of excellent street food (even for a vegetarian like me). Lots of bargaining, which I translated into a shiny new Canon EOS 40D for half the price, and a brand new Sony Cyber-shot T300. You can see their quality in my Flickr account.

Beijing. The great city in the north. A HUGE city, may I say. Had the pleasure of travelling to the Great Wall, more specifically to the Mutianyu section.

Conference days. I presented on W4A, which I was attributed with the best paper award. Great news! On the second day I presented on WebEvolve, the Web Science Workshop. The next three days were enjoying the main WWW conference, with excellent keynote speeches, excellent papers (some Google guys presented there a PageRank for images), and excellent food.

I deeply recommend everyone to go to China when possible. And WWW, well, it continues with its excellency on research and industry.

WWW2008

2008-04-11T16:42:00.003+01:00

THE Web conference will happen once again. This time, it'll be hosted in Beijing, China. It's the main venue for both researchers and industry that have a stake in the Web's past, present, and future.

I'll be there too, presenting my humble research work both at W4A and WSW. If you're attening, please feel free to drop by!

Small update

2008-03-03T23:07:00.004Z

Sorry for not posting lengthy and thoughtful insights on Web user experience, but lately there has been a lot of work (as you may follow on my twitter micro-posts, including writing papers, proposals, and pumping a bit of code (more on this in a later post).

Please stay tuned for more posts about the social Web. Lots of stuff happening...

Sunday morning

2008-01-20T12:19:00.001Z

Cascais, while inline skating...

Sun reflection

2008-01-09T17:30:00.001Z

Just taken now while going for a snack

The overload of online social networks: part III

2008-01-02T17:15:00.000Z

It's gaining momentum, since my last two posts about this. I've just read a bit about current efforts to cope with this ever increasing overload of social-ish information production and consumption.

Over the last weeks I've been thinking a bit on a (possible) successful recipe to fully meet this goal. But first let us first examine the nature of social networks:

Professional: typically links persons based on professional connections, lists CVs, support job hiring, etc. Such examples are facebook or linkedin;

Friends: these one-size-fits-all social networks are centred on connecting friends in two perspectives: friends I know and care about (e.g., facebook), and friendships (worships?) I want to make (e.g., myspace);

Utility: these are a bit anti-social networks, where everyone shelfishly contribute to the whole. del.icio.us and digg come as prime examples of leveraging collaborative efforts (tagging and voting) to meet each individual's expectations (e.g., discovering new resources or having personalized news);

Topic-centric: these networks are built around a common interest. Bakespace (recipe sharing) and last.fm (music profiling) are well-known examples, amongst hundreds (thousands?) of others (dogster anyone?);

This categorization leverages a particular aspect of utmost importance (already discussed by everyone else): there is a tendency to register into different social networks based on their offerings - a kind of vertical market segmentation - which is usually broken by network effects of some behemoths such as facebook or myspace. Nonetheless, it is an understandable way of differentiation between competitors. However, one surely knows that these categories are far from being disconnected. Especially due to widgetization, cross-pollination has become a normal practice.

When thinking about aggregating social networks, one realizes that each person might have different identities/personas. A first question arises? Do I want to share my personas with everyone else? (Actually, I don't mind at all, as you can see from my homepage, with my dumb/cool personal aggregator.) But does someone wants to share their myspace alter-ego with everyone?

This question leads to another questions: what's the purpose of a social network aggregator? Is is to build *THE* social network of all social networks (kinda like a meta-network) that everyone can access, or is it just a humble tool that helps each individual managing their personas and frame each network accordingly (all in a single page)? First thought: privacy matters.

Hence, here is my recipe for a successful social network aggregator:

Identity: I don't want to have to register 1000 times, write the same stuff everywhere, put up the same picture of myself. One time is enough. OpenID helps a bit, as well as solutions built on top of it (such as sxip's solutions). It's Identity 2.0;

Privacy: Having a granular way to select my identity aspects that I want/need to share is critical. As well as to whom I show them. Do I want to share a photograph just with my closest friends (from what social network, btw?), or with everyone? FOAF helps describing social networks in terms of connections, which could be leverage to cope with these privacy aspects;

Read access: An aggregator has to access my information, mix it appropriately, and leverage it (new visualization methods anyone?). Only this way I won't have headaches by just thinking about seeing *all* the updates on *all* social networks;

Write access: Do I want to post something on twitter as well as on facebook's wall? Do I want to update my status accross different social networks? Do I want to publish a picture on a subset of my profiles? An aggregator has to cope with these things. They are typically done by hand, albeit a set of existing APIs leverage these tasks. Google's OpenSocial comes to rescue, fortunately;

Sustainable business model: I won't provide an answer to this item (actually I don't have one), but someone has to figure it out. And no, google ads doesn't count...

Finally, and coming back to a previous questions, what would be the visible side of an aggregator? A simple login page open to the public and everything else is closed to each individual (walled garden - privacy matters, don't forget), or picking up each individual's granular control of privacy and expose the Network to everyone? An open garden might benefit some (hyper-targetted advertising?), but disturb others...

And what about after transposing the login page, what would I be faced with? Some kind of billboard/mashup containing every information I want to access, as well as updating facilities to cope with the overload issue? Or should an aggregator go a bit further and become a first class citizen in the social network battlefield? That'd be intersting, from an end user's point of view: one time login, infinite procrastination :)

One last thought: where to start. Identity consolidation. After that, connection networks and semantics might be built upon it.

I twit. You twit?

2007-12-10T23:08:00.001Z

Follow me over here. And feel free to ping me for adding you or just any other reason. Let's see how this experience goes...

The overload of online social networks: part II

2007-11-28T22:05:00.000Z

Since my last post on social networks overload a lot of things have happened. Some more insightful, some more trendy. Nonetheless, the world has kept spinning.

First, a lot has already been said about one of the newest Google initiatives (no, not Android - that'll be a theme for another post), OpenSocial.

In a nutshell, OpenSocial (from Google's own words) provides a common set of APIs for social applications across multiple websites. With standard JavaScript and HTML, developers can create apps that access a social network's friends and update feeds.

When launched on November 1st, Google's press release already included an impressive list of companies/websites that provide (or are in the process of providing) support for the OpenSocial API, such as MySpace, orkut (obviously), hi5, Oracle, Salesforce.com, NY Times, and PayPal. That is really impressive.

My opinion: this most probably means that social networks will become open (do you hear that, Facebook?), third-party developers will simply focus on providing the best experience to users for their products, instead of focusing on a bunch of APIs with bad documentation. But the best part is the easyness of importing and exporting my own data, user info, photos, friends network, etc. across different social networking websites. About time....

On a more conceptual side, and with a smaller impact (when comparing to Google's), but still of the utmost importance, is a breakfast-fueled rant by Tim Berners-Lee.

Tim talks about The Graph. The social network graph, as a particular case of the Semantic Web, advocating it as another way to bootstrap, access, and explore social networks independently from any website (using FOAF, by the way).

Lastly, discussions are popping up with similar thoughts like mine's, already proposing some solutions to this problem (despite being more or less architectural/conceptual).

I think that the social networking revolution is just beginning. I wonder when will they start taking into account the always increasing number of Web Interaction Environments to provide the best user (and social) experience to everyone, everywhere. Has anyone tested social network websites with any disabled person? I wonder what would've happen...

How Many HTML Elements Can You Name in 5 Minutes?

2007-11-20T23:09:00.000Z

Looking for payday loans?

bits of code from .pt

2007-11-13T14:35:00.000Z

Due to my lack of time I had to skip going to SAPO codebits. It's a sort of hackathon/conference on Web2.0 enterpreneurship, targeted to the portuguese Web2.0 community.

Head on to their blog for continuous updates and info (warning: in portuguese).

I wonder what sort of stuff will be getting out from this...

slowing down

2007-11-12T22:05:00.000Z

Unfortunately, I'm having little to no time to do proper blogging on the past month. This slowdown has been influenced by:

Finishing a paper for ACM's WWW 2008;

Improving my methodology for modeling Web Interaction Environments (more on this on a later post);

Reviewing students' assignments;

Traveling;

Helping out on organizing ACM's CIKM 2007;

Reviewing some stuff for XProc.

Apart from these, two or three (as a matter of fact, three) startup projects are being started. They're at different inception stages: some just on the back of my head+some chatting with Daniel, others with Tiago and Bruno.

Too much stuff, too little time on my hands... *sigh*

broken

2007-10-18T00:29:00.001+01:00

Yes... I know that my website's design is broken on IE7. One day I'll take a stab on it. One day...

I sure hate having to tweak really clean CSS in order to support Microsoft's browsers... *sigh

Shell script: process finding on steroids

2007-09-23T12:39:00.000+01:00

Albeit being a bit of an off-topic subject, today's post concerns a little unix admin script I've done...

Apart from my main focus on the research lab (i.e., doing research on Web user experience things for my PhD) , I've also got administration responsabilities on our servers, desktops, etc.

Since our server is a Linux based 1U rack machine, handling Web and e-mail stuff, we have to stay on top with all the things - processes - that are running in it. The reason for this is surveillance is to avoid it to become a zombie of a botnet and, consequently, used to send huge amounts of spam around the world.

From the latest count on our lab's website, we've got 72 researchers listed. Anyone with a bit of unix (or even Windows) experience on administrating a server for this number of persons knows that quickly finding the needle on the haystack (i.e., finding a problem on the server) may be cumbersome.

One of the things I wanted to do really quickly was to know more things about the processes each user is running, as a user running an abnormal number of processes could indicate that an account had been compromised. I wanted this really badly, as doing a simple ps, would yield pages and pages of running processes listings.

That's when shell scripts come to rescue.

With a bit of knowledge, some Google kung fu, and an almost obsessive use of digital duct tape, I've come up with a script that quickly summarizes how many processes for each application/utility are being run by each user.

Here it is on all of its glory:


#/bin/bash
ps auex | grep -v ^USER | awk '{print $1, $11}' | sort | uniq -c | awk 'BEGIN{m="_";f=1}{if($2!=m){m=$2;if(f!=1)print "";printf("%s ::",$2);f=0;}printf(" [%s %s]",$1,$3)}END{print ""}'

This script's output lines are similar to this:


rlopes :: [2 awk] [2 -bash] [1 grep] [4 imap] [1 ps] [1 sort] [1 sshd:] [1 uniq]

From this you can see that I'm running 4 instances of imap (silly server...) and other assorted stuff. Similar lines appear for each user with, at least, one running process on his/her behalf. Much, much, much better than using "ps | less" all the time :)

Drilling through that cryptic script, here's the rational behind it:

ps auex lists all processes. Really all of them.
grep -v ^USER removes ps's output headers. No garbage, thanks!
awk '{print $1, $11}' filters just user names and process names.
sort, well, sorts by user name.
uniq -c removes all repeated entries, but keeps the number of process copies running on the system.
awk 'BEGIN{m="_";f=1}{if($2!=m){m=$2;if(f!=1)print "";printf("%s ::",$2);f=0;}printf(" [%s %s]",$1,$3)}END{print ""}' pretty prints this information, with one concise line per user.

Use this script at your will and, please, feel free to make suggestions and improvements!

The overload of online social networks

2007-09-20T13:14:00.000+01:00

During the past few months, I think everyone with at least a tiny bit of internet savvyness knows what an online social network is. From wikipedia's entry, this is defined as focuses on the building and verifying of online social networks for communities of people who share interests and activities, or who are interested in exploring the interests and activities of others, and which necessitates the use of software.

All this mumbo jumbo is easily understood if I mention MySpace, Facebook, or any other from this list. The phenomenon has expanded to music, photography, among many other interests (some of them really weird).

So, as a tech savvy, I explore these sites from time to time, to check what's all the hype about... This resulted on having multiple profiles entered on different networks, with inconsistent information between them. And I hate having to update repeatedly all of them, instead of doing it just once. Heck, recently I even deleted my accounts on some networks, as my profile was so much out of date, that mainaining them didn't make any sense to me. Nevertheless, while some of this networks simply exist to make friends, or to browse disparately without a purpose, just to kill time (i.e., also known as deliberately lost in the hyperspace).

Despite this, I think that some networks really do have meritable purposes (from my point of view): I use Flickr to show some photos from my travels (typically when I go to conferences); LinkedIn as a socialnetwork-flavored curriculum vitae (you'll never know when to look for a new job); Facebook to get in touch with some overseas friends; and, lastly, Last.fm to find new music I might me interested (really cool network, I confess).

So, to lower the burden of updating all my information of each site, there should be a mechanism to lower this burden. Yes, I know that, in fact, each one provides its special features, allowing people to differentiate from each others. But a great deal of information is the same (e.g., profile info, user photos, commenting, partial friend networks, shout boxes, blog posts - you name it).

Why can't I perform this updates on a centralized way? This issue is similar as having to sign-in into each site with different username/password. OpenID delivered a solution to this identity authentication problem. (I've posted something about this before). Is this a new opportunity for this standard? Or to anyone else outhere?

Oh, and why do I have to keep checking each site, just to take a quick glance over the latest updates and info? Yes, I know that most of these sites rely on advertising programs to squeeze a buck or two. Nevertheless, I'm sure that a good solution can be found in between, thus making everyone happy. And since this is a blog about user experience, and I'm a user, I want to be happy. And I'm not happy at all with this... updating overload.

On a side note, I haven't resisted on fullfiling my profile at Digg. At least on this case, I still win something with this new network: interesting news will be pushed to me by my peers... Interesting, IMHO.

On full screen apps

2007-09-09T15:35:00.000+01:00

Recently, a new breed of full screen applications have emerged and, from the feedback that reviewers and users have been giving, it seems that it works.

A few months ago I have bought one of those Apple MacBooks that so many people love (me too, btw). On the last couple of weeks, while searching and trying out new software stuff, I've watched the increasing growth of the number of applications for OS X that provide a full screen user experience.

Yes, full screen apps are not a new. We've had them for a long time: games and bunch of screen real-estate hungry applications (such as 3D modeling or movie playing apps). But, apart from those, full screen applications meant going against the traditional GUIs of all operating systems. Things such as window managers, APIs, usability guidelines, etc., have been tightly tied and cooperative in order to deliver better user experiences. Whether we talk about applications, windows, or documents, all UI metaphors are evolving towards interacting with several windows, in order to accomplish a given task. We do it everyday with our beloved and almost impulsive Alt/Command+Tab task switching.

Even with OS X's window manager, everything is centred around easily finding a window, viewing them all, etc. with all the fancyful animations of Exposé. So, what happened to users that they started to demand for full screen applications?

Back to OS X applications and their... fullscreen-ness, I've come across with applications that see full screen as a competitive advantage, regarding their competitors, such as: Adobe's Lightroom; Apple's Logic, iTunes on cover flow mode, OS X'sDashboard, or Front Row; Scrivener; Writeroom; and the list goes on, and on, and on...

But why?

Well, from this small list of applications we see that some lean towards multimedia (iTunes et al.), others to media editing (Lightroom, Logic), or to text editing (Scrivener and Writeroom). From crawling through blog posts, mailing lists archives, tech news sites, etc., I believe that this new breed of applications fill an important usability gap: attention. With the increase of screen real estate and better window managing, users are bombarded with information coming from everywhere. Things such as Growl notifications, instant messaging blinking or jumping icon notifications, etc. This is, IMHO, increasingly overwhelming to users. Users and getting tired of this.

That's where full screen comes along.

Full screen applications tend to be more imersive. The user is simply centred on fulfilling a task. Nothing gets in between this scenario. No distractions. No bells and whistles around. Consequently, productivity increases. It seems to make sense, doesn't it? I like it and use it, a lot.

Well, from some reports elsewhere, Apple is bringing support for developing full screen apps into OS X's latest installment, Leopard (a.k.a., 10.5), thus dismissing a few full screen hacks that one can find with a bunch of Google queries. Good for us, developers and users.

Finally, as this blog is geared towards Web related user experience, here's a thought. Do we see a clash between the Web's multi-window/page/site hyperlinkingness and full screen metaphors as a weakness when we begin to think on applying this concept to Web browsers, or even to the way websites are designed and how users should interact with them?

In times, I've prototyped a Web multimedia database/hyperbase, whose user interface was specifically optimized for a full screen Web environment (through a Firefox full screen add-on), with good results. Maybe this will be a trend for future Web based applications.

I'll think about it more seriously. For sure.

Upgrading my home

2007-08-28T17:11:00.000+01:00

I've updated a tiny bit of my homepage (www.rlopes.net just in case you've forgot the URL). Since I'm migrating the playground stuff to Google code (see my previous post on this blog about it), I had to replace the infobox with something else.

For coherency purposes, this blog's archive is now displayed side by side with the latest entry, whereas the missing infobox is presenting my lattest scrobblings on last.fm, an online music community/social network. Now you can sneak peek over my musical preferences.

I'm also working on a new blog about writing music, that's being hosted also on last.fm. Currently I'm writing a series about the creation of concept albums. Keep reading it at this location.

Now, back to work on this scientific journal article...

Quick update on MashMeUp!

2007-08-27T21:55:00.000+01:00

I'm writing this short post to tell you all that I'm currently moving MashMeUp! to be hosted on Google Code.

Therefore, please update your bookmarks to the new location.

All progress on this small project will be updated on its new home's wiki pages.

Art & literature

2007-08-17T11:43:00.000+01:00

This is just a short post (almost a la Twitter). I'm back, refueled and ready to jump right into work.

For those who might be interested, I've managed to read David Yallop's In God's Name, José Rodrigues dos Santos' A Fórmula de Deus (a Dan Brown -esque portuguese novel about trying to find a scientific answer about the existance of God), a book about Ireland's history, a geographical encyclopedia volume about the Northern Europe, and a small book about Chopin and his contemporary fellows.

I've also tinkered over my drawing and typographic skills by practicing ambigrams, specially to create the logotype of my prototype band/musical project (more on it on some future post), Winterfall.

Talking about music, yes, I'm still playing the guitar and composing. My stack of guitar riffs and melodies has grown (my latest count is around 70 or 80 of them), where the latest are exploring the difficult art of mastering dissonance on harmonies, melodies, and phrases. Someday I might post something about it.

Investigatione miscellanea

2007-07-26T13:12:00.000+01:00

Despite not posting a lot of stuff in the past weeks (apart from the smallish post about OpenID), I've been quite busy working on my PhD - apart from a small vacation hiatus in the last bunch of days.

In a nutshell, my PhD hypothesis says that, in order to cope with rich interaction scenarios on the Web (i.e., everything that is not a common user with a desktop computer with a typical Web browser and a mouse), one must center their focus on characterizing the set of Web Interaction Environments (WIEs) that one's interested in.

Currently, I've defined a way to specify WIEs (and encompassing prototype modeling tool) - more on that later on (I guess I'll have to create a wiki page about it on my research group's website). I've also sketched a way to reverse engineer existing websites and Web applications crossing the ConcurTaskTrees and traditional hypermedia/Web engineering modeling practices (such as OOHDM or W2000), that allows leveraging accessibility and usability in a pragmatic way. Also, this practice may (can?) be used to fully model highly dynamic websites and Web applications for a given set of WIEs (this is yet to be proven).

However, now it's time for one more pause to fully rercharge my batteries. A long year is waiting for me, from the middle of August onwards, fulfilled with ideation, prototyping, testing, writing, and presenting tasks. See you then.

OpenID

2007-07-13T12:20:00.000+01:00

I've just setup my OpenID account. As they promise,

With OpenID, you create a single username and password, along with some data about you.

You can then log into an increasing number of sites without registering each time! It's also free - forever.

OpenID also provides you with a place to store your digital identity - a place where you can easily be found on the web.

Do you already have yours?

User Agent detection and segmentation

2007-05-23T20:14:00.000+01:00

Web browsers indentify themselves with a particular string. It's called the User Agent string. In order to better fit contents to different scenarios, trying to segment the whole spectrum (or, at least, a big chunk) of user agents proved to be a daunting task.

While working on a prototype for an adaptation engine for Web based documents, I came across the need of finding out which type of Web browser is requesting a document. While nowadays some efforts are being made to ease this task, such as UAProf and WURFL. However, being pragmatic, an ubiquous availability of these two technologies may take several years to take off. Therefore, the simplest way of doing it today is sniffing the request's HTTP header, and looking for a User Agent field.

From the HTTP 1.1 specification, Web browsers and other Web user agents (e.g., crawlers) may identify themselves with a specific string on the header of each HTTP request. The production rule for this header is:

User-Agent = "User-Agent" ":" 1*( product | comment )
product = token ["/" product-version]
product-version = token

What's the meaning of this expression? Basically, it states that this header field should start with the string User-Agent:, followed by a product name and its version, or a comment. This must appear at least one time, at most... infinite times. Hence, user agents identify themselves with almost arbitrary strings, as long as they comply with the production rules. Headache warning.

Despite existing a huge amount of Web browsers available in the market, my adaptation engine should indentify them according to their segment, such as desktop browsers, mobile browsers, etc. But, thanks to HTTP's loose user agent rule, putting browsers correctly on their segment is really hard (read: cumbersome, error prone, nearly impossible).

Here's a quick sample of user agent strings from miscellaneous browsers, taken from a huge list found elsewhere:

Internet Explorer 7: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; WOW64; .NET CLR 2.0.50727)

Firefox 2.0: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.8.1) Gecko/20060918 Firefox/2.0

Sony Ericsson K610i builtin Web browser: SonyEricssonK610i/R1CB Browser/NetFront/3.3 Profile/MIDP-2.0
Configuration/CLDC-1.1 UP.Link/6.2.3.15.0

Pocket PC Internet Explorer: Mozilla/4.0 (compatible; MSIE 4.01; Windows CE; PPC; 240x320)

Once again, pragmatics tell me that tailoring the Web towards each single device is unfeasible. Hence, it should be possible to define different segments and associate each User Agent string to the appropriate segment, through a set of heuristics. Even when WURFL, UAProf, or even more recent work from W3C's Mobile Web Initiative Device Description Working Group becomes widespread, segmenting the Web end-points - browsers - into a treatable set of characteristics will continue to be useful.

Going back to the User Agent strings mumbo jumbo, my initial proposal relates to distinguish between the mobile and desktop landscapes, and it goes something like this (beware - pseudo-code algorithm):

function user_agent_segment(string ua_str)
{
  switch (ua_str)
  {
    case /MSIE/ except /PPC|PocketPC|Windows CE/:
    case /Gecko/:
    case /KHTML/:
    case /Opera/ except /Mini|Mobile|Wii/:
      return DESKTOP;
    default:
      return MOBILE;
  }
}

The simple, yet crucial, aspect of this algorithm relates to detecting desktop browsers at first, since the (useful) desktop browser landscape is narrower (in comparison to the wildwest style huge range of User Agents on mobile phones). From there, one may just detect specific substrings.

If your keen on this topic, please feel free to implement, test, extend, and improve the algorithm. My (mid-term) goal lies on expanding it in order to detect and diferentiate mobile phones, ultra mobile PCs, and desktop environments (at least). Also, it could be somewhat interesting to extrapolate input mechanisms (i.e., modalities) available - e.g., if a mobile phone is detected, we may infer a numeric pad (and possibly arrow/cursor keys) as the available input modality. This way, navigation on a Web site may be tweaked in order to facilitate user interaction, thus leveraging the user's experience and increasing one's satisfaction.

Afterthoughts

2007-05-16T13:06:00.000+01:00

The last two weeks were really really interesting. So interesting that my initial plans on blogging while at the conference went straight to the garbage bin, especially coped with the average 5 hours sleep I was able to get there.

The first four days at Banff were simply beautiful. Surrounded by the rocky mountains at the Douglas Fir, I managed to wake up every morning and go skiing with a bunch of good friends from all around the world on the Sunshine Village ski resort. In one word: beautiful. I even managed to do some black diamond runs, no way I could've imagined myself doing it... But as a matter of fact, I did :) Awesome!

Returning to reality, being a volunteer for WWW and presenter for W4A, some things had to be done. Moving to the jawdropping Fairmont Banff Springs Hotel, with an insane window view towards mountains, river, golf course, snow, forest... simply beautiful. It was a good omen, I thought. And I was right. It was.

W4A started. There were several interesting presentations over Web 2.0 technologies and how to leverage them regarding accessibility. Some more technical, others geared towards research, but nevertheless interesting. My presentation went fine, despite some anxiety (oh, so typical of me...), got a bunch of interesting questions.

On the second day, as an assigned volunteer for W4A's room (thanks John!), I got to see the rest of the conference, and think about my own research goals. That's what conferences are for.

Heading to WWW itself, I was pleased to have the chance of hearing and seeing lots of great presentations on Browsers and User Interfaces, advances on standards from W3C's Technical Track, some cute demos on the Developers' Track, and loads and loads of Information Retrieval and Semantics. Concerning the plenary keynotes, they were simply great. Hearing Tim talking about WSRI - Web Science Research Initiative - and viewing those simple state charts summarizing the whole research process for the emergence of the Web Science field (and other Internet gimmicks such as e-mail) was definitely insightful. And viewing the Web as a set of linked data (as Brian reported), coupled with some chat I've managed to make with Brian Kelly, Peter Brusilovsky, people from the DAISY Consortium, and others, I managed to flourish several thoughts and research directions for my PhD work.

Summing it all up: it's a must-go-to conference every year, it's a must-go-to place to be on vacations when possible!

WWW2007 and W4A

2007-05-01T00:19:00.000+01:00

Today (May 1st) I'm heading off to WWW2007, at Banff, Canada. The beautiful Banff Springs Hotel will host this huge conference, where I'll be part of the volunteers staff, helping out when and where necessary.

Also, on May 7th, I'll be presenting at W4A - Web4All - some progressions on my research work towards getting my PhD degree. Hopefully, I'll come back with lots of interesting ideas to improve my work.

The Bonus: since the conference starts at the 7th, I have five days of skiing and hanging out with lots of great people I met last year at WWW2006 in Edinburgh, some sort of a (well deserved?) vacation period :)

Concerning this blog... I guess I'll try to post some things while at the conference (live updates maybe?). After all, this is the Web conference!

Mash Me Up!

2007-04-16T11:48:00.000+01:00

Mash Me Up! is a software to create feed aggregation mashups, requiring near zero configuration to put it online.

When procrastinating through my daily bookmarks, such as Original Signal or the Web 2.0 Workgroup, I've always wondered: Why can't I find a software to create these public mashups easily? Why do they always implement their own feed mashup solution? Doesn't Google homepage, My Yahoo!, and similar services deliver the same solution?

In a nutshell, Mash Me Up!'s uniqueness resides on the fact that it can be deployed both for personal and public use, it's skinnable (100% CSS), it's got a clean markup (no tweaks, verbosity, or whatsoever), and it's really lightweight (no widgets, no javascripts, no XHRs).

Try my live demo and download it!

Moreover, as a gift to you, I've also added support to pass any number of feed URLs directly on Mash Me Up!'s URL (disabled by default), e.g.:

http://example.com/mashmeup/?feeds=url1|url2

This way, one can potentially create a mashup without even configuring the software, or have different instances of Mash Me Up! bookmarked for his/her own pleasure without having to use fake tabs inside the UI (like Google homepage does - bad UI, no cookie for you!)

The really cute thing is that this took me just an evening to create, test, and deploy. How? Simple. By using MagpieRSS to parse RSS/Atom feeds, it required me strictly 50 lines of PHP (including HTML tagsoup) to deliver Mash Me Up! in your browser.

Feel free to use/tweak/improve this software at your own will, as long as you keep visible an acknowledgement to the author (me).

Some technicalities:

Software requirements

No need for a special setup on a Web server, it's as simple as having the Web server (Apache recommended) and PHP 4.1.X or greater.

Setup

In order to use Mash Me Up! you just have to unzip the script into a proper Web server location, configure your feeds and (optionally) a few other things, and that's it!

When configuring Mash Me Up! you just have to edit a few things on the included config.inc.php:

The title
$mmu_title = "Mash Me Up!";

The subtitle
$mmu_subtitle = "the no-brainer way to create feed aggregation mashups";

Select your feeds
$mmu_feeds = array("http://feeds.feedburner.com/ajaxian", ...);

Regarding other options, please refer to the config.inc.php file, as they are self explainatory (I hope) :)

Launching my new home

2007-04-09T17:30:00.000+01:00

My new home has been launched. Following this blog's trend on titles, it will be the play:ground for my thoughts on Web user experience.

Currently, the play:ground is a simple façade where I present some info about this blog, my latest del.icio.us bookmarks, lastest additions to Flickr, and a small (yet important) box where I'll put links to my experiences on Web user experience (the pun is intended).

Enjoy!

A new home

2007-04-08T21:13:00.000+01:00

Ok, first of all, forgive me about the semi-pun on Star Wars' A New Hope. This is, in fact, a new hope for me to approach the blogging ecosystem in a gentle way.

As for next posts, well... I'll try to post once a week (no promises though), about my thoughts on Web user experience. Stay tuned!