Différences entre versions de « Design »

De Mi caja de notas

(Page créée avec « {{xw}} »)
 
Ligne 1 : Ligne 1 :
{{xw}}
+
<cite class="h-cite">Cette page a démarré sur [[iwc:design]]</cite>
 +
 
 +
 
 +
<span style="float:right;height:192px;font-size:192px;margin:64px 0 -32px">✂</span>
 +
{{stub-fr}}
 +
 
 +
<div class="p-summary">'''<dfn>Design</dfn>''' est un terme fourre-tout pour faire référence à tout ce qui concerne les utilisateurs concernant une page/un comprenant : 
 +
* le [[Graphic design-fr|Design Graphique]] (y compris l'[[icon-fr|icone]] du site)
 +
* l'[[User interface-fr|Interface-Utilisateur]] (UI design)
 +
* l'[[User experience-fr|Expérience-Utilisateur]] (UX)
 +
* l'[[Information architecture-fr|Architecture de l'information]] (IA)
 +
** le [[URL design-fr|design d'URL]]
 +
</div>
 +
 
 +
== Réflexions ==
 +
__TOC__
 +
Quelques réflexions sur le design.
 +
 
 +
=== Minimalisme ===
 +
Quelle est l’UI minimum viable (MVUI) que vous pourriez implémenter et commencer à utiliser via votre site web ? - [[User:Tantek.com|Tantek]] 11:25, 15 mai 2013 (PDT)
 +
 
 +
Article en rapport : https://petermolnar.eu/minimalism-is-not-asceticism/
 +
 
 +
=== Définir les Priorités par l'Usage ===
 +
Une fois que vous avez designé/implémenté cette MVUI et que vous l’avez utilisé, par une véritable utilisation dans la jungle, vous parviendrez à un ensemble plus avisé des fonctionnalités à-suivre-les-plus-importantes-pour-vous à mettre en oeuvre. - [[User:Tantek.com|Tantek]] 11:25, 15 mai 2013 (PDT)
 +
 
 +
=== Incrémental ===
 +
Il est bien (et même souvent bon !) de produire des améliorations incrémentales au design, même si elles sont petites ou conditionnelles.
 +
 
 +
Par exemple, chaque fois que vous réduisez le nombre de situations où l'utilisateur voit une erreur et/ou doit déposer un ticket de support, la probabilité d'une meilleure expérience utilisateur globale est augmentée.
 +
 
 +
Et au contraire, éviter de faire que de telles améliorations progressives dépendent d'autres améliorations progressives qui peuvent être produites de façon indépendante ou plus tard. Ces dépendances sont une forme atténuée du piège de l'exhaustivité.
 +
 
 +
=== UX Avant l'Infrastructure ===
 +
Il existe une priorité/un désir mal orienté (souvent parmi les développeurs / ingénieurs) pour des choses comme :
 +
* "un message général producteur/consommateur afin que je puisse le mettre en oeuvre en une seule fois" [http://indiewebcamp.com/irc/2013-08-22/line/1377195851] ou équivalent
 +
* un analyseur général afin que je puisse le mettre en œuvre en une fois
 +
"... et ensuite passer le reste de mon temps à me concentrer sur l'UX» (ibid)
 +
 
 +
C'est le type de raisonnement qui a conduit les gens à pousser XML sur tout le reste.
 +
 
 +
Ce fut une orientation mal placée pour résoudre l'infrastructure *avant* l'UX.
 +
 
 +
Il se trouve que cela ne vous aide pas à résoudre l'UX, qui demeure le véritable défi.
 +
 
 +
Au contraire, si vous avez bonne UX, l'infrastructure/la plomberie peut n'être presque rien, et changé aussi par la suite.
 +
 
 +
Ceci est peut-être une caractéristique distinctive de l'indieweb et des efforts IndieWeb.
 +
 
 +
 
 +
=== UX Avant les Protocoles ===
 +
Commencez par la MVUI/l'UX que vous voulez sur votre site et mettez la en œuvre en conséquence.
 +
 
 +
Lorsque vous atteignez une limite de site à site, à savoir une frontière IndieWeb-vers-IndieWeb, dans quelque fonctionnalité que vous concevez, créez, itérez, utilisez l'UX souhaitée pour conduire la conception d'un protocole minimal.
 +
 
 +
Ne forcez jamais au chausse-pied, du protocole jusqu'à l'UX - car c'est la queue qui remue le chien.
 +
 
 +
En fin de journée, l'UX est ce qui importe, indépendamment des attributs, protocoles, etc.
 +
 
 +
Et sans UX, si tant est que vous ne savez pas quelle UX vous voulez, vous irez sur de l'overdesign/ overengineer de vos protocoles & amp; formats, comme le sont presque tous les protocoles et formats.
 +
 
 +
Sur l'IndieWeb, nous nous concentrons d'abord sur l'UX, et ensuite une fois compris ça, nous construisons/ développons /découpons les protocoles les plus minimaux et suffisants pour soutenir cette UX, et rien de plus. [http://indiewebcamp.com/irc/2013-08-22/line/1377196236]
 +
 
 +
== Screenshots ==
 +
Voir les caractéristiques spécifiques (par ex. à partir d'[[IndieMark-fr|IndieMark]]) et les [[building blocks-fr|blocs de construction]] pour des screenshots et pour en ajouter d'autres, par ex.
 +
* [[create-fr|créer]] des posts - [[posting interfaces|interfaces de post]]
 +
* ...
 +
 
 +
== Expérimentations ==
 +
Il existe différentes expériences de design qui peuvent être utiles comme sources d'inspiration, ou peuvent indiquer des modes ou tendances de design éphémères :
 +
* '''parallax scrolling''' - utilisation du scrolling pour changer la perspective / le layout de ce qui est sur la page, par exemple :
 +
** http://pitchfork.com/features/cover-story/reader/daft-punk/
 +
** Les opinions anecdotiques de conversations en personne avec des designers web lors de Brooklyn Beta 2014 faisaient remarquer que le design parallax était ringard et devait être évité.
 +
 
 +
== Articles ==
 +
Articles concernant le design orienté utilisateur et UX dans le contexte de l'IndieWeb (social fédéré).
 +
* 2009-07-01 {{benwerd}} <cite>[http://benwerd.com/2009/07/01/building-the-user-centered-web/ Building the user-centered web]</cite>
 +
* ...
 +
 
 +
== Voir aussi ==
 +
* [[icon-fr|icône]]
 +
* [[building-blocks-fr|blocs de construction]]
 +
* [[principles-fr|principes]]
 +
* [[projects-fr|projets]]
 +
* [[create-fr|créer]]
 +
* [[admin-fr|admin]]

Version du 20 juin 2016 à 08:39

Cette page a démarré sur iwc:design



Design est un terme fourre-tout pour faire référence à tout ce qui concerne les utilisateurs concernant une page/un comprenant :

Réflexions

Quelques réflexions sur le design.

Minimalisme

Quelle est l’UI minimum viable (MVUI) que vous pourriez implémenter et commencer à utiliser via votre site web ? - Tantek 11:25, 15 mai 2013 (PDT)

Article en rapport : https://petermolnar.eu/minimalism-is-not-asceticism/

Définir les Priorités par l'Usage

Une fois que vous avez designé/implémenté cette MVUI et que vous l’avez utilisé, par une véritable utilisation dans la jungle, vous parviendrez à un ensemble plus avisé des fonctionnalités à-suivre-les-plus-importantes-pour-vous à mettre en oeuvre. - Tantek 11:25, 15 mai 2013 (PDT)

Incrémental

Il est bien (et même souvent bon !) de produire des améliorations incrémentales au design, même si elles sont petites ou conditionnelles.

Par exemple, chaque fois que vous réduisez le nombre de situations où l'utilisateur voit une erreur et/ou doit déposer un ticket de support, la probabilité d'une meilleure expérience utilisateur globale est augmentée.

Et au contraire, éviter de faire que de telles améliorations progressives dépendent d'autres améliorations progressives qui peuvent être produites de façon indépendante ou plus tard. Ces dépendances sont une forme atténuée du piège de l'exhaustivité.

UX Avant l'Infrastructure

Il existe une priorité/un désir mal orienté (souvent parmi les développeurs / ingénieurs) pour des choses comme :

  • "un message général producteur/consommateur afin que je puisse le mettre en oeuvre en une seule fois" [1] ou équivalent
  • un analyseur général afin que je puisse le mettre en œuvre en une fois

"... et ensuite passer le reste de mon temps à me concentrer sur l'UX» (ibid)

C'est le type de raisonnement qui a conduit les gens à pousser XML sur tout le reste.

Ce fut une orientation mal placée pour résoudre l'infrastructure *avant* l'UX.

Il se trouve que cela ne vous aide pas à résoudre l'UX, qui demeure le véritable défi.

Au contraire, si vous avez bonne UX, l'infrastructure/la plomberie peut n'être presque rien, et changé aussi par la suite.

Ceci est peut-être une caractéristique distinctive de l'indieweb et des efforts IndieWeb.


UX Avant les Protocoles

Commencez par la MVUI/l'UX que vous voulez sur votre site et mettez la en œuvre en conséquence.

Lorsque vous atteignez une limite de site à site, à savoir une frontière IndieWeb-vers-IndieWeb, dans quelque fonctionnalité que vous concevez, créez, itérez, utilisez l'UX souhaitée pour conduire la conception d'un protocole minimal.

Ne forcez jamais au chausse-pied, du protocole jusqu'à l'UX - car c'est la queue qui remue le chien.

En fin de journée, l'UX est ce qui importe, indépendamment des attributs, protocoles, etc.

Et sans UX, si tant est que vous ne savez pas quelle UX vous voulez, vous irez sur de l'overdesign/ overengineer de vos protocoles & amp; formats, comme le sont presque tous les protocoles et formats.

Sur l'IndieWeb, nous nous concentrons d'abord sur l'UX, et ensuite une fois compris ça, nous construisons/ développons /découpons les protocoles les plus minimaux et suffisants pour soutenir cette UX, et rien de plus. [2]

Screenshots

Voir les caractéristiques spécifiques (par ex. à partir d'IndieMark) et les blocs de construction pour des screenshots et pour en ajouter d'autres, par ex.

Expérimentations

Il existe différentes expériences de design qui peuvent être utiles comme sources d'inspiration, ou peuvent indiquer des modes ou tendances de design éphémères :

  • parallax scrolling - utilisation du scrolling pour changer la perspective / le layout de ce qui est sur la page, par exemple :

Articles

Articles concernant le design orienté utilisateur et UX dans le contexte de l'IndieWeb (social fédéré).

Voir aussi