logo


enatu :: fondements

[septembre 2002 à novembre 2002] Sont exposées quelques idées de la nature du projet... Ce sont les lignes directrices aussi claires et précises que possible, cependant. Vous devriez pouvoir apprécier la progression du projet réflétant la discussion engagée.
N'hésitez pas à nous contacter: Stéphane et/ou Nico.
[Il est possible que vous retrouviez certaines similitudes entre enatu et Paratchack. C'est absolument normal, enatu prend certaine de ses racines dans cet autre projet. Cependant, pas de méprise: enatu se distingue par de nouvelles idées et une réflexion plus conséquente fruit de deux pensées.]

Principes, Idées variées et autres Doléances  ~  Apparence & Comportement de l'Interface Graphique Utilisateur  ~  Explications sur les Techniques Employées et/ou Envisagées

››» Principes, Idées variées et autres Doléances

D'abord, en préalable à tout propos, je veux juste rappeler que l'interface graphique a été créée pour faciliter l'utilisation en se passant de l'interface de commande. Ce fut et cela reste un besoin réel qui ne peut être contesté sous prétexte d'une quelconque perte de performance... Ce petit rappel fait sera la clef de voute de ce qui va suivre: peut-être n'a-t-on jusqu'à présent pas poussé l'idée assez loin et doit-on encore investir dans l'interface graphique, probablement au détriment des performances brutes (disons), mais certainement pas au niveau de l'efficacité ressentie par l'utilisateur final.

  1. boite-à-idées

    • Détection Pour le Bureau, détecter les zones "unies" dans une image de manière automatique pour y placer les icônes.
    • Diffusion Pour les objets à éclosion: les phénomènes de diffusion (une goutte d'encre qui se répend par capillarité, quoi) serait un bon moyen pour figurer une progression.
    • Colorisation L'interface a une couleur dominante (comme proposé par Stuart McCoy) qui varie en fonction de l'humeur de l'utilisateur. S'il s'énerve, la dominante devient pastel/claire pour le calmer, s'il s'endort un rouge ou un jaune pourront le réveiller ;), s'il est speed le vert est une couleur apaisante etc...
      -----
      #:oD hum... c'est risqué comme idée!
      Même si c'est bien vu, il faut qu'on soit certain que ce n'est pas à cause de l'ordi justement que l'utilisateur s'énerve... et ça risque d'avoir un effet étrange quand l'utilisateur se rend compte que l'ordi *s'adoucit* alors que c'est lui qui pose problème (retour en arrière: comment connaitre l'humeur de l'utilisateur?)
    • Graduation possibilité de graduer l'intérieur du titre de la fenêtre: mettons en gras le titre principal, et le reste en normal ou alors une taille plus importante au début...]
    • Flou appliquer un effet de flou, d'adoucissement comparable aux logiciels de dessin. J'ai cette idée depuis pas mal de temps: au lieu de focaliser l'attention par un changement d'état du machin, pourquoi ne pas modifier tout le milieu extérieur: mimer les phénomènes physique d'accomodation de l'oeil en *flouant* tout sauf le machin sur qui est portée toute l'attention?
      -------
      Hmmm, je ne vois pas à quoi tu veux appliquer un flou
      • aux fenêtres : je ne sais pas si c'est très pratique quand on veut travailler avec plusieurs fenêtres qu'une d'entre elles soit floues.
      • à d'autres parties de l'interface : pourquoi pas, c'est faisable, dis moi où !
      Il y a des contraintes:
      • comment savoir quand flouer. Peut-être à rapprocher à la faculté de zoomer (toujours la notion de hiérarchie) ?? On floue les icônes pas intéressantes pour la partie de hiérarchie où on se trouve ?
      • doit-on tout flouer, et sinon, comment restituer esthétiquement les contours d'objets pendant cet effet? Tu veux dire la limite flou/non flou ? On peut faire un flou "progressif".
  2. doléances

    • Cohérence 3D Le problème avec la 3d c'est que si on veut un bureau en 3d il faut des interfaces 3d : écran 3d, gant d'acquisition 3d... La souris (qui se déplace dans un plan la pauvre) et l'écran classique ne sont (à mon avis) pas adaptés à la 3d.
    • Raffinement Le monde papier a encore une large avance sur le rafinement, sur la richesse du détail, sur les procédés de mise en valeur... Les ouvrages sont d'une incontestable qualité... bien absente en info je trouve. J'ai trop l'impression qu'une fonction/une appli dés qu'elle n'est plus buggée (et encore) et mise en pature. C'est quand même pas normal, de ne pas privilégier l'aspect d'utilisation quotidien, alors que c'est ce à quoi l'utilisateur est confronté sans cesse.

››» Apparence & Comportement de l'Interface Graphique Utilisateur

  • le Bureau ou plutôt "truc"

    1. Autre Approche [09/2002, Stéphane] A l'usage, quelque soit l'OS, et pour la majorité des utilisateurs, le concept de Bureau n'est pas pleinement exploité. Dans le pire des cas, on ne sait qu'une fenêtre peut être réduite; dans le meilleur des cas, il y en a tellement que faire apparaitre le Bureau est long et fastidieux.
      Ainsi, le Bureau tel quel perd son réel intérêt car il n'est pas vu comme une entité pratique. L'idée est donc de construire un nouveau "truc" qui aurait les qualités escomptées du Bureau et un accès nettement amélioré.
      Enoncé des caractéristiques: il doit remplacer (ou afficher) le Bureau, qu'il soit visible tout le temps et dégageant une impression de 'bouée de sauvetage informatique'. En outre, sa position serait plutôt sur un des cotés de l'écran (économie et optimisation de la surface de travail) et il serait composé de morceaux rétractables.
    2. [09/2002, Nico] Réaction sur l'accessibilité du Bureau: on peut utiliser l'espèce de raccourci imaginé dans Windows (dans la quickbar). Peur de donner au Bureau un intérêt purement esthétique en afficheur d'image ;o)
      Précisions "truc" = Panier hyperpratique. Imagination d'une sorte d'immense onglet contextuel: sur le coté on en a l'ébauche (icônes à la DockBar|morceau de rectangle dépassant), le pointeur dessus fait surgir "truc" et l'utilisateur voit se dérouler un tiroir|bandeau|fiche qui propose tout ce qui est en relation avec l'élément de référence: il a ses documents avec ses applis, avec ses ressources (liens+contacts+off line websites). Note: "truc" ne recouvrirait jamais entièrement la surface de l'écran (mettons: 85% max).
    3. [09/2002, Stéphane] En fait, il y a convergence des idées Bureau et "truc"! [en quête d'un nom pour "truc" ;o)]
      Volonté affichée de revoir l'utilité du Bureau: en changeant son concept et en le mettant comme afficheur d'image, par défaut - quitte à fusionner "truc" et le Bureau, si l'utilisateur préfère cette configuration.
      Concept Le but de ces manoeuvres est d'éviter au maximum le nombre d'interfaces proposées : si on a un bureau+une barre+des menus+des quick launch+un dock+... on s'y perd. Et comme l'utilisateur utilise rarement plus d'une seule de ces interfaces, il ne sert à rien de toutes les mettre, il serait plus intelligent de n'en avoir qu'une seule (intelligente, ça devient obligatoire) et de la faire ressembler à ce que l'utilisateur aime utiliser (pour l'instant on suppose que l'on sait ce que l'utilisateur "aime" en supposant que "ce qu'il aime = ce qu'il fait").
      L'idée des "85%" est approuvée - on visualise bien que ce n'est que quelque chose "par dessus" s'il ne recouvre pas tout l'écran. L'utilisateur voit ses fenêtres, elle ne sont pas perdues. Autre idée, celle d'intégrer certaines applications ou composant d'application (des commandes d'un Player, etc.). Mais aussi automatiser certaines actions: si après l'action X on effectue toujours l'action Y, "truc" produit tout seul l'action Y quand il voit que j'ai fait X.
    4. [09/2002, Nico] L'intégration de composants comme Workspaces, Pulse, ou des morceaux d'un Player à "truc" est bonne, déjà les certains bacs de Stuart McCoy...
    5. [09/2002, Stéphane] Pour le Bureau, détecter les zones "unies" dans une image de manière automatique pour y placer les icônes.
    6. [09/2002, Nico] Mise au point: au cas où cela ne serait pas clair, on délaisse le Bureau comme porteur d'icônes, "truc" (éventuellement fixé) s'en charge désormais! [par exemple: au démarrage, "truc" est étiré pour attirer l'oeil!]
      Attention au *systématisme*: l'algorithme de placement des icônes est plus complexe... on touche à l'esthétisme de chacun! [à creuser]
  • Window Manager

    1. [09/2002, Stéphane] Supression du window manager, "truc" "avale" les fenêtres et les présente quand il y en a besoin, les cache sinon.
    2. [09/2002, Nico] Hein? Gestion de la présence des fenêtres à l'écran? (hypothèse) ça peut être dangereux... l'utilisateur débutant pouvant être rapidement paumé...
    3. [09/2002, Stéphane] Précisions: des window manager essaient de faire ça sous linux (enfin pas exactement : en fait il n'y a plus de cadre aux fenêtres, et les fenêtres sont placées automatiquement par le window manager). Bon c'est hautement experimental et pas très abouti mais ils ont le mérite d'essayer !
      Moi je pense plutôt que "truc" se met à "englober" la fenêtre lorsqu'elle arrive.
    4. [09/2002, Nico] "truc" se dispose un peu comme une écharpe? *s'accumulant* par endroit, pour présenter certaines fonctions|autres? séduisant...
      mais reste encore le problème de l'agrandissement des fenêtres: comment concilier ces deux propositions? [Un moment, j'ai voulu m'attaquer au principe des fenêtres... mais ça n'a pas beaucoup duré: en réfléchissant, je me suis rendu compte de la puissance de l'idée]
    5. [09/2002, Stéphane] Oups! En fait je cherchais à trouver comment "truc" allait gérer les fenêtres, les cacher et les montrer sans que cela ne devienne incohérent (si la fenêtre se cache dans "truc" ça doit vouloir dire que quelque part il l'englobe ??).
    6. [09/2002, Stéphane] Nouvelles précisions: pour obtenir un effet hybride entre "truc avale toutes les fenêtres" et "truc n'avale pas les fenêtres". Quand la fenêtre est minimisée elle devient un tab dans truc (classique). Puis quand la souris passe sur un des tabs la fenêtre correspondante "glisse" pour sortir de "truc" mais sans s'en désolidariser. Et quand la souris quitte l'aire de la fenêtre incriminée, celle-ci "glisse" à nouveau pour retourner sagement dans "truc". Ca peut être utile par exemple pour:
      • changer la chanson dans le Player
      • choisir un autre outil dans The Gimp
      • regarder si il y un nouveau mail
      • regarder si la discussion icq/irc a bougé et y répondre vite fait
    7. [09/2002, Nico] J'approuve, ça semble assez interessant, mais franchement complexe à représenter de manière statique... Quoiqu'il en soit, "truc" serait une sorte de plateau qui présente à la volée les applis.
      Pour aller dans ce sens, on doit pouvoir concrétiser cette idée par des blurbs (bulles bizarroïdes) où se niche les logiciels. Mais ça implique de réécrire des pans entiers de code pour ces applis en question...
      Enfin, pour la gestion des programmes lancés, je verrais bien une sorte de Dock qui dévoilerait les fenêtres ouvertes sous forme d'éventail [mais là, je retourne un peu en arrière :-\].
    8. [09/2002, Stéphane] Problème: Comment harmoniser les formes arrondies de "truc" avec les formes tranchées et à tendance rectangulaire des fenêtres... Quelle palette adoptée?

››» Explications sur les Techniques Employées et/ou Envisagées

  • Vectoriel...

    1. [09/2002, Stéphane] Consensus sur l'utilisation de données vectorielles. Cela présente l'énorme intérêt de s'adapter aux différentes résolutions possibles, de garantir les zooms, permettre l'antialiasing, etc.
      Problème: pas encore de véritable standard dans ce domaine, technos peu développées... voir notamment, l'initiative de Guillaume Maillard de BlueEyedOS sur l'optimisation de Xfree.
      Regard du coté de SVG et d'extension... recherches en cours...
    2. [09/2002, Nico] Discussion à propos du rendu SVG: ça demande énormément de ressources...
    3. [09/2002, Stéphane] Solution: redéfinir un format vectoriel pour décrire "truc", un peu dans l'esprit de lisp par exemple (on peut automodifer le code). Les raisons:
      • svg est compliqué et il faudrait que je réécrive un moteur de rendu
      • svg est lent
      • svg ne décrit pas le comportement de l'interface, et ça je voudrais le mettre dans un fichier car ça doit être automodifiable.
      Gros problèmes pour l'implémentation...
    4. [09/2002, Stéphane] Résumé: il faut un format,
      • qui définisse une interface graphique vectorielle
      • automodifiable (donc relativement simple !)
      • qui définisse les interactions avec l'utilisateur et entre les fenêtres
      • qui définisse l'agencement des éléments les uns par rapport aux autres
      Solutions:
      • construction d'un propre format: plus long à faire, mais plus rapide à l'utilisation
      • on étend le svg: plus rapide à faire, mais peut ne pas supporter tous les types d'extensions (en particulier l'automodification). C'est peut-être plus difficile que la première option puisque je dois modifier du code que je n'ai pas écrit.
      • on utilise une approche hybride: un format qui définit le côté graphique des objets (le svg) et un format qui fait tout le reste (genre lisp): compliqué, et ça empêche d'automodifier l'apparence qui est figée dans le svg.
    5. [09/2002, Nico] Interrogations: le protocole X11 n'est donc pas adapté à la vectorialisation de l'interface...
      • on peut *patcher* Xfree pour lui faire assimiler la notion de vecteurs et ce qui s'en suit,
      • au contraire batir une sorte de X11+... qui lui aurait l'avantage d'accepter facilement le vectoriel.
      Problème: tu peux pas te permettre de réécrire X11 (perte de temps, de compatibilité, etc.). Qu'est ce qu'attend la communauté Linux pour combler ce retard? Quelle solution la team de X11 propose-t-elle?
      Réticence (dernière) sur la création d'un nouveau fichier: le SVG est porté comme un standard, et sera utilisé de plus en plus dans différents projets.
    6. [09/2002, Stéphane] Trois voies envisagées:
      • partir des restes de l'initiative de Sun, XFree 4.0 propose un équivalent (xdps). Voir quelles sont ses possibilités (par exemple, rendu limité à l'intérieur de la fenêtre ce qui n'est pas trop intéressant, ou définition de la forme de la fenêtre par des formes vectorielles, ce qui nous arrangerait bien).
      • créer un nouveau format de fichier: mais il faut
        • spécifier un format qui gère bien tout ce qu'on attend de lui
        • implanter un moteur de rendu assez rapide
      • utiliser du code déjà écrit par des projets antérieurs sur le rendu d'icônes SVG
      Pour le moment, tout ce qu'on peut faire de vectoriel (y compris avec du svg) c'est en le transformant en bitmap avant l'affichage. Au mieux, on peut utiliser un système de cache pour limiter les temps de redessin.
      [liste de programmes autour du rendu de formats vectoriels]
    7. [09/2002, Stéphane] Solution: (envisagée) créér un format de description d'interfaces et y placer des graphismes svg. Réutilisation commencée du code de l'afficheur de Gnome.
  • OpenGL

    1. [09/2002, Stéphane] Utilisation d'OpenGL pour afficher le Bureau/les icônes (quelque soit l'aspect définitif que prendra le Bureau). Ca permet de faire des effets fluides de zoom/colorisation/rotation très facilement.
      Problème: l'utilisation de l'opengl est limitée à une fenêtre rectangulaire.
    2. [09/2002, Nico] Esthétiquement parlant, OpenGL me parait une bonne idée, si le support 2D est conservé. Peut-on facilement manipuler du vectoriel?
    3. [09/2002, Stéphane] Concrètement:
      • Contrairement à une croyance largement répandue, OpenGL permet de faire aussi de la 2d.
      • On limite l'emploi d'OpenGL au Bureau [impossible d'écrire tout un window manager en OpenGL].
      • On prend du svg, on fait le rendu des icônes en bitmap, et on peut les afficher réduites/agrandies/tournées/colorisées/transparentes, OpenGL se charge de faire tout ça (pour le reste, OpenGL est limité au niveau vectoriel).
  • Intelligence Artificielle

    1. [09/2002, Stéphane] Utilisation de fonctions de projection pour la mise en forme des éléments classés: affichage en cercle ou en spirale, par exemple. Il reste à déterminer toutes les entrées à prendre en compte, comme par exemple le degré d'utilisation, le type de l'icône (document, programme, graphique, son, jeu...), taille, et d'autres...
      Création de hiérarchie, possibilité de zoomer sur une partie pour en explorer des aspects plus profonds. (représentation des liens peu utile)
      Problème: du manque d'entrée: impossibilité pour le moment de capter les mouvements occulaires de l'utilisateur. Mise en évidence de lacunes dans l'idée de modeler l'interface!
    2. [09/2002, Nico] Promotion de la représentation des liens: l'utilisateur sait bien ce qui est en relation avec quoi, mais leur mise en évidence fournit un moyen d'accès différent pas forcément connu à l'utilisateur, ou qui facilite l'emploi de l'appareil (je navigue souvent entre mon mail|mon site et les ressources audio: un *lien* de ce type serait particulièrement indiqué).
      De même on peut utiliser leur représentation pour concrétiser les résultats d'un fréquencemètre (donnant des infos sur l'utilisation), en figurant les éléments dissimulés par des branches *mortes*, un clic réactivant l'objet (objets à éclosion).
      [Pour visionner l'effet de rentrer dans une arborescence: 'Sacré SVG', très prenant.]
    3. [09/2002, Stéphane] L'utilisation de classification devrait permettre de regrouper ces trois domaines en un après un certain temps d'utilisation.
      Solutions:
      • trouver un moyen d'avoir un retour utilisateur sur les points où on ne peut pas le faire de manière transparente.
      • utiliser un petit réseau de neurones pourrait donner le comportement qu'on attend. L'apprentissage peut être très long et doit être (au moins partiellement) supervisé, mais le résultat pourait bien être surprenant. [ici aussi à creuser]
      • "truc" comprend sinon demande quel est le type de hiérarchie préférée (menus, objets à éclosion, tabs, icônes & fenêtres, représentation en arbre... ) et l'emploie ensuite.
      [à la recherche de documentation récente sur les UI 2D!]
    4. [09/2002, Nico] Approuve entièrement:
      • la possibilité de comprendre le type de hiérarchie qui convient vraiment l'utilisateur parmi ceux imaginés... (trop tendance à vouloir remplacer les choses par de nouvelles idées... pas forcément tout à fait comprises, donc appréciées). Laisser l'utilisateur choisir le mode 'menus' s'il préfère travailler ainsi... même si intuitivement une autre approche est recherchée.
      • les phénomènes de répétition, c'est vraiment un principe à implanter partout: *l'espionnage* des intéractions de l'utilisateur avec sa machine...
Copyright © 2001-2003, Tous droits Réservés • Contactez le WebMestre.