De faktorer som man bör se på vid konstruerande av komponenter är
implementeringstiden, komplexiteten, återanvändbarheten och användbarheten. Om implementeringstiden är hög och komplexiteten är låg, ska man se om komponenten används flitigt av användarna och om komponenten går att återanvända i andra projekt. Annars bör man se efter om det går att göra komponenten återanvändbar.
Om implementeringstiden är låg och komplexiteten är hög så går det förmodligen inte att återanvända komponenten i andra projekt, det kan även öka tiden att underhålla systemet. Men om systemet inte ska uppdateras, komponenten inte ska återanvändas och inte användaren störs av det kan man implementera komponenten. Annars bör man fundera på att minska komplexiteten.
I prototypen var det egentligen två funktioner som drog upp komplexiteten. Det ena var att informationen skulle hämtas från en extern källa och den andra funktionen var länkarna. Funktionen för att göra katalogen dynamiskt gjorde att flera olika tekniker blev inblandade. Länkarna gjorde att det behövdes en tredjepartskomponent som gjorde att systemet blev operativsystemsberoende. Då både komplexiteten och
implementeringstiden var relativt hög för länkarna så borde de implementeras på ett annat sätt. Däremot vinner utvecklarna tid genom att spara in på implementering vid
uppdatering av katalogen när informationen hämtas från en extern källa.
I följande punkter resonerar jag mellan implementeringstid och komplexitet med hjälp av Reschers (1998, s.9) nio aspekter av komplexitet
1. Descriptive complexity. Det är viktigt att göra en sakenlig beskrivning av systemet för att underlätta implementering och underhåll av systemet. Det är speciellt viktigt när flera parter är inblandade i projektet. Vid en ökad
komplexitet vid beskrivningens komplexitet ökar även implementeringstiden. Det är då viktigt att hålla nere komplexiteten för att få en låg
implementeringstid.
2. Generative complexity. Om en funktion bara har en specifik uppgift och inte ska göra något annat. Då kan det vara lönt att implementera en funktion med hög generativ komplexitet, då implementeringstiden blir lägre. Men om
funktion ska lösa flera uppgifter eller ska återanvändas i andra projekt bör man implementera en funktion som är generisk även om implementeringstiden blir högre just vid det tillfället. Anledningen till det är att tid sparas in nästa gång som du ska skriva en funktion för att lösa liknande uppgift.
3. Computational complexity. Att implementera ett system som har låg tidskomplexitet borde vara ett av målen när ett system implementeras. Men i vissa fall kan en lösning som tar längre tid att lösa för datorn att vara bättre. Om en funktion tar fem minuter att implementera och har mycket högre tidskomplexitet än en funktion som har tagit flera timmar att implementera men om inte användaren märker någon skillnad så borde man ändå avväga att implementera funktionen som tog fem minuter att implementera. Här borde man avväga om användaren upplever att systemet går långsamt eller inte. Systemet ska då testas på målgruppens datorer och inte någon superdator. 4. Constitutional complexity. Här gäller det att göra en avvägning mellan hur
många komponenter systemet behöver vara uppbyggd med för att göra systemet överskådlighet och lätt implementerat. Systemet ska inte vara uppdelat i så många komponenter som det bara går för att det ska vara uppdelat. För varje uppdelning tar en liten stund att implementera även om
funktioner kan återanvändas. Till exempel om ett program hämtar information från ett antal olika funktioner kan det vara lönt att dela upp en funktion för att hämta data som flera andra funktioner kan använda sig av. På detta sätt får man en bättre översiktlighet och en lägre implementeringstid då inte kod för att hämta data behövs skrivas flera gånger om.
5. Taxonomical complexity. Detta är lite av samma resonemang som vid constitutional complexity alltså om en funktion kan läsa flera olika typer av data behövs inte flera olika funktioner implementeras för att läsa in data. Men om programmet bara behöver läsa in en typ av data och funktionen inte ska återanvändas kan det vara lönt att implementera en funktion som bara kan läsa in en typ av data.
6. Organizational complexity. För återanvändning av funktioner i andra projekt är det viktigt att koden inte är sammanflätad med resten av systemet. Alltså det är viktigt att funktionen inte är beroende av systemet utan funktionen ska kunna gå att tas ut och sättas in i ett annat projekt. Exempelvis om en
zoomfunktion är implementerad i en produktkatalog ska det gå och ta ut den funktionen och kunna importera den i exempelvis ett bildvisningsprogram. Det är framförallt viktigt att tänka på hur systemet är organiserat i stora program. Om du till exempel implementerar ett program för att bara lösa en ekvation kan det vara meningslöst att strukturera up programmet, då det bara tar en massa onödigt tid att implementera. Men om stora system ska
implementeras är det viktigt att strukturerar upp systemet på ett vettigt sätt och då sparas tid in på felsökning och uppdatering av systemet. Det underlättar även för andra att läsa och ändra om koden.
7. Hierarchical complexity. Att det är viktigt att ha en bra struktur i stora system medan i mindre system går det bara åt mer tid till implementering.
8. Operational complexity. Avvägningen beror dels på hur mycket interaktivitet systemet ska vara uppbyggt med. Tillför interaktiviteten något för användaren kan det vara lönt att implementera funktionen. Om det till exempel tar 1 timme att implementera en 3D-visualisering där man kan snurra, dra och förstora objektet i en lösning och det i den andra lösningen går att ändra färg på objektet, även om det tar 30 timmar att implementera den funktionen, så kan det vara lönt att implementeraförsta lösningen om inte hela funktionen går ut just på att ändra färg på objektet.
9. Nomic complexity. Ju mer regler som styr systemet desto komplexare blir systemet. Här är det viktigt att inte sätta upp regler som gör det nästintill blir omöjligt att utföra en uppgift. Reglerna borde vara satta för att hjälpa
implementering och även skydda systemet.
Något som användartesten har visat att användarna upplever funktioner som svåra då interaktiviteten är bristfällig. Då är det bra att skapa återkoppling, mapping och
affordance, se kapitel 2.2 interaktivitet. En avvägning mellan vilken lösning på
interaktivitet får man lösa genom att välja något som inte tar för lång tid att implementera men ändå fyller upp målgruppens behov av interaktivitet.