Chéri(e) !! on mange quoi ce soir ?

Idée : Qui ne s’est jamais demandé quoi faire à manger le soir même. Comment préparer un repas bon, original, plus ou moins rapide …. L’idée serait donc de proposer un site web qui prendrait en charge de vous donner des recettes en fonction d’un certains nombres d’informations

Phases : 1) Vous accédez au site et répondez aux questions posées :

– combien de personnes seront à table ce soir ?

– Quels sont les aliments que l’une des personne à table n’aime pas ?

– Qu’avez vous dans votre frigidaire ? (aliment + quantité)

– Combien disposez vous de temps pour préparer votre repas ?

– Disposez vous d’un four, micro-ondes … ?

…..

On peut un peu tout imaginer qui va venir compléter la recherche

2) une fois toutes ces questions renseignées, le site vous propose alors 3-4 recettes ( ou aucune si votre demande est impossible ;-)) en fonction  de vos besoins et attentes

3) Vous pouvez obtenir une version imprimable de la recette

Modèle éco : Je sais pas trop dans quelle mesure ce service peut être payant – j’attends vos avis sur ce point

Qu’en pensez vous ?

Cette idée vous intéresse ? N’hésitez pas à intervenir dans les commentaires pour l’enrichir, apporter des suggestions, remarques… Cette page est vivante et va évoluer au fur et à mesure de vos cogitations.

Vous êtes développeur ? Créatif ? Spécialiste du domaine abordé ? Nous recherchons en permanence à monter et animer des équipes autour de ces projets, afin que ces idées deviennent autre chose que de simples articles dans un blog… Contactez nous !

Appli FaceBook – “t’habites ou ?”

Projet : Comme le titre de l’article le montre, l’idée est la réalisation d’une appli Facebook basée sur la notion d’habitation et du voisinage.

Je m’explique – Pour le moment nous pouvons grâce à l’admin de facebook créer des listes personnalisées de nos ami(e)s. Ces listes sont bien sur à usage privé. Et si on les rendait “plus ou moins publiques” en passant par la notion de voisinage, rue que nous avons dans la vie réelle.

Pas évident finalement à expliquer, autant passer à l’étape “phases” 😉

Phases : J’ouvre l’appli “t’habites ou ?” (pas top comme nom d’ailleurs !), je crée ma rue en la nommant (ex : rue des fêtards) et je glisse mes amis que je veux avoir dans cette rue ; ils deviennent alors mes voisins.

Sur mon mur figure : “antho a crée la rue des fêtards” avec en dessous l’avatar des habitants de la rue

et mes amis reçoivent , tu habites rue des fêtards , antho, JD, …. sont tes voisins

Pour tout ceux qui connaissent et utilisent facebook, je pense que vous voyez à peu près le “délire”

Par la suite , pourquoi ne pas avoir des “actions” uniquement possible avec ses voisins et pas ses ami(e)s.(ex : aujourd’hui antho passe la tondeuse dans ton jardin,  voisin )

Cette idée vous intéresse ? N’hésitez pas à intervenir dans les commentaires pour l’enrichir, apporter des suggestions, remarques… Cette page est vivante et va évoluer au fur et à mesure de vos cogitations.

Vous êtes développeur ? Créatif ? Spécialiste du domaine abordé ? Nous recherchons en permanence à monter et animer des équipes autour de ces projets, afin que ces idées deviennent autre chose que de simples articles dans un blog… Contactez nous !

Home tickets !

Projet : Idée rapportée par Monsieur CHM alias CriCri (pour ceux qui se souviennent des sitcoms AB des années 90 ;-))

Postula : Qui ne rale pas après les tickets de caisse toujours plus nombreux, toujours plus grands trainant dans nos poches et qui une fois sur deux passent à la machine à laver ?

La réflexion est assez simple : Pourquoi ? pourquoi l’existence de ces tickets ? Pour qui ?

Le système d’information des supermarchés est aujourd’hui assez développé pour gérer des bases de données en temps réel et ainsi sauvegarder l’ensemble de ventes réalisées dans le magasin. De ce fait, les tickets ne les intéressent plus vraiment !

Pour le client alors ? Sincèrement, combien d’entre nous aujourd’hui gardons les tickets proprement pour faire nos comptes fin de semaine ou fin de mois ?? je l’espère de moins en moins. L’accès à nos comptes bancaires persos directement via le web permet un suivi quotidien, un export en format excel….. L’utilité de stocker les tickets est donc aujourd’hui “nulle”.

Les moyens : d’un point de vue technique, rien ne nous empêche finalement de “tuer” le ticket aujourd’hui. Nous avons des ordinateurs ultra-performants, un réseau mondial (le web), des accès sans fil pour y accéder (wifi), nous sommes tous connectés les uns aux autres (communauté), les individus avec les individus, les entreprises avec les individus, les entreprises avec les entreprises.

De nouveau, comme nous l’exprimons souvent sur ce blog, si nous prenons un peu de recul, nous avons les moyens, nous avons l’intérêt à le faire … et pourtant rien ne bouge . J’ai souvent voulu mettre ça sur le manque d’idée ou d’initiative de l’humain en général mais finalement je crois tout simplement que c’est une histoire de “coutume” (au sens juridique du terme) . C’est cette fameuse phrase que tout le monde à déjà entendu “pourquoi je ferais autrement puisque j’ai toujours fais comme ca” !!!

Le respect : Un seul mot :” l’environnement” ; combien de tickets imprimés par seconde dans le monde ? combien tirent-on de tickets d’un arbre ? ….. la solution : stopper la production de  tickets !!

Le gain de temps et la zen attitude : combien de temps perd-on à chaque fois qu’une caissière change le rouleau ? combien de fois nous énervons nous auprès de la pompe à essence qui bien sur n’a plus de papier à tickets ?

Phases :  Je passe à la caisse, plutôt qu’un ticket de 30cm la liste des articles est envoyée, classée et triée dans une appli de mon téléphone, idem avec les facturettes. Evidemment cette appli pourquoi pas mi-smartphone / mi-soft en ligne m’aiderait à gérer mon budget selon les catégories de produits que j’utilise couramment (“Dis-donc tu y vas fort sur le rouge ce mois-ci…”). Plus pratique au final que le coché de relevé que pratiquait nos parents il y a peu en déballant les facturettes non ?

Pour aller plus loin : Idéalement, le supermarché me fournirait également les infos détaillées du produit que je viens d’acheter, notamment la date de péremption histoire que je l’oublie pas au fond du frigo, comme ça arrive des fois malheureusement…Toujours plus utile que de savoir qu’on vient de passer à la caisse de “la Monique”. Là on peut partir également en délire sur les liaisons numériques entre ma caissière préférée et mon frigo intelligent qui me fait mes menus 🙂

Un prix erronné sur le “ticket” de caisse ? pas de pb, y’a des ID de références pour mettre tout le monde d’accord.
Besoin d’un justificatif ? Vu que l’adminstration sera encore à la traine, la possibilité d’imprimer le justificatif devrait être possible.

Les limites : je vois deux limites à ce projet :

premièrement, le problème comptable et juridique pour les entreprises ; il leur faut justifier par tickets de leurs dépenses (ou factures) ; cependant rien d’insurmontable, il suffirait que la loi comptable accepte les factures envoyées par les supermarchés ou l’impression d’une facture de ses achats via une appli iphone par ex (ou pourrait même imaginer que le journal d’achat et de banque de la compta de l’entreprise se fasse automatiquement à partir de ces données)

deuxièmement : le rôle à jouer des supermarchés ; en effet , sans leur contribution à ce projet, pas grand chose ne se passera . il faut échanger de l’informations ; informations qu’il possède dans leur base de données ; rien de bien insurmontable de nouveau si ce n’est la volonté de ces “hypers” à participer au projet et à investir un peu de leur temps

Cette idée vous intéresse ? N’hésitez pas à intervenir dans les commentaires pour l’enrichir, apporter des suggestions, remarques… Cette page est vivante et va évoluer au fur et à mesure de vos cogitations.

Vous êtes développeur ? Créatif ? Spécialiste du domaine abordé ? Nous recherchons en permanence à monter et animer des équipes autour de ces projets, afin que ces idées deviennent autre chose que de simples articles dans un blog… Contactez nous !

Keep it simple stupid

Je me suis souvent posé tout un tas de question sur l’éloge -souvent justifiée- de la simplicité, en particulier dans le domaine des nouvelles technologies. Petite compilation des notes que j’ai pu prendre sur ce sujet….

L’épure dans l’interface utilisateur

Google et Apple, chacun à leur manière, représentent les écoles les plus connues de l’épure d’IHM. La page d’accueil de Google est le parfait exemple de l’épure ultime, même s’il s’agit un peu de l’arbre qui cache la forêt : dans les faits, on sait que peu de gens passent aujourd’hui par la page d’accueil de Google, préférant les barres d’outils, ou les champs de recherche intégrés dans divers sites.

Toujours est il que le succès initial de Google est en partie dû à sa page d’accueil légendairement simple, et qui est le meilleur acte de foi de la société : “notre métier, c’est la recherche”. Vu la forme tentaculaire que prend Google ces derniers temps, ce postulat peut prêter à sourire, mais l’idée est restée gravée : Google, c’est simple.

Les sites étiquettés “Web 2.0” sont restés le plus souvent dans cette même lignée. Fini les looks surchargés de la fin des années 90, un site Web doit être, au moins en apparence, d’une simplicité extrême.

Un exemple parmi plein d’autres : le site de l’éditeur du logiciel Coda. Le produit n’est pourtant pas d’une simplicité extrême (il est destiné à des développeurs), mais sa présentation est très épurée.

L’épure dans l’analyse fonctionnelle

L’exemple le plus flagrant d’épure fonctionnelle est sans doute le site Twitter. Non seulement il s’agit d’un des sites les plus simples en termes de fonctionnalités (je fais régulièrement “refaire” le site par des étudiants débutants en développement Web), mais, au delà de ça, toute sa puissance vient de cette simplicité qui est devenu un vrai moyen pour ses utilisateurs de “s’approprier” le site, en détournant certains fonctionnements ou en inventant d’autres (la notion de “ReTweet”, par exemple, consistant simplement à mentionner “RT” devant un message pour montrer qu’on retransmet le message de quelqu’un d’autre).

Curieux paradigme : plus un site est simple, mais ouvert (Twitter est réputé pour son API permettant à de nombreux sites et applications de graviter autour de son écosystème), plus l’appropriation, et la richesse, qu’en font ses utilisateurs au final est importante ?

L’épure dans le discours marketing

Je vais encore une fois revenir sur l’exemple Apple, cette fois-ci avec les gammes d’iPod.

Avant les iPod, et longtemps après également, la plupart des baladeurs nécessitaient d’acquérir un minimum de compétences techniques :

  • il fallait connaître la notion de taille, en Mo, Go….
  • il fallait connaître la différence entre ce qu’était un baladeur à disque dur, d’un baladeur à mémoire Flash, etc…

Les iPod, comme tous les autres baladeurs, sont dépendants des progrès des constructeurs d’électronique. En 2004, par exemple, l’iPod mini utilisait un tout petit disque dur d’1,8 pouce. Lorsque les capacités et les coûts d’une mémoire Flash ont atteint des seuils suffisants, Apple a pu lancer le projet d’iPod nano, qui n’était rien d’autre qu’un iPod mini avec de la mémoire Flash, et donc forcément bien plus petit.

Ca, c’est la technique. Mais pour le discours commercial, rien de tout cela. A part les technophiles, personne ne sait ce qu’il y a à l’intérieur d’un iPod. Ils ont à leur disposition des gammes de prix, et des noms commerciaux facilement mémorisables (Shuffle, nano, Classic, Touch).

Cette pratique, basée sur le fait que l’utilisateur n’a pas à connaitre les éléments techniques favorisant leur choix, détonait énormément par rapport aux concurrents, qui utilisaient tous des sigles un peu obscurs, style MF-128Mo+.

Inutile de dire que cette façon de procéder a contribué de manière non négligeable au succès des iPod. Elle a toutefois ses limites : Jobs a également tenté de supprimer toute notion ou presque de capacité mémoire, en quantifiant un baladeur MP3 à partir du nombre de chansons qu’il peut stocker. Le premier iPod permettait de stocker 1500 chansons, les plus récents 30 000 ou 60 000. Une chanson était arbitrairement considérée comme représentant 3 à 4 mégaoctets.

Cette “simplification” n’a jamais réellement fonctionné, tout d’abord parce que le grand public s’est familiarisé, même sans forcément vraiment le comprendre, les notion de méga-octet, giga-octet… L’autre raison était d’ordre pratique : petit à petit, les baladeurs embarquèrent autre chose que de la musique : des photos, de la vidéo, des jeux… La “mesure-étalon” chanson n’avait donc plus court.

L’épure dans la conception technique

Je me souviens, en tant que développeur Java, de l’époque où Sun lançait son offre “J2EE”, basée en bonne partie sur la notion d’Enterprise Java Beans. Une vraie révolution dans la façon de voir la gestion des données. Mais aussi une usine à gaz inaccessible pour 99% des développeurs de l’époque : un investissement en temps beaucoup trop important était nécessaire pour arriver à une maitrise fragile du concept. Et surtout, des applications très difficilement maintenable, puisque liée à une technologie complexe et peu répandue.

Ces EJB ont été une aubaine. Pas pour eux même, puisqu’ils sont restés confidentiels. Mais dans le contre pouvoir qu’ils ont amené. Quelques développeurs ont été excités par l’idée d’exploiter d’une manière différente les données au sein d’une application. Et, en même temps, ont été très décontenancés la façon de concevoir un objet. C’est l’époque des objets “KISS” (Keep it Simple Stupid) : des classes simples, faciles à comprendre, faciles à manipuler, faciles à modifier. Une base simplissime, mais qui permet au développeur d’effectuer des choses complexes. Parce qu’il y a un “point d’entrée” accessible pour ceux qui découvrent l’architecture. Parce que les bases sont simples et donc maitrisables.

Ironiquement, la philosophie “KISS” a été la base de bibliothèques sans cesse plus évoluées, et qui ont petit à petit ramené énormément de complexité… D’où l’autre principe que j’essaie de ne jamais oublier, avec celui de la simplicité : Back to basics ! 🙂

Cotation “graphiste” web

cote
cote

Projet : éditer un livre (ou un site web) recensant la côte des artistes web français (mondial par la suite)

Explications : L’idée est en fait de rejoindre ce qui se fait déjà pour les artistes peintres professionnels.

En effet, il existe divers ouvrages dont un bouquin appelé l’AKOUN qui recence toutes les ventes aux enchères au monde et établie à partir de celles ci une cotation d’un artiste en suivant une formule mathématique définie.

Le problème avec les artistes web, c’est que pour le moment nous n’avons pas de support (comme les ventes aux enchères) afin de lisser le talent et travail des uns par rapport aux autres

Cependant, pourquoi ces artistes la, n’auraient-ils pas eux aussi un droit à la cotation et à la reconnaissance de leur talent et travail par les connaisseurs mais également le grand public ??

Je pense que bientôt les galeries d’art vont changer un peu de forme pour se diriger de plus en plus vers de nouvelles techniques qui à un moment donné convergerons avec les évolutions multimédia et autres.

Qu’en pensez vous ? et surtout voyez vous sur quel socle pourrait s’appuyer le calcul de cotation ?

Cette idée vous intéresse ? N’hésitez pas à intervenir dans les commentaires pour l’enrichir, apporter des suggestions, remarques… Cette page est vivante et va évoluer au fur et à mesure de vos cogitations.

Vous êtes développeur ? Créatif ? Spécialiste du domaine abordé ? Nous recherchons en permanence à monter et animer des équipes autour de ces projets, afin que ces idées deviennent autre chose que de simples articles dans un blog… Contactez nous !

Appli IPhone : Help Me !!!

trousse de secours

Précision : Comme vous l’avez compris et par transparence, l’idée vient de Frédéric Melon dit Fredodo, voici son blog : http://www.fredodo.com/

Projet : L’idée est ici de réaliser une appli Iphone gratuite qui serait un guide de premiers secours

Phases : Vous êtes témoin d’un accident, la victime est allongé devant vous mais vous n’avez aucune connaissance des premiers secours à apporter

– Vous sortez alors votre Iphone et lancer l’appli “Help Me !!”

– vous repondez alors aux questions qui vont sont posées L’appli vous guide alors dans les soins à apporter à l’aide de schémas, dessins, vidéos, conseils audios …

Bien sûr, on aucun cas, on ne peut s’improviser Pompier professionnel, Médécin, sauveteur .. cela n’est pas le but de cette application ; l’idée est de préparer au mieux l’arrivée des secours professionnels.

Qu’en pensez vous ????

Cette idée vous intéresse ? N’hésitez pas à intervenir dans les commentaires pour l’enrichir, apporter des suggestions, remarques… Cette page est vivante et va évoluer au fur et à mesure de vos cogitations.

Vous êtes développeur ? Créatif ? Spécialiste du domaine abordé ? Nous recherchons en permanence à monter et animer des équipes autour de ces projets, afin que ces idées deviennent autre chose que de simples articles dans un blog… Contactez nous !

Briser l’atom

Le format RSS, ou plutôt la façon d’utiliser le RSS, a bien du mal à s’imposer. Pour beaucoup, c’est même le parfait exemple d’une technologie géniale, aux possibilités impressionnantes, mais qui n’a jamais réussi à joindre le fameux camp du “mainstream”, celui qui ouvre les portes de la reconnaissance auprès du grand public.

Autant le RSS fait partie de ma vie “online” au quotidien, autant une large proportion d’internautes n’en utilise jamais, et se portent plutôt bien…

Les raisons compliquant “l’évangélisation” du RSS sont nombreuses, mais, dans les multiples petites complications à l’utilisation de ce standard, je me suis posé la question l’autre jour des flux “Atom”. Atom, c’est un format concurrent de RSS, apportant quelques petites améliorations intéressantes mais pas franchement transcendantes, de mon point de vue.

Or, lorsque je clique sur l’icône “RSS” à côté de l’URL, pour m’abonner à un flux, j’obtiens à chaque fois ou presque un petit menu m’imposant de choisir entre Atom et RSS. Quel intérêt pour l’utilisateur ? D’autant plus que la plupart des “RSS-readers” lisent les deux formats ? N’est ce pas amener une complication inutile pour pas grand chose ? Quel est l’intérêt aujourd’hui de continuer à “porter” les deux standards, alors qu’aucun n’apporte d’intérêt transcendant à l’autre ?

Vous utilisez Atom, de votre côté ? Vous y voyez un avantage particulier ? Ou vous ne verriez aucun inconvénient à ce que vos blogs ne proposent plus ce format ?

Un autre angle de vision

J’ai pas mal l’occasion ces temps-ci de travailler sur des problématiques d’ergonomie. C’est complètement passionnant, et en même temps très difficile, car vous avez d’un côté une interface, une logique logicielle, et de l’autre une infinité (potentielle 😀 ) d’utilisateurs, avec chacun leur sensibilité différente, leur façon de raisonner et d’interpréter l’interface qui s’offre à eux. Cette perspective finalement très “humaine” que l’on se doit d’apporter à nos projets est vraiment intéressante, et amène parfois à bousculer de vieilles habitudes. Un exemple…

Les règles du jeu

Un exemple qui m’a frappé est celui, classique, des écrans de configuration de “règles de messages” : lorsque vous utilisez un client mail classique (Outlook, Mail, Eudora, Thunderbird….), tous fonctionnent d’une manière similaire : on peut définir des règles, des automates, qui vont permettre de classer automatiquement tel ou tel message.

Un écran de définition d’une règle ressemble toujours plus ou moins à ceci :

Ici, une copie d’écran de l’appli “Mail”, sous Mac, mais les concurrents sont très similaires.

Je ne sais pas pour vous, mais moi, en tant que développeur, je “vois”, au travers de cette interface, une traduction directe d’un code métier, manipulant des objets conçus directement à partir du cahier des charges. Un truc style :

Regle r=new Regle();

r.setName(“Regle No 1”);

r.set…..

listeregles.ajout(r);

r.appliquer();

Quoi de plus normal diriez vous (enfin si vous êtes développeurs…) : l’interface utilisateur doit permettre de manipuler les fonctionnalités métiers d’une application, et je passe mes formations a expliquer comment monter ce genre d’architecture “multi-couches”.

Mais, en prenant du recul… est ce que cette vision très “cartésienne” des choses est la bonne ?

Une histoire de Monopoly

Souvenez vous, lorsqu’on vous explique les règles d’un jeu, style monopoly ou jeu de cartes. Classiquement, votre interlocuteurs va commencer par vous reprendre les règles complètes, d’un point de vue un peu “théorique”. Au début, ça va. Puis, les détails s’accumulant, vous allez perdre petit à petit pied, jusqu’à décrocher complètement, jusqu’au moment clef où l’interlocuteur va prononcer la phrase magique : “Par exemple…”. Et là, votre esprit va s’éveiller d’un coup, et se raccrocher à cette vision hyper partielle, mais concrète et assimilable, de l’exemple qu’on va vous donner. “Là, si machin met un 8 de coeur, tu vas pouvoir mettre un 9 de trèfle”.

Ce n’est qu’une pièce du puzzle, mais cet exemple va être comme le bout de bois flottant en pleine mer auquel vous allez vous raccrocher, pour ensuite reprendre pied petit à petit et avoir une vision plus claire du jeu. Et, seulement ensuite, vous allez pouvoir relire sereinement les règles, y repérer les exemples que vous avez assimilé, et vous faire vous même votre vision du jeu.

Bien sûr, ce raisonnement n’est pas valable pour tout le monde : certains esprit préféreront ingurgiter d’un bloc les règles du jeu, et n’utiliseront les exemples qu’en fin de cycle d’apprentissage, simplement pour valider quelques zones floues ; mais la grande majorité des êtres humains fonctionnent par l’exemple.

Regarder par l’autre bout de la lorgnette

Pour définir les régles de tri de votre mail, c’est la même chose : on vous demande de définir des règles “théoriques” d’emblée de jeu. Alors que vous, humanum vulgaris, vous êtes “programmé” pour fonctionner avec des exemples !

Les concepteurs de cette interface n’ont pas voulu mal faire. Ils ont simplement cherché à faire de leur IHM un moyen de manipuler leurs objets métiers, et donc de fournir une interface au cahier des charges qu’on leur a demandé de remplir. Point. Et on peut pas en vouloir à un “barbu”, comme je les appelle (on se demande pourquoi 😉 ) de raisonner comme un barbu, avec des instances de classes et des appels polymorphes !

Simplement, dans ce cas précis, il aurait été utile de voir un peu le problème avec un autre angle de vision : celui de l’humain, de l’utilisateur, qui a son mode de raisonnement propre, et qui n’est pas toujours relié à la simple traduction IHM d’un paradigme objet !

On efface tout et on recommence

Donc, l’utilisateur aime raisonner par l’exemple : qu’on lui en donne la possibilité ! Ca donnerait à peu près ceci :

Imaginons que l’utilisateur veuille déplacer automatiquement les mails Facebook qu’il reçoit dans un dossier qu’il a créé pour l’occasion.

outlook1) Il prend un mail Facebook, et le glisse, comme il l’a déjà fait plein de fois, sur le dossier approprié

2) Une boîte de dialogue apparaît alors, lui demandant “Quelle caractéristique de ce mail vous amène à le déplacer ici ?

3) Parmi les choix proposés : “Le nom de domaine de l’expéditeur“. Il clique là dessus

Et c’est terminé ! Pas besoin de préciser “déplacer vers”, ni un nom du dossier, puisque l’exemple aura permis au programme de le deviner. Par la suite, lorsqu’il voudra affiner ses règles, il pourra ensuite accéder à des écrans similaires à celui du début de cet article. Mais seulement à ce moment là, lorsqu’il aura bien maitrisé “les règles du jeu” et qu’il voudra simplement en préciser certains comportements.

Au boulot !

Cet exemple n’est sans doute pas parfait. Et il ne parlera sans doute pas à tout le monde. Mais on touche ici à ce qui fait le fondamental de l’ergonomie : trouver un juste équilibre entre les besoins “métiers” (les fonctions), et les réflexes, les intuitions de l’utilisateur. Dur boulot !