7

Recentemente ho giocato con php-gtk e in passato ho sperimentato con Java per realizzare app 'hello world' della GUI.Da dove viene realisticamente la lucentezza professionale di un'applicazione GUI?

Tuttavia entrambi questi tipi di applicazioni hanno avuto un aspetto un po 'goffo (quasi infantile). Non posso negare che sono a portata di mano per creare app per uso interno (e rispetto totalmente la quantità di impegno della comunità che si inserisce in questi progetti). Ma non sarei necessariamente orgoglioso di venderlo come applicazione commerciale con un prezzo di, ad esempio, £ 450 o £ 1,000.

Se volevo creare un'applicazione che avesse l'aspetto e l'aspetto di, ad esempio, Firefox per Windows o Adobe xyz, quale GUI/lingua dovrei usare?

È la "lucentezza professionale" o il look intelligente e si sentono al 100% verso i progettisti o è il caso che, a prescindere da quanto sia bravo un progettista, scegliere la struttura della GUI corretta è essenziale per ottenere quello sguardo?

+0

grazie per tutte queste risposte - tutte cose davvero utili –

risposta

7

Ci sono alcuni aspetti di avere un UX lucido per un pezzo di software.

  1. Utilizzo del framework nativo per la piattaforma. Win32/WPF per Windows, Cocoa per Mac ecc
  2. artefatti visivi di applicazione sono coerenti - questo include immagini, la grafica, le icone della barra degli strumenti ecc
  3. Seguendo le linee guida piattaforme e best practice.
3

Provare sempre a utilizzare il framework GUI utilizzato dall'ambiente desktop. Le librerie di .NET sono probabilmente le migliori per creare app per Windows. GTK + è sempre il migliore su GNOME, mentre Qt funziona bene su KDE - anche se tutti e tre lavorano sui rispettivi sistemi, il loro appeal visivo diminuisce con la loro mancanza di integrazione visiva.

+1

Assolutamente giusto. Usa l'aspetto nativo per la tua piattaforma. Le app Java su Windows hanno sempre un aspetto orribile (si pensi a Lotus Notes). Usa .Net per Windows (supponendo che tu voglia usare un linguaggio gestito). – jwismar

+0

Vorrei notare che anche la pura Qt non si integra perfettamente con KDE - almeno sui miei computer, c'è una differenza notevole tra le interfacce basate sulle librerie Qt e quelle basate sulle librerie UI di KDE. Anche se è un po 'oltre il punto della domanda ... –

+1

Le note di Lotus sono state originariamente scritte in assembly ... che è la _definizione_ di nativo. –

1

Non mi interessa il modo in cui le GUI dell'applicazione Java tendono ad apparire con i soliti toolkit. Se ti piace il modo in cui guarda Firefox, potresti guardare in XUL e nella struttura della GUI condivisa dalla maggior parte delle applicazioni Mozilla. Komodo Editor/IDE usa gli stessi strumenti (insieme a molte altre applicazioni). GTK è molto potente e dubito fortemente che ciò che impedisce alle tue applicazioni di avere quella lucentezza professionale. Continua a esplorare le sue funzionalità e ripensa il modo migliore per visualizzare i tuoi componenti, e sono sicuro che incapperai in un accordo che ti fa sentire meglio.

D'altra parte, non è tutto sul toolkit. Il buon design dell'interfaccia è un'arte e interfacce come Firefox si sono evolute attraverso una quantità infinita di feedback. La cosa migliore da fare è parlare con gli utenti e scoprire cosa li renderà più a loro agio usando la tua applicazione. Ho trovato che il software tende a guardare bene quando è anche funzionale.

Consiglierei di spendere molto tempo nel software che trovi piacevole da usare. Prendi nota di come sono fatte le cose e cerca elementi comuni tra gli elementi dell'interfaccia. La maggior parte dei software si attiene a una serie di principi piuttosto comune che facilitano l'uso del software e più esplori il software che trovi attraente, più presto inizieranno a emergere modelli.

Buona fortuna!

+0

grazie per la risposta. Ri: "Prendi nota di come sono fatte le cose" - ha. Sì, ho iniziato a vedere le mie vecchie e fidate applicazioni in una nuova luce - le mie pinze di schermo hanno sempre annotato le altezze e le larghezze ridimensionate minime e le sfumature del telaio e tutti i tipi ... è tutto molto distratto; o) –

3

L'API GUI/lingua utilizzata è assolutamente irrilevante per la progettazione dell'interfaccia utente, sebbene alcune API rendano più facile o più veloce l'implementazione.

buona interfaccia utente è di circa:

  • buon design grafico/opera d'arte (equilibrio visivo e simmetria, colori complementari, visivamente forme 'piacevoli' e layout, la coerenza visiva all'interno della vostra app e con le altre applicazioni intorno ad esso - posizionamento coerente, dimensioni, spazi vuoti, colori, ecc.)
  • Comprendere i flussi di lavoro dell'utente e rendere semplice e intuitivo ciò che vogliono. Ciò significa spesso implementare 3 o 4 modi per ottenere la stessa azione (ad esempio, "Copia e incolla" può essere normalmente ottenuto da: menu principale-> copia/incolla, menu contestuale-> copia/incolla, ctrl + c/v, pulsante: copia/incolla, trascina e rilascia)
  • Mantenere tutto semplice. Rimuovi il più possibile per ridimensionare l'interfaccia utente in base alle esigenze dell'utente e non più.
  • Essere intuitivo e non sorprendere l'utente. I controlli dovrebbero assomigliare ai controlli che l'utente conosce, funzionare come i controlli che l'utente conosce e trovarsi nei luoghi che un utente si aspetta data la loro precedente esperienza con il computer.
  • Seguendo le convenzioni (pulsanti posizione OK/Cancel nei percorsi standard, utilizzare i colori del sistema operativo definiti per evidenziare gli oggetti selezionati, ecc)

Per ottenere questo, è necessario guardare a un sacco di applicazioni "buoni" e sezionare ciò che li rende buoni. Ottieni un buon artista/grafico per disegnarti buone icone, ecc. Passa molto tempo a pensare ai flussi di lavoro dell'utente.

Assicurati di separare la logica di business dall'interfaccia utente - questo ti permetterà di ridigitare facilmente l'app per migliorare l'interfaccia utente. E di solito i dati di cui il programma ha bisogno non sono legati al modo in cui l'utente ha bisogno di usare l'applicazione - non essere tentato di esporre le tue variabili x, y, z in campi modificabili! L'interfaccia utente è il livello che nasconde la tua implementazione e la rende utilizzabile!

4

E 'un po' di sovrapposizione con la risposta di Igor, ma qui è il mio prendere:

nativo di controllo Guardate - controlli dell'interfaccia utente oggi hanno un aspetto piuttosto complesso. Ci sono molti segnali visivi che derivano istintivamente da loro, e anche se è un rettangolo bianco con qualche cornice, con l'ombra di Wong sembra stranamente fuori posto. Un menu di contesto spesso non basta aprire oggi, scorre da qualche direzione, o si dissolve in

Native Controllo del comportamento - Ancora più complesso di interfaccia utente, c'è un sacco di dettagli al comportamento:. Diversi menu contestuali a seconda sulla posizione di scatto, diverse aree "calde" durante la selezione o trascinando gli elementi, le scorciatoie da tastiera, ecc

L'attenzione ai dettagli - C'è un sacco di comportamento dell'interfaccia utente coerente per scoprire su qualsiasi piattaforma. Proprio come i tasti freccia funzionano in un controllo ad albero WRT selezionando, aprendo e chiudendo nodi.

Basta guardare di Windows: La maggior parte dei toolkit non nativi ottenere la base sbagliata navigazione da tastiera - i tasti freccia, Home, Fine, Pag e PgDown, comportamenti modificati con Ctrl, estendendo la selezione con Shift offre fino a 32 comportamenti. Copia & La pasta è tradizionalmente con Ctrl + C/Ctrl + X/Ctrl + V e MAIUSC + INS, MAIUSC + CANC e mancante. Il doppio clic del mouse seleziona spesso una parola, il clic triplo del mouse a volte una frase, una linea o un paragrafo.

tempo di risposta e Muscle memoria - Ci sono, fondamentalmente, due modi di funzionamento dell'interfaccia utente:

atto-look ciclo, dove si attende per la risposta prima di decidere il passo successivo,
riproduzione da memoria muscolare, che è molto più veloce e richiede meno risorse per l'elaborazione mentale.

Ci sono, tuttavia, due requisiti per questo: la risposta deve essere omogeneo e "istantanea", e l'azione successiva devono essere registrati in modo corretto immediatamente (almeno entro 10 ms)

Abbastanza spesso, con i non-native toolkit, questo diventa difficile dalla risposta in ritardo rispetto a una o due azioni (la mente blocca la discrepanza) e dai toolkit che richiedono 50 o più volte per mostrare un menu, nel qual caso un clic non viene registrato come previsto.

Un lucido UI prende a lungo per ottenere il diritto - Una libreria di controllo buon grado di risolvere la maggior parte dei problemi per-controllo, ma c'è qualche finale del 10% prendendo il 90% del tempo, e si dispone di interazioni di controllo. Devi provare approcci diversi, devi aspettarti utenti con riflessi allenati da FPS, devi provare tutti i tipi di flussi di lavoro.

toolkit multipiattaforma non possono farlo perfettamente ragione - sono bloccati tra l'incudine e il martello: Essi possono optare per coerenza interna indipendente dalla piattaforma, o di essere in linea con la piattaforma che attualmente girano. Per farlo bene, quest'ultimo spesso richiede codice dipendente dalla piattaforma nel codice chiamante, la cosa reale che stai cercando di evitare.