Architecture assembleur, lecteur et autres réflections
Je vous livre (avec un certain retard) le fruit d’une discussion avec Patrice autour de l’architecture des différentes interfaces que nous mettons en place.
Tout d’abord l’assembleur.
Dans cette interface il y a à priori 4 espaces, que l’on peut vouloir fractionner très clairement ou au contraire fondre et intégrer au maximum.
la table de travail, sur laquelle sont disposées le perles, qui forme le fond
la zone des outils, aujourd’hui la poubelle, bouton share… qui sont pour le moment intégrés dans l’espace de travail. D’autres outils pourrait trouver leur place dans une barre ou dans une palette flottante (logique Adobe par exemple)
une zone « identité » de l’éditeur (à minima un avatar et un nom)
une zone « sociale » qui comprend les commentaires (communication publique) mais aussi les fonctions de communications privées: fonction PM (personal message, à mi-chemin entre le mail et le commentaire)
En discutant nous avons identifié un 5ème élément qui permettrait de mesurer ou de signifier le degré d’interaction de l’éditeur dans le monde Broceliand. Les règles restent bien sûr à établir, mais une première piste serait le nombre de pas communs avec les autres éditeurs ou bien encore le nombre de broceliands repris pas d’autres éditeurs…
Ce 5ème élément peut n’être qu’une diode changeant de couleur en fonction du « statut » de l’éditeur ou un compteur Geiger…
La piste formelle que je me propose d’explorer est la suivante:
sur la base du joujou 2.2 une table de travail blanche sans texture, pure, simple. Pour les zones identité et sociale des palettes flottantes que l’utilisateur peut positionner où bon lui semble et dimensionner selon ses besoins du moment. On peut imaginer donner à ces palettes une matérialité assez forte, un métal laqué dans un blanc légèrement cassé, chaud et très brillant par exple. Cette liberté permet à notre utilisateur de faire sien notre outil sans que nous ayons à nous casser la tête inutilement sur des options de customisation gadget. Fermez les yeux et imaginez…
Le point suivant est un début de réflexion autour d’un moment assez particulier: la transition de assembleur vers le lecteur. Rien de décisif à ce stade, sinon qu’on est là à un noeud important que je ne vois pas comment gérer pour l’instant. Patrice suggère que c’est le moment d’être didactique. Je suis sur ce point en désaccord, préférant aux explications imposées et systématiques un mode « aide » activé par l’utilisateur, qui doit de fait être facilement accessible. De plus je considère l’utilisateur n’est novice qu’une fois. Cela dit, il serait dommage de se contenter d’un simple compteur de chargement à la mode flash. Vos réactions sur ce point seront donc précieuses.
Vient donc ensuite le lecteur. L’option retenue à ce jour pour le lecteur standard est la barre en haut de l’écran, reprenant les codes couleur et fonctionnel de l’intégrateur. Barre aussi discrète que possible qui ne doit pas venir en choc avec la diversité des contenus à afficher. Quantité de fonctions restent à définir.
Il ne faut pas oublier que l’on arrive pas toujours au lecteur de la même façon. En effet l’utilisateur peut passer de l’intégrateur au lecteur (sur son propre compte mais aussi en explorant le compte d’un autre éditeur). Il a alors déjà vu la forme (et l’étendue, la complexité…) de l’arborescence qu’il s’apprête à parcourir. En revanche l’utilisateur qui « ouvre » un broceliand trouvé sur un site ou joint à un mail n’a pas cette vision. Il y a donc des étapes transitoires à penser en fonction des différentes hypothèses. Gros travail d’architecture en perspective. Qui s’y colle?
En passant un point soulevé durant notre discussion: il serait intéressant de faire figurer l’avant et l’après (page précédente/page suivante). Pas de solution miracle à ce stade. A propos de miracle, je vous remets sous le nez ce petit lecteur que je vous avais déjà proposé il y a quelque temps: http://www.whitevoid.com/application.html
Un autre point en suspend: comment pousse-t-on notre utilisateur à éditer?
Je m’explique: naturellement notre utilisateur va accumuler des parcours, des bookmarks qui temps qu’ils ne sont pas édités ne peuvent pas être rendu publics (une attitude « autoritaire » de notre part n’est pas envisageable pour des raisons de confidentialité). Donc, de la même façon qu’un enfant ne range pas naturellement sa chambre, ce que nous avons nommé la friche de chaque utilisateur va enfler jusqu’à devenir inexploitable. Simultanément nous passons alors à côté de notre objectif: le web n’est ni organisé, ni personnalisé. Il faut donc imaginer un système qui fasse qu’il n’est pas possible de stocker indéfiniment des surfs non édités dans la friche. Plusieurs hypothèses à ce stade: la friche à une taille finie (maximum 50-100 pas en stock?) ou encore elle a une date de péremption (pas moyen de garder plus de quelques jours un surf non édité?). On peut encore imaginer être plus contraignant: la friche se vide dès que l’utilisateur se déconnecte. Ou juste incitatif: un indicateur de santé de la friche?
Comme vous le voyez ce post est plein de questions. Vos commentaires, idées, suggestions sont donc attendues.
Sam
Filed under: Platform, User Interface by Sam on April 29th, 2008
Sur le “comment pousser l’éditeur à éditer”, je crois qu’une piste naturelle (en v1) est de mettre systématiquement à la poubelle les parcours qu’un utilisateur a déjà vu dans l’assembleur et n’a pas publié. En fait, de considérer simplement que la friche est la poubelle. Bien sur, on peut toujours récupérer une perle dans la poubelle.
Cela peut sembler radical aux amateurs d’espace privé, mais cela pousse la plateforme dans une logique communautaire d’emblée – ce qui est probablement un objectif clé de la v1
Effectivement, ça fait du bien de se poser toutes ces questions d’ailleurs. Je n’ai pas d’avis très tranché à ce stade mais je pense que pour l’exercice il faut se lancer, les choses préciseront petit à petit (très broceliand comme idée)
1) Pour l’assembleur : J’aurais tendance à intégrer au maximum les parties la zone “identité” et “PM” et peut-être a zone “sociale” mais il faut savoir notamment ce que l’on commente une édition? une perle? les deux?un éditeur?
By the way j’adore l’idée de l’indicateur du niveau d’intégration dans Broceliand (reste à effectivement à définir les critères du niveau d’intégration : rythme d’édition, commentaire/parcours lus, nombre d’amis, nombre d’éditeurs favoris mais ça pousse un peu à sélectionner tout le monde au détriment de la qualité)
2) Pour la piste que tut t’apprêtes à explorer je ferme les yeux et je rêve… Quel beau métier tu fais.
3) Pour le passage de l’intégrateur au lecteur, j’ai plutôt tendance à être d’accord avec toi, sauf si on ne comprend rien à la transition (ce qui va plutôt dans le sens de Patrice). Cette position faux-cul pour dire qu’à mon sens c’est un point difficile sur lequel on doit pouvoir innover. Pour canaliser l’imagination nécessaire je pense que ça vaudrait le coup qu’on se voit pur bien définir l’expérience que l’on veut proposer à l’utilisateur (cf brainstorming pour le player pour le joujou 2.2)
4) Le lecteur est effctivement un “gros morceau” plus ça va plus je me dis qu’une miniaturisation du parcours faciliterait considérablement la navigation du lecteur. Je suis aussi assez pour la pré-post-visualisation avec cette difficulté des points carrefour. Peut-être que l’affichage permanent du titre de l’édition que l’on parcours et éventuellement de ses sous-titer serait intéressante. Ce ne sont pas des mots que l’on impose mais un espace d’écriture réservé à l’éditeur pour organisé son édition.
5) Et un autre “gros morceau” avec le comment on pousse les éditeurs à éditer? Voilà mes propositions (faut bien se lancer) :
a/ quand quelqu’un se met à collecter un onglet s’ouvre automatiquement permettant de passer par son compte au cours de sa navigation
b/ l’espace de travail doit vraiment avoir une gueule d’espace de travail, pour le coup je soutien assez l’analogie avec photoshop (sauf que photoshop il y en a vraiment partout et qu’on comprend rien, la preuve il y a des formations photoshop, pardon je m’emporte)
c/ une notification peut-être envoyer à chaque collecte : vous avez 1 parcours non partagé, vous avez 2 parcours non partagés, etc.
d/ des gages. Par exemple au delà de 5 chemins non édités la photo de l’éditeur se voit affublé d’un bonnet d’âne. hihhihihi (han)
Bon A+
François
Quelques commentaires:
* Je suis d’accord avec toi sur le mode de l’aide.
Une fois que l’on sait faire quelque chose, l’aide est assimilable a` du bruit.
Lors de la premiere visite sur Broceliand, cette aide doit etre visible, et pourra etre ferme a` tout moment.
On retiendra ensuite que l’aide est ferme’e, et on la montrera alors a` la demande.
* Je ne suis pas sur de l’interet de voir son avatar en permanance. Ca prends de l’espace sans creer de l’information utile.
* Pour ce qui est d’inciter les gens a` organiser les parcours, on pourrait proposer un meilleur service de navigation pour un parcours publie’: Par exemple la navigation entre carte pourrait se faire facilement que dans un sens (d’une carte privee vers une carte publique), mais le retour vers sa carte serait plus difficile.
Je pense par contre que conserver les historiques est une feature clef de Broceliand, et indispensable pour demarrer la courbe en S. C’est son interet qui justifiera l’installation d’un collecteur.
my 2 cts,
Alain