Avgränsning: I det här exemplet är fokus på komponent och modelldesign. Det är de saker som användarna aldrig ser, men som har stor påverkan på hur enkelt det är att underhålla, vidareutveckla och återanvända de komponenter som vi bygger våra dialoger av. Det kommer fler artiklar som får fokusera på design av det grafiska gränssnittet, eller med andra ord, hur komponenterna bäst läggs ut i dialogen för att göra det enkelt för användarna att förstå hur de ska använda dem.
Så vad menar vi med en dialog?
En dialog används av en applikation antingen för att uppmärksamma användaren på något (info, fel) eller för att begära någon form av bekräftelse eller ta emot ett val (eller data om något) som antingen ska sparas någonstans eller användas för att hämta andra data.
Oavsett vad du ska använda din dialog till är det viktigt att du känner till att dialoger kan presenteras i två olika lägen och att de i sin tur medför ett antal outtalade krav om förväntade beteenden, som du behöver efterleva för att dina användare ska känna sig trygga med hur din applikation fungerar.
I normalfallet vill du kunna skicka in data med värden som säger något om det tillstånd applikationen befinner sig i till den nya dialogen, för att sedan ta emot data ifrån dialogen i ett senare moment. Du behöver avgöra om din dialog är modal eller ej – vilket i sin tur får följande designkonsekvenser:
- Modal (stannar all annan aktivitet i din applikation tills användaren väljer OK eller Avbryt)
- Du förväntas inte påverka data i omgivningen innan ett OK
- Vid ett avbryt ska inget alls ha påverkats.
- I det här fallet vill du skicka in en modell som inte blir lyssnad på av något utanför dialogen och du behöver se till att valet användaren gör innan dialogen stängs, sparas till modellen så att du kan ta emot valet efter att dialogen stängts.
- Icke-modal
- Dialogen är öppen och tillgänglig tills användaren stänger/döljer fönstret.
- Förändringar i dialogen ska i realtid påverka den källa som startade den.
- I det här fallet kan du skapa modellen som ovan, men istället för att kolla vad användaren valt i samband med att dialogen stängs, vill du registrera lyssnare på modellen från andra delar av systemet redan innan dialogen öppnas.
- Lyssnarna blir notifierade när data i modellen förändras och de kan då anropa modellen för att hämta data och sedan anpassa sig till det nya tillståndet
- Pattern: observer-subscriber
Vi kommer att gå igenom både en modal och en icke-modal lösning för dialogen ovan, men låt oss först kika på hur dess underliggande modell behöver se ut för att fungera ovasett dialogtyp.