Non aux brevets logiciels

SpipLab

ReferencesExternes

PagePrincipale :: DerniersChangements :: Vous êtes 38.103.63.16 (Connexion)

Cette page est destinée à fournir un tissu de références externes (textes et projets) permettant d’appréhender les questions générales que l’on retrouve dans le développement de SPIP. D’où on pourra mieux comprendre, et faire évoluer, la PhilosophieSPIP.

Animation de la communauté

— http://www.wikini.net/wakka.php?wik...

Interfaces graphiques et logiciels libres

Free software and good user interfaces : un texte écrit par Havoc Pennington, un des leaders du projet GNOME. Ce texte n’est pas une vérité révélée ; il exprime l’opinion d’un développeur qui a décidé d’insuffler une orientation particulière à son projet (voir plus bas). Il recèle néanmoins quelques constats intéressants.

Exemple :

I don’t have any genius definition of "good UI" ; I’m not a UI expert. But it clearly doesn’t mean snazzy graphics or featuritis. In the end when I think good UI I think of MacOS* classic : clean, simple, consistent, productive. You focus on your work or play and the GUI isn’t in the way. OS X adds the cool graphics too, but those aren’t the part that makes it a good UI, just the part that makes it fun.

Sur le sujet des options de configuration :

A traditional free software application is configurable so that it has the union of all features anyone’s ever seen in any equivalent application on any other historical platform. [...] Does this hurt anything ? Yes it does. It turns out that preferences have a cost. Of course, some preferences also have important benefits - and can be crucial interface features. But each one has a price, and you have to carefully consider its value. Many users and developers don’t understand this, and end up with a lot of cost and little value for their preferences dollar.

-  Too many preferences means you can’t find any of them. [...]

-  Preferences really substantively damage QA and testing. As someone who reads dozens of bug reports per day, and occasionally fixes a couple, I can tell you that it’s extremely common to find a bug that only happens if some certain combination of options are enabled. As a software developer, I can tell you that preferences frequently do add quite a bit of code complexity as well ; some more than others, but even simple preferences can add a lot of complexity if there are 200 of them. [...]

-  Preferences can confuse many users. Take the famous too many clocks example. A significant number of test subjects were so surprised to have 5 choices of clock they couldn’t figure out how to add a clock to their panel. This cost of preferences is invariably underestimated by us technical types.

Je vous laisse le soin de traduire en français (note : UI signifie User Interface ; QA veut dire Quality Assurance, c’est-à-dire les procédures de test et de correction de bugs).

(NicolasHoizey) Pour compléter, un article de Matt Gemmell intitulé Unusability dont voici un bref extrait :

I have a theory that the number of preferences (UI-configurable options) in a piece of software is a function of the number of contributors to the software, multiplied by the inverse of how well-designed and specified it is, multiplied further by the inverse of its nominal ease-of-use, and finally multiplied by an arbitrary large scaling factor if the software is open source.

Une analyse de l’interface privée de SPIP, et propositions

http://diala.rezo.net/

-  Analyse des principes généraux de SPIP (notamment l’aspect «intégré»).

-  Analyse et propositions au sujet de l’ergonomie.

(Bill) Histoire d’avancer un peu sur le sujet, je jette une premiere proposition, sans doute pas la bonne ... Permettre de definir plusieurs types d’interface et, pour chacune, la possibilité de definir le niveau de droit par bouton. L’idée etait de reprendre le meme type de declaration que les extras (tableaux PHP), genre :

$GLOBALS[’interface’] = Array( ’simplifiee’=>Array( "asuivre"=>Array( "asuivre"=>"1Comite", "infoperso"=>"1Comite", "tout"=>"1Comite", "viedusite"=>"0Minirezo", ) "edition"=>"Array( "rubriques"=>"1Comite", "articles"=>"1Comite", "breves"=>"1Comite", "auteurs"=>"1Comite", "admincache"=>"admin_vider", )", ...

) ;

$GLOBALS[’interface_liens’] = Array( "asuivre"=>"index", "infoperso"=>"auteur_edit", "tout"=>"articles_tous", "rubriques"=>"naviguer", "articles"=>"articles_page", "breves"=>"breves", "auteurs"=>"auteurs", ... )", ...

) ;

ou peut etre mettre les liens dans interface et faire un interface_droit (on suppose que si le redacteur n’a pas droit à un lien dans une interface, c’est valable egalement dans les autres interface ...), je ne sais pas trop, mais bref, passer à un menu "declaratif" plutot que ce inc_presentation de 3km de long me semble une bonne idée, non ?

-  Analyse et propositions au sujet du graphisme.

-  Propositions sur d’autres formes d’interaction avec le système.

Gnome vs. KDE

Pour les linuxiens, c’est une référence très importante. Ce sont les deux environnements graphiques les plus avancés sous Linux. Historiquement, ils se ressemblaient assez. Puis, avec l’arrivée de la version 2 de Gnome, les projets ont divergé profondément. Aujourd’hui, on peut tracer d’un trait assez net :

-  KDE accumule le maximum de fonctionnalités afin de satisfaire les besoins les plus exotiques. Cela donne des outils à l’interface extrêmement touffue, où l’on se perd facilement dans les options rarement utilisées.

-  Gnome recherche au contraire la simplification et la cohérence maximale de l’interface. La démarche mérite d’être relevée : par rapport à Gnome 1.x, une partie du travail de la version 2 a consisté à enlever des fonctionnalités (ou les masquer, ou les présenter de façon plus simple). Ce qui, bien évidemment, a conduit beaucoup d’utilisateurs à râler ; cependant, la renommée du projet Gnome n’a pas diminué pour autant et sa démarche est aujourd’hui appréciée par un bon nombre d’utilisateurs (y compris l’auteur de ces lignes ;-)).

Un exemple frappant : le gestionnaire de fichiers. Les captures d’écran suivantes montrent l’interface par défaut des outils respectifs :
-  le gestionnaire de fichiers de KDE 3.2
-  le gestionnaire de fichiers de Gnome 2.6

Note : ne pas tenir compte de l’habillage graphique (qui dépend du thème utilisé). La différence se situe dans : le nombre de menus ; la complexité des menus ; la présence ou non d’une barre d’icones ; la présence, ou non d’une barre d’adresse ; la complexité des informations affichées...

Divers

On pourra lire tout Joel on Software.

Par exemple Building Communities with Software :

Q. Could you make a feature where I check a box that says "email me if somebody replies to my post ?"

A. This one feature, so easy to implement and thus so tempting to programmers, is the best way to kill dead any young forum. Implement this feature and you may never get to critical mass. Philip Greenspun’s LUSENET has this feature and you can watch it sapping the life out of young discussion groups.

Why ?

What happens is that people go to the group to ask a question. If you offer the "notify me" checkbox, these people will post their question, check the box, and never come back. They’ll just read the replies in their mailbox. The end.

If you eliminate the checkbox, people are left with no choice but to check back every once in a while. And while they’re checking back, they might read another post which looks interesting. And they might have something to contribute to that post. And in the critical early days when you’re trying to get the discussion group to take off, you’ve increased the "stickiness" and you’ve got more people hanging around, which helps achieve critical mass a lot quicker.