Ett utvecklar- perspektiv · Mjukvara är just mjuk; det bör gå att göra förändringar För att...

1

Design och konstruktion av användargränssnitt – distanskurs 1MD113

Uppsa

la un

iversi

tet @

2005

Ett utvecklar-perspektiv

Design och konstruktion av användargränssnitt - distanskurs

Informationsteknologi | 2005-05-28 | #2Uppsala universitet @ 2005

Användbarhet vs. utvecklingVarför har så många system låg användbarhet?• Konflikter – bråk om vad som ska utvecklas• Tidsbrist – användbarhet hinns ej med• Upphandling – kan ge formella hinder• Okunskap – inte veta vad göra• Oförmåga – inte klara av att möta mål



KonflikterHar vi egentligen konflikter mellan beställare och utvecklare? Nja, men…• olika faktorer styr när man blir nöjd• det är svårt att skilja systemutveckling från

verksamhetsutveckling (= turbulens)• svag förståelse för varann: mycket är en språk- och

intressebarriär, ej nödvändigtvis en konflikt i sig• dålig medverkan i de andras aktiviteter leder ofta till

osämja

2



Tidsrelaterade problemProduktivitet• Avtar med antalet personer. Kompensera med

gruppuppdelning; ger ännu fler parter att hantera• Att ”öka takten” är snudd på omöjligt

Människor är inte plug & play-kompatibla



Formella hinderDåliga odds från första början på grund av upphandling• Fast pris + låsta krav = betong

Upphandling är ofta lek i en ”låtsasvärld”• Beställaren låtsas veta alla framtida krav• Leverantören låtsas tro på det, och låtsas vidare att det

går räkna ut fix kostnad för att konstruera systemet• Utvecklarna låtsas att utveckling är statiskt och använder

metoder som tar ”fyrkanter” som indata och som producerar nya fyrkanter

• Alla blir förvånade/upprörda när systemet sedan inte håller måttet…



Upphandling

Analys: behov

Krav

Offert

Analys: tid & pengar

KUNDEN LEVERANTÖREN

3



FörändringarMjukvara är just mjuk; det bör gå att göra förändringarFör att nå användbarhet så måste man kunna korrigera felLösningen är att inte låsa krav, speciellt inte tidigtVad utvecklingskostnaden blir beror nästan enbart på krav (som vi ju inte vet i förväg)



Offertvarianter

Löpande räkning

Blandformer

Fast pris

Fast pris med böter

Chans attfå kontrakt

Risk



OkunskapDesign för användbarhet• Inget som skiljer sig från andra krav• Dock, det finns sällan konkreta

användbarhetsmål om man frågar beställare/användare/experter!

• Alltså ligger svaret troligen i hur man utvecklar, inte vad

4



OförmågaProjektmedlemmar• Något av ett tabu: vi är olika bra (och dåliga)• Vi är dessutom individuellt olika bra/dåliga på

olika saker• Ofta saknas kompetens för nya moment och

situationerMycket hade kunnat förbättras med lite framförhållning



Lösningen?Problemen är många så enkla lösningar finns ej tyvärr!Dock, det går lösa flera problem genom en lämplig utvecklingsmetodikAnvändbarhetsprocess!• Svaret ligger i metoden!

Om utvecklarna varit med i framtagandet av krav och prototyp så ökar chanserna att nå bra resultat



SvaghetStor brist ligger i ”my baby”-syndromet; att man aldrig vill ändra på en egen (=vacker) lösning• Leder till 1 enda utvecklingsspår mot målet; det är ej

tillräckligt• Denna naturlag fungerar åt båda håll, men oftast är det

utvecklarna som får skäll…Finns en mängd olika strategier för att undvika just den fällanHär är 7 stycken:

5



1. PerfektionismHela tiden leta efter den ultimata lösningen; nuvarande lösning endast temporär…Bygger på att det existerar en ”killer app” som löser alla våra problem• Inte riktigt sant• Eller…



Verkligheten“Worse is Better” gäller tyvärr• Richard P. Gabriel vs. Nickieben Bourbaki

Good News, Bad News, How to Win Bighttp://www.dreamsongs.com/WorseIsBetter.html

• I korthet:Enkelhet i kod > enkelhet i designEnkel > korrektEnkel att bygga > enkel att använda



2. ProjektledningArbetssätt är en fråga om inställning• Jämför hur coachning sker av målvakter i hockey och

handbollKompetens och självförtroende• Duktiga utvecklargrupper tvekar inte att slänga bort saker

som inte passar eller är bra nog. Det gäller nå denna nivå/attityd!

CoachningLedargestaltUtbildning, anställa den bästa i världenPrestigelös miljö

6



3. MetodikArbeta på ett sätt som omöjliggör revirbevakande och rigida strukturerPrototypdriven verksamhet är sådan, med stora vinster:• I en datorvärld kommer prototyper sanningen

mycket nära• Prototyper kan dock bara ge svar på frågor; ingen

generell räddningsplanka



Metodik, hur bäst förstöraSkapa moment som går emot allt mänskligt• Förutsätt konsekvent beteende av de som ska använda

metodenOm vi bara folk kunde vara konsekventa (och vara snälla, motionera mera, röka mindre…) så skulle det inte vara ett problem

• Förutsätt att folk ska ändra beteende ifall någon vill detIngen byter personlighet pga metod



4. eXtreme Programming (XP)Förändringarna har förändrats• Verksamhet förändras hela tiden, alltså bör även

systemen göra detEtt nytt sätt att utveckla system• Kontinuerliga förändringar!• Testdriven process• 2 x personer = 1 dator• Inga dokument sparas• Gemensamma ståmöten• Långsiktig planering är osäker, alltså låter man bli sånt

7



XP, del 2Gör upp med gamla ”sanningar”• Att tänka efter ger bättre kvalité än att göra nu

Fel: kvalité har med riktig användning att göra, inte planerad användning. T.ex. snabbast ta första tunnelbaneuppgången än den rätta

• Att göra rätt sak från början är billigare än att rätta i efterhand

Fel: troligtvis behövs saken inte alls, om den sedan behövs gör man det då.

• Dokumentation är viktig att sparaFel: den är så dålig att den inte är värd något



XP, del 3• Planera noga för viktiga saker

Fel: om framtiden är oklar, och du kan fixa saker i efterhand, varför införa något som man misstänker kan vara bra?

• Välj bästa lösningenFel: välj enklaste lösningen, för den är ändå bra nog (och enklare att ändra)

• Se framåtFel: gör endast vad du vet, inget mer



XP, del 4• Koda, testa sedan att det blev rätt

Fel: gör test först, koda sedan • Många rader kod/dag, och många funna fel i ett

test är braFel: få rader går snabbare att skriva, noll antal fel vore bättre

8



5. DesignkriteriaJobba mot förbestämda mål• Överenskomna• Gemensamma• Styrande

Målen riskerar bli förtäckta krav(Exempel kommer i del 2)



6. RationaleAtt arbeta enligt Design Rationale kan hjälpa utvecklingsgruppen att ompröva alla lösningarMotiverar lösningar även för andra, externa personerGer bättre kvalité på varje del-lösning, men hjälper det i det stora hela?



7. VerktygGenom att noggrant välja verktyg kan man uppnå många positiva effekter• Inga låsningar• Visionära

Nästan samma vinst som via prototyperPapperslappar, skisser, …

9



Verktyg, hur bäst förstöraVerktyg för kommunikation• Börja med 2 personer vid svarta tavlan• Ta bort närhet mellan personer (video)• Ta bort alla förklarande gester (telefon)• Se till att intonation inte kan användas till att förmedla vad

som är viktigt (epost)• Se till att man inte kan ställa frågor (dokument)

Detta är vad de flesta metoder rekommenderar…



Verktyg, välj rätt

Kommunikation

Verktyg

Svarta tavlan

Epost

Formell notation

Dokument

Strukturerat dokument

Telefon



Verktyg, välj rätt byggnad"Make sure there are whiteboards and coffee corners all over the building.” (IBM)

10



5 vanligaste verktygenFör hand (ovanligt)Färdigt bibliotek (toolkit)Färdigt gränssnittsverktyg (builder)Modell-baserade gränssnitt (kommer starkt)



HandgjortLigger direkt ovanpå hårdvaraHögsta möjliga kontrollHögsta möjliga prestandaSvår och arbetskrävande utveckling, oflexibelt, hög kunskapströskelGer ganska ofta låg kvalité• Tänk ’videobandspelare’



BibliotekHög tröskel; man måste kunna alla delar i biblioteketKräver mycket kod/arbeteUtmärkta prestandaBra kontroll

11



Hello, exempel i Java

import javax.swing.*;

class HelloWorldSwing {

public static void main(String args[]) {

JFrame mainWin = new JFrame("MainWindow");

JButton button = new JButton("Hello World");

mainWin.getContentPane().add(button);

mainWin.pack();

mainWin.show();

}

}



Bibliotek, byggklossar



Builder/RADVanligaste lösningen idag• Visual Basic, Visual C++, Forte, etc

Kräver fortfarande att man kan hela biblioteketFlexibel utveckling, stor frihetBilligt Hjälpsystem, underhåll, distribution, felhantering, …Ger initialt en snabb utveckling (falsk känsla dock)

12







Modellbaserat gränssnittrubrik:

textfält(ej inmatning),bakgrund=vit.

varningsrubrik:rubrik,bakgrund=röd.

13



Modellbaserat gränssnittBokabiljett:

rubrik(”Boka biljett”),dag,namn(”Ditt namn”),knapp(”Skicka beställning”).

dag:rubrik(”När vill du resa),datum.

1

Medicinsk informatik - Telemedicin


Exempel: Medicus



MedicusDeutsche Telekom beställare.Ville skapa produkter som använder ISDN, för att kunna sälja som mervärden till den tjänsten.Specifikation:• Telekonferens.• Utbyte av bilder.



Tidiga kravBeställaren om systemet:• Ska nyttja ISDN• Konferens• ”Säljande”

Medicinsk personal:• Vara som förr, fast bättre• Katastofhjälp• Se motpart

Bild + ljud

• Dela ”pekare”

2







Medicus, design

Bag Panel Folder Panel

Work Area

Session Panel

Status Panel Quit Panel

Task Panel

3



Medicus, look&feel





Senare kravJättestor bildStor bildFunktionalitetAnvändbarPrisvärd

4





Användning

Krankenhaus Salem Onkologische DiagnostikDeutsches Krebsforschungszentrum



Start av applikation

0

20

40

60

80

100

120

01:00

03:00

05:00

07:00

09:00

11:00

13:00

15:00

17:00

19:00

21:00

23:00

5



Konferenslängd

0

50

100

150

200

250

<1min

1-2min

2-3mins

3-4min

4-5min

5-10min

10-15min

15-20min

20-25min

> 25min



Start av konferens

0100200300400500600700800900

1 000

01:00 04:00 07:00 10:00 13:00 16:00 19:00 22:00



Nya idéer

6



CHILI PDA, senaste

Ett utvecklar- perspektiv · Mjukvara är just mjuk; det bör gå att göra förändringar För att...

Documents

Transcript of Ett utvecklar- perspektiv · Mjukvara är just mjuk; det bör gå att göra förändringar För att...