Sekundära fönster som visas ovanpå primära, överordnade fönster
Allan Day
aday@gnome.org
Calum Benson
Adam Elman
Seth Nickell
Colin Robertson
Anders Jonsson
anders.jonsson@norsjovallen.se 2015, 2018
Sebastian Rasmussen
sebras@gmail.com 2017, 2018

# Dialogfönster

Dialoger är sekundära fönster som visas ovanpå ett primärt överordnat fönster. De används för att presentera ytterligare information eller komponenter, inklusive inställningar och egenskaper, eller för att presentera meddelanden eller frågor.

GTK+ tillhandahåller ett antal standarddialoger som kan användas, så som de för utskrifter eller färgval.

Det finns tre grundläggande typer av dialoger.

# När ska de användas

Dialoger är ett vanligt designmönster och det finns etablerade konventioner för de olika typerna av dialoger som du eventuellt vill använda. Riktlinjerna för varje typ av dialog tillhandahåller vidare information om detta.

Även om dialoger kan vara ett effektivt sätt att visa ytterligare komponenter eller information kan de också vara en störningskälla för användaren. Av denna orsak bör du alltid ifrågasätta huruvida dialogen är nödvändig och arbeta på att undvika situationer där de är nödvändiga.

Det finns många sätt att undvika att använda dialoger:

Använd inbäddad komponering för nya meddelanden, poster eller kontakter.

Aviseringar i programmet är ett alternativ till meddelandedialoger.

Kontextfönster kan vara ett sätt att visa ytterligare komponenter eller alternativ på ett mindre störande sätt.

# Meddelandedialoger

Meddelandedialoger är den enklaste typen av dialog. De presenterar ett meddelande eller en fråga tillsammans med 1-3 knappar som kan användas för att svara. De är alltid modala, vilket innebär att de förhindrar åtkomst till sitt överordnade fönster. Meddelandedialoger är ett lämpligt val när det är viktigt att användaren ser och svarar på ett meddelande.

## Exempel

Bekräftelsedialoger använder en meddelandedialog för att kontrollera, eller bekräfta, att användaren vill utföra en åtgärd. De har två knappar: en för att bekräfta att åtgärden ska utföras och en för att avbryta åtgärden.

Bekräftelsedialoger kommer ofta att bekräftas av misstag eller per automatik, och kommer inte alltid att förhindra misstag från att ske. Det är ofta bättre att tillhandahålla möjligheten att ångra sig.

Feldialoger presenterar ett felmeddelanden till användaren. De inkluderar ofta endast en knapp som låter användaren bekräfta och stänga dialogen.

Feldialoger bör generellt vara det sista alternativet. Du bör designa ditt program så att fel inte inträffar och att det automatiskt återhämtar sig om något faktiskt går fel.

# Åtgärdsdialoger

Åtgärdsdialoger presenterar alternativ och information om en specifik åtgärd innan den utförs. De har en rubrik (som typiskt beskriver åtgärden) och två primära knappar: en som låter åtgärden utföras och en som avbryter den.

Ibland kan användaren behöva välja alternativ innan en åtgärd utförs. I dessa fall bör den bekräftande dialogknappen vara okänslig tills att de nödvändiga alternativen har valts.

## Exempel

Många av standarddialogerna i GTK+ är åtgärdsdialoger. Utskriftsdialogen är ett bra exempel: den visas när användaren använder utskriftsåtgärden och presenterar information och alternativ för utskriftsåtgärden. De två rubrikradsknapparna låter utskriftsåtgärden antingen avbrytas eller utföras.

# Presentationsdialoger

Presentationsdialoger presenterar information eller komponenter. I likhet med åtgärdsdialoger har de en rubrikrad och ett ämne. Men istället för att föregå en åtgärd relaterar deras innehåll till ett program eller ett innehållsobjekt.

## Exempel

Inställningar och egenskaper är båda exempel på presentationsdialoger och båda presenterar information och inställningar som relaterar till en specifik post (antingen ett program eller ett innehållsobjekt). Egenskapsdialoger är ett bra exempel på hur dialoger kan användas för att avslöja ytterligare information som inte alltid behövs i programmets huvudfönster.

Motstå frestelsen att tillhandahålla ett inställningsfönster för ditt program. Ifrågasätt alltid huruvida ytterligare inställningar verkligen är nödvändiga. De flesta användare kommer inte att bry sig om att undersöka inställningarna du tillhandahåller och konfigurationsinställningar kommer att bidra till komplexiteten i ditt program. Gör en ansträngning för att säkerställa att din programdesign fungerar för alla utan att behöva ändra dess inställningar.

## Omedelbart och uttryckligt verkställande

Presentationsdialoger får antingen effekt omedelbart eller kräver explicit verkställande. I dialoger med omedelbar effekt kommer ändring av inställningar eller värden att omedelbart uppdateras. Detta står i kontrast till dialoger som kräver explicit verkställande, vilka har en knapp för att verkställa ändringarna.

Dialoger med omedelbart effekt bör användas där så är möjligt. Dialoger med omedelbar effekt har en stängningsknapp i deras rubrikrad, i likhet med ett primärfönster.

Dialoger som kräver explicit verkställande är endast nödvändiga om ändringar i dialogen måste tillämpas samtidigt för att få det önskade beteende. Dialoger med explicit verkställande har en Klar- och Avbryt-knapp. (Avbryt återställer alla värden i dialogen till tillståndet de hade innan den öppnades och Klar tillämpar alla ändringar och stänger fönstret).

# Primärknappar

Meddelande- och åtgärdsdialoger inkluderar primärknappar som påverkar hela fönstret. Ordningen på dessa knappar, samt de etiketter de använder, spelar en nyckelroll i dialogen.

## Ordning

När en dialog inkluderar en bekräftelse- och en avbrytknapp, försäkra dig alltid om att avbryt-knappen visas först, innan bekräftelseknappen. I vänster-till-höger-lokaler är detta till vänster.

Denna knappordning säkerställer att användaren blir uppmärksammad på, och påmind, om möjligheten om att avbryta innan bekräftelseknappen anträffas.

## Etiketter

Ge den primära bekräftelseknappen en etikett med ett specifikt, imperativt verb, till exempel Spara, Skriv ut, Ta bort. Detta är tydligare än en generell etikett så som OK eller Klar.

Feldialoger inkluderar typiskt en enda knapp som avfärdar dialogen. I detta fallet behöver en specifik åtgärd inte refereras till, utan detta är ett bra tillfälle att använda humor. Ursäkten accepterad eller Uppfattat är båda exempel på bra etiketter.

## Standardåtgärd och avbrott

Tilldela alltid Retur till att aktivera den primära bekräftelseknappen i en dialog (till exempel Skriv ut i en utskriftsdialog). Detta kallas för standardåtgärden och indikeras med en annorlunda visuell stil. Gör inte en knapp till standardalternativ om dess åtgärd är oåterkallelig, destruktiv eller på annat sätt besvärlig för användaren. Om det inte finns någon lämplig knapp att beteckna som standardknappen, ställ inte in någon.

Du bör också säkerställa att Escape-tangenten aktiverar avbryt- eller stängknappen, om endera av dessa existerar. Meddelandedialoger med en enda knapp kan binda både Escape och Retur till samma knapp.

Att binda Retur och Escape på detta sätt tillhandahåller ett förutsägbart och behändigt sätt för att fortsätta vidare efter en dialog, eller att gå tillbaka.

# Allmänna riktlinjer

Dialogfönster bör aldrig visas oväntat och de för endast användas för att visa omedelbar respons till en avsiktlig användaråtgärd.

Dialoger bör alltid ha ett överordnat fönster.

Följ layoutriktlinjerna när du designar innehållet i fönster.

Använd vyväxlare eller flikar för att dela upp komponenter och information.

Undvik att stapla dialogfönster ovanpå varandra. Endast ett dialogfönster bör visas åt gången.

När en dialog öppnas, tillhandahåll inledande tangentbordsfokus på den komponent som du förväntar dig att användaren ska interagera med först. Detta fokus är speciellt viktigt för användare som måste använda ett tangentbord för att navigera i ditt program.

# API-referens

GtkAboutDialog

GtkDialog

GtkMessageDialog