Linee guida Interfacce Umane

These guidelines are designed to help developers and designers create a beautifully consistent experience on the elementary OS desktop. They were written for interface designers, graphic artists and software developers who will be working on elementary OS. They will not only define specific design elements and principles, but will also instill a philosophy that will help you decide when it is appropriate to deviate from the Guidelines. Adhering to the suggestions contained here will provide many benefits:

Per aiutarti a raggiungere questi obbiettivi, queste lineeguida copriranno gli elementi di base dell'interfaccia, come usarli e metterli efficacemente insiemie, e come fare per integrare al meglio la tua applicazione con il desktop. La cosa più importante da ricordare è che queste lineeguida renderanno più semplice progettare una nuova applicazione, no più difficile.

Comunque, ricordati che queste sono linee guida, non regole. Ogni giorno vengono scoperti nuovi, incredibili paradigmi di interazione e molti altri sono in attesa di essere scoperti. Questo è un documento attivo che può e sarà cambiato.

Questa sezione non è ancora stata scritta, per favore rivolgiti a Le linee guida dell'interfaccia GNOME

Filosofia di Design

The elementary OS HIG isn't just about a set of concrete rules; it's meant to be flexible and extensible. As such, this very first portion of the guideline is all about the guiding philosophy we employ. For a quick crash course, we like "The User is Drunk":

Cosa non è il Design

Before we get into all the things that make up elementary OS apps, there is a clarification that needs to be made. We need to understand what exactly design is about, but more importantly we want to smash two major myths:

  1. Il design non è qualcosa che si aggiunge dopo aver completato un prodotto. Che ve ne rendiate conto o no, stai costantemente progettando qualunque cosa costruisci. Si tratta di una parte intrinseca di creare qualcosa. Il design non è solo ciò a cui una cosa assomiglia. Non sono solo i colori e i caratteri. Il design è come funziona. Quando si decide di aggiungere un pulsante che fa una cosa, quello è design. Hai preso una decisione di aggiungere un pulsante con un'icona o un'etichetta e dove quel pulsante è andato e la dimensione e il colore di quel pulsante. Le decisioni sono design.

  2. Il design non è solo come la tua opinione. Il design è testabile. Un design incontra uno specifico obbiettivo meglio di un altro design. Considera tipi differenti di biciclette. Una bicicletta ripiegabile ha un differente set di obbiettivi di design rispetto ad una mountain bike. Elementi come il peso, la grandezza, ed il battistrada sono fattori importanti che aiutano l'utente a raggiungere i propri obbiettivi. Capendo che lo scopo del design è di risolvere problemi specifici, dobbiamo anche capire che possiamo confrontare oggettivamente l'efficacia di due disegni alla risoluzione di questi problemi.

  1. Il Design non è impiallacciatura, Aral Balkan
  2. Il Design non è Soggettivo, Jeff Law

Concisione

Lavora sempre per rendere la tua applicazione immediatamente comprensibile. La funzione principale della tua applicazione dovrebbe essere immediatamente evidente. È possibile farlo in diversi modi, ma uno dei modi migliori è quello di attenersi ad un principio di concisione.

Evita di Inserire troppe funzionalità

Spesso è molto forte la tentazione di continuare ad aggiungere sempre più caratteristiche alla tua applicazione. Tuttavia, è importante riconoscere che ogni nuova caratteristica ha un prezzo. In particolare, ogni volta che si aggiunge una nuova funzionalità:

Pensa per Moduli

Build small, modular apps that communicate well. elementary OS apps avoid feature overlap and make their functions available to other apps either through Contractor or over D-Bus. This both saves you time as a developer (by other apps making their functions available to you), and is a courteous gesture towards other developers (by making your app's functions available to them).

Evita la Configurazione

Se possibile, evita completamente di presentare qualsiasi impostazione o configurazione nella vostra applicazione. Fornire le impostazioni di solito è un modo semplice di prendere decisioni progettuali per il comportamento di un app. Ma proprio come con problemi di funzionalità, impostazioni significano più codice, più bug, ulteriori test, maggiore documentazione, e maggiore complessità.

Costruisci un'esperienza "Pronta all'uso"

Design with sane defaults in mind. elementary OS apps put strong emphasis on the out of the box experience. If your app has to be configured before a user is comfortable using it, they may not take the time to configure it at all and simply use another app instead.

Chiedi al Sistema Operativo

Ottieni automaticamente quante più informazioni possibili. Invece di chiedere ad un utente il suo nome o la sua ubicazione, chiedi al sistema queste informazioni. Questo riduce la quantità di cose che un utente deve fare e rende la vostra applicazione intelligente e integrata.

È veramente necessario?

Chiedetevi se l'opzione di configurazione che si sta aggiungendo è davvero necessaria o ha senso per un utente. Non bisogna mai chiedere agli utenti di prendere decisioni di ingegneria o di progettazione.

Quando è assolutamente necessario

Mantieni le cose contestuali. Invece di rimboccare preferenze in una finestra di configurazione, pensare alla loro visualizzazione in un contesto con gli oggetti che interessano (molto simile a come "casuale" e "opzioni di ripetizione" appaiono vicino alla vostra libreria musicale).

Se la tua app ha bisogno di essere configurata prima dell'uso (tipo un client email), presenta questa configurazione nella finestra principale come se fosse una Schermata di Benvenuto. Accertati però che questa configurazione sia veramente necessaria. Aggiungere schermate di configurazione inutili impedisce agli utenti di fare ciò che volevano quando hanno aperto l'app.


Vedi Anche:

  1. Checkboxes That Kill Your Product di Alex Limi
  2. Don't Give Your Users Shit Work di Zach Holman
  3. The Wizard Anti-Pattern di Stef Walter

Documentazione minimale

La maggior parte degli utenti non vuole leggere la documentazione prima di utilizzare il tuo programma. Si aspettano solo che l'app sia intuitiva e semplice da capire senza assistenza.

Usa un linguaggio comprensibile

Avoid technical jargon and assume little-to-no technical knowledge. This lets your app be "self-documenting."

Fornisci delle spiegazioni non tecniche invece che dei messaggi di errore criptici. Se qualcosa va per il verso sbagliato, una spiegazione semplificata di cosa è successo e come risolvere il problema dovrebbe essere mostrata.


Per maggiori informazioni, vedi Stile di Scrittura.

Flusso di interazioni dell'utente

Il design visivo è una parte importante dell'esperienza utente, ma lo è anche il flusso di lavoro dell'utente, o come esso interagisce con un'app. In questo capitolo, parleremo di alcuni passaggi di un flusso di lavoro tipico:

Prima esperienza di lancio

Configurazione necessaria

When a user first launches an app, they should be able to get down to business as quickly as possible. If configuration is not absolutely required for the first use, they should not be required to configure anything. If configuration is required, they should be presented with a clean and simple welcome screen within the app. Avoid separate configuration dialogs when launching.

Velocità di avvio

Il primo avvio della tua applicazione dà la prima impressione all'utente; è una chance per mostrarne il design e la velocità. Se la tua app deve effettuare configurazioni in background prima di essere visibile, darà l'impressione di essere lenta nell'uso o nell'avvio. Invece, focalizzati nel mostrare la finestra il più velocemente possibile, già pronta da usare, e solo successivamente effettua le configurazioni in background. Se la configurazione limita l'usabilità dell'app (ad es. non possono essere effettuate alcune operazioni) mostra un indicatore dei processi in corso e rendi temporaneamente bloccati gli oggetti interessati. (vedi Concetti sui Widget )

Dai il Benvenuto all'utente

If there is no content to show the user, provide actions they can act upon by using a simple welcome screen. Let them open a document, add an account, import a CD, or whatever makes sense in the context of the app.

Ripristino dell'applicazione

Se un utente "resetta" volontariamente l'app (ad es. cancellando tutte le canzoni o rimuovendo tutti gli account mail), dovrebbe tornare allo stato del primo avvio.

Avvio normale

Quando un utente avvia un'app sta svolgendo un'azione volontaria e si aspetta una risposta veloce, spesso immediata. Dovresti focalizzarti su tre aree fondamentali dell'avvio: velocità, ovvietà della azione successiva e stato del programma.

Velocità

Come detto prima, la velocità, soprattutto in fase di lancio dell'app, è molto importante. Dovrebbe esserci il minor ritardo possibile tra l'istante in cui l'utente decide di lanciare il programma e quando può effettivamente usarlo. Se la tua app richiede una splash screen, stai lavorando male.

Ovvietà

Quando un utente lancia il tuo programma, dovrebbe sapere esattamente cosa fare dopo. L'obiettivo si raggiunge seguendo le altre linee guida per l'interfaccia (garantendo la coerenza con le altre app) e offrendo azioni da compiere. Se l'app mostra solitamente degli oggetti, come canzoni o email, permetti all'utente di vederli subito mostrandoli appena l'app si apre. Se non ci sono oggetti già aperti, dovresti permettere di aprirne o crearne di nuovi (ad es. un documento) tramite una Pagina di Benvenuto.

Stato

Se un utente ha già usato l'applicazione, è meglio ripristinare lo stato dell'app quando viene aperta nuovamente. Questo significa che si aprirà così come l'utente l'aveva chiusa, in modo da poter riprendere il lavoro. In un lettore musicale, alla riapertura, dovrebbe apparire la schermata aperta nel momento della chiusura e la stessa canzone che era in riproduzione in quel momento. In un editor di testo, invece, dovrebbe aprirsi lo stesso documento, nello stesso punto della pagina e con il cursore già posizionato laddove era stato lasciato.

Offri Sempre la Possibilità di Annullare

Sometimes a user will perform an action which could possibly be destructive or traditionally irreversible. Rather than present the user with a warning, apps should let the user undo the action for an appropriate amount of time. Some prime examples of when this behavior is useful are:

Questa via dovrebbe essere usata solo in ultima istanza prevedendo un tempo di attesa tra il momento in cui l'applicazione mostra all'utente ciò che è accaduto e l'effetuazione dell'azione. Per mantenere l'esperienza reattiva, l'applicazione deve sempre apparire come se l'azione venisse eseguita non appena l'utente la richiede.

Questo comportamento è il miglior compromesso per non interferire con l'utente e allo stesso tempo evitare che faccia qualcosa di non voluto. E' importante mantenere la funzione di annullamento semplice, intuitiva e non intrusiva; un modo comune per farlo è usare una info bar, ma altri metodi posso essere ugualmente appropriati.


Vedi anche: Never Use a Warning When you Mean Undo di Aza Raskin

Mantieni salvato

Gli utenti dovrebbero sentirsi sicuri quando utilizzano elementary; essi dovrebbero sapere che tutto quello che vedono è salvato e aggiornato.

Le applicazioni in elementary dovrebbero salvare sempre il proprio stato. Ciò significa che le modifiche effettuate dall'utente devono essere immediatamente applicate e rese visibili, e permettere all'utente di salvare manualmente è un retaggio o un comportamento specifico.

Ad esempio, una finestra "Dettagli canzone" dovrebbe aggiornare istantaneamente le informazioni sulla traccia senza che l'utente debba premere un pulsante di salvataggio, le preferenze dell'utente devono essere applicate non appena l'utente manipola il relativo widget, e la chiusura di un'applicazione dovrebbe significare che alla riapertura l'utente tornerà al punto in cui ha terminato.

Chiusura

Quando un utente chiude un'applicazione, significa in generale che ha finito di usarla per ora e vuole toglierla di mezzo.

Salvataggio dello stato

Le applicazioni dovrebbero salvare il loro stato quando vengono chiuse in modo da poter ripartire da dove l'utente ha chiuso l'applicazione l'ultima volta. Idealmente chiudere e riaprire un'applicazione dovrebbe essere indistinguibile dal tradizionale concetto di minimizzazione e ripristino di un'applicazione; quindi tutti gli elementi dovrebbero essere salvati, compresi i documenti aperti, la posizione di scorrimento, la storia delle modifiche, ecc.

Attività in background

Se ha senso per un'applicazione completare le attività in background dopo che la finestra è stata chiusa, le attività dovrebbero essere completate il prima possibile dopo la chiusura della finestra. Se l'applicazione esegue operazioni ripetitive in background (come ad esempio un client di posta elettronica), queste operazioni dovrebbero essere gestite da un processo separato che non si basa sul fatto che l'applicazione sia aperta.

Chiusura della finestra della Applicazione

Non è auspicabile che una finestra di un programma si minimizzi piuttosto che chiudersi quando l'utente tenta di chiuderla. L'applicazione dovrebbe essere solo "nascosta". Se ha senso proseguire il processo in background (come scaricare file, riprodurre musica o eseguire un comando dal terminale) l'applicazione dovrebbe continuare ad operare e chiudersi al completamento. Se il completamento del processo non è subito visibile (come lo scaricamento o il comando dal terminale), l'applicazione dovrebbe mostrare una notifica che informi del completamento. Se il completamento è visibile, come nella riproduzione musicale, non è necessaria alcuna notifica.

Ri-apertura della finestra della Applicazione

Se l'utente riapre l'applicazione mentre il processo in background è in esecuzione, la finstra dovrebbe riaprirsi esattamente nello stato in cui sarebbe stata se fosse rimasta aperta. Ad esempio, il terminale dovrebbe mostrare l'output, il player multimediale essere nella stessa pagina in cui è stato chiuso e il browser riaprire la pagina aperta. Per altri dettagli, vedi le info sullo stato dell'applicazione all'Avvio normale.


Vedi anche: That's It, We're Quitting di Matthew Paul Thomas

Integrazione con la Scrivania

An important advantage that developers have when choosing the elementary OS platform is the ability to seamlessly integrate their application with the default desktop. Outlined below are the several ways in which you can make your application feel beyond native in elementary. This section will cover things like:

Lanciatori di app

Il primo modo per scoprire e usare la tua applicazione è il lanciatore in Slingshot o nella dock. per fornire questi lanciatori devi installare un file .desktop appropriato insieme alla tua app. Dovrai dare un nome al lanciatore, posizionarlo nella categoria corretta, assegnargli un'icona, etc.

I file .desktop seguono le Desktop Entry Specification di freedesktop.org. Dovrebbero essere installati in /usr/share/applications e gli utenti dovrebbero poter creare i propri lanciatori inserendo i file .desktop in ~/.local/share/applications.

I contenuti del file .desktop devono seguire questo modello:

Titolo è un(a) NomeGenerico che ti consente di Commento.

Titolo

You should not include descriptive words in your title. For example, Dexter is called "Dexter," not "Dexter Address Book." Midori is just "Midori," not "Midori Web Browser." Instead, use the GenericName attribute of your app's .desktop file for a generic name, and the Comment attribute for a longer descriptive phrase.

NomeGenerico

Se la tua app può essere ben descritta o categorizzata dal nome generico dovresti usare quello per l'attributo GenericName del file .desktop della tua applicazione. Se puoi dire "La mia app è un(una) ____," allora ciò che riempie gli spazi bianchi può essere il nome generico. Ad esempio Maya è un calendario, quindi il nome generico è "Calendario".

Non dovresti includere gli articoli (un, il, la) o le parole "programma", "app" o "applicazione" nel nome generico della tua applicazione.

Il nome generico dovrebbe essere in title case e usato in tutto il sistema per descrivere o categorizzare meglio la tua applicazione.

Commento

The system uses an app's Comment attribute (found in the .desktop file) to succinctly inform a user what can be done with the app. It should be a short sentence or phrase beginning with a verb and containing the primary nouns that your app deals with. For example, the following are appropriate comments:

Il commento di un'applicazione dovrebbe essere in sentence case, non includere punteggiatura (punti, punti escamativi o di domanda) e dovrebbe essere quanto più corto possibile, descrivendo il principale uso dell'applicazione.

Categorie

Le seguenti categorie possono essere utilizzate per aiutare a cercare o individuare la vostra applicazione:

Per ulteriori informazioni, vedi i dettagli sulle voci di menu su FreeDesktop.Org.

Parole chiave

Puoi anche includere parole chiave nel lanciatore per aiutare la ricerca dell'applicazione. Vengono seguite le convenzioni "X-GNOME-Keywords" (per il lanciatore) e "X-AppInstall-Keywords" (per l'installer). Ad esempio, il browser web potrebbe includere "Internet" come parola chiave, anche se non è presente nel nome, nel nome generico o nella descrizione. Così facendo, un utente che cerchi "Internet" troverà il programma. Alcuni esempi:

Keywords should be single words (in title case) separated by semicolons.


Vedi anche: Desktop Entry Specification su FreeDesktop.org

Contractor

Contractor is a service and a protocol for exposing services easily between apps. It lets apps interact with other apps and services without hardcoded support for them. You simply add Contractor support, and then any service registered with Contractor is now available for your app to use. Your app can integrate with Contractor in two different ways:

Mostrare i risultati da Contractor

Contractor results are typically presented to users in menu form. Keep the following in mind when presenting Contractor results:

Integrazione con la Dock

Integrate your app with Pantheon's dock communicate to communicate its status to the user at a glance.

Barra di avanzamento

Make progress bars unambiguous by referring to a single, specific task. For example, use progress bars to indicate the status of lengthy processes like file transfers and encoding. Do not use progress bars to compound the progress of different types of action.

Bolle

A badge shows a count of actionable items managed by your app. Its purpose is to inform the user that there are items that require user attention or action without being obtrusive. This is a passive notification. A badge should not show totals or rarely changing counters. If the badge is not easily dismissed when the user views your app, it is likely that this is not a good use of a badge.

Indicatori di sistema

Gli indicatori sono piccole icone presenti nella parte alta del pannello. Danno la possibilità di posizionare un'indicazione rapida ad alcune impostazioni o eventi. Cliccando l'icona, viene mostrato un piccolo menù con alcune azioni disponibili per l'utente.

Does Your App Need an Indicator?

The indicator area is prone to clutter and inconsistent paradigms. Given that users will probably install many third-party apps, we must be careful about the number of indicators we show and how they behave. Keep in mind that only a very small set of applications need or benefit from an indicator. Avoid adding an indicator if:


See also: Farewell to the Notification Area by Matthew Paul Thomas

Widget contenitori

Finestre

Windows form the foundation of your app. They provide a canvas with basic, built-in actions such as "closing" and "resizing". Although users may see windows as being all the same, elementary OS has several distinct window types. It's important to understand the types of windows available to you, window behavior in general, and behavior that is specific to a certain window type. This section will cover the different types of windows available in elementary OS. Although each type of window is a bit different, think of them all as a subclass of a window. Unless otherwise stated, they all behave as an average window.

Titoli delle finestre

Quando gestisci i titoli delle finestre considera che il loro scopo primario è distinguere una di esse dalle altre. Un buon titolo dovrebbe fornire una descrizione che aiuti un utente effettuare la scelta. Ricorda di considerare i seguenti punti:

Finestre di dialogo

24
Dialog warning icon

Primary text providing basic information and a suggestion

Secondary text providing further details. Also includes information that explains any unobvious consequences of actions.

24
Cancella
Azione Consigliata

Messaggi di Avviso

Un avviso contiene sia testo primario che secondario.

The primary text contains a brief summary of the situation and offer a suggested action. This text should use the CSS class primary.

Il testo secondario fornisce una descrizione più dettagliata della situazione e descrive ogni possibile effetto delle azioni disponibili. È importante notare che un utente dovrebbe poter scegliere grazie al testo primario e dovrebbe riferirsi a quello secondario solo per chiarimento. Questo testo dovrebbe essere posizionato una riga sotto il testo primario, usando il carattere e la dimensione standard.

Rendi selezionabile sia il testo primario che quello secondario. Questo permette all'utente di fare copia-incolla del testo su un'altra finestra, come un messaggio e-mail.

Ordine dei pulsanti

"OK" non è Okay

When presenting a dialog to a user, always use explicit action names like "Save..." or "Shut Down". Consider how "OK" lets users proceed without understanding the action they are authorizing. Not all users will read the question or information presented to them in a dialog. Using specific action names will make it harder for a user to select an unintended action and may even encourage them to read the presented information before making a selection.

Finestra delle preferenze

Preference dialogs should be made Transient, but not Modal. When a user makes a change in a preference dialog, the change should be immediately visible in the UI. If the dialog is modal, the user may be blocked from seeing (and especially from interacting with) the change. This means they will have to close the dialog, evaluate the change, then possibly re-open the dialog. By making the dialog transient, we keep the dialog on top for easy access, but we also let the user evaluate and possibly revert the change without having to close and re-open the preference dialog.


Vedi anche:

  1. Why 'Ok' Buttons In Dialog Boxes Work Best On The Right di UX Movement
  2. Why The Ok Button Is No Longer Okay di UX Movement
  3. Should I use Yes/No or Ok/Cancel on my message box? su UX StackExchange
  4. Where to Place Icons Next to Button Labels di UX Movement

Popover

I popover sono contestuali. Mostrano del contenuto transitorio direttamente su qualcosa che viene cliccato e vengono chiusi quando si clicca da un'altra parte, come i menù.

Un popover dovrebbe essere usato quando un utente vuole svolgere un'azione rapida senza uscire dalla UI principale. Alcuni esempi di quando un popover potrebbe essere usato sono il contatto via e-mail, aggiungere un segnalibro nel browser o mostrare i download e i trasferimenti di file.

I popover non dovrebbero essere usati per mostrare una lista di oggetti, usa invece un menù. Inoltre, non usare un popover se l'utente spenderà più di alcuni secondi su di esso, usa una finestra di dialogo. Ricorda poi che i popover sono contestuali e dovrebbero essere direttamente collegati agli elementi della UI da cui sorgono.

Barre degli strumenti

A Toolbar is useful for providing users with quick access to an app's most used features. Besides Buttons, a Toolbar is one of the most frequently used UI elements. It may seem like a simple container, but it is important to remain consistent in its use and organization.

Ordinamento della Barra degli Strumenti

Gli oggetti più significativi devono sempre trovarsi sulla parte sinistra della Barra degli Strumenti e quelli meno significativi sulla destra, con il menù del programma sempre all'estrema destra della Barra. Se ci sono molti oggetti è importante dividerli in gruppi separati da alcune spaziature. Ricorda che, visualizzato con i linguaggi RTL, il layout della barra sarà capovolto.

Concetti sul Toolkit della UI

elementary OS uses consistent user interface (UI) elements to bring a unified and predictable experience to users, no matter what app they're using. When used properly, this ensures a small (or nonexistent) learning curve for your app.

Concetti sui Widget

Prima di approfondire tutti gli widget disponibili in elementary OS è necessario spiegare alcuni concetti base comuni a tutti i widget. Utilizzare questi concetti correttamente genera un'esperienza d'uso coerente per gli utenti e ti evita di spulciare i bug report!

Controlli che non fanno nulla

Un errore molto comune per gli sviluppatori è quello di creare controlli che apparentemente non fanno nulla. Ricorda che noi vogliamo fornire un ambiente dove gli utenti si trovino loro agio. Un utente il curioso interagirà con controlli dai quali si aspetta una reazione immediata. Quando un controllo non fa nulla, genera confusione e può essere spaventoso (Pensa "oh oh, non so cosa sia successo!"). In alcuni casi i controlli che non eseguono azioni sono confusionari e aggiungono complessità inutile alla UI.

Consider the "clear" button present in search fields. This button only appears when it is relevant and needed. Clicking this button when the field is already clear essentially does nothing.

Sensibilità

Sometimes it doesn't make sense for a user to interact with a widget until some pre-requisite is fulfilled. For example, It doesn't make sense to let a user click a browser's "Forward" button unless there is forward history available. In this case, you should make the "Forward" button insensitive or a user may click it, expecting a result, and be confused when nothing happens.

Di solito è meglio rendere un widget bloccato piuttosto che nasconderlo. Il widget bloccato informa l'utente che la funzionalità è disponibile, ma solo al verificarsi di certe condizioni. Nascondere il widget dà l'impressione che la funzionalità non sia disponibile oppure può portare l'utente a chiedersi perché quella funzionalità sia improvvisamente "scomparsa".

Widget Nascosti

Quando un widget ha senso solo in un certo contesto (e non come indicatore di un'azione da compiere) alcune volte è meglio nasconderlo. Si pensi ai requisiti hardware ad esempio: non avrebbe senso mostrare le opzioni multi-display se il sistema ha un solo display. Rendere le opzioni multi-display bloccate non sarebbe certamente utile. Un altro esempio di questa regola è un widget che verrà visto solo in un certo contesto, come il bottone "Clear" di esempio qui sopra. Ricorda che gli oggetti bloccati vengono inoltre riconosciuti dai lettori di schermo e dalle tecnologie di accessibilità, mentre quelli nascosti no.

Spaziatura

Allineamento


Vedi anche: Form Label Proximity: Right Aligned is Easier to Scan di UX Movement

Infobar

Una infobar fornisce informazioni contestuali, e possibili azioni, all'utente con vari livelli di importanza.

È importante determinare la severità di infobar da usare. Ce ne sono di quattro tipi:

Pagina di Benvenuto

La schermata di benvenuto è un modo amichevole per aiutare gli utenti ad iniziare ad usare la tua app.

Utilizzo

Tipicamente una schermata di benvenuto viene utilizzata per applicazioni come Noise o Scratch, dove devi importare o creare oggetti in una libreria prima di poter interagire con loro. Questo fornisce ai tuoi utenti un percorso chiaro per iniziare e mette subito in evidenza tutte le procedure che devono seguire prima che la vostra applicazione diventi utile.

If your app lets users clear its library, make sure that it returns to the Welcome Screen instead of an empty list.

Etichettamento

La schermata di benvenuto consiste di due insiemi di etichette:

Iconografia

Raggruppata con ogni azione c'è un'icona che permette di riconoscerla velocemente. La maggior parte delle volte sarà una "Action Icon", ma si possono usare "Places Icons" mentre si sta importando o impostando una posizione, oppure anche "Apps Icon" se si dovesse aprire uno strumento di configurazione.

Elenco risorse

Un elenco risorse può essere usato come una forma di navigazione di alto livello. Gli elenchi risorse sono utili per mostrare diverse località, segnalibri o categorie nella tua app.

Sezioni

A source list may be separated into different collapsible sections, each with its own heading. For example, a file manager might have a section for bookmarked locations, a section for storage devices attached to the computer, and a section for network locations. These sections help group related items in the source list and lets the user hide away sections they might not use.

Evita di nidificare le sezioni in un elenco risorse se possibile; se ti capita di volerlo fare, dovresti ripensare l'organizzazione delle sezioni.

Gerarchia

La gerarchia è importante negli elenchi risorse, sia nel widget stesso, sia nel quadro generale della tua app.

Le sezioni in un elenco risorse dovrebbero essere messe in ordine di importanza dalla più importante in alto alla meno importante in basso. Se hai difficoltà a decidere l'importanza di ogni sezione, pensa a quale sezione l'utente potrebbe usare di più. Ordinare le sezione fa sì che gli elementi più importanti siano sempre visibili anche se l'elenco è troppo corto per mostrare tutti gli elementi, anche se sono visibili scorrendo l'elenco.

Una lista sorgente va sul lato sinistro di una finestra (o destra per lingue da destra a sinistra). Poiché l'utente legge in questa direzione, la barra laterale è rinforzata prima (e quindi ad un livello superiore) del contenuto della app.

Pulsanti

I pulsanti sono un widget incredibilmente importante da capire in quanto la vostra applicazione ne conterrà sicuramente.

Pulsanti Strumento

Etichettamento

I pulsanti degli strumenti sono quasi sempre icone e non hanno un bordo del pulsante. Non dovrebbero avere un'etichetta.

Suggerimenti

Tutti i pulsanti strumento dovrebbero avere dei suggerimenti poiché non hanno un'etichetta. Questo aiuta a dare una spiegazione a un'icona sconosciuta dall'utente e anche gli utenti con disabilità. I suggerimenti andrebbero scritti con Lettere Maiuscole.

Come le etichette dei pulsanti testuali, il suggerimento dovrebbe descrivere chiaramente cosa accadrà quando il pulsante verrà premuto.

Pulsanti testuali

Etichettamento

Le etichette dei pulsanti testuali dovrebbero essere fatte in Title Case

Come le voci di menu, le etichette dei pulsanti testuali dovrebbero rappresentare una azione o una posizione ma non uno stato. Accertati che l'etichetta del pulsante descriva chiaramente cosa accadrà quando verrà premuto.

"Rimuovi Account", "Invia al portatile di Jim" e "Importa 20 Canzoni" sono delle buone etichette.

"OK", "Get more storage!", and "Low Battery" are not good button labels. The "Get more storage!" label has incorrect capitalization and unnecessary punctuation. The other two labels do not indicate what will happen as a result of clicking the button.

Suggerimenti

Visto che i pulsanti testuali hanno un'etichetta chiara ed esplicita, spesso non è necessario aggiungere un suggerimento.

Pulsanti collegati

Utilizzo

I pulsanti collegati vengono utilizzati per azioni di gruppo che sono o simili in natura o che si escludono a vicenda. Ad esempio, potrebbero raggruppare opzioni di testo come Grassetto, Corsivo e Sottolineato. Oppure possono essere utilizzati per raggruppare gli stati mutuamente esclusivi come Griglia, Elenco, o vista Colonna.

Etichettamento

I pulsanti collegati non dovrebbero mai contenere icone colorate. Usa solo icone con simboli da 16px OPPURE testo. Non mischiare mai testo e icone.


  1. Why The OK Button Is No Longer Okay di UX Movement
  2. Should I use Yes/No or Ok/Cancel on my message box? su UX StackExchange

AppMenu

Un AppMenu è un menu opzionale che viene aperto utilizzando l'icona a forma di ingranaggio sull'estrema destra della barra degli strumenti dell'applicazione. Fornisce degli elementi di menu rilevanti al posto delle tradizionali voci "File, Modifica, Visualizza" della barra del menu.

Utilizzo

Dovresti prima considerare se la tua applicazione necessita di questo widget. Anche se molte applicazioni ne hanno uno, la tua applicazione potrebbe non averne bisogno.

Quando aggiungi degli elementi al tuo AppMenu, tieni a mente che:

Campi di ricerca

Apps that support the searching or filtering of content should include a search field on the right side of the app's toolbar. This gives users a predictable place to see whether or not an app supports searching, and a consistent location from which to search. Gtk+ provides a convenient complex widget for this purpose called Gtk.SearchEntry.

Distinguere tra Cercare e Trovare

Search is for filtering the contents of a library, i.e. Music or Videos, to the matching items. Search is typically initiated when typing anywhere in a library view.

Find is for highlighting matching instances of a string, i.e. in a text editor, web page, or Terminal. It is triggered by a keyboard shortcut (Ctrl+F) or with a search icon. The find bar appears in a revealer below the headerbar with relevant actions such as find next, find previous, highlight all, etc. The revealer may also contain other relevant actions such as replace or go to line.

Comportamento

Se è possibile includere funzionalità di ricerca all'interno della vostra applicazione, è consigliabile farlo. Ogni lista o rappresentazione di più parti di dati dovrebbero essere ricercabili tramite un campo di ricerca che segua queste regole:

Etichettamento

I campi di ricerca dovrebbero contenere un testo di suggerimento che descriva quello che verrà cercato. È possibile impostare questo comportamento utilizzando la proprietà "placeholder_text".

La maggior parte dei campi di ricerca dovrebbero utilizzare il formato "Cerca OGGETTI" dove OGGETTI è qualcosa da cercare, come Contatti, Accounts, ecc.

Se il campo di ricerca interagisce con un servizio di ricerca, il testo del suggerimento dovrebbe essere il nome di questo servizio come "Google" o "Yahoo!"

Checkbox & Interruttori

Checkbox

Le checkbox consentono agli utenti di scegliere degli elementi da una lista.

Utilizzo

Usa le checkbox quando gli utenti devono selezionare degli elementi. Assicurati che un utente possa cambiare lo stato della checkbox cliccando sull'etichetta ad essa associata.

Etichettamento

Le etichette associate con le checkbox dovrebbero essere nomi o frasi nominali.

Interruttori

Gli interruttori presentano all'utente un modo di cambiare lo stato di alcune funzioni con stato "on/off".

Utilizzo

Non usare gli interruttori per includere degli elementi in una lista, per quello ci sono le checkbox. Pensa agli interruttori come a qualcosa che agisce su funzioni indipendenti e alle checkbox come a qualcosa che serve a includere degli elementi in una lista. È importante fare questa distinzione.

Osserva come l'opzione "Registra dal microfono" sia ottima per un interruttore. Stai attivando o disattivando la funzione di registrazione.

Se invece ci sono due opzioni "Registra i suoni di sistema" e "Registra dal microfono", stai avendo a che fare con una lista di elementi simili che fanno parte di una funzione di registrazione più grande(la quale può essere accesa o spenta in base agli elementi selezionati). In questo caso, una checkbox è più appropriata per denotare queste funzioni.

Etichettamento

Quando possibile, scrivi direttamente la funzione su cui stai agendo. Non usare parole che descrivono lo stato come "Abilita Multitouch", "Usa Multitouch", o "Disabilita Multitouch". Questo può creare confusione. Usa solo il nome e scrivi "Multitouch".


Vedi anche: 3 Modi di Rendere Checkbox e Pulsanti di Opzione più Facili da Cliccare di UX Movement

Blocchi note

Notebooks are a type of widget that lets apps show one of multiple pages (also colloquially referenced as "tab bars").

Notebooks Statici

Un blocco note statico è un piccolo insieme di schede non modificabili, mostrate solitamente nelle preferenze o nelle impostazioni. Le schede appaiono come pulsanti collegati e centrati in alto nella pagina del contenuto. Un blocco note statico dovrebbe contenere da due a cinque schede,

Notebooks Dinamici

Un blocco note dinamico è un modo per fornire delle schede gestibili dall'utente, come avviene nei browser web. Le schede appaiono collegate alla barra degli strumenti sopra il contenuto del blocco note. Le schede possono essere spostate e chiuse, mentre un pulsante "nuova scheda" si trova alla sinistra del widget blocco note.

Iconografia

L'iconografia è una parte fondamentale di elementary OS. Le icone rappresentano la maggior parte dell'interfaccia con cui l'autenticità avrà a che fare; sono loro che danno vita al sistema e catalizzano il potente sistema di ricognizione del cervello umano.

Forma

Le icone dovrebbero avere una forma/silhouette che stimoli il loro riconoscimento. La forma non dovrebbe essere troppo complessa, ma le icone non dovrebbero essere tutte dei rettangoli arrotondati.

Warning dialog iconIcona della ChatIcona di FotoIcona di VideoIcona degli Account OnlineIcona del Terminale

Metafore

Se stai creando un'icona per un hardware o un tipo di file (come quelle per MimeType o le icone dei dispositivi), le forme normalmente sono una rappresentazione visiva della controparte nel mondo reale. Per esempio, l'icona per una macchina fotografica è quella di una macchina fotografica stilizzata.

Icona di CameraIcona dell'Hard DiskIcona del MouseIcona del pacchettoIcona HTML TextIcona Computer

Action Icons

Le Action Icons sono usate per rappresentare azioni dell'utente comune, come " cancella" , "gioca" , o "salva " . Queste icone si trovano principalmente in barre degli strumenti delle applicazioni , ma si possono trovare in tutto il sistema operativo .

Icona PrecedenteProssima iconaIcona di esportazione dei documentiStampa iconaSalva iconaElimina iconaTaglia l'iconaCancella l'iconaIcona inversaPlay iconNuovo tag per l'iconaIcona del Menu

Se la tua applicazione usa una di queste azioni comuni, fai riferimento alla corrispondente icona invece che crearne una per conto tuo. Questo assicura un'esperienza utente coerente, che mira nel riconoscimento delle funzioni comuni da parte di quest'ultimo.

Se la tua applicazione possiede un'azione unica, potresti aver bisogno di crearne una per conto tuo. Quando lo fai, prova a seguire l'aspetto e l'effetto di icone già esistenti, ed includila assieme alla tua applicazione.

Dimensioni dell'icona

elementary OS utilizza sei principali dimensioni delle icone per tutto il sistema operativo ed è meglio includerle tutte e sei come parte della tua applicazione.

Icona del Terminale da 16 pixelIcona del Terminale da 24 pixelIcona del Terminale da 32 pixelIcona del Terminale da 48 pixelIcona del Terminale da 64 pixelIcona del Terminale da 128 pixel
16 24 32 48 64 128
Icona del Terminale da 128 pixel
128

Progetta ogni icona per la dimensione cui è destinata ad esser vista. In altre parole, non progettare un'icona per riempire le dimensioni rimanenti, il risultato migliore si ottiene quando ogni icona è progettata individuamente. Per ulteriori informazioni riguardo questa tecnica (chiamata "pixel-fitting") e la sua importanza, consigliamo di leggere Dustin Curtis' article, Pixel-fitting.

Palette dei colori

Color, don't be afraid to use it! Many of the elementary OS icons use vibrant colors; it's best to reserve muted tones and greys for boring system icons.

Icona di MailIcona del Lettore RSSIcona del Web BrowserIcona di FotoIcona della ReteIcona del Calendario

I colori hanno le loro connotazioni, quindi sii consapevole diq uesto quando li sceglierai. Ad esempio: rosso è solitamente associato con errore o "pericolo", ed arancione con degli avvisi. Tuttavia puoi usare le connotazioni di questi colori per far trasmettere alle icone un significato, come il verde per "vai".

Icone simboliche

Symbolic icons are common system icons, that symbolize files, devices, or directories and are also used to represent common actions like cut, copy, and save.

Each symbolic icon is a reduced form of its full-color counter part. This minimal design ensures readability and clarity even at small sizes.

Symbolic vs. colored icon

Colored vs. Symbolic Icons

The use of full-color and symbolic icons is not interchangeable, both have appropriate uses.

Full color icons are best used for:

Le icone simboliche sono le migliori usate:

Composizione

There are three aspects to note when designing an elementary OS icon:

Composition breakdown of elementary OS Videos icon Composition breakdown of elementary OS Terminal icon

Tenere in mente queste linee mentre progetti, significa che puoi posizionare gli elementi insieme, così che le icone appaiano più coerenti quando messe insieme. Ad esempio, nota come alcuni elementi, sia dell'icona terminale che video qui sopra, si relazionino alla linea media.

Misure Comuni

Se stai progettando un'icona di forma quadrata, come quello per il Terminale visto sopra, considera l'utilizzo di queste misurazioni comuni (in pixel) per ogni icona.

Grandezza Canvas Linea di base x-Altezza Altezza Linea Media
16x16 1 14 8
24x24 2 20 12
32x32 2 26 16
48x48 3 40 24
64x64 4 56 32
128x128 9 104 64

Eccezioni

Tuttavia esistono delle eccezioni. Molte icone (specialmente quelle "mimetype") hanno elementi ascendenti e discendenti, che rappresentano quegli elementi che si estendono oltre la linea di base e la linea x-altezza (mostrata qui in arancione.)

Composition exception example in elementary OS Video icon Composition exception example in elementary OS Terminal icon

I componenti arrotondati generalmente richiederanno un certo superamento per compensare l'illusione ottica che li fa apparire più piccoli delle loro controparti rettangolari.

Contorni e Contrasto

All elementary OS icons have a thin outline (stroke) to improve their contrast. The width of this stroke is one pixel for all icons, at every size. The color of the outline is a darker variant (30% darker) of the primary color of the icon. For instance, in the calendar icon below, the green header has a stroke of a darker green.

Example of contrast in elementary OS Calendar icon Example of contrast in elementary Settings icon

Per migliorare ulteriormente il contrasto, i tratti sono anche semi trasparenti. Questo assicura che le icone appaiano nitide rispetto ad una varietà di sfondi. Inoltre, se l'elemento è tendente al bianco, questo tratto si comporta come un bordo e contiene, invece di sovrapporsi, il corrispondente elemento. Vedi l'icona sopra per un esempio di questo.

Ombre e Luci

If you picture an icon sitting on a shelf, facing you, with a light source above it, you may see a small fuzzy shadow near the bottom. Also, since the edges of an object tends to reflect more light due to your position relative to it and to the light source, they will have a highlight. Both these effects are something elementary OS icons emulate in their design to lend them a degree of realism.

Bordo Evidenziato

Per applicare l'effetto di evidenziazione bordi alla tua icona, disegna un tratto interno sottile 1 pixel. Questo contorno risulta leggermente più brillante nella parte superiore ed inferiore di quanto lo sia nei bordi.

Edge highlight example in elementary OS Music icon

Ombra

Per tracciare l'ombra, partirai disegnando un rettangolo. Quindi riempilo con un gradiente lineare che è perpendicolare al margine inferiore dell'icona. Il gradiente ha tre stop, di cui il primo e l'ultimo hanno un'opacità pari a zero. Infine l'intera forma ha il 60% di opacità.

Successivamente crea due rettangoli più piccoli per agire da "fermalibri" sul più largo. Riempi ognuno di essi con un gradiente identico al primo, ma rendilo radiale. Centra il gradiente radiale nel centro di un lato corto con ogni stop direttamente verso il bordo più vicino - vedi sotto per un esempio. Anche questi rettangoli sono settati sul 60% di opacità.

L'ombra del pittogramma

Se la tua icona ha un pittogramma, come ad esempio il triangolo che simboleggia il "play" nell'icona qui sotto, puoi donargli un'ombra per farlo stagliare rispetto allo sfondo sottostante.

Per fare questo, prima copia il pittogramma, riempilo con un colore nero solido, e setta un 15% di opacità. Poi, spostati di 1 pixel sotto, e piazzalo sotto il pittogramma. Crea una copia di quest'ombra, e donagli 1 pixel di tratto (anch'esso nero) ed impostale un7% di opacità.

Materiali iconografici

Sei libero di aggiungere brillantezza (extra rilievo) alle tue icone, ma questa risulta una buona idea solamente se si sta emulando una superficie più riflettente nella vita reale (come plastica, vetro, ecc.). Per esempio, un foglio di carta non è lucido, pertanto un'icona che sta emulando la carta, non sarà lucida.

Cosa fare e cosa no

Sotto ci sono alcuni esempi "fare e non fare" da considerare quando crei le icone per la tua applicazione.

Testo

Although elementary OS primarily uses graphics as a means of interaction, text is also widely used for things like button labels, tooltips, menu items, dialog messages, and more. Using text consistently and clearly both in terminology and format is an extremely important part of designing your app and helps add to the overall cohesiveness of the elementary OS platform.

Stile di scrittura

Usa le seguenti regole per mantenere il testo comprensibile e coerente:

Sii sintetico

Non dare all'utente troppo testo da leggere; una frase lunga può apparire scoraggiante e può dissuadere gli utenti dal leggere realmente i tuoi messaggi. Usa testo breve e conciso.

Pensa semplice

Assumi che l'utente sia intelligente, ma non tecnico. Evita parole lunghe, non comuni e concentrati sull'uso di verbi, sostantivi e aggettivi semplici e di uso comune. Non usare mai gergo tecnico.

Arriva al punto

Metti le informazioni più importanti all'inizio del testo. Se l'utente smette di leggere, avrà ancora in mente ciò di cui ha bisogno.

Non ripeterti

Le ripetizioni possono risultare fastidiose e aggiungono lunghezza inutile ai tuoi messaggi.

Usa la Gerarchia Visuale

La gerarchia visiva aiuta gli utenti a leggere e comprendere il tuo testo oltre a riconoscere ciò che è più importante. Usa intestazioni e gli altri stili di testo in modo appropriato.

Lingua

While much of elementary OS is developed in English, there are many users who do not know English or prefer their native language. While putting text into your app, keep the following in mind:

Uso delle maiuscole

Tutti gli elementi testuali delle interfacce utente, compresi menu, pulsanti e etichette, dovrebbero usare uno di questi due schemi per le maiuscole: sentence case o title case.

Sentence Case

in Sentence Case si usano le maiuscole come in una frase normale.

Solo la prima lettera della frase e la prima lettera dei nomi propri sono in maiuscolo. Usato per etichette e testi descrittivi.

Title Case

In Title Case si usano le maiuscole come nel titolo di un libro o di un articolo.

La prima e l'ultima parola iniziano con lettera maiuscola. Tutti i sostantivi, pronomi, aggettivi, verbi, avverbi e congiunzioni subordinate (poiché, perché, sebbene) iniziano con lettera maiuscola. Usato per titoli, pulsanti, menu, e la maggior parte degli altri widgets.

Note/Eccezioni

I nomi propri dovrebbero sempre utilizzare le maiuscole correttamente; questo significa che, ad esempio, Google dovrebbe sempre essere indicato come "Google", elementary dovrebbe essere sempre indicato come "elementary", e MPEG dovrebbe essere sempre indicato come "MPEG". Se non si è sicuri dell'utilizzo ufficiale delle maiuscole per un certo pronome, consultare la documentazione del pronome in questione.

Punteggiatura

L'utilizzo di una adeguata tipografia è importante in ogni parte di elementary OS. Non solo per la coerenza con il sistema operativo, ma anche per seguire la corretta convenzione e presentarci come una piattaforma seria e professionale.

Evita errori comuni

Trattini & Lineette

Trattino (-)

Usa \u2010 nel codice. Utilizzato per:

En Dash (–)

Usa \u2013 nel codice. Utilizzato per:

Em Dash (—)

Usa \u2014 nel codice. Utilizzato per:


Se hai dei dubbi, leggi Butterwick's Practical Typography.

Queste regole si applicano per l'Inglese; altre lingue potrebbero avere le proprie conversioni che dovrebbero essere seguite dai traduttori.

Utilizzo dei Puntini di Sospensione

I puntini di sospensione (…) sono usati nell'interfaccia per due motivi principali: informare l'utente che è richiesta un'informazione aggiuntiva e far capire all'utente che il testo è stato accorciato.

Informazioni Aggiuntive

I puntini di sospensione dovrebbero essere usati per far capire all'utente che altre informazioni sono necessarie o che un'azione da parte sua è necessaria per continuare. Di solito questo vuol dire che l'utente si aspetta che appaia un nuovo elemento dell'interfaccia tipo una nuova finestra, dialogo, barra degli strumenti ecc. nel quale dovranno inserire delle informazioni o fare una scelta prima di compiere l'azione desiderata. Questa è una distinzione importante perché l'utente si dovrebbe aspettare un'azione istantanea dai pulsanti e dagli elementi del menù, mentre i puntini di sospensione lo preparano ad un comportamento diverso. In particolare, i puntini dovrebbero essere usati quando l'azione associata:

Testo Accorciato

Ellipses should be used when shortening text that cannot fit in any specific place. For example, if a playlist's name is longer than the space available in the sidebar, truncate it and use an ellipsis to signify its truncation. There are two ways to use an ellipsis when shortening text:

Se non sei sicuro, è meglio tagliare in mezzo perché mantiene intatto sia l'inizio che la fine del testo. È anche importante non creare le app con del testo tagliato. Questo deve esserci solo a causa dell'utente, se ridimensiona una barra laterale o inserisce del testo.

Quando non usare i puntini di sospensione


Accertati di usare il carattere dei puntini di sospensione (…) invece di tre punti (.) consecutivi.

Nomi delle voci di menu

Le voci di menu dovrebbero avere nomi che siano azioni o posizioni, mai descrizioni. Assicurarsi che le voci di menu siano concise, ma che descrivano anche pienamente l'azione che verrà eseguita una volta cliccate.

"Trova nella Pagina..." è accettabile dato che descrive chiaramente quale azione verrà eseguita quando il tasto sarà cliccato. "Il Software è Aggiornato" non è accettabile. Cosa accade quando viene cliccato? Dove mi porterà? Cosa farà? Il risultato è incerto.