Návrh uživatelského rozhraní v desktopových aplikacích

Ondřej Linhart       20.12.2011       C#, VB.NET, WinForms, .NET       16457 zobrazení

Doporučené postupy a běžné praktiky při vytváření uživatelského rozhraní desktopových aplikací převážně ve Windows Forms.

Uživatelské rozhraní (dále jen UI) je součást téměř každé desktopové aplikace a je to první věc, kterou uživatelé uvidí a se kterou budou neustále přicházet do styku (samozřejmě za předpokladu, že ji budou používat). Proto je třeba velmi pečlivě dbát na to, aby toto UI bylo co nejlepší, konkrétně: Aby se snadno ovládalo, aby úkony, které chce uživatel provést, se daly udělat co nejefektivněji, aby bylo intuitivní a z estetického hlediska přijatelné. U složitějších aplikací by mělo být přizpůsobitelné potřebám uživatele (např. přizpůsobitelný panel nástrojů).

Tento článek je psán na základě Windows Forms, ale obecné koncepty jsou použitelné i ve Windows Presentation Foundation, nebo jiných UI knihovnách (Qt, Swing). UI aplikací pro mobilní zařízení se řídí stejnými pravidly, ale musí být přizpůsobeno pro dané zařízení. Tedy pokud se plánuje i mobilní verze nějaké aplikace, mělo by se UI kompletně přepsat, nikoliv se snažit portovat z desktopové verze pro ulehčení práce, to lze jen u aplikační logiky. Uživatelské rozhraní webových a hybridních aplikací zde řešeno nebude, neb s tímto nemám zkušenosti.

Postup při návrhu

Při návrhu UI se většinou postupuje podle níže uvedených kroků, z nichž v závislosti na míře komplexnosti aplikace jsou některé důležitější více, některé méně a některé se nemusí realizovat vůbec. Ve velkých softwarových firmách jsou designéři specializovaní na tvorbu UI, ale v malých firmách nebo v jediné osobě toto musí zajišťovat sám vývojář, což není ideální, protože ten se obvykle soustřeďuje na funkčnost a optimalizace a postrádá grafické cítění nutné pro návrh profesionálního UI.

Získávání informací

Nejprve je dobré sestavit seznam funkcí, které budou potřeba k realizaci účelu aplikace a dalších potenciálních požadavků uživatelů. V tomto kroku si pokládáme následující otázky:

  • Co chceme, aby aplikace dělala?
  • Jaké podobné aplikace uživatel používá (nebo jaké už existují) a jaké s nimi má zkušenosti?
  • Jak ovlivňuje vzhled UI uživatele?
  • Očekává se rozšiřování aplikace zasahující i do uživatelského rozhraní?

Vytvoření prototypu UI

Na základě informací získaných v předchozím kroku můžeme vytvořit prototyp UI. U tohoto prototypu je třeba dbát na funkčnost a použitelnost, estetickou stránku lze zatím vynechat. Po dokončení se prototyp nechá testovat skutečným uživatelem (pokud se jedná o malou aplikaci, uživatele obvykle nahrazuje sám vývojář). Praktikuje se metoda “přemýšlení nahlas”, což znamená že uživatel skutečně říká jak ho napadlo dospět k určitému kroku, který by měl vést ke splnění určité úlohy. Na základě toho se dá UI lépe přizpůsobit.

Základní požadavky profesionálního UI

Vysoká vypovídací hodnota je důležitá k tomu, aby uživatel měl vždy jasnou představu o tom, jaký vliv budou mít prováděné kroky na výsledek práce. K tomuto patří například různé náhledy, popis částí UI ve smyslu jejich vlivu na výsledek práce, nebo funkční kontextová nápověda.

Splnění očekávání uživatele zahrnuje především ukládání všemožných uživatelských nastavení od šířek sloupců, přes pamatování naposledy zadávaných hodnot až po jazyková nastavení. Patří sem i populární klávesové zkratky (Ctrl+A pro výběr všech objektů, F1 pro nápovědu, atd.) a kontextové nabídky.

Tolerance vůči chybám (“blbuvzdornost”), kde je snaha co nejvíce zabránit zadávání neplatných hodnot volbou vhodných ovládacích prvků. Když už se nějaká chyba ve vstupu dat ze strany uživatele vyskytne, měl by na ni uživatel být upozorněn co nejdříve a co nejméně obtěžujícím a interakci vyžadujícím způsobem (nejvhodnější jsou bublinové zprávy).

Globalizace, kde program zobrazuje data v souladu s místním nastavením systému, nikoliv v napevno definovaném formátu a také třídění a porovnávání textových řetězců (například CH se v české kultuře bere jako další písmeno za H, kdežto v anglické jako dvě písmena C a H, což má vliv na řazení v seznamech).

Vhodnost použití ovládacích prvků

Data Vhodné ovládací prvky Nevhodné ovládací prvky
Číslo (celé nebo desetinné) NumericUpDown TextBox
Datum DateTimePicker TextBox
Celé číslo v rozsahu NumericUpDown
TrackBar
TextBox
HScrollBar
Měna MaskedTextBox TextBox
Výběr jedné z možností RadioButton
ComboBox
ListBox
Zobrazení výsledné hodnoty nebo důležitého údaje
Label + TextBox (ReadOnly = True)

Label
Provedení nějaké akce v daném kontextu
LinkLabel

Button
     
     

Zarovnávání a rozložení ovládacích prvků a jejich obsahu

Existují dva způsoby jak zarovnávat související ovládací prvky. První z nich je zarovnávat k sobě, druhý je zarovnávat do sloupců (používá Microsoft). Druhý způsob se mi nelíbí, protože je potom nutné vizuálně dohledávat co k čemu patří. Ukázka obou způsobů je na obrázku:

Nastavení zarovnání ovládacích prvků vzhledem k sobě je dobré ponechat ve výchozím nastavení návrháře Windows Forms, tedy SnapLines a 8, 8. Potom stačí vizuálně tahat prvky po formuláři a držet se naváděcích čar. Zde má Windows Forms oproti WPF obrovskou převahu (vše je rozvrhováno vizuálně, nikoliv XAML kódem podobně jako v HTML).

Zarovnávejte vždy nižší ovládací prvek k vyššímu na střed (viz. fialová čára), nejčastěji je to v případě popisků a nějakého vstupního ovládacího prvku.

Zarovnávání textového obsahu se řídí stejnými pravidly jako běžné psaní – text a datumy vlevo, čísla vpravo. Naprosto katastrofální zlozvyk některých vývojářů je zarovnávat libovolný text na střed – v žádném případě nedělat.

Při lokalizaci aplikace do cizích jazyků se občas nevyhnete tomu, že cizojazyčný text je kratší nebo delší než původní text v neutrální kultuře a proto je nutné posunout ovládací prvky v dané kultuře. V praxi se mi osvědčilo vše vytvořit nejprve v neutrální kultuře a až nakonec lokalizovat pomocí nástroje Windows Resource Localization Editor (součást Windows SDK), kde jdou prvky i přesunovat.

TabIndex a akcelerátory

TabIndex je v podstatě pořadí, v jakém bude vybrán ovládací prvek při přepínání klávesou Tab(+Shift). Pořadí přepínání je důležité (spousta uživatelů ještě pořád používá jenom klávesnici) a musí být logické (je nesmysl aby výběr přeskakoval zcela náhodně v pořadí, v jakém jste prvky na formulář naházeli). Zde bych rád vyzdvihnul vynikající doplněk TabIndex Assistant ze sady MZ-Tools, který nějakým magickým způsobem (pravděpodobně podle pozice prvků na formuláři) dokáže přiřadit TabIndexy přesně tak, jak je potřeba.

Akcelerátory jsou klávesové zkratky Alt+{písmeno}, které vyberou požadovaný ovládací prvek na jediný stisk klávesy. Po stisknutí klávesy Alt se obvykle příslušné písmeno v popisku podtrhne. Důležité je brát ohled na to, aby nebylo více stejných akcelerátorů na jednom formuláři a aby akcelerátory byly pokud možno stejné jako v běžných aplikacích (Soubor Úpravy Nápověda)

Nežádoucí efekt vzniklý jiným nastavením DPI než na vývojářském systému

Drtivá většina uživatelů má v systému ponecháno standardní nastavení DPI – 96. Pokud ale spustíte vaší Windows Forms aplikaci na počítači s jiným nastavením DPI, nastává problém s rozmístěním ovládacích prvků, některé dokonce nemusí být vidět vůbec. Zde žehnám WPF, kde je to dokonale vyřešeno pomocí jednotek Device Independent Pixels místo pixelů a k těmto nežádoucím efektům nedochází.

Ribbon – ano nebo ne?

Ribbon – nový typ panelu nástrojů vyvinutý Microsoftem údajně podle statistiky způsobu používání UI. Tento panel nástrojů má své počátky už někdy kolem roku 1995, kdy se jeho obdoba poprvé objevila v aplikacích Borland Delphi a Allaire HomeSite.

O ribbonu většinou od uživatelů slyším, že je to “pás sraček” a já sám z něho mám rozporuplné pocity. Někam se hodí, ale někam zase vůbec ne. Jeho největší slabinou je téměř nulová možnost uživatelského přizpůsobení na rozdíl od klasického panelu nástrojů, který jde plně přizpůsobit potřebám a preferencím uživatele. Ribbon se hodí do aplikací, kde je hodně funkcí (Office), ale ne zase tolik, aby citelně chyběla možnost přizpůsobení včetně vytváření vlastních panelů nástrojů (Visual Studio, AutoCAD). Co jsem se z různých zdrojů dočetl by ribbonu mělo být plné Windows 8 včetně tak primitivních věcí jako je Průzkumník, kde je plus mínus pět funkcí a to je přesně ten případ, kdy se ribbon naprosto nehodí.

Závěr

Tvorba UI rozhodně není primitivní záležitost, kterou je možné odbývat, ale celkem komplexní záležitost která spadá do zcela vlastní kategorie vývoje software. A samozřejmě jako obvykle čím více aplikací napíšete, tím více získáte zkušeností v tomto oboru.

Použitelnost a ergonomii UI definuje standard ISO 9241.
Doporučené postupy pro pojmenovávání a překlad prvků UI do češtiny jsou v dokumentu Czech Style Guide.
Podrobná příručka od Microsoftu zabývající se návrhem UI je ke stažení zde.

 

hodnocení článku

1 bodů / 1 hlasů       Hodnotit mohou jen registrované uživatelé.

 

Mohlo by vás také zajímat

Genericita, rozhraní a dědičnost

Jazyk C# je multiparadigmatický, což v praxi znamená, že v něm můžeme dělat hodně věcí. Jak ale do sebe jednotlivá paradigma zapadají? Co se hezky doplňuje a co není vzájemně kompatibilní? V tomto článku chci popsat, jak se chová IEquatable vzhledem k dědičnosti typu T.

Windows 10 GameJam: konference a herní hackathon

Co čeká webové vývojáře na platformě .NET, představení .NET Core 1.0

 

 

Nový příspěvek

 

Diskuse: Návrh uživatelského rozhraní v desktopových aplikacích

Děkuji autorovi, že mi potvrdil o ribbonech to, co si o nich myslím i já...

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Diskuse: Návrh uživatelského rozhraní v desktopových aplikacích

To je sice pěkné že nám zde výkládáš něco o ribbonu. Jak ho ale dostat do vlastních aplikací?

nahlásit spamnahlásit spam -1 / 1 odpovědětodpovědět

Za prvé mi netykejte a za druhé jak udělat Ribbon nebylo předmětem článku. Pro Windows Forms na to existuje spousta zdarma dostupných komponent, které jsem zde už několikrát zmiňoval.

nahlásit spamnahlásit spam 1 / 1 odpovědětodpovědět

Diskuse: Návrh uživatelského rozhraní v desktopových aplikacích

... ve Windows forms? Máte někdo tipy? Já se s tím stále nemůžu nějak popasovat, sám mám 96 dpi, zákazníci pak typicky větší písma a vypadá to hrozně ;-(

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Bohužel řešit to efektivně je tak pracné, že je lepší to neřešit.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Koukám, že řešíte stejnej problém (viz mé příspěvky tady: http://www.vbnet.cz/forum-tema--5278-vyt... a tady: http://www.vbnet.cz/forum-tema--4861-dpi... ).

Já bohužel na odpověď nepřišel :( Nicméně je tento problém stále častější s používáním (nejen) malých notebooků s velkým rozlišením displeje.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

No, bude to fuška, ale možno by pomohlo zvlášť nadesignovať UI na niekoľko najbežnejších DPI a dať možnosť výberu.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Zcela zbytečná práce a hloupost, kterou nikdo dělat nebude. To už je lepší do minimálních požadavků aplikace připsat nutnost 96 DPI.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

A co takto k tomu použít patřičné prvky které winforms nabízí? Formulář má na to vlastnost AutoScaleMode.

A nejlepší způsob je dávání ovládacích prvků do layout manažeru, ve winforms jsou v základu k dispozici dva a to FlowLayoutPanel a TableLayoutPanel. Uděláte si "mřížku" v layoutu a pak do jednotlivých buněk vložíte ovládací prvky (co políčko jeden prvek). Prvky jdou roztáhnout přes více sloupců nebo řádků pomocí ColumnSpan a RowSpan. Funguje to v podstatě podobně jako ve WPF, ale ve WPF je to mnohem vychytanější.

Jelínek Petr

www.jelineksoft.net

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Vím o co jde a používám to, ale ne vždy se to hodí. AutoScaleMode jsem přiznám se ještě nikdy nepoužil, ale nevěřím, že by to mělo nějaký valný výsledek.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Len by som chcel podotknut, ze WPF ma toto velmi elegantne vyriesene, takze ked sa budete rozhodovat pre dalsi projekt, berte aj toto do uvahy.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Vzhledem k tomu, že většina uživatelů používá standardních 96 DPI, tak má toto při rozhodování mezi WF/WPF velmi malou váhu.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Diskuse: Návrh uživatelského rozhraní v desktopových aplikacích

Nenadával bych tolik na ribbon, z hlediska customizovatelnosti je na tom v podstatě stejně jako klasický toolbar, minimálně třeba v Outlooku si jde nadefinovat vlastní taby, skupiny a tlačítka - je pravda, že vytvoření pěkného customizovatelného ribbonu dá (vývojářsky) víc práce (ale ne o moc, třeba MFC už customizační dialogy obsahuje v sobě).

Ohledně zarovnávání prvků do sloupců - divím se, že vám to zákaznící trpí, podle mých zkušeností aktivně na nezarovnání upozorňují a chtějí ho odstranit, chtějí mít prostě všechno ve sloupečcích i za cenu, že mezi labelem a controlem bude mezera.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Z hlediska uživatelského přizpůsobení je na tom ribbon tak špatně, že s klasickým panelem nástrojů ho vůbec nelze srovnávat. Viz. aplikace sady Office, kde jediné přizpůsobení zpočívá v možnosti umístění miniaturních 16x16 ikonek do horní části. Porovnejte například s možnostmi přizpůsobení klasických panelů nástrojů ve VS. Zákazníci jsou spokojeni s aplikacemi, které se dobře ovládají a jsou přehledné, což ty moje splňují. Sloupcové zarovnávání nepoužívám z výše uvedeného důvodu horší orientace. Pokud je z nějakého vážného důvodu potřeba sloupcové uspořádání, použiju TableLayoutPanel nebo jiné ovládací prvky.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Právěže v Office 2010 už jde obsah Ribbonu customizovat kompletně, to jen v první verzi to nešlo.

nahlásit spamnahlásit spam 1 / 1 odpovědětodpovědět

Tak to jsem nějak přehlédl, budu muset vyzkoušet (momentálně to ani nemám nainstalované, používám LibreOffice). Ve 2007 to ale zcela jistě nešlo.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

V 2007 to opravdu nešlo.

Na druhou stranu někde jsem četl, že do 2010 to udělali a stejně to používá méně než 0,5% uživatelů. Většina lidí, kteří si vůbec panel přizpůsobují, si na něj vytáhne pár oblíbených příkazů a tím to hasne.

Já jsem to hodně používal ve starých Office, protože tam bylo všechno zahrabané v několika úrovních menu. U nových jsem nepřesouval nic - ne proto, že by to nešlo, ale prostě jsem to nepotřeboval. Důležité příkazy jsou na velkých ikonách, méně důležité na malých, vše, co používám, v Ribbonu je.

Je to jen o zvyku a když je Ribbon dobře navržen (což v Office je), tak se to používá snadno.

Jiná věc je samozřejmě, když ho někdo použije a nenavrhne rozumně - pak to spíš otravuje.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Těch 0,5% bych vůbec nezmiňoval, protože 9 z 10 uživatelů má to Zlepšování softwaru a služeb na základě zkušeností uživatelů buď ponecháno ve standardním stavu - vypnuté, nebo to vypíná explicitně.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Office používá velké mnžoství uživatelů a nedávno MS uvedl, že zapnuté to má necelých 6% lidí. Což ale v tom množství jsou pořád desítky tisíc lidí. Na takovém množství už statistika funguje a číslu 0,5% z těch, které už mají zapnuté, bych věřil.

Navíc není podle mě moc důvodů proč tu funkci vypínat - jen si tím zvyšuji pravděpodobnost, že MS vyhodí funkce, které používám. Když to udělá jeden člověk, je to jedno, ale od značného množství lidí jsem slyšel, že MS nemá zajímat, jak uživatelé používají jeho software.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Diskuse: Návrh uživatelského rozhraní v desktopových aplikacích

A co použít zarovnání "na střed"?

Tím myslím něco jako kombinaci "sloupcového" a zarovnání "k sobě".

Textboxy, comboboxy atd by byly pod sebou a vlevo začínaly na stejné souřadnici. K nim by byly labely zarovnány pravou stranou, takže by vždy končili u těchto prvků jako v prípadě zarovnání "k sobě"

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Jestli to dobře chápu, tak máte na mysli zarovnání do bloku. To nepřichází v úvahu, protože potom by některé ovládací prvky byly zbytečně roztažené k pravému kraji okna. Podívejte se na obrázek výše a zkuste si představit, jak by vypadal takto ke kraji roztažený NumericUpDown k nastavování portu pro naslouchání...

nahlásit spamnahlásit spam 0 odpovědětodpovědět

asi myslel nieco taketo:

..abcdegf: 123456
.....abcd: 123

to zarovnanie dolava nieje zarovnanie, ale bordel :) subjektivne sa to moze niekomu pacit, ale je to proti vsetkym typografickym pravidlam.

Jeden priklad za vsetky:

Kazdy pozna property grid vo visual studiu (zalozka properties) dobre sa na nu pozrite. Teraz si predstavte, ze by hodnoty neboli zarovnane. To by bol chaos :)

Dajte si do googlu vyhladavat obrazky s heslom login form. Kazdy dobry design ma zarovnane textboxy (username a password) pod sebou.

Liero

nahlásit spamnahlásit spam 0 odpovědětodpovědět

uf, trochu sa mi to rozbilo

myslel som to tak, ze popisky su zarovnane pod sebou do prava a a hodnoty zarovnane dolava, najlepsie s rovnakou sirkou

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Myslíte si, že z vašeho příspěvku je něco poznat? Pokud chcete dávat lekce typografie, podívejte se nejdřív na něj.

PropertyGrid, ListView, nebo třeba DataGridView jsou ovládací prvky typu seznam, u kterých to ani jinak udělat nejde.

Přihlašovací dialog je zrovna ten nejdebilnější příklad, co jste mohl vybrat, protože tam jsou všeho všudy dva Labely, dva TextBoxy a dvě tlačítka. Já se bavím o oknech s desítkami ovládacích prvků.

Na zarovnávání k sobě není vůbec nic špatného, používá se to běžně a má to ty výhody, že není nutné vizuálně dohledávat co k čemu patří a na formuláři je využito více místa (bez dopadu na přehlednost).

nahlásit spamnahlásit spam 0 odpovědětodpovědět
                       
Nadpis:
Antispam: Komu se občas házejí perly?
Příspěvek bude publikován pod identitou   anonym.

Nyní zakládáte pod článkem nové diskusní vlákno.
Pokud chcete reagovat na jiný příspěvek, klikněte na tlačítko "Odpovědět" u některého diskusního příspěvku.

Nyní odpovídáte na příspěvek pod článkem. Nebo chcete raději založit nové vlákno?

 

  • Administrátoři si vyhrazují právo komentáře upravovat či mazat bez udání důvodu.
    Mazány budou zejména komentáře obsahující vulgarity nebo porušující pravidla publikování.
  • Pokud nejste zaregistrováni, Vaše IP adresa bude zveřejněna. Pokud s tímto nesouhlasíte, příspěvek neodesílejte.

přihlásit pomocí externího účtu

přihlásit pomocí jména a hesla

Uživatel:  
Heslo:  

zapomenuté heslo

 

založit nový uživatelský účet

zaregistrujte se

 
zavřít

Nahlásit spam

Opravdu chcete tento příspěvek nahlásit pro porušování pravidel fóra?

Nahlásit Zrušit

Chyba

zavřít

feedback