mercredi 3 novembre 2010

Google va offrir dans les semaines qui viennent 10 000 appareils équipés de son système «Google TV» à des développeurs qui créeront des applications optimisées pour cette nouvelle plateforme. Google, non content d'offrir la gratuité de ses API, va promouvoir ses nouveaux services par le don massif de matériel.

Et pourtant le plus intéressant dans l'histoire n'est pas la générosité du mammouth de l'internet, mais bien l'importance du potentiel que représente ce futur service. Tous les grands groupes de télévision l'ont d'ailleurs bien compris en réagissant très très négativement à l'écoute de ce projet. Youtube a tenté (plusieurs fois) de se lancer dans ce secteur, mais chaque fois sans succès réel. Le marché de la télévision représente 260 milliards d'€ en 2009 (estimation Idate), cela montre l'énormité de l'enjeu et l'énervement des acteurs en présence, et le fait que Goolgle ne s'arrête pas à quelques échecs.

Google doit surmonter au moins 3 obstacles (chacun très dur à escalader):
-les pays qui tous exigent de contrôler ce secteur. La France en particulier refuse qu'un nouveau opérateur de TV diffuse des programme sans contrôle, autant pour des raisons fiscales que des règles à respecter.
-les groupes de télévision actuellement en place, qui sont parfois internationaux mais surtout surpuissants; un TF1, un HBO, ou autre NBC possède un pouvoir difficile à contourner.
-les ayant droits de contenus vidéo qui préfèrent négocier avec des interlocuteurs habituels, plutôt que de laisser entrer le loup Google (ou autre Apple) dans la bergerie. Leur marge et leur tranquillité d'esprit est en jeu, et Internet leur fait peur.

De toute manière, Google aurait tort de ne pas tenter le coup, même si la ficelle est grosse. Google tente de faire croire qu'il s'agit de réaliser de petites applications pour la télévision, alors que la véritable finalité est de devenir un jour un groupe majeur de télévision. Steve Jobs tente le même coup actuellement en essayant de pirater la carte SIM du téléphone mobile pour s'affranchir des opérateurs mobiles locaux de la planète. Plus on est riche et puissant, plus grand est le culot. Il n'est pas certain que ces batailles finissent positivement pour Google et Apple, car les forces en présence (opérateurs mobiles & groupes de télévision) sont solidement ancrés dans des marchés difficiles à concurrencer. Le résultat de ces combats permettront peut-être de déterminer certaines limites du pseudo web 3.0.

mardi 2 novembre 2010

Le nouveau défi de Steve Jobs

Steve Jobs semble être sur le point d'équiper ses prochains iPhone d’une carte SIM scellée. Ce défi technologique (car il oblige de créer de toute pièce un nouveau type de carte SIM) est comme à chaque fois avec Apple et Steve une remise en question des us et coutumes.

L'idée serait sympathique, sauf que cette fois Apple veut devenir par ce stratagème le premier opérateur de téléphone mobile dont on ne pourra jamais rompre le contrat, en créant le premier téléphone impossible à déverrouiller. Et avec le talent qu'il possède, il finira par nous faire croire que c'est pour notre bien à tous.

Le diable possède le copyright de ce genre de contrat à vie. Steve va devoir négocier ces droits, avec une personne pour une fois plus fort que lui en terme de marketing.

mardi 8 juin 2010

facebook, un futur altavista?

Qui se souvient d' Altavista, moteur de recherche précurseur de google? Et pourtant Alatavista était considéré comme l'une des entreprises les plus prometteuses de la planète internet à ses débuts. Le cimetière des sociétés n'ayant pas tenu leur rang de leader au delà de quelques années est fort bien rempli. Internet plus qu'ailleurs peut faire et défaire une réputation ou un leadership en seulement quelques mois. Ce constat permet de relativiser les n°1 d'aujourd'hui, dont un en particulier selon moi: Facebook (FB pour faire court et jeune).

Pour résumer ma pensée, je considère facebook comme une perte de temps. FB de plus n'apporte rien qui n'existe par ailleurs depuis des lustres: blog, mail, forum, message instantané, etc... Et pourtant innombrables sont ceux qui peuvent y passer des heures quotidiennement. Ce phénomène d'addiction peut se comparer à certains mécanismes de mouvements sectaires (je plaisante qu'à moitié). C'est son caractère de communauté fermée (cloisonnée en quelque sorte) qui pousse ses utilisateurs dans l'addiction. Ce type d'addiction est déjà patent avec internet, mais lui au moins ne vous oblige pas d'utiliser un outil unique pour faire son blog, un seul forum pour échanger ou une seule adresse de mail pour dialoguer. Pourquoi tant de critique envers un simple outil de sociabilisation qui parait être semblable à la plupart des autres? A cause de deux caractéristiques graves de conséquence: son caractère exhibitionniste et son environnement cloisonné.

L'exhibitionnisme est une source de problèmes potentiels au sein de l'internet. L'internet à été créée à l'origine pour permettre un minimum de confidentialité, pour des raisons de simplification et d'efficacité. Cette relative confidentialité d'internet se traduit dans les usages par une certaine pudeur ou par un anonymat certain selon les cas. Ce principe a permis le développement de très nombreux services et outils permettant de lire, de dire, ou de discuter de nombreux sujets sans le soucis du regard de l'autre. A l'instar de la VPC (vente par correspondance) qui a permis à de nombreux clients de se décomplexer pour acheter certains produits trop difficiles à trouver ou délicats à choisir. Cet anonymat est un formidable moteur de stimulation du commerce, d'échange et de partage d'information. FB inverse totalement ce principe, en mettant au centre du service offert, son identité ouvertement partagée, avec des barrières plus ou moins efficaces pour protéger sa sphère privée. Cet aspect de FB que j'appelle grossièrement exhibitionnisme, recèle des effets pervers, dont des risques personnels et professionnels décriés régulièrement dans des articles de presse savoureux: licenciement, réputation détruite, etc..., . Petit exemple personnel à propos de mon profil FB: Même en faisant attention de n'y mettre aucune information (en dehors de ma photo) et de ne rien y faire, mon profil est déjà cité plusieurs fois (et sans compter les photos). Cela démontre le caractère potentiellement intrusif et délateur de FB.

Le deuxième élément de FB que je déplore, c'est son caractère cloisonné. C'est là encore une négation de la philosophie originelle de l'internet des débuts, à savoir offrir un support de base (DNS, HTTP, HTML, etc...) pour donner libre court à une multitude de services concurrents, sans autres limitations que celles de l'imagination des créateurs. Et là encore FB détruit cela en réinventant la plupart des fonctions fondatrices et primordiales de l'internet (mail, blog, forum, etc..) en les incluant dans le service lui-même. Par cela FB ôte le libre choix des outils à ses utilisateurs. Les inconvénients sont évidents: Par exemple ne pas avoir de mail FB peut vous empêcher dans le futur d'avoir des contacts réguliers avec vos amis utilisateurs forcenés de FB. Ne plaisantez pas, cela arrive déjà et plusieurs connaissances m'ont déjà fait la réflexion: tu ne réponds pas sur FB donc je ne t'envoie pas d'email. Beaucoup délaissent ainsi leur outils de mail traditionnel pour ne plus utiliser que FB. Idem pour d'autre moyen de communication ou de sociabilisation. Même les sites de rencontres ou de recrutement sont en dangers. Cette menace n'est pas pris à la légère par certains poids lourd pourtant florissant de l'internet. Les sites de rencontre et de recrutement par exemple réfléchissent sérieusement à des mesures pour contrer ces nouveaux usages progressant rapidement au sein de FB.

Pour conclure sur ce sujet qui mériterait un long article, j'ai la certitude que le bon sens des utilisateurs finira par triompher. Ce bon sens finira par l'emporter, et les utilisateurs de FB finiront par revenir vers des outils offrant autant de services mais sans les défauts tels exhibitionnisme et le cloisonnement. Je prend le pari: facebook aura perdu de sa superbe dans 3 ans ou 4 ans maximum. C'est le temps qu'il faudra pour que ces inconvénients deviennent évidents au plus grand nombre. On reviendra alors vers des outils moins intrusifs et plus traditionnel. L'élément chronophage de FB sera certainement le catalyseur de cette futur prise de conscience.

RDV en 2014 pour en rediscuter. Espérons que d'ici là, il ne soit pas devenu obligatoire de créer un profil FB pour exister sur la toile.

jeudi 22 avril 2010

Red button sur freesat

Je dois l'avouer tout de go, je suis un fan de snooker. Je suis capable de rester une journée entière à regarder ce sport exigeant des qualités de stratégie et d'adresse hors du commun. Et comme pour tous les fans de snooker, le grand rendez vous de l'année à ne pas manquer est le championnat du monde.

Lors de ces deux semaines réunissant les matchs à ne pas manquer, la BBC offre le tapis rouge à cette compétition reine grâce à la magie du "red button" qui permet de sélectionner le match que l'on veut voir en dehors des chaines BBC1, BBC2 ou BBC3 qui elles ne peuvent retransmettre toute la compétition.

Étant en France, j'utilise Freesat avec une parabole et un tuner sat basique (un OPTEX pour ne pas le citer). Et là point de "red button", pas plus que de beurre en broche. Heureusement la solution est à la porté de tous. Il suffit pour regarder les flux vidéos servis par le "red button" de sélectionner les chaines libélles "STREAM0, STREAM1, ....STREAM10. Chacun de ces flux retransmet les différentes émissions spécifiques à l'interactivité du "red button". Il suffit ainsi de zapper entre ces STREAM pour trouver son bonheur. Pour les trouver, il suffit de faire une recherche alphabétique des chaines avec sa télécommande sat.

J'ai donc pu regarder Steve DAVIS gagner contre un gamin ayant largement l'age d'être son fils. Pour ceux qui ne le connaisse pas, il s'agit du commentateur vedette de la BBC pour le snooker, ancien champion du monde, jouant depuis plus de 30 ans professionnellement. Incroyable.


Liens:
A propos du "red button"
A propos de freesat
A propos du snooker

vendredi 26 mars 2010

Silverlight et France3

Les VOD de France télévision ont évolué. Cela rend les anciennes méthodes pour sauvegarder une émission VOD obsolètes. C'est l'utilisation de silverlight à la place de windows media player qui rend obligatoire d'utiliser de nouveaux outils.

Pour faire court, il m'a fallu deux outils: orbit pour pouvoir télécharger la vidéo, et windows media coder 9 pour découper la vidéo.
Le premier s'utilise en deux temps: Après l'avoir fait démarrer, il faut lancer "grab++" (bouton droit sur l'icone d'orbit), puis seulement lancer son navigateur. Normalement au moment de regarder la vidéo qui nous intéresse, la fenêtre grab++ devrait lister la vidéo correspondante, parmis une liste parfois importante. Pour déterminer laquelle, procédez par élimination et par bon sens. La taille et le nom associé sont des bons éléments.
Une fois téléchargée, il faut utiliser l'utilitaire Windows Media Coder 9 pour filtrer le canal vidéo que l'on veut conserver. Normalement il y en a deux, un pour petite bande passante et l'autre pour l'ADSL. Ensuite, l'utilitaire d'édition permettra la découpe plutôt facilement.

Je ne rentre pas dans les détails car il existe plein de tutoriaux fort bien fait, et les utilitaires cités sont assez simple.

Pour finir, je signale que france 3 continue à utiliser à certain endroit de son site Windows Media player, qui est plus permissif pour cela (bouton droit-propriétés-copier le MMS-downloader), pour cela voir un ancien article. Pour les JT régionaux, une même émission peut être ainsi vu par les deux players. Amusant.

vendredi 19 mars 2010

Une tour de Babel moderne: les "charsets" en PHP

Vaste sujet, qui mérite les nombreuses pages qui lui sont consacré: la gestion des caractères étendues en PHP. Le texte ci-dessous est une rapide explication d'une méthode permettant d'éviter les problèmes d'affichage liés à ces caractères.

De quel problème s'agit-il?
Quand je parle d'un caractère étendue, je parle naturellement des caractères spéciaux, ceux traditionnellement codés avec une code ASCII supérieur à 127. Ces caractères étendues sont normalisés à travers des centaines de "charset" différents et spécifiques à chaque pays. Je désigne par "Charset", une table de correspondance de 256 caractères, sachant que les 127 premiers sont normalisés.
Voici pour l'exemple une série de caractères posant problème:
é É è È ê Ê ë î ï ç Ç ç Ç æ œ ä Ä ö €
Cette liste est un florilège des caractères pouvant s'afficher bizarrement. Si vous pouvez lire ces caractères spéciaux sans signe cabalistique, cela signifie que blogger.com gère très bien cette douloureuse problématique (ce dont je ne doutais pas). Premier soucis, les "charsets" les plus populaires ne possède pas en même temps tous ces caractères. Il manque souvent le signe monétaire €, ou le œ("e dans l'o"). Ces spécificités françaises rend donc délicat l'usage de ces "charsets".

Si vous sauvegardez cette liste de caractères sous "Notepad" (de Windows), vous avez plusieurs solutions de format de caractère à votre disposition: ANSI, unicode, UTF-8. Le premier est un charset propriétaire, popularisé par Windows, dérivant de l'ISO-8859-1 par quelques caractères. C'est un standard de fait comme on voit si souvent. Problème, il n'est pas apprécié par PHP. En revanche l'ISO-8859-1 (appelé aussi par son surnom "Latin 1"), est adoré par PHP, mais certains caractères manquent à l'appel. Il faut souvent utiliser les petits frères "Latin 2" (apprécié par certain éditeur tel mon PSPad) ou encore "Latin 9".

Pourquoi se soucier de tout cela? Pour au moins deux raisons: les fichiers php de votre site, et les fichiers textes coté serveur, chacun contenant potentiellement des chaines de caractères à afficher. Le problème est le même avec mysSQL par exemple. Si ces textes contiennent des caractères étendus, il faut pouvoir les afficher correctement coté navigateur internet. C'est pour cela que l'on a besoin de connaitre un minimum de chose sur les "charsets", sinon il y a un risque de voir des caractères sibyllins sur son navigateur à la place des caractères étendus attendus ;).

Un peu de pratique
Pour illustrer le problème, voici un exemple d'une ligne PHP, présente dans un fichier texte sauvegardé au format UTF-8:
echo ('é É è È ê Ê ë î ï ç Ç ç Ç æ œ ä Ä ö €');
Pour que cette ligne s'affiche correctement, il faut prévenir le navigateur du "charset" employé. Il existe pour cela deux moyens (là où un aurait suffit):
une directive HTML de type META:
<meta equiv="content-type" content="text/html; charset=utf-8">
Ou alors une ligne dans le header HTTP que l'on spécifie en PHP par une ligne:
header('Content-Type: text/html; charset=utf-8');

La deuxième méthode prédomine sur la première, ce qui oblige le développeur PHP de faire les deux pour être certain d'être bien compris.
Voici quelques exemples d'affichage exotique pouvant s'afficher:
é É è È ê Ê ë î ï ç Ç ç Ç æ œ ä Ä ö €
ou bien:
é � è � ê � ë î ï ç � ç � æ � ä � ö �

La problématique est la même pour un fichier dont on doit afficher une partie de son contenu. Il faut d'une part lire correctement le fichier en PHP et ensuite l'afficher correctement (toujours en PHP). Pour cela il faut prévenir PHP de la nature du fichier, et ensuite prévenir le navigateur.

Pour finir, il ne faut pas oublier la problématique des formulaires HTML et de leurs champs de saisie. Là encore, il faudra prendre en considération le format qui sera utilisé pour récupérer et traiter correctement les informations correspondantes à travers les variables $_POST. Il faut également afficher correctement les caractères étendues dans le formulaire, mais dans ce cas il n'y a pas de choix, car seul les entités HTML le permettent. Je ne rentre pas dans les détails car seul le principe général est intéressant pour l'instant.

Dernier point critique à signaler: la plupart des fonctions de gestion de caractères en PHP sont incompatible avec les "unicode" ou autre "UTF8", car PHP nativement manipule uniquement les caractères codé sur un octet, et gère donc très mal les caractères multi-octets. L'UTF-8, l'unicode sont donc à déconseiller dès lors que l'on a besoin d'utiliser les nombreuses fonctions PHP de gestion de caractères.

Une solution théorique serait d'utiliser à la place de tous ces formats dignes de la tour de Babel, un langage universel qui existe dans le monde HTML: les entités HTML. Cet ensemble de méta-caractères HTML permet d'afficher par exemple l'accent "é" en utilisant une série de caractère commençant par & et finissant par un point virgule: "&eacute;". Ces méta-caractères parfaitement compatibles avec la table ASCII originelle, sont un moyen élégant de contourner les problèmes de format de caractères. Malheureusement cette solution est incompatible avec la plupart des éditeurs de texte, même les plus performant comme PSPad. Il est donc déconseillé d'écrire soi-même les entités HTML, surtout si l'on veut par la suite éditer facilement ces caractères étendus. En revanche, ces entités sont excellentes en tant que format d'affichage, puisque tous les navigateurs sont compatibles avec ces entités et ne poseront jamais de problème. Les entités HTML sont également indispensables comme format d'affichage dans un formulaire. Elles sont une solution pratique dans de nombreux cas, surtout que PHP gère nativement le codage et le décodage des ces entités HTML.

Quand faut-il s'en préoccuper
:
En résumé, ce problème de caractères étendues doit vous préoccuper dans au moins 3 cas:
  1. dans un fichier php, quand vous devez afficher des chaines de caractères
  2. dans un fichier (ou une base), quand vous y stocker des chaines de caractères à afficher
  3. dans un formulaire, au moment de récupérer les champs de saisie.
Personnellement, après avoir commencé à utiliser le format de fichier UTF8 pour son universalité et sa compatibilité avec l'ASCII, j'ai commencé à faire marche arrière pour plusieurs raison: les navigateurs pouvait parfois être pris de cours, en voulant tout le temps afficher de l'UTF8. De plus certains fichiers étant destinés à être modifiés directement par notepad ou par un autre éditeur, je voulais un format universel pour Windows. Le format "ANSI" (autrement dit "Windows-1252") m'a semblé plus pratique. Je n'ai pas choisi l'ISO-8859-1 (autrement dit "Latin-1") malgré sa popularité, car certains caractères peuvent poser problème, un peu plus que le "windows-1252". De plus le "latin-1" n'est pas toujours pris en compte dans les éditeurs. PSPad en particulier, ne gère que le "latin-2" dans cette famille, alors que tout logiciel sous Windows n'a aucun problème pour gérer l'"ANSI". Voici donc trois exemples, en sachant que tous mes fichiers coté serveur son sauvegardé en ANSI.

1- Pour afficher des caractères dans PHP
, il suffit normalement de faire:
echo ('é É è È ê Ê ë î ï ç Ç ç Ç æ œ ä Ä ö €');
Pour afficher correctement, je modifie légèrement le source:
echo (htmlentities('é É è È ê Ê ë î ï ç Ç ç Ç æ œ ä Ä ö €')ENT_NOQUOTES,'cp1252');

2- Pour afficher des caractères d'un fichier ANSI, il suffit normalement de faire:
$f=fopen(,"r");
$ligne= fgets($f, 4096);
echo ($ligne);
Pour afficher correctement, je modifie légèrement le source de la même manière:
$f=fopen($txt,"r");
$ligne= fgets($f, 4096);
echo (htmlentities($ligne,ENT_NOQUOTES,'cp1252'));

3- Pour récupérer correctement le champ de saisies:
Rien de plus simple, car il suffit seulement de dire au navigateur quel est le "charset" que l'on veut utiliser dans la page. C'est le navigateur qui s'occupe ainsi d'envoyer le texte avec le format spécifié dans page hébergeant le formulaire. Donc si le même "charset" est utilisé dans le formulaire, et dans la page qui affiche le résultat, il n'y aura pas de problème.
Ne pas oublier de traduire en entité HTML le texte par défaut d'un champ de saisie. Ces entités seront traduites automatiquement en caractères UTF-8 si par exemple c'est l'UTF-8 qui est spécifié dans la page du formulaire. C'est assez déroutant, mais finalement fort pratique.
En résumé il suffit pour être tranquille de mettre dans toutes vos pages une ligne de ce type, en y spécifiant votre "charset" préféré:
<meta equiv="content-type" content="text/html; charset=utf-8">

Et que fait donc blogger.com?
Le gestionnaire de blog de google a choisie la facilité en utilisant dans ses pages le charset UTF-8, et en laissant le navigateur coté client gérer toutes les problématiques de caractères exotiques. C'est évidement la solution la plus sage, car blogger a besoin d'être véritablement universel. Devoir gérer un transcodeur UTF-8=> meta-caractères HTML aurait alourdi le gestionnaire lui-même, ainsi que les pages HTML de ses blogs. En revanche, pour un site purement personnel et pour un usage limité à une seule langue, on peut très bien choisir un charset "ANSI". Le transcodage en entités HTML est ensuite un choix plus philosophique que technique, que j'adopte plus pour me faire plaisir que pour l'efficacité. Toutes les méthodes sont bonnes, à la condition de bien en maitriser les tenants et les aboutissants. C'est d'ailleurs le but de ce documents: expliquer le principe et les limites d'une méthode parmi d'autres.

Conclusion:
L'UTF-8 est un bon compromis, mais relativement dangereux en PHP de par sa mauvaise gestion des chaines de caractères multi-octets. En final, comme PHP ne gère pas beaucoup de charset, le choix est fort limité (voir la liste complète ci-dessous). Pour ma part, j'utilise l'ANSI de Windows (alias "cp1252" qui est en fait son nom officiel) car mes éditeurs de texte sont sous Windows. Ce "charset" n'est pas le meilleur, mais très pratique sous Windows. L'unicode de notepad est une catastrophe à cause de sa non-compatibilité avec les autres formats (il ajoute un zéro binaire à la fin de chaque caractère). En final, un des meilleurs moyens de ne pas se tromper est d'utiliser dès que cela est possible les entités HTML qui possède le double avantage d'être véritablement universelles, et compatibles avec tous les "charsets" et les navigateurs. Pour cela, il faut connaitre les deux fonctions PHP prévues à cet usage. Évitez d'écrire vous-même les entités HTML, car les sources d'erreur sont alors nombreuses et le modifications peu pratiques:
htmlentities() => traduit tout caractère étendue d'une chaine à partir d'un "charset". Il ne faut pas oublier de spécifier l'argument "charset", sinon le résultat peut-être aléatoire.
htmlspecialchars() => permet principalement d'afficher un code HTML, en traduisant en entités HTML les caractères <>' et ". Les caractères étendues ne sont pas traduits avec cette fonction. Attention donc à ne pas la confondre avec la précédente. Utile également dans le cadre d'un formulaire au moment de spécifier le texte par défaut d'un champ de saisie, qui lui doit s'inscrire à l'intérieur de tags HTML.
Je résume ma méthode en une phrase:
Format "ANSI" pour tous les fichiers coté serveur (php ou autre), et substitution de tous les caractères étendues par des entités HML pour toutes les pages HTML coté client.
Ce principe n'est pas le plus efficace, mais c'est celui que je maitrise le mieux et qui me permet d'éviter tous ces caractères bizarres en lieu et place de nos chers caractères nationaux.

Bon courage à vous et pour vos caractères étendues, en espérant qu'ils ne vous trahiront plus à travers un navigateur internet.



Liens:
A l'origine de ce joyeux bordel: la table ASCII
Le charset "Windows-1252", abusivement appelé "ANSI" (utilisé par défaut dans mon Notepad)
Excellente synthèse des formats les plus important
La liste complète des charsets et de leur alias (pour les plus courageux)
Liste des entités HTML (pour l'oublier au plus vite mis à part deux ou trois).


Liste des charsets gérés sous PHP:
  • ISO-8859-1(Latin-1)
  • ISO-8859-15(Latin-9, signe Euro, et quelques caractères français manquant au Latin-1)
  • UTF-8 (Unicode 8 bits multioctets, compatible avec l'ASCII)
  • cp866 (ibm866 Jeu de caractères Cyrillic spécifique à DOS, depuis PHP 4.3.2)
  • cp1251 (Windows-1251 depuis PHP 4.3.2)
  • cp1252 (Windows-1252,spécifique Windows pour l'Europe occidentale=> ANSI)
  • KOI8-R (Russe depuis PHP 4.3.2)
  • BIG5 (Chinois traditionnel, utilisé à Taïwan)
  • GB2312 (936 Chinois simplifié, officiel)
  • BIG5-HKSCS (extensions de Hong Kong, chinois traditionnel)
  • Shift_JIS ( 932 Japonais)
  • EUC-JP (Japonais)

PS:
Pour écrire ce document il m'a valu par deux fois utiliser des entités HTML sans quoi blogger m'interdisait la sauvegarde ou bien un affichage correcte:
1-au moment de citer le tag META, il a valu remplacer les signes "<" et ">" (plus petit et plus grand que) par leur équivalent sous forme d'entité HTML.
2- au moment d'afficher un exemple d'entité, utilisation de l'entité HTML "et commercial".
Comme quoi, il est toujours utile de connaitre par cœur quelques entités HTML.

mardi 2 février 2010

iPad, du talent mais si peu d'innovation

Est-ce un produit à acheter?
Le compte rendu le plus intéressant sur iPad est certainement celui de blogeee.net.
Il met en évidence la part d'ombre du produit, sans jamais oublier de souligner sa part de lumière. Sa conclusion semble dire tout de même que les qualités de cette machine ne parviennent pas à éclipser les manques ou les incohérences de cette superbe machine.

Je résume cela en une phrase: Beaucoup de talent dans cet iPad, mais très peu d'innovation. C'est peut-être une conséquence de la longue maladie ou plutôt de la longue guérison de Jobs, et qui n'a pas pu par son absence, insuffler les éléments nécessaires pour que cette machine soit objectivement intéressante. Une machine bonne à tout, mais excellente pour aucun usage. A trop vouloir viser des usages différents, on finit souvent par y perdre son âme.

Pourquoi autant de limite?
Une question personnelle dont je n'ai pas encore la réponse: Existe-t-il un micro? Si c'est non, encore un trou dans la raquette de cet iPad. C'est une des limites des stratégies marketing, qui n'ont parfois pas d'autre but que de segmenter les acheteurs en petites catégories, oubliant souvent l'évidence. C'est par exemple le cas de l'iPod touch, le clone mp3 de l'iPhone. Le micro est absent, chose idiote, purement marketing, mais qui a interdit un nombre incroyable d'usages pour le client, dont le plus évident pour l'iPod: shazam (l'application permettant de reconnaitre automatiquement le titre d'une musique à travers le micro de l'iPhone). Priver l'iPod de Shazam est une incroyable gaffe, purement marketing, purement idiote. La source probable de cette erreur: avoir voulu différencier les deux produits en établissant des formules de ce type:
iPhone = iPod + Photo + GPS + GSM + micro
Plus la formule est compliquée plus la société est contente, dans l'espoir secret de vendre deux fois la même machine sous différentes formes. La Webcam manquante de l'iPad est un exemple d'aveuglement marketing dont nous gratifient Apple et les autres.

Le tiercé d'un semi-echec?
Il est toujours facile de donner des conseils sans avoir les responsabilités correspondantes. Mais pourquoi se priver de ce petit plaisir sans conséquence, surtout avec Apple qui a fait de l'arrogance un fond de commerce et un art de la communication. Voici dans l'ordre décroissant d'importance ma petite liste des oublis malencontreux:
  1. Un écran innovant à base d'encre électronique
  2. Une autonomie réellement importante pour se différencier d'un PC nomade
  3. Une ergonomie et une tenue en main agréable dans la durée
Je n'ai pas les réponses à ces trois points, mais je suis certain que des possibilités innovantes étaient possibles. Au lieu de cela, Apple s'est contenté d'un gros iPod touch sans originalité. Le point trois est plus important que l'on ne le pense de prime abord, car on l'oublie souvent l'une des raisons du succès de l'iPod, sa capacité à être piloté d'un doigt et d'une main, facilement et sans effort. Sa taille et son écran le rendait agréable à utiliser, contrairement à tous ces téléphones modernes nécessitant trop souvent deux mains et plusieurs doigts. A l'inverse, l'iPad semble lourdaud dans sa prise en main, dumoins sur le papier (voir le pdf que proposer en lien par Pierre de Blogeee) et selon les premiers retour d'usage.

Pour finir, je reste pantois sur le choix des applications mis en avant pour vendre ce nouvel objet. Le plus incongru selon moi est le jeu en général, et celui en particulier vanté dans les publicités en ligne, un jeu de conduite de voiture dont le volant est tout simplement l'iPad lui-même, offrant une vision de la route en caméra suggestive. Le problème, au delà du ridicule de la situation et des problèmes d'ergonomie évidents, c'est le problème du joueur de devoir regarder en permence un écran et des images mouvantes, avec un écran lui-même en mouvement permanent. Mal de crâne en perspective.

Tous les moyens sont bons pour Apple pour justifier un objet qui aura grand mal à trouver un usage intéressant pour ces futurs clients et usagers. Si les futures acheteurs n'en trouvent, ils risquent de trouver la facture un peu élevée pour un simple cadre photo.