Non, ce qui m’a vraiment frappé c’est que sur les 10 raisons évoquées, à peine 2 sortent la tête du lot :

• utilisation du push
• l’écosystème de l’App Store

Mais surtout, les véritables raisons ne sont même pas évoquées.
Rectification.

Ces 10 raisons sont du bullshit

La grosse dérive de ces articles à base de n-raisons, c’est qu’on se sent obligé d’en pondre pour arrondir le compteur. Forcément, 2 raisons ça fait pas rêver.

Je vais revenir sur chacune de ces raisons de préférer une application à une version mobile :

1. un format adapté
   Ça ne veut strictement rien dire : le site Web mobile et l’application peuvent avoir la même apparence et s’affichent dans le même espace disponible (à quelques détails près − les boutons de navigation par exemple).  L’application ne garantit par le rendu mais utilise bien souvent une charte de facto ; charte qui est rarement reprise pour les sites Web mobile et pour cause, ces derniers s’adressent à tous les mobinautes.
2. une plus grande facilité d’utilisation pour le public
   Là encore il y a grosse confusion entre fond et forme. Un site Web mobile peut avoir la même apparence et le même type de navigation qu’une application. La preuve : l’application Facebook (pour Android en tous cas) renvoie régulièrement sur la version mobile (adaptée aux écrans tactiles) pour terminer certaines actions.
   En terme d’apparence, elles sont quasiment identiques. D’ailleurs, vu qu’il est impossible de consulter ses messages privés sur l’application, le site Web mobile est plus facile à utiliser que l’application.
3. le grand public déteste les URL
   Il s’en fiche surtout, parce qu’il ne comprend pas. Donc bien souvent le nom du site est cherché dans le moteur de recherche par défaut du navigateur. Cela se termine par un ajout dans les favoris.
   Entre chercher un nom d’appli dans un store ou dans un moteur de recherche Web, il n’y a strictement aucune différence.
4. le grand public adore les icônes
   Difficile de laisser échapper un sourire en lisant cette raison Je cherche encore le rapport car des icônes, on peut en mettre à foison sur un site Web mobile.
5. le push
   C’est quelque chose qu’on ne peut effectivement pas faire depuis un site Web mobile. C’est un avantage pour l’application. Combien de sites ont besoin de fournir du push ? Je n’imagine pas avoir 26 applications de blogs m’envoyer du push à chaque publication d’article. Donc à consommer avec modération d’autant plus que l’existence du push ne rend pas son utilisation obligatoire.
6. le buzz
   Le buzz ne se fait pas par rapport à l’application mais aux fonctionnalités du service. Que je sache, je joue avec Foursquare, j’utilise Seesmic pour son widget Android et ses options poussées, pas parce que c’est une application ou un site Web. Foursquare serait pourri, l’application n’y changerait pas grand chose.
   Le buzz est possible mais ça concerne un nombre tellement faible de services (par rapport à l’ensemble des sites Web existants) qu’il ne faut pas espérer un buzz uniquement parce qu’une application existe.
7. c’est bon pour ton image, coco
   Ne pas proposer une application pour un service à usage de masse est effectivement une erreur à l’heure actuelle. En revanche, c’est une décision stratégique qui n’empêche pas pour autant de disposer d’un site Web mobile. La raison est hors-contexte : ça se décide entre l’application et l’application.
8. une application est plus facile à trouver qu’un site Web
   Cf. ce que j’ai écrit plus haut : chercher sur l’App Store ou sur Google, c’est pareil. En revanche, le réflexe de chercher dans le store sera probablement bien plus élevé. Ça n’ajoute aucune facilité. C’est juste une habitude différente − donc ce n’est clairement pas la même chose.
9. une application offre des possibilités de fonctions plus avancées qu’une version Web mobile
   Oui, et le push en fait partie. Mais là encore, l’auteur de l’article n’a pas compris qu’un site Web est universel, à la différence de l’application qui est spécifique à la plateforme en question. C’est d’ailleurs pour ça que ça porte un nom différent, site Web, application.
   Encore que, avec des technos Web on peut réaliser une application mobile grâce à des outils comme PhoneGap.
10. l’écosystème de l’App Store, iAd et la possibilité de monétiser une application
    C’est fortement lié à la 8ème raison : l’écosystème fait qu’on va chercher en premier dans le store plutôt que depuis son navigateur mobile. D’ailleurs, pour un service existant, les utilisateurs n’attendent même pas que la communication soit faite sur l’application : les possesseurs de smartphones cherchent dans le store. Point final.
    iAd n’est qu’une plateforme publicitaire parmi d’autres mais on n’a pas le choix (sur iPhone en tous cas).
    La monétisation est possible en paiement à l’acte sur un site Web mobile, mais clairement pas à l’installation. La manière de monétiser est différente. L’acte d’achat aussi : l’utilisateur sera très certainement plus propice à payer une application qu’un accès à un site Web mobile.

S’il ne fallait retenir qu’une seule raison

Quand même, je vais citer LA raison qui me fait utiliser une application plutôt qu’un site Web mobile : la vitesse. L’application ayant toute l’interface préchargée, la navigation est fatalement plus rapide.

Je pourrai quand même citer un excellent contre-exemple : le site Web mobile de Flickr. Sa navigation entièrement en Ajax (pour les mobiles supportant cela) la rend véloce et très agréable à utiliser. Elle est aussi rapide à consulter que l’application Facebook. Elle est même plus rapide en ce qui concerne le chargement d’images.

Application ou site mobile ? Les deux mon capitaine !

Il faut quand même comprendre une chose : le choix ne se fait pas entre une application ou un site Web mobile.

Comme je l’expliquais avant, la cible est différente.
Quand je publie une application iPhone, le public est mécaniquement la population possédant un iPhone.
Quand je publie un site Web mobile, le public est mécaniquement la population connectée à l’Internet mobile, y compris les utilisateurs d’iPhone naviguant avec Opera Mini.

Le Web a une notion d’universalité que n’ont pas les stores. Un store, c’est un service Minitel 2.0. On se connecte au service et on n’en sort pas.
Ne pas proposer de site Web mobile, c’est nier une frange des internautes. Et ce n’est pas ce que j’appelle un progrès, l’exclusion.

Ah et dernier point : il n’y a pas que l’iPhone dans la vie. Il y a aussi Android, webOs et Windows Phone. Certes en Europe l’iPhone domine l’Internet mobile et le marché des smartphones mais ce n’est pas une généralité mondiale.

Conclusion

La mobilité et le Web mobile sont des sujets très chauds et en pleine croissance. Ça serait bien d’arrêter de se secouer la nouille pour le bon plaisir des statistiques.

Vous pouvez proposer un site Web mobile.
Vous pouvez proposer une application mobile.

Vous n’avez par contre pas vocation ni obligation de sortir une application mobile pour y caser tous les buzzwords ou être hype. Un exemple ? L’application Agenda de la ville de Bordeaux. C’est une appli mais un chargement systématique de 10 minutes au lancement, c’est un non-sens complet.

Comme quoi, application ou site Web mobile, encore une fois, la clé du succès c’est une bonne conception et surtout une réflexion sur les apports à l’usager en situation de mobilité.

J’ai publié il y a quelques semaines un widget Jaiku dans l’écosystème Netvibes. Autrement dit, on peut désormais interagir avec le sous-employé Jaiku depuis son compte Netvibes en levant à peine le petit doigt.

La réalisation de ce widget était pour moi l’occasion de réaliser mon premier widget utilisant la plateforme UWA : un développement rendu compatible pour plusieurs plateformes dont iGoogle, MacOS X Dashboard, Windows Live etc.

Présentation du widget Jaiku pour Netvibes

Avant de rentrer dans les détails techniques, faisons ensemble un petit tour de ce qu’est capable de faire le widget Jaiku. Rien de bien méchant puisqu’il fait ce qu’on veut : lire et envoyer les messages. Faut savoir rester simple

Widget Jaiku pour Netvibes

Je ne me cacherai pas que je me suis largement inspiré du widget Twitter pour Netvibes au niveau de la présentation tout en ajoutant ma touche personnelle.

L’écran de connexion accueille directement avec des champs identifiant et mot de passe pour faciliter son utilisation. Pas besoin d’aller fouiller dans les options. Un petit confort on dira.

L’entête contient ce qu’il faut pour envoyer des messages : votre lieu de présence et le champ de saisie. Le compteur de texte se met à jour à chaque caractère saisi et surtout, votre saisie n’est pas bloquée une fois que vous atteignez la limite. Il n’y a rien de plus pénible que ça.

Le gros du morceau réside dans les onglets : pour une fois vous pouvez facilement naviguer d’une ligne de temps à une autre. Choisissez les messages de vos contacts, les vôtres (un peu narcissique non ?) ou encore les messages publics.
Les 3 onglets sont paginés à la convenance de l’utilisateur, de 1 à 20 messages par page.

J’ai ensuite agrémenté de plusieurs fonctionnalités que j’apprécie à l’usage (à vous de me dire si c’est aussi le cas) :

• possibilité de répondre à un message en pré-remplissant le champ de saisie avec ce qu’il faut (et ce que l’API Jaiku permet de faire …)
• icône signalant l’origine des messages affichés (flux RSS, Twitter, Last.fm etc.)
• filtrage de ses propres messages : vos messages n’apparaîtront pas dans la ligne de temps des contacts (ce qui en soit n’est pas plus mal)
• formattage des messages avec une meilleure reconnaissance de URL que le widget Twitter et surtout, une reconnaissance des noms d’utilisateurs (@utilisateur) et des noms de canaux (#canal) … vous permettant de leur répondre en cliquant sur leur nom

Il resterait encore pas mal de choses à faire mais on arrive malheureusement assez rapidement aux limites des 2 services.

L’API Jaiku

L’API Jaiku est très bien mais un peu chiche en services.

Le nombre de flux en récupération est suffisant : contacts, messages, informations personnelles.
En revanche les méthodes d’envoi sont limitées et pour cause, il n’y en a qu’une : envoyer un message.

Il ne manque pas grand chose pour qu’on puisse tout faire :

• obtention de la liste des icônes personnalisées
• préciser à quel message on adresse une réponse (pour éviter de casser les discussions)
• une gestion de messages privés (et les flux qui vont bien)
• une API qui ne souffre pas d’autant de délai … parfois il faut attendre 3 heures avant d’avoir un flux actualisé. Pas pratique pour de la messagerie en temps quasi-réel

Ces demandes ont été faites mais bon, il faudra attendre la relance de Jaiku avec Google App Engine … très bientôt visiblement.

Et du côté de Netvibes ?

Le développement du widget repose sur l’API UWA de Netvibes et donc par conséquent, c’est du développement 99% JavaScript.

Heureusement tout n’est pas à faire puisqu’UWA fournit une base d’outils et quelques fonctionnalités natives comme la pagination ou les onglets.

Quels avantages à utiliser Netvibes UWA ?

La spécification UWA permet donc à partir d’un développement unique de le porter sur d’autres plateformes de blogs en un minimum d’efforts (très souvent aucun). Il faut savoir qu’à chaque plateforme de widget il y a une manière de développer différente.

Alors plutôt que de parier sur un cheval, avec UWA, on peut parier sur tous. Et ne faire qu’un seul développement.

Le développement d’un widget aboutit très généralement à l’ajout dans l’écosystème Netvibes. Le widget se retrouve ainsi à la portée de toutes les pages de démarrage par le biais de son moteur de recherche intégré.

Côté développement, tout reste globalement simple quand on veut faire du simple.

Mais quelle galère à développer avec Netvibes UWA …

En revanche ça devient beaucoup moins drôle quand on tombe sur des besoins mal couverts par la documentation.
Et quand je dis mal couvert, ça inclut :

• pas de documentation du tout
• une documentation partielle et pas suffisamment verbeuse (genre pour les onglets et la pagination)
• une documentation obsolète et pas recommandée de leur propre aveu (le stockage des mots de passe)

L’adoption d’un service et sa qualité se jugent à mon avis par sa documentation. Certes des efforts sont faits mais leur API deviendra crédible et fiable le jour où elle sera à jour et complète.

En plus de ça, certaines fonctionnalités sont elles aussi incomplètes.

Au hasard, le processus de l10n : à implémenter soi-même et encore, il ne pourra pas couvrir tous les besoins comme les préférences. C’est d’autant plus dommage que leur système est particulièrement au point pour l’interface traduite en une dizaine de langues.
Mais pas les widgets …

Toute à l’heure j’évoquais les mots de passe. Il y a bien un mécanisme qui permet de les stocker mais il agit comme il veut : on ne peut stocker qu’un mot de passe par widget et surtout, on ne peut pas l’utiliser autrement que dans le cas d’une identification HTTP.
Autrement dit, le stockage d’un clé d’API se fera dans un champ texte standard.

Ça ne serait pas gênant si la plupart des widgets étaient exécutés dans une iframe et que cette dite iframe embarquait dans l’URL toutes les préférences enregistrées. Donc votre clé d’API.
Pourquoi c’est gênant ? Car il y a un mécanisme inhérent à tout navigateur Web qui s’appelle le Referrer. En clair, quand vous affichez une page, votre navigateur envoie l’adresse de la page appelante.
Je me passerai du dessin …

Enfin, et pour terminer sur une note un peu moins noire, l’environnement de développement est un superbe outil pour tester son widget de manière indépendante. C’est à dire sans se connecter sur netvibes.com.
Enfin là où le bas blesse c’est que les comportements et la présentation sont différents entre l’environnement de développement et Netvibes.

Ce qui sous-entend des bugs présents en développement et pas en production, la gestion des mots de passe qui diffère en développement de la production et du paramétrage spécifique pas documenté.

Proxy local pour widget Netvibes

Le proxy de développement Netvibes indiqué dans la FAQ est fonctionnel mais trop minimaliste. On peut en effet récupérer les données mais dès qu’il s’agit d’en envoyer, c’est cuit.

J’ai donc adapté le proxy du Yahoo! Developer Network à mes besoins en ajoutant plusieurs fonctionnalités :

• mise en cache des requêtes GET pour accélérer les chargements de page et éviter de cramer trop de requête auprès de fournisseurs les limitant (qui a dit Twitter ?)
• transmission des données POST ; c’est ce qu’il manquait le plus à la version fournie par Netvibes
• compatible texte/JSON/XML ; le proxy renvoie les bonnes entêtes en fonction de la demande

<?php
define('CACHE_TTL', is_int($_GET['cache']) ? $_GET['cache'] : 3600);
define('CACHE_FOLDER', dirname(__FILE__).'/cache');
//
$session = curl_init($_GET['url']);
// If it's a POST, put the POST data in the body
if (isset($_POST) && !empty($_POST))
{
  $postvars = '';
  while ($element = current($_POST))
  {
    $postvars .= key($_POST).'='.$element.'&';
    next($_POST);
  }
  curl_setopt ($session, CURLOPT_POST, true);
  curl_setopt ($session, CURLOPT_POSTFIELDS, $postvars);
}
// Play with some cache
$md5sign = md5($_GET['url'].$postvars);
$md5file = CACHE_FOLDER.'/'.$md5sign;
/*
 * Read cache
 */
if (file_exists($md5file) && filemtime($md5file)+CACHE_TTL > time())
{
  curl_close($session);
  send_headers_content_type($_GET['type']);
  readfile($md5file);
  exit();
}
// Don't return HTTP headers. Do return the contents of the call
curl_setopt($session, CURLOPT_HEADER, false);
curl_setopt($session, CURLOPT_RETURNTRANSFER, true);
// Make the call
$output = curl_exec($session);
$fp = fopen($md5file, "wb+");
fwrite($fp, $output);
fclose($fp);
send_headers_content_type($_GET['type']);
echo $output;
curl_close($session);
/*
 * Functions
 */
function send_headers_content_type($type)
{
  // Set the Content-Type appropriately
  switch ($type)
  {
    case 'text':
    default:
      header("Content-Type: text/plain");
    break;
    case 'xml':
      header("Content-Type: text/xml");
    break;
    case 'json':
      header('Content-Type: text/x-json');
    break;
  }
}
?>

En revanche, je serais vous, j’éviterais de m’en servir publiquement car il n’y a aucune vérification de sécurité donc à moins que vous ayiez envie de servir de relais à spam, le mieux est de n’utiliser ce proxy que sur une instance locale ou bien de davantage le blinder.

Conclusion

On arrive désormais au terme de ce billet fleuve

Quoique je puisse en dire, Netvibes UWA est quand même fort sympathique et permet d’aboutir à des temps de développement assez courts une fois la majorité des problèmés rencontrés. Nul doute que votre premier développement sera le plus compliqué. Surtout si comme moi vous avez envie de tout utiliser : pagination, onglets et AJAX à droite à gauche.

Dans tous les cas, une bonne conception de l’application vous sauvera la mise et évitera trop de réécriture de code.
L’implémentation de la pagination et des onglets est particulièrement douloureuse si vous n’utilisez pas de programmation objet. Soyez-en avertis.

Je me suis personnellement bien amusé à développer en utilisant UWA et en jouant avec l’API Jaiku. Cette dernière met vraiment l’accent sur le JSON ce qui est très pratique pour manipuler des données distantes de manière minimaliste.

Une fois que ces 2 plateformes arriveront à maturité, il y aura de quoi faire d’encore plus belles applications.

N’hésitez pas à utiliser Jaiku sur Netvibes, à me laisser vos remarques et à partager votre expérience de développement de widgets si le cœur vous en dit

La nouvelle génération d’iPhone, iPhone 3G, sort dans la majorité des pays du monde dans 2 jours. On devra attendre le 17 juillet 2008 pour en bénéficier en Europe.

iPhone a amorcé une transformation des interfaces utilisateurs dans le monde des téléphones mobiles et c’est une bonne chose. Tellement bonne que je m’imaginais déjà synchroniser mes contacts avec mes calendriers en ligne, accéder à mes comptes mails, surfer facilement sur le Web et téléphoner via mon compte SIP Free.

J’étais prêt à suivre l’enthousiasme fébrile des adorateurs de Mac jusqu’à ce que j’essaie un iPod Touch … à savoir un iPhone sans micro ni écouteur.

J’ai donc utilisé un iPod Touch pendant 2 semaines pour tester ses capacités, comme si c’était le mien. Il était bien évidemment jailbreaké car pourquoi utiliser un produit bridé alors qu’il peut faire beaucoup plus ?

J’ai au début été séduit … puis déçu dès qu’il s’agissait de pousser les choses un peu plus en profondeur (pas d’arrières-pensées merci ).

Les raisons d’acheter un iPhone

1. un bel objet il faut bien le reconnaître ;
2. une interface utilisateur globalement simple et intuitive (quoique, sur du tactile on ne pense pas nécessairement au double-tap) ;
3. une connectivité maximale avec un Mac (courrier, contacts & cie) ;
4. ENFIN un clavier déconnecté du matériel : les claviers s’adaptent aux contextes (langues, saisies d’URL etc.) et non l’inverse ;
5. la possibilité de synchroniser ses calendriers Google Calendar avec le petit programme qui va bien (NemusSync, bientôt avec Funambol)

Au final, on peut se retrouver avec un produit totalement autonome, permettant de téléphoner sans abonnement téléphonique … mais en allant à l’encontre de la politique d’Apple.

Les raisons de ne pas acheter un iPhone

1. on est à la merci de la politique d’Apple : fermée et finalement sans respect pour l’utilisateur. Microsoft se fait jeter des cailloux pour les mêmes choses avec l’activation sous 30 jours de Windows et j’en passe et des meilleures ;
2. pas de rétention des mots de passe : vous aimez retaper sans arrêt vos identifiants et mots de passe sur les sites Web ? Moi non et pourtant c’est le lot de tout utilisateur iPhone … ;
3. l’ajout de favoris depuis Safari sur le Dashboard est chaotique : ça nous fait quitter l’application ? Et devinez quoi ? Si celle-ci nécessite une identification, on en revient au point #2 ;
4. une autonomie ridicule en veille : même en veille iPhone pompe un max (10/12 heures à vue de nez). Je n’ai pas envie de me balader en permanence avec un câble USB ou un chargeur secteur … surtout vu leur prix ;
5. politique d’économie d’énergie minimaliste : pas de possibilité de connecter/déconnecter facilement du Wifi ni d’avoir la main facilement sur tous les processus actifs, potentiellement consommateurs d’énergie ;
6. une seule boîte mail pour écrire : que paramétriez votre iPhone pour 1 ou 10 comptes mails, vous ne pourrez en envoyer que depuis votre compte par défaut. Ça incite à tout sauf à rédiger du mail en somme ;
7. cette sensation d’avoir toujours besoin d’un ordinateur/Mac : je croyais qu’on était avec des mobiles équipés de Wifi ? Pourquoi diable avoir de besoin de synchroniser avec un ordinateur nos données déjà présentes sur le Web ?
8. le verrouillage des opérateurs, de l’OS, du développement … pourquoi concevoir un produit et tenter de nous enfermer dedans d’une manière aussi peu élégante ?
9. l’obligation d’utiliser un logiciel type iTunes pour synchroniser ses musiques et compagnie : c’est la vente liée revue à la sauce Apple. Les baladeurs UMS c’est tellement plus pratique …

On pourrait également citer le copier/coller mais ces 8 points m’ont au final davantage dérangé. Loin de moi l’envie de démonter sur la place publique iPhone mais j’ai quand même du mal à croire qu’un appareil aussi sophistiqué suscite autant d’enthousiasme avec de pareilles tares.

Où est passé le sens critique ?

Mon ressenti sur iPhone

iPhone est un magnifique objet avec une interface innovante. Je le vois très bien devenir le PDA par défaut de tout commercial, la console de jeux de nos enfants mais aussi leur téléphone, carnet d’adresses … bref un appareil numérique qui rassemble notre vie tout en la rendant communiquante.

Le modèle économique reposant sur les forfaits vocaux va inévitablement se casser la figure : avec un iPhone et le protocole SIP on peut déjà appeler et recevoir les coups de fils comme si on était chez soi … à partir d’une simple connexion Wi-Fi !
J’imagine que ça viendra le cas quand les revenus générés via l’AppStore seront suffisants. Apple pourrait avec ça devenir le premier opérateur mobile. Et volontairement je ne mets pas opérateur de téléphonie car on sera bien au-délà.

En clair, c’est un produit tentant, plein de promesses mais avec des défauts trop gênant à mes yeux ; des défauts qu’on est obligé de rencontrer, comme la rétention des mots de passe. J’ai du mal à croire que des personnes trouvent cette situation accommodante.

Bref, iPhone ou pas iPhone … ou autre chose ?