Afin de pouvoir longuement comparer Windows 10 par rapport à Linux,
sachez que toutes personnes s'inscrivant au programme de test pour
Windows 10 recevra une copie gratuite à installer.
C'est l'oocasion ou jamais de comparer ces 2 systèmes et d'arrêter
votre choix.
Une interface bien faite est "auto-descriptive" (il y a un mot pour ça, mais je ne remets plus la langue dessus), et avec quelques infobulles pour plus d'explications ça évite 90% du temps de se plonger dans une doc. On le fait une fois au début pour comprendre la philosophie de l'outil, et après c'est bon en général.
Tu raisonnes toujours en termes d'une GUI pour un outil qui a un nombre limité d'options. Quand on arrive au niveau de complexité d'un outil comme wget, tu ne peux pas juste regarder les options disponibles, il y en a trop et tu ne trouveras jamais celle qui fait presque exactement ce que tu veux.
Ce qui est idiot c'est en effet de dire "on va faire une GUI pour wget", alors qu'en fait on fait une GUI pour réaliser une tâche particulière, plus ou moins complexe. Cette GUI peut utiliser derrière wget, pas focément tout wget, et pas forcément que wget.
La solution dans ce cas, c'est évidemment la doc : tu sais ce que tu veux faire, tu fais une recherche par mot clef dans le doc, et tu finis par trouver.
Pour le moment, c'est pareil pour la GUI et la CLI, on trouve le bon paragraphe dans la doc. La différence se manifeste quand tu veux transposer ce que tu as vu dans la doc à un cas pratique. Avec une GUI, il faut que la doc t'explique le chemin complet, menu, sous-menu, onglet, etc. Avec la ligne de commande, il suffit de copier-coller l'exemple.
Un exemple de soft bien conçu en GUI est Handbrake pour ripper/réencoder des DVD. La prise en main est rapide, les menus et onglets bien organisés... Au pire il y a besoin de lire la doc au début et après pas besoin d'y revenir. A contrario, quand j'ai besoin de ffmpeg je suis pratiquement toujours obligé de relire la doc, parce que je ne l'utilise pas assez souvent pour me souvenir d'une fois sur l'autre de la syntaxe exacte de telle ou telle opération.
En théorie, rien n'empêcherait de faire une partie de ça avec des GUI. On pourrait imaginer une GUI qui permette une recherche par mot clef dans le texte des bulles d'aide, et qui t'ouvre directement les bons menus et sous-menus pour y arriver. Mais ça, pour le moment, c'est de la théorie, alors qu'avec la ligne de commande, c'est déjà de la pratique depuis des années.
Pas mal de choses dans OS X fonctionnent de la façon dont tu le décris là.
Le 23/06/2015 11:57, Nicolas George a écrit :
pehache , dans le message
<7b1dc8a5694d109c020fe2b7b4296a92e8a3718f@news.nemoweb.net>, a écrit :
Une interface bien faite est "auto-descriptive" (il y a un mot pour ça,
mais je ne remets plus la langue dessus), et avec quelques infobulles pour
plus d'explications ça évite 90% du temps de se plonger dans une doc. On
le fait une fois au début pour comprendre la philosophie de l'outil, et
après c'est bon en général.
Tu raisonnes toujours en termes d'une GUI pour un outil qui a un nombre
limité d'options. Quand on arrive au niveau de complexité d'un outil comme
wget, tu ne peux pas juste regarder les options disponibles, il y en a trop
et tu ne trouveras jamais celle qui fait presque exactement ce que tu veux.
Ce qui est idiot c'est en effet de dire "on va faire une GUI pour wget",
alors qu'en fait on fait une GUI pour réaliser une tâche particulière,
plus ou moins complexe. Cette GUI peut utiliser derrière wget, pas
focément tout wget, et pas forcément que wget.
La solution dans ce cas, c'est évidemment la doc : tu sais ce que tu veux
faire, tu fais une recherche par mot clef dans le doc, et tu finis par
trouver.
Pour le moment, c'est pareil pour la GUI et la CLI, on trouve le bon
paragraphe dans la doc. La différence se manifeste quand tu veux transposer
ce que tu as vu dans la doc à un cas pratique. Avec une GUI, il faut que la
doc t'explique le chemin complet, menu, sous-menu, onglet, etc. Avec la
ligne de commande, il suffit de copier-coller l'exemple.
Un exemple de soft bien conçu en GUI est Handbrake pour ripper/réencoder
des DVD. La prise en main est rapide, les menus et onglets bien
organisés... Au pire il y a besoin de lire la doc au début et après pas
besoin d'y revenir. A contrario, quand j'ai besoin de ffmpeg je suis
pratiquement toujours obligé de relire la doc, parce que je ne l'utilise
pas assez souvent pour me souvenir d'une fois sur l'autre de la syntaxe
exacte de telle ou telle opération.
En théorie, rien n'empêcherait de faire une partie de ça avec des GUI. On
pourrait imaginer une GUI qui permette une recherche par mot clef dans le
texte des bulles d'aide, et qui t'ouvre directement les bons menus et
sous-menus pour y arriver. Mais ça, pour le moment, c'est de la théorie,
alors qu'avec la ligne de commande, c'est déjà de la pratique depuis des
années.
Pas mal de choses dans OS X fonctionnent de la façon dont tu le décris là.
Une interface bien faite est "auto-descriptive" (il y a un mot pour ça, mais je ne remets plus la langue dessus), et avec quelques infobulles pour plus d'explications ça évite 90% du temps de se plonger dans une doc. On le fait une fois au début pour comprendre la philosophie de l'outil, et après c'est bon en général.
Tu raisonnes toujours en termes d'une GUI pour un outil qui a un nombre limité d'options. Quand on arrive au niveau de complexité d'un outil comme wget, tu ne peux pas juste regarder les options disponibles, il y en a trop et tu ne trouveras jamais celle qui fait presque exactement ce que tu veux.
Ce qui est idiot c'est en effet de dire "on va faire une GUI pour wget", alors qu'en fait on fait une GUI pour réaliser une tâche particulière, plus ou moins complexe. Cette GUI peut utiliser derrière wget, pas focément tout wget, et pas forcément que wget.
La solution dans ce cas, c'est évidemment la doc : tu sais ce que tu veux faire, tu fais une recherche par mot clef dans le doc, et tu finis par trouver.
Pour le moment, c'est pareil pour la GUI et la CLI, on trouve le bon paragraphe dans la doc. La différence se manifeste quand tu veux transposer ce que tu as vu dans la doc à un cas pratique. Avec une GUI, il faut que la doc t'explique le chemin complet, menu, sous-menu, onglet, etc. Avec la ligne de commande, il suffit de copier-coller l'exemple.
Un exemple de soft bien conçu en GUI est Handbrake pour ripper/réencoder des DVD. La prise en main est rapide, les menus et onglets bien organisés... Au pire il y a besoin de lire la doc au début et après pas besoin d'y revenir. A contrario, quand j'ai besoin de ffmpeg je suis pratiquement toujours obligé de relire la doc, parce que je ne l'utilise pas assez souvent pour me souvenir d'une fois sur l'autre de la syntaxe exacte de telle ou telle opération.
En théorie, rien n'empêcherait de faire une partie de ça avec des GUI. On pourrait imaginer une GUI qui permette une recherche par mot clef dans le texte des bulles d'aide, et qui t'ouvre directement les bons menus et sous-menus pour y arriver. Mais ça, pour le moment, c'est de la théorie, alors qu'avec la ligne de commande, c'est déjà de la pratique depuis des années.
Pas mal de choses dans OS X fonctionnent de la façon dont tu le décris là.
Nicolas George
pehache , dans le message , a écrit :
Ce qui est idiot c'est en effet de dire "on va faire une GUI pour wget",
Tu admets donc que wget est plus pratique en ligne de commande. Merci de ton soutien.
pehache , dans le message <d2r1doF33mnU1@mid.individual.net>, a écrit :
Ce qui est idiot c'est en effet de dire "on va faire une GUI pour wget",
Tu admets donc que wget est plus pratique en ligne de commande. Merci de ton
soutien.
