This is an important question to be asked at an early stage in a project, especially when stakeholders (clients, managers) are trying to assess whether to go ahead with the project.

When faced with such a question, I’ve seen people usually split in two groups:

• Those who will refuse to say anything unless tortured, since the project brief is obviously way too vague and there are possibly weeks of research, analysis and specification needed before having a clear idea of the work involved. They’re right of course, but their lack of an answer is about as useful for the decision process as throwing a dart at random towards a sheet full of numbers.

  With experience, they will learn to give befuddlingly vague estimates such as “somewhere between 5,000 and 5,000,000” and at least get a chuckle out of this torturing process.

• Those who will painstakingly list everything involved in the project, estimate time for each small activity, and add up. Unless they are really experienced at delivering and managing such projects, they are very likely to forget half of the activities involved (meetings, interruptions, time waiting for an answer) and will wildly underestimate.

  Or, if they decide to play it safe and comfortably pad the estimates for each activity, they will sooner or later get into the even more painful process of having someone challenge each of these numbers, one by one.

There is, fortunately, an alternative which few people seem to go for. It goes like this:

(Team Size) * (Full Time Ratio) * (How Long to Complete)

Suppose you have a project to deliver. First, imagine who would work on this. Yourself? A team? No, we’re not talking man-months, think of real people. (e.g if you think yourself, Bob and Alice could do it, your first number in the equation is 3.)

Now, would this team be working full time on this? Is this reasonable? Are they more likely to have to wait a lot, and thus should they split their time between this project and others? (e.g if the team is going to be half-time on this, the second number in the equation is 1/2.)

Then, ask yourself how long it should probably take to deliver the project. Sure, this is hard, but remember at this point you’re looking for a ballpark estimate, an order of magnitude. So don’t think in terms of tasks and activities and deliverables, look at the big picture and ask yourself how long “such a team” would need to deliver “such a project”. Is this going to take a week to deliver the whole thing? Two weeks? A months? Six months? (e.g if the project is something that should take about two months, then you’re looking at about 300 hours of effective time. 300h is your third and last number in the equation.)

Finally, multiply it all. In our example, the project would take an approximate effort of 3*0.5*300, or 450 hours of work.

See, wasn’t so hard?

From then on you can improve on this method to match your organization and working style (need to factor in overhead and project management?), by splitting the project in iterations or milestones if it is too big to estimate, etc. The trick is to go just granular enough to match your working style, but to resist the urge to get into details and fall in the pitfalls of micro-planning.

Such a formula may not be perfect, but at least it is quick, not painful, and in my experience it is about as effective at giving a ballpark estimate effort – if not better – as any of the other solutions mentioned above.

It works for me… YMMV. Anyone ever used something similar? If so, did it work for you, or did you have to change it drastically to make it more reliable?

Love the “internet explorer” icon there. Consistent, since the image on the box also looks like iOS, but within the IE6 GUI.

ePad box. Note the EBook app icon.

Unboxing the beast. Weird screen aspect ratio, but hey, it's MUCH lighter than an iPad.

At first I thought we had an exclusive on the first tablet running flash. Correction: the box runs flash. Not the tablet.

Quality Control seal. We feel safe.

It DOES run android.

Good news: it is a tactile screen. The screen is ugly. But Android runs.

Definitely running Android. This is where I got bored.

Priceless.

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.

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.

Oui, et non.

Le web comme ecosystème d’information n’est pas en danger.

Les technologies du web ne sont pas en danger (au contraire – le même Steve Jobs par exemple se gargarise des technologies ouvertes du W3C comme HTML5 ou CSS).

Par contre, le paradigme du “site” web, comme espace où l’on se déplace, lui, est je crois moribond. C’est un changement important qui voit son origine, entre autres, dans l’apparition des mobiles.

Note: an english version of this post is also available: The Web Site: a moribund metaphor.

Avant l’arrivée de l’internet mobile (laptops, smartphones, netbooks, tablettes), notre perception est que l’ordinateur nous transportait vers l’internet. D’ou la métaphore: site, navigateur, “aller sur yahoo”. Métaphore qui existait aussi avec les premiers systèmes de réalité virtuelle. Métaphore qui nous a donné geocities: souvenez vous! geocities etait plein de quartiers virtuels…

Avec l’arrivée du wi-fi, de la connectivité fiable sur les réseaux téléphoniques cellulaires, c’est tout le contraire.

Nous sommes tout le temps en déplacement, donc nous n’allons plus sur le web, c’est le web qui se déplace avec nous. Et comme le web et ses informations sont disponibles tout le temps, les personnes veulent des réponses immédiates (ici et maintenant) à leur besoin.

D’où l’émergence d’une nouvelle métaphore et une nouvelle économie autour:

Exit geocities et le “site” web. Entrent en scène les services ubiquitaires, adaptés à des besoins précis. Pour l’instant sous la forme d’applis et/ou de widgets, mais la forme n’est pas fixée. L’avenir nous dira si Apple réussira son pari de dominance, ou si la fragmentation du marché des “app stores” tuera ce modèle, comme semble le croire des gens comme PPK. Mon pari, par contre, c’est que le “changement de paradigme” (buzzword alert!) du site Web au service web est durable.

An english version of this post, called Three Innovation Models, is available on my personal blog.

Google

Suivant le modèle de McKnight et 3M, google donne a ses employés 20% de leur temps pour expérimenter sur des projets de leur choix. Les projets les plus prometteurs deviennent des projets officiels – le reste est une formation utile. Intéressant aussi est le facteur de pollinisation et de compétition entre les différents projets: les employés sont tenus de présenter aux autres leur travail, et une saine (?) émulation compétitive les pousse à faire de leur mieux.

J’ignore si la plupart des googlers sont sous pression de livrer un volume de travail de 5 jours en 4, s’ils font leurs 20% en heures supplémentaires, ou si ce sanctuaire est effectivement respecté.

Stefan Sagmeister

A la tête d’une agence de design (produits physiques, videos, etc) Sagmeister a décidé de donner à toute l’agence une année sabbatique tous les 7 ans. Il utilise cette année pour voyager, jouer avec des idées, lancer des prototypes sans la pression de livrer.

J’ignore si Sagmeister paye l’année sabbatique de son staff, ou si le staff va travailler ailleurs pendant 1 an…

Ferran Adria et El Bulli

El bulli, l’un des restaurants les plus courus au monde, n’ouvre ses portes que 6 mois par an. Les 6 autres mois, Adria et son équipe se retranchent dans leur laboratoire pour préparer le menu de la prochaine saison. Les reservations sont généralement toutes remplies en l’espace d’une journée.

Hélas, il semble que le restaurant aux 3 étoiles Michelin ferme… faute de profits. Ou pour se réinventer?

Investir dans le temps

Les points communs? Ils investissent dans le temps – en donnant à leurs employés une chance de sortir du pilon quotidien de la production pour expérimenter. La seule différence est sur le ratio et la fréquence de ce “temps libre”: 1 an tous les 7 ans… 6 mois par an… ou 1 jour par semaine?

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 is the second post in my coverage of Mobile World Congress (see also the first post with my first impressions and the major trends at the MWC). Today I finished reading the 30-odd position papers for the upcoming Mobile Augmented Reality Summit, and while I am not yet at liberty to share the location of the papers, I took the time to write down what I think is the rough consensus among the participants, before the summit itself.

The rough consensus on mobile augmented reality seems to be the following: Mobile Augmented Reality (MAR or just AR) is a field with a lot of potential, but it is still in its infancy. Yet, 2009 has seen MAR in the spotlight and receiving a lot of attention and hype. All the players thus feel that they need to make progress, and make it fast.

There is no doubt that the current breed of mobile AR tools are, for the most part, a new generation of what was called “mashups” only a few years ago: superposition of several sources of information, mostly based on geolocation metadata. Indeed, one of the basic technology used for mobile AR (KML) is the same being used for google maps, the darling child of the mashups hype. This geolocation-based technology is already being useful, but there seems to be an agreement among the industry that AR needs to go beyond the current state of the art to really shine.

The path forward, according to many, will necessarily take the shape of strong, fast and effective visual recognition. While a lot of progress has already been made in providing AR services through markers (usually barcodes, or NFC tags). Others, however, think that the real value to the user will not necessarily come from technological breakthroughs, but with the smart use of the existing framework, and the solving of some of the most pressing policy issues, with privacy for instance: with the integration of the physical world and online information mass becoming more and more seamless, how do we ensure the right to privacy and mitigate the effects of “too much information” being available on everyone at everyone’s fingertip?

You can also read the position paper I wrote for Pheromone on MAR here.

I am currently in Barcelona, Spain for the 2010 edition of the Mobile World Congress. I will be trying to cover the event as I experience it, through pseudo-live-blogging articles. I also plan to produce an ePub report at the end.

After a week-end marred by flight delays, surprisingly cold weather and mild food poisoning, here I am on the Plaça d’Espanya, in one of my favorite cities in the world, about to enter the Mobile World Congress for the first time.

The first impression when you pass the gates of the Fira de Montjuic, and get your identity checked (thrice – just in case) is that the congress is huge. HUGE! Each hall could host a sizable international congress… and there are eight of those, not counting the extra halls requisitioned by companies like Nokia, Huawei or Vodafone.

A lot of the exhibitors are here to sell hardware: amplifiers, antennas and handset components, about which I know little so skipped most of the time. Instead, I tried to go through the whole exhibition in one go and try to distinguish some trends for the contents industry.

SMS, payments and platform fragmentation

So many booths seem to be dedicated to micropayments, payment solution, and billing solutions. This seems to be a very big market, both oriented towards the mobile operator business (billing, payment) and content providers (micropayments).

SMS/MMS messaging still appears to be the leading mode of messaging. Although most new UI innovation seems to be revolving around all-integrated platforms mixing e-mail and social networks for rich applications, a lot of the companies specializing in mobile communication still tout their SMS throughput.

NFC is an interesting trend. Short for “Near-Field communication”, it encompasses all the technologies allowing contactless communication between devices.

As would be expected, video is big, between the makers of DSP, video on demand, mobile TV and other similar solutions.

So much greenwashing! Every big player seems to have the obligatory part of their booth dedicated to how green they are – but mostly they limit themselves to claiming their hardware is not laden with harmful chemicals. The actual green presence is tiny and hidden in one of the most remote parts of the congress: a handful of companies selling wind turbines, solar panels and other alternative energy sources to power mobile grid. No sign of the recent trend to product and sell hardware made from recycled materials. I’ll assume these were not selling so well.

Adobe selling Flash as “One Web, Any Device”

Content providers are clearly not playing here. No Time Warner, no Sony. Google is supposed to be around, but nowhere to be found. Mobile apps developers are few, too, which surprised me. So far, beyond a few companies presenting variants of geolocation systems, the apps world has eluded me at the congress.

Big platform vendors are here, however – except for the very conspicuous absence of Apple. This is a great opportunity for others to show off their development platforms. The sheer number of mobile development platforms is actually scary. Samsung just released bada, their new Operating System and associated development platform. Others seemed to be doing the same, promoting their proprietary OS and development platform as the best, most powerful and flexible.

At the other end of the spectrum, the LiMo Foundation appears to be a cross-vendor effort to build an open-source operating system for mobile, based on linux. Motorola, Panasonic, Else and Samsung seem to be on board, along with a few carriers such as Vodafone.

Win7 Phone Event

One of the large events of the day was the announcement of the new windows 7 phone. Steve Ballmer was here, and Joe Belfiore, VP of the Windows Phone programme came and explained the philosophical shift behind the Win7 Phones. In a nutshell, they wanted to revisit the User Experience of the phone and move beyond the pc metaphor. They devised a new UI made of “live tiles” which are basically concentrated aggregation of information, from a view of people (from various social networks), agenda, mail, media, etc. The goal it seems is to finally mix home and work into a single device.

update 16 Feb 2010: Paul Kwiatkowski has a good analysis of the phone’s potential path to success, along with a video of its interface.

I am not (yet) impressed and couldn’t help shake off the impression that Ballmer was a terrible speaker, and that Belfiore was a bit too much of a Steve-Jobs-wannabe in his pushy enthusiasm. But if you want to read more about the phone UI – engadget has a hands-on review.

Wait… what?

Finally, the “are you for real?” award of the day goes to the DoCoMo team who were presenting a most interesting piece of innovation: eye-controlled earphones. Look left to play or pause, look right to fast-forward. Roll your eyes for volume control (no, not kidding…). I’m suspecting you have to cross eyes to shuffle?

Live demo of DoCoMo's eye-controlled earphones.

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?

Why cheer upon seeing the iPhone sales skyrocket in the last quarter, or the latest Android device releases boosting that platform, too? After all, both Apple and Google push their own development platform, with their own SDK, programming language alien to a lot of Web developers (Objective C for the iPhone OS, java for Android), and so on.

At Pheromone, our developers are clearly gearing their expertise towards Web technologies and open-source platforms. A few of us do know Java but would rather never need to use it again. As for Objective C, the verdict seems to go from a puzzled “huh?” from most developers, to “this is just wrong” from C++ veterans. Clearly we are not experts in the iPhone or Android official development kits, nor, I suspect, will we ever be. And yet, we are loving the platforms, and having a great time building applications for them.

The key to understanding this paradox is WebKit, the open-source web browser engine that happens to be deployed on almost all the major mobile platforms. Granted, experts will tell you that “not all webkits are created equal”: there is not a single webkit, and each device will have a slightly different instance of the engine, with its own bugs and odd behavior sometimes. Yet, WebKit happens to implement most of the APIs that are being added in and around html5. Geolocation? check. Notifications? check. Local storage? check.

Open standards and Web technologies being the best solution for cross-platform development of applications or interfaces around online data is nothing new. What is rather new, however, is the ability to marry this cross-platform compatibility and ease of development with the business incentive presented by the Apple App Store, Android Market, Blackberry appworld and others: package an app, upload it, and start making money. This is the nifty trick made possible by the likes of PhoneGap or Titanium.

Technically speaking, these two are fairly different. Titanium puts more effort into compiling your Web application into native code and native UI controls, but is still limited to iPhone (and now iPad) and Android. On the other hand, PhoneGap seems content with providing native capabilities through a powerful javascript library and compiling a thin wrapper around your web application – but it does so for many more platforms than its main competitor: iPhone, iPad, Android, Blackberry, Symbian, WebOS, …

I tried both tools in the past few weeks. Originally, I was more attracted to Titanium, with its better documentation, cool UI, excellent demo and promise of native UI controls and extensibility. It just looks and feels more… professional. Eventually however, I was a little put off by the rather “small” number of platforms supported and the presence of a centralised tracking (analytics) system I could not switch off. PhoneGap may have slightly poorer documentation (they say they’re working on it) but the promise of real multi-platform worked for me. We may just end up switching from one to the other depending on the needs of what we are building.

How about you? Would you rather use native SDK development for your mobile applications? Have you tried any of the up-and-coming web-to-mobile frameworks?

salut www.rds.ca, pourrais-tu me donner la ressource /new_images/small_STEPLARO.gif ?

Un serveur Web bien configuré répondra quelque chose de ce genre:

1. OK, voici l’image
2. tu peux conserver cette image en cache pendant 24 heures (Cache-Control: max-age=86400, public)
3. je te donne aussi un hash du contenu de l’image pour que tu vérifies que mon image n’a vraiment pas changé (Etag: "89bfd6-56a-444cef52ba15b")
4. le serveur pourrait aussi répondre “Expires: Tue, 01 Dec 2009 16:00:00 GMT” ce qui est redondant avec le Cache-Control, mais puisque tous les clients, notamment les plus anciens, ne comprennent pas toujours très bien l’en-tête Cache-Control, Expires en est une alternative utile.

Ainsi, le navigateur va récupérer l’image, mais aussi garder en cache local une copie, avec une date d’expiration dans 24 heures. Si quelques minutes plus tard le navigateur a de nouveau besoin de cette image, il a le choix entre deux solutions:

1. utiliser son cache local. Le navigateur peut le faire car le serveur lui a dit de conserver un cache.
2. demander au serveur si l’image a changé depuis la dernière fois. Le client va envoyer une requête HTTP vérifiant la fraîcheur de son image en cache:

   GET http://www.rds.ca/new_images/small_STEPLARO.gif HTTP/1.1
   Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
   If-Modified-Since: Mon, 28 Jan 2008 21:26:14 GMT
   If-None-Match: "89bfd6-56a-444cef52ba15b"
   Cache-Control: max-age=0
   

Dans ce cas, le serveur peut vérifier qu’effectivement, l’image n’a pas changé et n’aura pas besoin de renvoyer l’image, il lui suffit de répondre avec le statut HTTP 304 Not Modified.

Dans la plupart des cas, le second scenario est désirable: le client (navigateur) s’assure vraiment que la ressource est fraîche, et il n’y a presque pas de gâchis de bande passante. Par contre, dans les rares cas tels que rds.ca, ou le trafic et la charge des serveurs est immense, il nous serait très intéressant de ne pas avoir à gérer des millions de requêtes 304 Not Modified pour des images qui ont été correctement cachées! Malheureusement, nos recherches jusqu’ici s’avères infructueuses et il ne semble pas exister de directive de cache en HTTP qui forcerait l’utilisation (sans validation) de ressource cachée en local. Recherche à suivre…

Pour plus d’infos sur HTTP et la gestion des caches, la meilleure ressource (en Anglais) nous vient de Mark Nottingham: Caching Tutorial for Web Authors and Webmasters.

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.

Parmi les changements majeurs apportés par cette refonte, outre le massif ouvrage de simplification de la navigation et d’architecture d’information, il est intéressant de noter que l’équipe du W3C a décidé d’utiliser pour ses feuilles de style la méthodologie de «CSS orienté objet» développée par Nicole Sullivan. Les principes fondateurs du ooCSS partent d’observations qui rejoignent les miennes: tout site d’envergure, de croissance organique, ou qui voit son design évoluer au fil du temps voit aussi ses feuilles de style se transformer en bazar inextricable.

Résultat: des feuilles de style lourdes, mal organisées, redondantes, utilisant rarement les potentialités (notamment pour les aspects de cascade) du langage CSS… Tous les projets de “refactorisation de code CSS” auxquels j’ai pu assister se transforment souvent en vilaine farce: on efface tout et on recommence. C’est souvent une perte de temps, un gâchis d’argent, et dans la plupart des cas le travail de rationalisation des feuilles de style est repoussé aux calendes grecques, à savoir à une éventuelle refonte complète du site.

C’est dans ce contexte que ooCSS fait son entrée. Se réclamant de deux principes fondateurs: «séparer la structure et l’habillage» et «séparer le contenu du contenant», le CSS orienté objet part surtout d’une affirmation: le CSS, c’est du code, et il revient aux professionels du Web de le traiter en tant que tel. Et tout comme la plupart des «frameworks» de code (Rails pour Ruby, Django pour Python, etc.) auront permis aux développeurs de structurer leur code autour d’une architecture réfléchie et adaptée au Web, il faut se réjouir de voir un effort similaire, quoique sans doute encore maladroit, tenter de structurer la pratique du langage CSS.

Pour en savoir plus sur ooCSS, la meilleure introduction au sujet demeure cette présentation par Nicole de son framework, et bien entendu, la mise en pratique.

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?