Finger Prince by opusinfinity, on Flickr

C’est ce que Sony a découvert, lors de tests avec des consommateurs:

The latest is a new line of Sony e-readers that the company will introduce Wednesday. For the first time, all have touch screens; Sony decided on the technology after watching person after person in focus groups automatically swipe the screen of its older, nontouch e-readers.

Cette tendance a ses implications, outre dans le design des nouveaux appareils, mais aussi dans le design d’interfaces. Depuis plusieurs mois, notre travail de design a dû évoluer avec cette nouvelle tendance. C’est le cas bien sûr pour le design d’interfaces dans notre travail sur des services ubiquitaires, puisque la plupart des appareils mobiles contemporains sont tactiles. Mais c’est aussi le cas pour notre design d’interfaces Web en général.

Depuis des années, le design Web a pris pour habitude d’offrir des interactions particulières à une utilisation d’une souris. Lorsque le visiteur passe le pointeur sa souris sur certaines zones (le fameux “hover” ou “mouse over”), de nombreuses fonctions peuvent être déclenchées: offrir de l’information contextuelle, ouvrir un menu, indiquer la présence d’un hyperlien ou la possibilité d’agir avec le contenu ou l’interface.

Tout cela change avec la multiplication d’appareils connectés au web dont la principale interface utilisateur n’est plus une souris et son pointeur, mais un écran tactile. Exit la possibilité pour le visiteur de traîner sa souris comme on traîne le regard à la recherche d’information. Même si elles ont toujours leur utilité comme petit “plus” pour les utilisateurs avancés (avec un ordinateur et une souris ou un trackpad, les fonctions de “:hover” ont fait long feu, et comme l’écrit Andy Croll, beaucoup d’interfaces migreront sans doute du hover au tapotement.

C’est sans doute une bonne chose. Depuis longtemps, les apôtres des bonnes pratiques Web notent qu’il est préférable, pour de nombreux utilisateurs du Web, de ne pas offrir d’information ou d’interaction exclusivement via “:hover” ou autre action qui nécessite l’utilisation de la souris. En effet, certains utilisateurs n’ont pas le contrôle neuro-moteur suffisant pour effectuer des déplacements subtils d’une souris. D’autres, dont la vision ne leur permet pas d’utiliser un écran et une souris, accèdent le Web entièrement avec un clavier et une synthèse vocale.

De nombreux développeurs pour le Web auront déjà pris en compte ces besoins d’accessibilité, mais d’autres auront sans doute eu du mal à voir pourquoi il faudrait “amputer leur design” pour un petit pourcentage d’utilisateurs aux handicaps divers. La prolifération des interfaces tactiles change la donne. Elle apporte avec elle une nouvelle démographie “handicapée de la souris”: un public souvent jeune, assez riche et prêt à adopter les nouvelles technologies. Et cela change tout.

1. bike stations with free docks (can you park?)
2. available bikes in each station (can you get a bike?)

for Montréal, Canada.

We like to experiment stuff and play with tools available around us. Most of the time, someone (a developer, someone in bizdev, etc) will get an idea or have a need, and ask Could we do that? Many of us at Pheromone are users of Bixi, the Montreal shared bike system. Sometimes, it is frustrating to reach a station to find out that everything is taken. Where are the closest stations around and in which directions. Bixar does just that. It creates a 3D overview of the position of bike stations and gives information about their vacancy status.

Jon Masse has developed the application using Layar and finally has ported his work on wikitude in 2 hours. Florin Gabor has created the logo, without forgetting the feedback and help of Olivier Théreaux, Sophie Leroy et Philippe Le Roux.

How to use layar on your phone?

For using layar on your phone you need to download the layar application, then you will be able to access a list of augmented reality layers.

How to use Wikitude on your phone?

For using wikitude on your phone you need to download the wikitude application, then you will be able to access a list of augmented reality layers.

Universal platforms

There are benefits to develop for open technologies and not be tied to proprietary technologies. The same way, we love opensource tools and open web standards, we are really looking forward to have an augmented reality format and apps that we could develop once and deploy everywhere.

1. les stations de vélos avec des places libres (puis-je me garer ?)
2. les vélos disponibles à chaque station (puis-je obtenir un vélo ?)

pour Montréal, Canada.

Nous aimons expérimenter et jouer avec les outils autour de nous. La plupart du temps, quelqu’un (un développeur, une personne aux développements des affaires, etc.) aura une idée ou un besoin, et demandera Pourrions nous le faire ? Nombre d’entre-nous à Pheromone sont des utilisateurs de Bixi, le système de partage de vélo de Montréal. Parfois, il est frustrant d’atteindre une station et de réaliser que toutes les places sont déjà prises. Où sont les stations les plus proches et dans quelles directions. Bixar répond justement à ce besoin. Il donne une vue 3D de la position des stations de vélos et donne de l’information sur le statut des places disponibles.

Jon Masse a développé l’application en utilisant Layar et puis finalement a porté son travail sur wikitude en 2 heures. Florin Gabor a créé le logo sans oublier les commentaires et revues de Olivier Théreaux, Sophie Leroy et Philippe Le Roux.

Comment utiliser Layar sur son téléphone?

Pour utiliser layar sur votre téléphone, vous devez télécharger l’application layar. Ensuite vous aurez la possibilité d’accéder une liste de calques de réalité augmentée.

Comment utiliser Wikitude sur son téléphone?

Pour utiliser wikitude sur votre téléphone, vous devez télécharger l’application wikitude. Ensuite vous aurez la possibilité d’accéder une liste de calques de réalité augmentée.

plate-formes universelles

Il y a des bénéfices à développer pour les technologies ouvertes et de ne pas être piégées par les technologies propriétaires. De la même façon que nous aimons les outils opensource et les normes Web ouvertes, nous attendons avec impatience un format et des apps pour la réalité augmentée où nous pourrions développer une fois et déployer partout.

Open Data and Licenses

To really promote open data, it is necessary to use the appropriate licence. Glen Newton looked at the licenses of different data sets published by canadian cities. The terms of the licenses are too restrictive. It is important to ensure that people will be able to use the data freely. There are many ways of achieving that. One of them is using creative commons licenses. It enables people to reuse the data in many circumstances keeping the attribution credits.

Open Data in Canada

What about Canada? Not that bad. Many initiatives push in the right direction. Governments (federal and local), cities as well as civic organizations are publishing data. Often the licenses are not the right ones, but that can be fixed.

• Info Source Canada Gov
• Open Data Edmonton
• Open Data Nanaimo
• Open Data Ottawa See also Ottawa Data – open data ottawa blog – opendata apps directory
• Open Data Toronto
• Open Data Vancouver
• Open Data Links Canada
• Open Ottawa (Civic Organization)
• Canadian Gov data by citizens
• CivicAccess

Montréal ?

And Montréal. There are whispers of interests. But I do not know of any concrete initiatives yet. Have you heard something? How do we encourage Montreal city to share the data?

Montréal has data, a lot of data. The access could be improved (RESTful API, data format) and licenses clarified.

Update 2010-08-09 : See the comment. Montreal Ouvert (Open Montreal) has opened a Web site. That is an excellent news.

Notice anything unusual? What fascinates me is how the top third of the page mentioned locations in no less than three countries. How? Why?

Near the top-left of the page, I can see an icon depicting a Canadian flag, along with a link to the Canada-specific Yahoo! portal. What this means is that the Yahoo! system knows that I am browsing from Canada (I have been, therefore, geolocated). If you view the site from another country, chances are you will be getting a different flag and a different link. And if you view it from Spain? I do not know. When I do follow the hyperlink to Yahoo! Canada, I get a similar link to Yahoo! Quebec, and when I go to Yahoo! Quebec, I get a link to Yahoo! Canada.

Interestingly enough, one of the most common elements of personalised user experience is missing here: language selection. There is no way I can read the news from Spain in English – or indeed, in Català or Gallego. Neither do I get a « Français » link on Yahoo! Canada, or « English » on Yahoo! Quebec.

Knowing where I am, the system could assume I necessarily want to view local content in my local language and therefore redirect me to the Canadian/English portal. Fortunately, it does not, and lets me browse news from Spain as much as I like, and limits the effect of geolocation to a subtle but clear hint that local content is also available.

How do they do it? Most likely, the IP address of the machine I used to access the site was compared against a GeoIP database such as this one or that one. Note that, unlike in many mobile applications, the IP-to-location translation is done automatically, without ever prompting the user for her agreement.

Next in our exploration of the personalisation elements is the page-wide bar of text links, calls for action and teaser questions serving a single purpose: convert the visitor into a user, either by registering, or by logging into an existing account.

Notice how the bar employs about about every trick know to web designers to entice us to log in: give regular users a quick link to their well-known personal space; showcase some of the added value gained through registration (preview of my inbox, directly in my news portal); comfort the potentially puzzled new visitor (New here?) and tease the social fiber (What are you doing? – obviously a go at copying the now-abandoned twitter tagline?).

The most surprising element comes last. How come, given that I am not logged into Yahoo!’s system, I am shown a weather widget for the city of Tokyo, Japan? I could have understood if it were Madrid (local to the portal, with an educated guess about which city I may be interested in) or Montréal (through geolocation) – but Why Tokyo? And how?

How do they do it? I quickly validated my initial hunch: Yahoo achieved this through the use of cookies – although other client storage options such as the localstorage in html5 would have been just as valid. My problem here, however, is that:

• The cookies are opaque – even with a cookie browser (most browsers with developer extension offers one) I would hardly be able to know which cookie was telling Yahoo! thay my preferred location was Tokyo. I had to delete cookies, one by one, until the weather widget changed to a geolocated default of Montreal.
• I cannot tell how and when this cookie was set in my system. Sure, I could set my browser to have me validate any cookie sites want to store, but given how cookies are entirely opaque, how would I know the meaning and consequences of allowing Yahoo (of flickr, or any site in the Yahoo ecosystem) to store a cookie that sets key T to …CAuNRMqKiCOsvekk….

And there’s more… All these modes of personalisation have been enabled without me even logging into the system. Imagine the many personalised features that can be implemented for recurrent, identified users: social filtering (content that my friends like, for instance), content adapted to my choices or patterns of use (recommendations for you), and much more. Has any content-heavy site ever tried to recommend their users items that they are unlikely to « like », or at least that they are likely to be surprised or challenged by?

The web is not print, however, and the embedding of nice typography seems to come with a few other issues: the first few site prototypes on which we worked with @font-face tended to be plagued with performance problems – a really big deal in our case, given that we manage high-traffic sites. The User experience of the pages we had tested was sub-par: slow loading times, blocks of text “jumping” after the actual font gets loaded, etc.

And yet, webfont services are popping like mushrooms and seem rather popular. I decided to give four of them a look, to see how good – and how fast – their service was.

My test page, based on fontsquirrel’s webfont comparison page loads the fonts from the 4 providers (unfortunately, fontdeck does not seem to offer the Cantarell fount, a common denominator between all other three services, hence the difference). The rest of my testing consists mostly of analysis of speed, HTTP headers and other tinkering through firebug.

Google Font Directory

Google’s webfont solution is « view source » friendly: one can copy-paste from another site and get the fonts working immediately. Their offering is still rather limited, but their site is no-nonsense, immediately usable, and does not require any signup, payment – indeed all the fonts provided are Open Source (distributed under Open Font License).

Google’s service is also pretty good with caching – their servers appropriately respond with a 304 not modified open a request, and they send proper Expires: and Last-Modified: HTTP Headers.

Font Deck

Setup with Fontdeck is relatively easy: one needs to register on their site, choose a few fonts, and get a piece of HTML and CSS code to use. While I ran into a silly UX issue and couldn’t find the code samples at some points (a case of bad whitespace and beyond-the-fold design), using the font deck web site is rather pleasant.

However, after setting up my test page by following all their instructions, I never managed to get the fonts to appear: the URIs given to me in the sample systematically resulted in “403 forbidden” responses. I could not test the performance of this solution yet.

Font squirrel

Font Squirrel is clearly different from the rest. Similar to the many foundry catalogs available for designers, it includes a really simple wizard to create a font-face kit from any (downloaded) font. Very geek friendly. This is also the only service that caters to site admins who want to host their fonts themselves, and it does not provide a hosted font-face service.

Typekit

One of the first service of the genre, Typekit also requires you to register yourself and your site. Javascript-based. Really similar to font-deck (which I believe it predates), Typekit will let you browse fonts for your site, and will provide a javascript snippet to add to pages to embed the fonts.

However, after setting up my test page by following all their instructions, I had trouble getting the fonts to appear: the URIs given to me in the sample systematically resulted in a “404 Not Found” response. It took me a while to understand (DOH!) that I had to choose fonts, add them to my site’s collection THEN publish in order for the system to work. My bad, their UX is really decent and I should really have understood this faster.

This solution is actually quite nice, as it allows me to choose which weight and style I want to include in my kit – which can be a big win for file weight, and thus performance.

Caching-wise, Typekit also behaves nicely, with the same combination of “304 Not Modified” response, Expires: and Cache-Control: HTTP Headers seen in Google’s service.

Their caching policy is much less aggressive than Google’s, however: while Google sends a cache directive for 14 days (Cache-Control: private, max-age=1209600), Typekit sends one for 300 seconds. I assume the reason for this difference is that with Google, you link to each individual font (which change very rarely), while with Typekit you link to your kit, which you may tinker with a lot. In any case, a cache policy of 300 seconds (5 minutes) is rather likely to cover the average visit, so this short timeout should hopefully not have too much of an impact on your visitor’s experience.

One thing I’m not a big fan of: the script Typekit gives you doesn’t just lets you embed fonts, it also adds a little Typekit logo on all your pages. Not cool. I assume that paid customers don’t get the pesky logo, but regardless, if a service is going to advertise itself on my site, I’d like to know in advance…

Anything Else?

Any other service you would like to see tested here? Any other indicator of performance or cost-effectiveness you would like to see in the table? Tell us in the comments and we’ll try to keep this page up to date.

The project is quite advanced, the blueprints have been created and we are almost ready to start working on building it. Then suddenly someone is raising his/her hand shyly and says:

“errr… sorry I may disrupt something… but where is the kitchen?”

The kitchen… The kitchen? The kitchen!!! Then everyone suddenly realize that the restaurant owner needs to cook to be able to deliver food on the tables of his/her customers and that this kitchen is very different depending on the type of food you are cooking. The restaurant owner also has specific habits, desires, tastes when managing his/her restaurants.

This story is happening too often in the Web industry business.

We spend a lot of time on the public UI of the Web site. We define the interactions (UX) in a way to maximize conversion ratio. We want the best possible user experience. And then we create a design. Later on, we realize that the design constraints are incompatible with the Content Management System which has been chosen.

The issue is that the CMS is often chosen too late by developers without keeping in mind very specific needs of the Web site owners. At best, the business rules will be customized for content catering, but not to the point where the UX of Web site kitchen (administration UI) will be part of the real work. All Drupal Web sites, WordPress, etc. will look the same on the kitchen side because we have forgotten about it.

Fuzzy?

Imagine you created a beautiful design where the first letter of the Web page is an initial and the requirement is that the owner of the Web site must be able to manage the content of the Web site.

• How do you handle the possibility of free text and the requirement of a specific html/css markup to create the initial?
• What is happening when the content editor is putting a space before the first letter in the form?
• Is the CMS hackable to do it?
• Will I have to modify the core of the CMS?
• How much will it cost to hack the CMS?

We often try to have a very pleasant Web site for the public. That’s fine. But we should not forget the kitchen of the Web site. It’s where the Web site owner will spend most of his/her time. If the UX is complex, doesn’t answer the basic needs of people in charge of making the site alive, the site will fail, create frustration from the Web site owners, and destroy the business relationship.

UX, design and development teams need to work together for the kitchen sink too.

This can sometimes goes as far as designing the UX of URIs. An example?

Take the CAPTCHA W3C specification, a simple and very dry document for most users who might read it. The URI is

http://www.w3.org/TR/turingtest/

Now add a ,tools at the end of the uri

http://www.w3.org/TR/turingtest/,tools

You access a list of tools to manage this content or do something with it. For example you can create a text version of the page.

http://www.w3.org/TR/turingtest/,text

or access the list of translations of this document

http://www.w3.org/TR/turingtest/,translations

It is very geeky in this context but it gives you an idea of where the UX can impact the design of your Web architecture.

Have you really thought about the kitchen sink? What are your techniques for designing the invisible? What are your tips for not missing the UX of Web site owners?

The mobile devices are bringing a lot of diversity to the Web world. That is good. It should encourage universal design, respect of Web standards and not designing systems for specific systems. Unfortunately, Web developers, designers are being caught in the way they designed past Web sites : Desktop designs. The experience is then being very poor on a mobile device.

Their first incentive is then to design yet another entirely new site that will be specific for the mobile. That is a mistake. Browser sniffing stinks, even more so with the mobile era. It’s a sisyphean challenge. Every year, new handsets, new specific browsers. Willing to sniff Webkit user agent string? There is no Webkit on mobile. The list of user agent strings can be daunting. And the future with the rise of mobile in North America, the tablets and ebooks readers will be colorful.

Design your Web site for any devices. If you want to create an experience on the mobile, then design specific applications for mobile devices. APIs should help here.

These are my notes for day 3 of the Mobile World Congress 2010, in Barcelona. For past entries, see my impressions on day 1 and my reading of the pre-summit consensus on mobile augmented reality on day 2.

This is day three of the congress and I think I am starting to get the hang of it! Orienting oneself in this maze of booths can be daunting at first, but one eventually finds the two or three exhibition halls most relevant to their business, and focuses on these areas.

The past couple of days brought me a new set of observations. I’d already noted on day 1 how much the congress was focused on hardcore technologies, with a strong showing by telco hardware vendors and video streaming/encoding/delivery, for instance, but it took me an incredulous two days to accept another conclusion.

Where is the Web?

The most strikingly absent word in all this congress was, in my opinion, « web ». Of the thousands of exhibitors, I think only one built their message around it, and it was nvidia, with banners claiming that they “power the mobile Web”. Quite a strange messaging from this video chipset vendor, which I would expect to claim to power mobile gaming, mobile video… but the web?

Other than nvidia, I think only the browser vendors were talking about the web. Opera had a decent presence, sandwiched between the enormous areas dedicated to Microsoft and Adobe; OpenWave was here too, and so were a number of browser vendors I did not know before, including for instance Bolt. Coming from North America where I suspect the mobile web usage is almost strictly limited to powerful, large-screened smartphones, one has to remember that other markets have a strong demand for Web browsing capabilities on smaller, less able handsets. The ability to download a « PC-like » browser capable of displaying CSS-styled, complex layouts on a tiny screens is a very big deal.

The absence of the “Web” word does not mean that the Web technologies are no longer relevant to the mobile world. On the contrary, I believe that no-one is talking about the Web because it has become such an integral part of mobile technologies. And thus, what used to be a buzzword has become the silent foundation, leaving more space for new darlings such as NFC, geolocation or others.

One such important buzzword this year is “mobile widget”, which in most case refers to packaged web application! In this area, one interesting announcement made during the congress was the opening of the Wholesale Applications Community. This looks like a joint effort from a number of vendors to fight the current fragmentation in mobile applications development, with Apple’s success causing every vendor and their dog to release their own apps platform and market. The announcement is still rather unclear about what technologies will be used, but it seems likely that they will build upon existing consensus on widgets.

Mobile Augmented Reality Summit

Day 3 of the congress was also the occasion for many actors in the “augmented reality” scene to come together and look at the state of the art, the state of the market, and most importantly, look at potential areas for collaboration.

And what a great meeting it was. 65 people joined the summit for more than 4 hours or passionate discussions on the themes of technology, business, user experience or privacy.

Interestingly enough, even after the summit, I still find it hard to define the scope of mobile augmented reality. At the moment, it tends to take the shape of applications superimposing layers of data (Points of Interest, most often) on a video feed, but there seems to be an agreement that this may not be, in the long run, the preferred mode of interaction. As one participant stated, “no-one likes to walk around with a mobile phone in front of their face”, and many agreed that AR was not a stated user need. Perhaps, we all agreed, we should look at Mobile AR as an enhancement to existing applications, but not necessarily standalone applications for a unique usage.

In the end, the best definition of Mobile AR (albeit vague) may be the one proposed by Vodafone’s Daniel Appelquist: Mobile AR is where the mobile platform bridges the digital and physical world.

More on the Mobile Augmented Reality summit in a matter of days, as soon as the embargo on the summit materials gets lifted.

This post is a position paper for the upcoming Mobile Augmented Reality Summit, held in Barcelona on Feb 17th, 2010 held in conjunction with the Mobile World Congress.
Pheromone, as company developing Web services and applications, and online social networks in particular, will be joining this summit to observe the upcoming technological trends in Augmented Reality. We would also like to propose our vision of MAR beyond the usual scenarios of the online tour guide and the dystopian overflow of information without any concern for privacy: Mobile Augmented Reality as a very personal tool for memory, egocasting, serendipity and discovery.

With the increase in power of smart phones and mobile computing devices, the promise of enriching our daily context has recently taken the face of Mobile Augmented Reality. In a study, Matthew Buckland and Philip Langley write:

Imagine holding up your phone or other digital device against a person you’ve just met or passing by. You’d instantly have information returned about that person within seconds, gleaned from an automatic web, public profile and social network search. You’d discover common friends, talking points — and then have the ability to add him/her to your network. Using a semantic scan, you’d discover negative or positive comments on Google or elsewhere relating to this individual.

For now however, AR on mobile platforms is still burgeoning. Companies like layar, acrossair wikitude or robotvision are leading the charge with their mobile AR browsers.

Mobile Augmented Reality: just a glorified tour guide?

Strictly speaking, one could argue that these are not exactly AR, since their technology is mostly limited to the knowledge of a list of geolocated Points of Interest, which are then overlaid on a live video view of the geography around the user.

Facial Recognition, often touted as the future of Augmented Reality

The usual definition of Augmented Reality would involve analysis of the video feed and its « augmentation » with meta data about the scene, and thus, the current crop of MAR browsers are often refered to as « pseudo-AR ». Regardless, these are technological prowesses that do provide extra information about a scene, and would fit a more etymological interpretation of « augmented reality ».

Regardless of the semantic debate, the current MAR solutions are acceptable, albeit often flawed because of the relative lack of precision of positioning systems. One can imagine future progress in AR transcending the technical limitations of geolocation systems, and actually use face or building image recognition. This is the scenario that most AR ideation seems to be heading towards: Mobile Augmented Reality as a ultra-precise and dense overlay engine of *everything* around me.

The problem with this vision of augmented reality is that it leads us from the current situation where AR is but a glorified tour guide tool, to a disturbing dystopia where the thin veil of privacy (or complete lack thereof) in the online world becomes the reality of our AR-mediated physical world.

We could imagine, however, less disturbing scenarios for the evolution of AR. This require taking a few steps back and looking at what our perception our reality in a generic context is, and what our needs are.

AR as a dystopia engine

Most AR futuristic scenarios take place in a situation when the user would already know a lot of information on the scene (e.g: the name of participants of my meeting, the name of the street in which I am walking, etc.). AR can then repeat and enhance all this knowledge and overlay it onto the perceived scene. But what if instead of « enhancing » data I already know, AR actually surprised me with relevant information I may not know about, or remind me of information I may have forgotten.

Indeed, rather than leverage crowdsourcing and masses of data, it would enhance my life through the analysis of my own recorded behavior, and my choices of « egosourcing ».

Rather than knowing the names of all the people in the street – some mildly useful knowledge, not to mention a little disturbing – I would be happy to know whether my favorite restaurant in the area is open and what its menu du jour is, I would be interested to receive suggestions of an exhibition just opened in the museum a block away from here.

Without needing to wait for technology to allow for some of the advanced capabilities that MAR promises, there is a yet untapped market for MAR to look into:

1. egocasting and personalized bookmarking
2. collaborative filtering for unique, personalized suggestions. That is, going beyond raw data and the overlay of POIs, and instead doing the hard work
3. becoming a serendipity engine by matching social behavior analysis with the wealth of online data

Next week, amidst the Mobile World Congress, I plan to attend the Mobile Augmented Reality Summit and observe the trends in the MAR industry: are we rapidly heading towards highly technological Augmented Reality, or will MAR be the new media platform for lo-fi personalized information and social networking?

The night was full of insight and fascinating discussions, and I went home fired up by the bits of wisdom shared by panelists and audience, in particular this one remark by Praized CTO Sylvain Carle. Speaking about how he and his company would factor in users, Sylvain said that the most important thing he often had to remind him of, was: “I am not my core/target user”.

For us builders of interaction and experience, this is one of the hardest pitfalls to avoid. Very often, one will hear the story of how a great product has been built first and foremost for its own creators, and just happened to meet the needs of a lot more people! This may often be true, especially at the beginning of a project, it tends to lead us to hubris and delusion.

When my product has been in development for several months or years, is my target user an expert who knows its nooks and crannies by heart, who long ago worked around its flaws? If at that point I think I am the core user, maybe I shouldn’t be surprised when I fail to get new users excited, and only manage to keep around a small core of veterans.

The trick, as one matures with their project, is to realise we drift further and further from our target user base, humbly listen to them and their needs, and find a way to build something that they, and ourselves, will utterly love.

Interaction designer and Typographer shared process

The best process when designing interfaces is the data driven design vs. the graphic driven design. When designing for people, for usability, designing a service, a useful object, a useful site or phone, we _as Interaction Designers_ need to think about the obvious. What is it that will make people intuitively understand the means of the product? In other words, make the end result as intuitive, and as natural to use as to turn a door knob in order to open the door.

Design should make our lives easier, and not complicate them. Design should be invisible. When designing a site, whatever this site might be, design should be the structure on which content sits and blossoms.

In an  attempt to describe what I mean by Id = = Typography, I will quote a passage from, The Elements of Typographic Styles, a bible for contemporary typographers and designers, written by Robert Bringhurst :

« There are always exceptions, always excuses for stunts and surprises. But perhaps we can agree that, as a rule, typography should perform these services for the reader:

• invite the reader into the text;
• reveal the tenor and meaning of the text;
• clarify the structure and the order of the text;
• link the text with other existing elements;
• induce a state of energetic repose, which is the ideal condition for reading.

While serving the reader in this way, typography, like a musical performance or a theatrical production, should serve two other ends. It should honor the text for its own sake – always assuming that the text is worth a typographer’s trouble – and it should honor and contribute to its own tradition: that of typography itself. »

The Invisible

Embracing the future, letting go of the past

The keys to hold in your hands as a designer, specially one designing interfaces aimed to serve as a service, or as a bank of content, is the following:

• invite the reader/customer/blogger into the content;
• reveal the tenor and meaning of the content of the site;
• clarify the structure and the order of the site;
• link the content with other existing elements of the site, or other services, or other contents;
• induce a state of energetic repose, which is the ideal condition for reading/browsing/using the information.

Your design should be honoring the content of the site. Content itself should be placed on an invisible and solid structure balanced in space and organized in a hierarchical way favoring priority of information. Brand should have enough space to deploy its colors or shape not overlapping the information, or compromising the understanding of the content.

Concepts of visual design can be applied when thinking of an interface. Concepts like how the eye reads in diagonal, « le vide est aussi important que le plein », catchy elements, color attention, and so on. However any type of ornamentation, or decoration should be abolished when thinking and drawing an interface as it serves no purpose for the content. The goal and purpose of the site is aimed to invisible and transparent.

When designing the obvious, the useful, the seamless, it is important to always be reminded to know the content of which you apply Information or Interaction design to. The structure that is thought first, then drawn should also be basing itself on reality (data) and feasibility.

Check List

Things to remember

1. Get the content
2. Make a thorough content inventory of the site
3. Work on a content strategy
4. Know where this product is positioned in the market, and who else is offering the same type of things (competitor research can inspire you a lot!)
5. Research who is going to use it, and how
   

The user experience on these two kinds of devices are entirely different in their focus, spacial context or time context.

NY Times mobile app, similar on iPhone and Android

Data, however, has been steadily converging in the past few years, and the promise of One Web has become a reality. Most major (text-based, at least) content providers generally have an offering un traditional media, on « desktop » web clients as well as mobile. The latter two can be part of the same web space, with minor content adaptation and separate presentation. Also interesting are all the recent « mobile applications » and « mobile widgets » that use the Web as a source of linked data, and dress that data accordingly.

Recent diving into the logs for a number of websites I take care of showed some overwhelming trends in sites mainly aimed at the urban creative class: on the mobile version of the sites, up to 98% of the traffic was caused by either indexing robots or browsing devices such as the iPhone. Practically none of the visitors were browsing the site with devices sporting pre-CSS browsers and monochrome screens…

in Japan, a country with a rich history of mobile browsing (notably with i-Mode), and a stronger legacy of low-tech mobile browsers in almost every handset, I have observed that close to 70% of the traffic for mobile sites are bots, with googlebot nearing 55%. The rest is almost exclusively from KDDI headsets – KDDI being the only carrier offering a mobile browser for free.

This seems to suggest that most of the rest of the customer base has now switch to what Japan calls « PC browser », aka full-featured, CSS-enabled browsers for mobile platforms, and that these browsers directly access the « full-featured » version of the sites. Add to this the fact that most « mobile websites » make the mistake of miniaturizing rather than mobilizing and it indeed makes little sense to go for the poorer experience.

NY Times mobile website
as experienced on iPhone

Not all phones on the market feature one of those CSS-enabled browsers with zooming capabilities, but a couple of players (opera mini and webkit) have been invading the landscape at a very fast pace. It actually looks like webkit is soon to be crowned king of the mobile device market: after being used in both the iPhone and the Android browser, it looks like it will also come soon on Blackberry, too.

Truth be told, the sites which I used as research subjects are aiming at a fairly wealthy, well-connected, urban audience. While my numbers are obviously not relevant for populations on the other side of the digital/mobile divide, they are certainly the tip of trends to come for the first world. And the trend says: do we still need mobile web sites?

We are still overwhelmingly designing Web sites for whatever computer screen width is the norm, or at least the least common denominator. How many times in the past few years have we seen sites re-designing with a fixed width around 970 pixels because « no-one uses 800×600 screens any more »? Fixed width designs are undoubtedly convenient, and do make sense if all devices used to access the site are consistent in their size and interface.

NYTimes.com: fixed width design at 972 pixels

This, however, may be changing soon. Recent rumours are spreading about Apple preparing the launch of a mobile tablet, which mode of interface would be very much like the iPhone, but with a 8 to 10 inch screen. Beyond gadget envy, what is exciting about such a tablet (and the increasing sales of other netbooks) is that we are finally bridging the gap between tiny mobile devices and big computer screens.

When the range of web-enabled devices becomes entirely continuous between the small and the very large, between the ultra-portable and the very static, will it still make sense to build specific « mobile » (read: miniaturized) websites?

I believe that there are two ways forward:

1. Hyperspecialized « applications » using Web-based linked data as a backend. This is definitely an ongoing trend, with Android, Apple, Palm etc. all building a lucrative application marketplace. These applications are costly to build, however, and incompatible between one another. So long as one player (the iPhone for now) reigns almost supreme, it makes sense to build an app for it, but if competition leads to a true balkanization of platforms, it will no longer be cost-effective to build similar apps for a dozen platforms when a single platform could do the job: HTTP+HTML+CSS+Scripting…
2. A maturing of web-based designing with fluidity in mind. Can we create designs that scale regardless of screen size or context? Can mobile stylesheets, media queries, content adaptation, and APIs for contextual enhanced features such as geolocation help us build single interfaces that scale? And what are the future challenges for User Interfaces in such a converged market?