Interface design: differenze tra le versioni

Versione delle 19:12, 3 mar 2021

Versione delle 18:03, 25 mag 2021

Riga 13:

* Raccolta dei requisiti di funzionalità: raccolta di un elenco delle funzionalità richieste dal sistema per raggiungere gli obiettivi del progetto e le potenziali esigenze degli utenti.

* Analisi degli utenti e dei compiti : una forma di ricerca sul campo , è l'analisi dei potenziali utenti del sistema studiando come eseguono i compiti che il progetto deve supportare e conducendo interviste per elaborare i loro obiettivi.   Le domande tipiche riguardano:

** Cosa il sistema vorrebbe che l'utente faccia?

** Come si adatterebbe il sistema al normale flusso di lavoro o alle attività quotidiane dell'utente?

Riga 22:

[[File:Wireframe of potential component of "structured tasks" feature in Mediawiki 2020-05-28 8.png|alt=Esempio di wireframe|miniatura|Esempio di wireframe]]

* Prototipazione: sviluppo di [[Wireframe (web design)|wireframe]], sotto forma di prototipi cartacei o semplici schermi interattivi. Questi prototipi sono privati ​​didi tutti gli elementi di ''look & feel'' e della maggior parte dei contenuti per concentrarsi sull'interfaccia.

* Ispezione dell'[[Usabilità del web|usabilità]]: consente a un valutatore di ispezionare un'interfaccia utente. Questo è generalmente considerato più economico da implementare rispetto ai test di usabilità (vedere il passaggio di seguito) e può essere utilizzato nelle prime fasi del processo di sviluppo poiché può essere utilizzato per valutare prototipi o specifiche per il sistema, che di solito non possono essere testati sugli utenti. Alcuni metodi comuni di ispezione dell'usabilità includono il [[walkthrough]] cognitivo, che si concentra sulla semplicità di eseguire attività con il sistema per i nuovi utenti, la valutazione euristica, in cui una serie di euristiche viene utilizzata per identificare i problemi di usabilità nella progettazione dell'interfaccia utente e la procedura dettagliata pluralistica, in cui un un gruppo selezionato di persone attraversa uno scenario di attività e discute i problemi di usabilità.

* Test di [[usabilità]] (test dei prototipi su un utente reale) spesso utilizzando una tecnica chiamata protocollo think ad alta voce in cui si chiede all'utente di parlare dei propri pensieri durante l'esperienza. Il test di progettazione dell'interfaccia utente consente al progettista di comprendere la ricezione del progetto dal punto di vista dello spettatore e quindi facilita la creazione di applicazioni di successo.

* Progettazione grafica dell'interfaccia utente. Questi sono i pannelli di controllo e le facce del design; Le interfacce a comando vocale implicano l'interazione orale-uditiva, mentre le interfacce basate sui gesti testimoniano che gli utenti interagiscono con gli spazi di progettazione 3D tramite movimenti corporei. Può essere basato sui risultati sviluppati durante la ricerca dell'utente e perfezionati per risolvere eventuali problemi di usabilità riscontrati attraverso i risultati dei test.   A seconda del tipo di interfaccia che si sta creando, questo processo richiede in genere un pezzo di programmazione per computer per convalidare moduli, stabilire collegamenti o eseguire un'azione desiderata<ref>{{cita libro|url=http://www.interaction-design.org/encyclopedia/contextual_design.html|titolo=Contextual design|editore=Interaction Design Foundation|pubblicazione=The Encyclopedia of Human-Computer Interaction, 2nd Ed.|accesso=20 aprile 2014|autore=Karen Holtzblatt and Hugh R. Beyer}}</ref><ref>{{cita web|url=https://martinfowler.com/eaaDev/uiArchs.html|titolo=Forms and control|editore=thoughtworks publication|opera=GUI architecture|accesso=20 febbraio 2017|autore=Martin Fowler}}</ref>.

* Manutenzione del software: dopo l'implementazione di una nuova interfaccia, potrebbe essere necessaria una manutenzione occasionale per correggere [[bug]] del software, modificare le funzionalità o aggiornare completamente il sistema. Una volta presa la decisione di aggiornare l'interfaccia, il sistema [[sistema legacy]] subirà un'altra versione del processo di progettazione e inizierà a ripetere le fasi del ciclo di vita dell'interfaccia<ref>{{Cita news|url=http://caristix.com/blog/2010/10/8-stages-in-an-hl7-interface-lifecycle/|titolo=8 Stages in an HL7 Interface Lifecycle - Caristix|data=5 ottobre 2010|opera=Caristix|accesso=1º marzo 2017|lingua=en}}</ref>.

== Requisiti ==

Riga 50:

== Ricerca ==

[[File:CHECKBOX-CSS.png|alt=Esempio di checkbox formattati per dare loro un aspetto estetico gradevole|miniatura|Esempio di [[checkbox]] formattati per dare loro un aspetto estetico gradevole]]

Il design dell'interfaccia utente è stato un argomento di considerevole ricerca, anche sulla sua [[estetica]]<ref name="The role of context in perceptions of the aesthetics of web pages over time">{{cita news|editore=International Journal of Human–Computer Studies|url=http://portal.acm.org/citation.cfm?id=1464532.1465384&coll=GUIDE&dl=GUIDE&CFID=27731682&CFTOKEN=18425618|titolo=The role of context in perceptions of the aesthetics of web pages over time|data=5 gennaio 2009|accesso=2 aprile 2009}}</ref>. Gli  standard sono stati sviluppati già negli anni '80 per definire l'usabilità dei prodotti software. Una delle basi strutturali è diventata il modello di riferimento dell'interfaccia utente IFIP. Il modello propone quattro dimensioni per strutturare l'interfaccia utente:

* La dimensione di input/output (l'aspetto)

Riga 57:

* La dimensione organizzativa (il supporto alla comunicazione e alla cooperazione)

Questo modello ha notevolmente influenzato lo sviluppo dello standard internazionale ISO 9241 che descrive i requisiti di progettazione dell'interfaccia per l'usabilità. Il desiderio di comprendere i problemi dell'interfaccia utente specifici dell'applicazione nelle prime fasi dello sviluppo del software, anche se un'applicazione veniva sviluppata, ha portato alla ricerca sugli strumenti di prototipazione rapida della GUI che potrebbero offrire simulazioni convincenti di come un'applicazione reale potrebbe comportarsi nell'uso di produzione.   Alcune di queste ricerche hanno dimostrato che un'ampia varietà di attività di programmazione per software basato su GUI può, infatti, essere specificata attraverso mezzi diversi dalla scrittura di codice di programma<ref name="HUMANOID">{{cita news|editore=Proceedings CHI'92|url=http://citeseer.ist.psu.edu/old/szekely92facilitating.html|titolo=The HUMANOID model of interface design|anno=1992}}</ref><ref name="ACM Transactions on Programming Languages and Systems">{{cita news|editore=ACM|url=http://portal.acm.org/citation.cfm?id=78942.78943&coll=GUIDE&dl=GUIDE&CFID=27731682&CFTOKEN=18425618|titolo=Creating user interfaces using programming by example, visual programming, and constraints|data=11 aprile 1990|accesso=2 aprile 2009}}</ref>.

La ricerca è fortemente motivata dalla crescente varietà di dispositivi che possono, in virtù della legge di Moore, ospitare interfacce molto complesse<ref name="ACM Transactions on Computer–Human Interaction (TOCHI)">{{cita news|editore=ACM|url=http://portal.acm.org/citation.cfm?id=344949.344959&coll=GUIDE&dl=GUIDE&CFID=27731682&CFTOKEN=18425618|titolo=Past, present, and future of user interface software tools|data=1º marzo 2000|accesso=2 aprile 2009}}</ref>.