Vous connaissez SuitSupply ? Il s’agit d’un fabricant de costumes hollandais qui n’a pas froid aux yeux. Ils exploitent ainsi le filon du porno chic dès la page d’accueil de leur boutique avec des visuels en plein écran :
J’apprécie cette touche coquine (et encore je n’ai pas choisi la photo la plus osée), même s’il faut bien remarquer que le menu de navigation situé à gauche de l’écran n’est pas très visible, ni très pratique. En grand professionnel que je suis, j’ai tout de même pris le temps de visiter cette boutique et je suis tombé sur deux ou trois idées tout à fait intéressantes.
Il y a tout d’abord une page de catégorie à défilement horizontal où l’on peut zoomer sur les détails des costumes :
Il y a ensuite une boîte d’ajout au panier (avec la sélection de la taille) où sont incrustés des produits associés (chemise + cravatte) :
Il y a enfin un tunnel de commande dans le plus pur style minimaliste avec un panier néanmoins parfaitement lisible :
Au final nous avons donc une boutique qui frappe très fort dès la page d’accueil (quitte à faire fuir des clients qui surfent au bureau) mais qui propose des astuces tout à fait intéressantes et un engagement graphique cohérent. Pour résumer : une boutique qui a de la gueule, ça change !
Le monde du jeu en ligne a subi deux électrochocs ces dernières années : La déferlante du modèle Free-to-Play et les social games. Mélangez les deux et vous obtenez un marché ultra-chaud bouillant. Estimé à plus de 2 milliards de $ en 2011, le marché des objets virtuels (« virtual goods » en anglais) attise donc toutes les convoitises. Pourtant force est de constater que l’intensité concurrentielle est déjà très forte. Tellement forte que les éditeurs occidentaux s’intéressent déjà à la prochaine niche à forte croissance : les objets virtuels sur mobile qui génèrent 80% des revenus des applications iOS (Mobile Virtual Goods Generate 4X More Revenue Than Ads et Zynga).
Répartition des revenus pour les social games
Pourquoi s’intéresser aux plateformes mobiles ? Tout simplement, car c’est un marché bien plus juteux que l’on ne pense. L’éditeur japonais DeNA annoncent ainsi 1,25 milliard de $ de C.A. (Japan’s DeNA claims it makes 30 times more per user than Facebook, 15 times more than Zynga). Ces chiffres astronomiques reposent principalement sur Mobage-Town, un portail accessible uniquement sur mobile, et sur la vente de biens et services virtuels.
Suite au rachat de ngmoco par DeNA, les grands éditeurs occidentaux sont donc sur les starting-blocks (Disney’s Playdom and Crowdstar Envision A Much Bigger Pie) mais misent peut-être sur le mauvais cheval, car la clé du succès de Mobage town est de toucher une très large par de la population japonaise : les possesseurs de téléphones mobiles et pas seulement de smartphones (et encore moins d’iPhone).
Mobage-Town, l’univers virtuel japonais accessible sur téléphone mobile
Ceci étant dit… il est tout de même impossible d’ignorer les spécificités du marché japonais où les mobinautes sont équipés de téléphones mobiles bien plus puissants que nos feature phones. Je pense que l’on pourrait résumer une longue histoire en disant que les Japonais ont commencé largement avant les marchés occidentaux (ce qui explique la taille du marché actuel) mais qu’ils sont maintenant confrontés à un problème de limitation du parc actuel (en comparaison avec le parc de smartphones en forte expansion en Europe et en Amérique du Nord).
Moralité : Si le mobile représente un très fort levier de croissance, ce n’est pas parce que les éditeurs asiatiques (japonais, sud coréens…) ont bien plus d’expérience qu’ils vont s’attribuer facilement des parts de marché. Le problème est ici lié au fossé culturel entre les marchés asiatiques et occidentaux. Attendez-vous donc à une vague de rachat d’acteurs de niche par des éditeurs asiatiques. À moins que Google ne rentre dans la danse pour faire barrage (Google Buys Zingku, Mobile Social Network et Google To Buy Social Payment Provider Jambool).
La bataille est donc loin d’être terminée (en fait elle commence à peine) mais j’ai comme l’impression que les leviers de compétitivité sont à développer sur les plateformes mobiles autres qu’iOS (trop fermée et trop exposée).TALENT MANAGEMENT
Après ChromeExperiments et The Wilderness Downtown, Google continue d’évangéliser le marché sur les capacités d’HTML5 avec un nouveau projet : 20 Things I Learned About Browsers and The Web. Il s’agit en fait d’un livre numérique (sur le même modèle que ce qui existe en Flash comme le FluidBook) qui vulgarise le web au travers d’explications courtes et d’illustrations enfantines :
Le livre numérique de Google en HTML5
Outre la qualité de la réalisation (mise en page, traitements graphiques), ce sont les animations et interactions qui sont les véritables vedettes de ce livre :
Le bord de la page se corne au survol de la souris ;
Les pages se tournent comme sur un vrai livre ;
Certaines illustrations sont animées ;
Il est possible de sauter directement à une page en cliquant sur la frise sous le livre.
Rien de très révolutionnaire, si ce n’est que tout est réalisé en HTML5, CSS3 et javascript. En quoi est important ? D’une part ce livre électronique ne repose sur aucune technologie propriétaire, mais chaque page possède sa propre URL et son contenu est parfaitement référencable (comme une page HTML en fait !).
L'index du livre
Cerise sur le gâteau, il existe même un mode de lecture à fort contraste pour lire au lit :
La version nuit
Au niveau du code source, vous pouvez aller vérifier vous même, mais c’est bien une page web traditionnelle :
Le code source
Vous pourriez me dire que cette première expérimentation signe l’arrêt de mort du format propriétaire iBooks d’Apple, mais les choses ne sont pas si simples, car ce livre électronique est illisible sur un iPad (malgré le fait que Safari utilise le même moteur de rendu que Chrome) :
Le livre électronique en HTML5 illisible sur l'iPad
Au-delà de cette (surprenante) incompatibilité, d’autres raisons font que cette expérimentation n’est pas réellement viable :
Les nombreux autres formats proposés par les constructeurs de e-readers (Comparison of e-book formats) ne vont certainement pas disparaitre, car il existe un important fonds documentaire à rentabiliser ;
Les e-readers ne sont pas assez puissants pour faire tourner un navigateur moderne comme Chrome.
Bref, cette expérimentation ressemble plus à une opération d’intimidation (voir de propagande) qu’à une réelle volonté de bouleverser le secteur des livres électroniques. Elle s’inscrit donc dans la stratégie à long terme de Google (cf. Google à l’assaut d’iTunes et d’iOS avec Chrome et HTML5 ?).
Vous connaissez les interfaces textuelles ? Mais si enfin, les interfaces à ligne de commande (« Command Line Interface » en anglais). Les premiers IHM ne proposaient ainsi pas d’interfaces graphiques; il fallait donc exploiter des lignes de commande :
find / -size +1000k -mtime -7 | sort | tee trace | less
Autant dire que la manipulation était complexe et l’apprentissage très long. Le pire, c’est que ces interfaces étaient également très laides :
Depuis l’outil informatique a beaucoup évolué (Windows turns 25 years old, let’s take a look back in time). Il n’empêche que si l’utilisation d’un ordinateur avec une souris est plus simple à comprendre, nous avons tout de même perdu en rapidité d’exécution. C’est à ça que servent les raccourcis clavier : à gagner du temps sur l’exécution de tâches répétitives. Voilà pourquoi des services en ligne à usage intensif comme Google Reader ou Twitter proposent les leurs : Google Reader Keyboard Shortcuts et New Twitter’s Keyboard Shortcuts.
Pour les nostalgiques il existe même des meta-moteurs de recherche proposant une interface textuelle comme Goosh ou YubNub :
Je rebondis tout naturellement sur un article publié par UX Magazine (Command Lines: Alive & Kicking) pour faire le point sur les dernières innovations en matière d’interface. Mélangez ainsi une interface graphique avec des raccourcis clavier et vous obtenez les lanceurs d’applications (l’auteur de l’article parle de Graphic Command Line). Ces utilitaires sont devenus en quelque temps les nouvelles coqueluches des geeks et autres power users (Launchy pour Windows, Quicksilver ou Alfred pour Mac).
Le principe de ces outils est de vous faire gagner du temps en vous permettant d’effectuer tout un tas d’opérations élémentaires à l’aide de raccourcis clavier (ouvrir une application, trouver un fichier, faire une recherche sur le web, effectuer des opérations mathématiques simples…). Ces outils se positionnent donc en complément des fonctions natives du système d’exploitation (menu démarrer, calculatrice…) mais sont accessibles depuis votre clavier sans avoir à lever les mains de votre clavier et attraper votre souris (il faut faire une combinaison de type Ctrl + Alt pour invoquer le lanceur).
Dans le même esprit, Mozilla propose un système similaire baptisé Ubiquity : un plug-in pour Firefox permettant d’exécuter des opérations à partir de commandes textuelles en langage naturel.
Tout ceci vous semble peut-être un peu trop expérimental, mais quand j’observe le rythme d’innovation sur des navigateurs modernes comme Firefox ou Chrome (et le barre de recherche universelle), je me dis que nous ne sommes pas loin de l’intégration en natif de ce type d’interfaces (en supplément des menus et icônes).
Au-delà des navigateurs, il me semble primordial d’envisager cette solution pour les applications en ligne à usage intensif, et je fais plus précisément référence aux applications internes. L’idée serait donc de proposer :
Une interface graphique avec des boutons, icônes et liens ;
Des raccourcis clavier pour les fonctions simples ;
Une interface à ligne de commande pour les fonctions plus élaborées.
Ces trois types de modalités d’interaction seraient bien évidemment complémentaires et permettraient de satisfaire à la fois les utilisateurs occasionnels et les utilisateurs avancés qui passent leur journée dessus. Idéalement il faudrait même prévoir deux interfaces graphiques :
Une interface privilégiant la pédagogie et le guidage (avec de l’aide en ligne et des intitulés explicites) au détriment de la densité d’information ;
Une interface privilégiant la productivité (en mode plein écran et avec des abréviations) mais nécessitant un temps d’apprentissage.
Tout ceci est théorique, mais je suis certain que dans de grosses institutions (banques, compagnies d’assurance…) de telles réflexions seraient bénéfiques.
Après ChromeExperiments et The Wilderness Downtown, Google continue d’évangéliser le marché sur les capacités d’HTML5 avec un nouveau projet : 20 Things I Learned About Browsers and The Web. Il s’agit en fait d’un livre numérique (sur le même modèle que ce qui existe en Flash comme le FluidBook) qui vulgarise le web au travers d’explications courtes et d’illustrations enfantines :
Outre la qualité de la réalisation (mise en page, traitements graphiques), ce sont les animations et interactions qui sont les véritables vedettes de ce livre :
Le bord de la page se corne au survol de la souris ;
Les pages se tournent comme sur un vrai livre ;
Certaines illustrations sont animées ;
Il est possible de sauter directement à une page en cliquant sur la frise sous le livre.
Rien de très révolutionnaire, si ce n’est que tout est réalisé en HTML5, CSS3 et javascript. En quoi est important ? D’une part ce livre électronique ne repose sur aucune technologie propriétaire, mais chaque page possède sa propre URL et son contenu est parfaitement référencable (comme une page HTML en fait !).
Cerise sur le gâteau, il existe même un mode de lecture à fort contraste pour lire au lit :
Au niveau du code source, vous pouvez aller vérifier vous même, mais c’est bien une page web traditionnelle :
Vous pourriez me dire que cette première expérimentation signe l’arrêt de mort du format propriétaire iBooks d’Apple, mais les choses ne sont pas si simples, car ce livre électronique est illisible sur un iPad (malgré le fait que Safari utilise le même moteur de rendu que Chrome) :
Au-delà de cette (surprenante) incompatibilité, d’autres raisons font que cette expérimentation n’est pas réellement viable :
Les nombreux autres formats proposés par les constructeurs de e-readers (Comparison of e-book formats) ne vont certainement pas disparaitre, car il existe un important fonds documentaire à rentabiliser ;
Les e-readers ne sont pas assez puissants pour faire tourner un navigateur moderne comme Chrome.
Bref, cette expérimentation ressemble plus à une opération d’intimidation (voir de propagande) qu’à une réelle volonté de bouleverser le secteur des livres électroniques. Elle s’inscrit donc dans la stratégie à long terme de Google (cf. Google à l’assaut d’iTunes et d’iOS avec Chrome et HTML5 ?).
We use cookies to optimize our website and our service.
Functional
Toujours activé
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
