2. HIG (Richtlijnen voor de gebruikersinterface)
Het is belangrijk dat de volgende richtlijnen worden gevolgd voor de lay-out en het ontwerpen van GUI’s om alle elementen van de grafische gebruikersinterface er consistent uit te laten zien en om de gebruiker instinctief dialoogvensters te laten gebruiken.
Groepeer gerelateerde elementen met behulp van groepsvakken: probeer elementen te identificeren die gegroepeerd kunnen worden en gebruik dan groepsvakken met een label om het onderwerp van die groep te identificeren. Vermijd het gebruiken van groepsvakken met slechts één enkel widget / item erin.
Geef alleen in labels, Helptips, beschrijvende tekst en andere tekst die geen koptekst of titel is de eerste letter een hoofdletter: Deze zouden als een frase moeten worden geschreven met alleen de eerste letter als hoofdletter, en alle resterende woorden een kleine letter als eerste letter, tenzij zij een zelfstandig naamwoord zijn.
Geef alle woorden in titels (groepsvak, tab, lijstweergave kolommen, enzovoort), Functies (menuitems, knoppen), en andere te selecteren items (items voor combinatievak, items voor keuzelijsten, items voor lijsten van de boom, enzovoort hoofdletters): Geef alle woorden hoofdletters, behalve voorzetsels die korter zijn dan vijf letters (bijvoorbeeld, ‘with’ maar ‘Without’), voegwoorden (bijvoorbeeld en, of, maar), en lidwoorden (de, een, het). Het eerste en laatste woord krijgen echter altijd een hoofdletter.
Laat labels voor widgets of groepsvakken niet eindigen op ene dubbele punt: Toevoegen van ene dubbele punt veroorzaakt visuele ruis en voegt geen aanvullende betekenis toe, gebruik ze dus niet. Een uitzondering op deze regel is wanneer u twee labels naast elkaar hebt, bijv.: Label1 Plug-in (Pad:) Label2 [/pad/naar/plug-ins]
Houd riskante acties weg van acties zonder risico’s: Als u acties heeft voor ‘delete’, ‘remove’ etc, probeer dan voldoende ruimte te houden tussen de riskante actie en ongevaarlijke acties zodat de gebruikers minder snel per ongeluk op de riskante actie kunnen klikken.
Gebruik altijd een QButtonBox voor knoppen ‘OK’, ‘Annuleren’ etc: gebruik van een knoppenvak zal er voor zorgen dat de volgorde van de knoppen ‘OK’ en ‘Annuleren’ etc, consistent is met het besturingssysteem / locale / desktopomgeving die de gebruiker gebruikt.
Tabs zouden niet moeten worden genest. Als u tabs gebruikt, volg dan de stijl van de tabs die wordt gebruikt in QgsVectorLayerProperties / QgsProjectProperties etc. d.i. tabs bovenin met pictogrammen van 22x22.
Stapels van widgets zouden zoveel mogelijk moeten worden vermeden. Zij kunnen problemen veroorzaken met lay-outs en onverklaarbare (voor de gebruiker) wijzigingen in grootte van dialoogvensters om widgets te accommoderen die niet zichtbaar zijn.
Probeer technische termen te vermijden en gebruik lekentaal als equivalent bijv. gebruik het woord ‘Doorzichtbaarheid’ in plaats van ‘Alfakanaal’ (bedrieglijk voorbeeld), ‘Tekst’ in plaats van ‘String’ enzovoort.
Gebruik pictogrammen consistent. Als u een pictogram of elementen van pictogrammen nodig hebt, neem dan voor assistentie contact op met Robert Szczepanek via de mailinglijst.
Plaats lange lijsten met widgets in scrollvakken. Een dialoogvenster zou niet groter moeten zijn dan 580 pixels in hoogte en 1000 pixels in breedte.
Geavanceerde opties dienen te worden gescheiden van standaard functionaliteit. Nieuwe gebruikers zouden in staat moeten zijn snel toegang te verkrijgen tot functionaliteit zonder dat zij zich zelf bezig dienen te houden met de complexiteit van geavanceerde mogelijkheden. Geavanceerde mogelijkheden zouden ofwel moeten zijn geplaatst onder een scheidingslijn, of op een afzonderlijke tab.
Voeg geen opties toe die niet bijdragen aan de gebruikerservaring. Houd de interface minimalistisch en gebruik logische standaard instellingen
Als het klikken op een knop een nieuw dialoogvenster zou openen, zou een ellipsis (…) na de tekst op de knop moeten worden geplaatst. Opmerking: zorg er voor dat u het teken voor Horizontale ellips U+2026 gebruikt in plaats van drie punten.