3D-modellering för bygglovsansökan DANIEL ERICSSON

Transkript

1 3D-modellering för bygglovsansökan DANIEL ERICSSON Examensarbete Stockholm, Sverige 2010

2 3D-modellering för bygglovsansökan DANIEL ERICSSON Examensarbete i datalogi om 30 högskolepoäng vid Programmet för datateknik Kungliga Tekniska Högskolan år 2010 Handledare på CSC var Kjell Lindqvist Examinator var Lars Kjelldahl TRITA-CSC-E 2010:052 ISRN-KTH/CSC/E--10/052--SE ISSN Kungliga tekniska högskolan Skolan för datavetenskap och kommunikation KTH CSC Stockholm URL:

3 Sammanfattning Innan en första formel ansökan om bygglov skickas in brukar den ansökande ha en diskussion med handläggaren om vad de vill göra, då brukar ofta den ansökande visa upp en preliminär skiss på vad de vill bygga, vart och även vilka dimensioner. Denna ligger sedan till grund för själva bygglovsprocessen. Ofta kan de första skisserna vara inexakta, svåra att tyda samt svåra att få en bra överblick över, då den ansökande inte är van att göra ritningar. Idén med det här examensarbetet var att utreda om det går att skapa ett 3D-modelleringsverktyg som personer utan förkunskap inom området kan använda för att skapa sin egen grundläggande skiss till bygglovet, samt att utreda om det är rimligt, eller om det finns bättre vägar att gå. Utvärderingen har skett med hjälp av användartester med personer utan förkunskaper. Det som i första hand utvärderas är om de kan förstå hur de ska använda programmet och hur de skapar sina egna skisser. Den slutgiltiga prototypen visar att det går att skapa ett program för 3D-modellering av skisser på byggnader inför bygglov, men samtidigt att det kommer krävas en del arbete för att få programmet tillräckligt snyggt och användarvänligt för att kunna användas av allmänheten. Abstract 3D modeling for application of building permit Before someone applies for a building permit they usually have a discussion with the administrator about their plans, and then the applicant usually presents a sketch with an approximation of what they want to build, a location and what dimensions the building will have. This sketch is then used as the foundation of the process of building permissions. These first sketches can often be inexact, hard to interpret and it is therefore hard to get a good overview, because the applicant is not used to making building plans. The idea with this thesis work was to investigate whether it was possible to create a 3D modeling tool which ordinary people can use for creating basic sketches of what they want to build. The author will also investigate whether this is reasonable to do, or if there are other ways to go. The evaluation will be done with user tests featuring ordinary people. It will focus on if the users can understand how to use the program and if they can create their own buildings. The final prototype shows that it is indeed possible to create a basic 3D modeling tool for sketches of buildings, but also that it will take some further effort to make the tool polished enough to be released to the public.

4 Förord Denna studie är ett examensarbete inom datalogi på CSC, Kungliga Tekniska Högskolan i Stockholm, med uppdragsgivaren Decerno AB. Jag vill tacka mina handledare Kjell Lindqvist och Torsten Hökby för deras hjälp och stöd under arbetet samt Lukas Johansson för hans hjälp under arbetet och Hans-Peter Aineskog för hans hjälp med bakgrunden till examensarbetet samt möjliga användningar av det. Jag vill även tacka alla som varit med och deltagit i användartesterna, vilka är följande: Fei Song, Christoffer Agn, Max Walter, Linnea Sundberg, Emelie Sundberg, Diana Wikström, Anna Ericsson, Ingemar Svensson, Marita Svensson och Patrik Svensson. Slutligen vill jag tacka Gunborg Ericsson och Bo Ericsson för hjälp med korrekturläsning av rapporten samt Anna Ericsson för hjälp med korrekturläsning och formgivning av programmets logotyp.

5 Innehåll Ordlista 1 Inledning Bakgrund Mittbygge.se Problem Begränsningar Teori Geografiska informationssystem Bygglovsprocessen Tekniker Tekniska krav för projektet C/C++ (OpenGL) Microsoft XNA Java3D jmonkeyengine CityGML Modellering i 3D Allmänt om modellering i 3D Sketchbaserade system Automatiserade system Professionella system Andra möjligheter Utvärdering och utveckling av prototyper Allmänt om utvärdering och utveckling av prototyper Designprinciper Utveckling av prototyper Utvärdering och användartestning Metod Allmänt om val av metod Val av teknik

6 3.3 Val av modelleringssätt Användartestning Genomförande Planering av prototyper Prototyp och utvärdering Allmänt om prototyperna Prototyp Prototyp Prototyp Slutsatser och rekommendationer Modellering Användartestning Litteraturförteckning 37 Bilagor 39 A Användartestsformulär, grundläggande information 41 B Användartestsformulär, avslutande formulär 45 C Snabbstart guide 49

7 Ordlista API Application Programming Interface; Det är ett interface som låter ett program kommunicera med annan mjukvara, det kan vara ner mot hårdvaran eller mot ett API på lägre abstraktionsnivå. 7 9, 25 CityGML Det är en vidareutveckling av GML, inriktad mot att kunna hålla information om byggnader, vägar och liknande. 3, 9, 10, 33 DirectX Programmeringsstandard för att kunna utnyttja grafikkortets funktioner på datorn, är beroende av operativsystem. 7, 8 GIS Geografiska Informationssystem; Det är ett samlingsnamn för datasystem som lagrar, analyserar och visualiserar lägesbunden information som till exempel kartor. 5 7 GML Geography Markup Language; Det är ett modelleringsspråk (som använder sig av XML) för att uttrycka geografisk data och även sedan kunna skicka data över internet. 9 Java3D Programmerings-API designat för att utöka det vanliga Java språket med 3D funktionalitet. 8, 9, 22 jmonkeyengine Programmerings-API för spelutveckling med Java som grund. 8, 9, 22 OpenGL Programmeringsstandard för att kunna utnyttja grafikkortets funktioner på datorn, är oberoende av operativsystem. 7 9, 21 projicera En tvådimensionell avbildning av ett tredimensionellt föremål. 11 semantisk Semantisk information innebär, i fallet för GIS-system, information om exempelvis en del av kartan. Det skulle kunna vara information om hur stor mängd mineraler det finns på ett visst ställe på kartan eller information om hur stor befolkningstätheten är. 9, 33

8 topologisk Topologi är en gren inom den moderna matematiken. Det handlar om geometrier och man betraktar endast formen på objekten, inte avstånden mellan dem, vilket kan vara användbart inom GIS tillämpningar. 9, 33 WMS Öppet standardprotokoll för att hämta geografiskt refererade kartbilder över internet, genererade av en kartserver som använder data från en GIS-databas. 30 XNA Programmerings-API designat för spelutveckling till Windows, Xbox360 och Zune. 7, 8, 22

9 Kapitel 1 Inledning 1.1 Bakgrund Vid första ansökan om bygglov måste den ansökande skicka med en skiss på ungefär vad de vill bygga, vart och även vilka dimensioner. Denna ligger sedan till grund för själva bygglovsprocessen. Ofta kan de första skisserna vara inexakta, svåra att tyda samt svåra att få en bra överblick över, då den ansökande inte är van att göra ritningar. Det leder till att personen som har hand om bygglovsansökan får mer jobb, i och med att han/hon måste tolka ritningarna. I värsta fall kan handläggaren tvingas skicka tillbaka ritningarna för att de inte går att tolka med tillräckligt stor säkerhet alternativt tillkalla ett extra möte med den ansökande bara för att få klarhet i vad som är vad i ritningen. Andra problem med denna metod att ansöka om bygglov är att det med endast en pappersritning i två dimensioner (2D) kan vara svårt att se hur den nya byggnaden kommer att påverka omgivningen, hur den kommer att se ut på fastigheten och liknande problem. Ett annat exempel på när en 2D skiss inte är lämplig är när grannarna ska godkänna ett nybygge. Då grannarna antagligen inte är bra på att läsa ritningar, kommer de troligtvis ha problem att se hur den nya byggnaden kommer att påverka dem. Saker som är viktiga i det här fallet är till exempel hur byggnaden passar in bland övriga byggnader i området, om den kommer vara i vägen för havsutsikt eller om den kommer hamna för nära ett annat hus. 1.2 Mittbygge.se Mittbygge.se (mittbygge.se, 2009) är en portal där personer som söker bygglov kan läsa och få kunskaper om att planera, kring byggprocessen och att bo. De tillhandahåller e-tjänster för att exempelvis söka marklov eller skicka in ansökan för bygglov. Flera kommuner, myndigheter och tjänsteföretag inom IT-branchen har medverkat i framtagandet av denna portal, även fyra forskningsinstitutioner har varit delaktiga. Mittbygge.se är intresserade av att ha ett program för 3D-modellering av bygglov 1

10 KAPITEL 1. INLEDNING för privatpersoner, som i så fall skulle kunna distribueras via deras hemsida. 1.3 Problem Samtliga problem som nämns i bakgrunden skulle kunna minskas om handläggaren kunde se denna första skiss i 3D på datorn istället. När det gäller måtten skulle de inte kunna misstolkas, eftersom det lätt går att kontrollera i 3D-modellen. Det skulle snabbt bli mycket mer tydligt hur den ansökande har tänkt, även om kanske inte alla detaljer i designen på byggnaden syns. Detaljerna i designen som till exempel skorsten, fönster och liknande spelar oftast inte en lika stor roll, i alla fall inte i början av processen. Då är det viktigast att fastställa att byggnationen inte bryter mot några regler för området, som till exempel antalet våningar på byggnaden, höjden på byggnaden, ytan som byggnaden ockuperar och liknande. När grannarna till den nya byggnaden ska granska planen blir även det lättare, då de får en bild i 3D av fastigheten under själva byggnaden. På så sätt får de en mycket bättre överblick över hela situationen. Det är ännu bättre om det finns möjlighet att visa omkringliggande byggnader i 3D, då går det ännu lättare att få en korrekt känsla för proportioner och hur den nya byggnaden kommer påverka området i stort. Med denna bakgrund har detta examensarbete undersökt om det kan vara rimligt att konstruera ett 3D-modelleringsprogram för byggnadslov samt utvärderat om det är en bra lösning eller om det finns bättre lösningar. Frågeställningarna för examensarbetet var följande: Är det rimligt att skapa ett 3D-modelleringsprogram designat enbart för bygglov? Hur skulle ett sådant program utformas? Hur pass svårt är det att göra ett 3D-modelleringsprogram enkelt att använda för en bred allmänhet? 1.4 Begränsningar Att ta fram ett fullständigt 3D-modelleringsprogram för godtyckliga modeller är en mycket komplex uppgift och det är inte rimligt att utföra inom den begränsade tid som examensarbetet skulle utföras på. Författaren satte därför följande begränsningar: Endast grundläggande 3D-modelleringsfunktionalitet ska implementeras 2

11 1.4. BEGRÄNSNINGAR Importering av byggnader skapade i andra datasystem (till exempel CityGML) ska endast införas i mån av tid Inte lägga stor vikt på utseende, texturer eller ljussättning Följande saker skulle utföras: Kunna modellera en grundläggande mindre byggnad i 3D med skalenliga mått och ett enkelt gränssnitt Kunna lägga till enkla tillägg på byggnaden, till exempel dörrar och fönster Kunna visualisera denna byggnad i 3D i kartapplikationen Ha skala, skalstock och norrpil i ritningen I första hand fokusera på räta vinklar Applikationen ska utvärderas med hjälp av användartestning Följande saker skulle utföras i mån av tid: Kunna utnyttja snappning (två närliggande objekt dras till varandra vid förflyttning om avståndet är tillräckligt litet) Kunna flytta/modellera byggnaden i realtid i kartapplikationen Kunna modellera mer avancerade former på byggnader Kunna markera gammal byggnad vid tillbyggnader 3

12

13 Kapitel 2 Teori 2.1 Geografiska informationssystem Definitionen på ämnet Geografiska Informationssystem (GIS) är "Ett datoriserat informationssystem för hantering och analys av geografiska data" enligt Eklundh (Eklundh, Arneberg, Arnborg, Eklundh, Harrie, Hauska, Olsson, Pilesjö, Rystedt, och Sandgren, 1999). Användningsområdena för GIS utökas hela tiden och några exempel är visualisering av höjddata, befolkningstäthet, planering av evakueringsplaner i händelse av en katastrof och liknande. Enligt Eklundh är något som gör just GIS system överlägsna den vanliga kartan möjligheten att ha mycket information i samma karta, men ändå kunna välja att se bara det som behövs för tillfället. Det kan åstadkommas genom att olika data ligger i olika lager och användaren kan då aktivera de olika lager som han/hon vill se och låta övriga vara inaktiva. På så sätt blir det också mycket lättare att jämföra olika data med varandra, då det går att se dem på samma karta, men utan att behöva ha information som inte är av intresse på kartan. Exempel på denna typ av lager kan till exempel vara att det finns ett datalager som markerar platser där det bor barn i en viss ålder och hur många de är. Ett annat dellager skulle då kunna vara platser där det idag finns skolor för barn i den åldern. Med hjälp av GIS är det möjligt att kombinera ihop de två lagren för att sedan kunna se var det skulle kunna behövas en ny skola. Ett exempel på hur det går att använda sig av GIS för olika tillämpningar är hur Farcas (Farcas och Sivertun, 2009) har gjort en karta över Skåneregionen som visar var buller från trafik är som störst, se figur 2.1. Information som denna kan användas inom många olika områden och att göra det via ett GIS gör det betydligt enklare att få en bra översikt. Wilke (Wilke, 2009) har istället tittat på hur det går att resonera om utökade geometriska objekt. Det innebär till exempel att det går att säga om en position på en karta ligger mellan två diffusa områden, som till exempel mellan skogen och staden. Frågeställningen är i det här fallet diffus på grund av 5

14 KAPITEL 2. TEORI Figur 2.1: Karta över trafikbuller i Skåneregionen (Farcas och Sivertun, 2009) att det inte går att koppla en stad till en specifik punkt samt att staden i olika sammanhang kan vara olika stor. Ibland menar man bara själva stadskärnan och ibland hela kommunen som staden tillhör. De ovanstående problemen skulle vara svåra att visualisera utan att ha tillgång till GIS system. Just tillämpningen om utökade geometriska objekt skulle dock troligtvis inte ens utredas om det inte hade funnits GIS redan från början. 2.2 Bygglovsprocessen Den del av bygglovsprocessen som är intressant för det här examensarbetet är själva inlämningen av en första skiss för bygglov. Bygglovsprocessen är uppdelad i flera olika steg, se figur 2.2, där den aktuella delen i princip motsvarar det första steget. För mer information om bygglovsprocessen se (Zdravkovic och Östman, 2007). Författaren har valt att fokusera på mindre byggnationer som till exempel uthus, paviljonger och liknande. Anledningen är att i fallet för riktiga bostadshus är det ofta en professionell arkitekt som ritar huset eller att man utgår från en färdig mall. Därför är det sällan personen som ansöker om bygglovet på ett större hus har gjort ritningen själv. I de fall där den ansökande ritar huset själv är ritningarna förhoppningsvis av så pass hög kvalité att missförstånd minimeras. Det är möjligt att, som tidigare nämnts, ritningarna håller låg kvalité och därför kan orsaka missförstånd som leder till förlängning av handläggningstiden för kommunen Figur 2.2: Bygglovsprocessen enligt (Zdravkovic och Östman, 2007) 6

15 2.3. TEKNIKER i fråga. Om missförstånd av den här typen kan undvikas kan både tid och pengar sparas för båda parterna. Som tidigare nämnts skulle en 3D-modellering av skissen kunna minimera missförstånden, då en bra visualisering av data kan hjälpa användaren att förstå hur saker hänger ihop på ett bättre sätt. Den ökade förståelsen kan också vara en av anledningarna till att GIS vuxit fram och att dess popularitet nu bara ökar. 2.3 Tekniker Tekniska krav för projektet Val av teknik är en viktig del vid utveckling av ett 3D-modelleringsprogram, speciellt om det är inriktat på användare utan förkunskaper. Det får då inte vara för krångligt att få programmet att starta, till exempel ska det helst bara fungera, utan installationer av programmet eller av nödvändiga ramverk. Andra krav är att det gärna ska fungera på alla plattformar, då både Linux och Mac OS X tar över mer och mer andelar från Microsoft, samt att även Google har lanserat ett eget operativsystem. Självklart är prestandan viktig och hur pass begränsande verktygen är, man vill gärna kunna få ut så mycket som möjligt ur programmet, samt ha möjligheten att expandera programmet vid ett senare tillfälle med ny funktionalitet. Författaren har i första hand fokuserat på 3D API:n som ligger nära hårdvaran och som därmed också kan utnyttja datorn effektivare. Alla tekniker som undersökts använder sig antingen av OpenGL eller av DirectX som båda två är stora och kända standarder och som alla nyare grafikkort på marknaden stödjer (dock stödjer inte alla de mest avancerade funktionerna) C/C++ (OpenGL) OpenGL (OpenGL, 2009) är det mest grundläggande API:t av de som tas upp. För absolut högsta möjliga prestanda är det här ett bra val, men samtidigt kommer utvecklingstiden antagligen bli längre än med ett API med högre abstraktionsnivå, då det i dessa ofta finns färdigskrivna funktioner för många av de vanligaste/jobbigaste problemen som kan uppstå inom grafikprogrammering. Ett annat problem med OpenGL baserade program är att det (om de är skrivna i ren C/C++) inte finns något sätt att starta dem direkt från internet och att programmeringsbibliotek måste skickas med. Det går förstås att lösa, men trots allt är nog OpenGL program skrivna i C/C++ mer anpassat för att vara en applikation, inte något som startas via internet Microsoft XNA XNA (Microsoft XNA, 2009) är ett API som är baserat på DirectX, men som ligger på en högre abstraktionsnivå med mycket färdigskrivna funktioner och vanligtvis skrivs det i C# (andra.net språk går också att använda i viss utsträckning). XNA 7

16 KAPITEL 2. TEORI är i första hand ett API inriktat på att göra spel till Xbox360, Windows samt Zune. Eftersom det till stor del är inriktat mot spel och dessutom mot utvecklare som inte har stor erfarenhet och/eller vill bygga något på kort tid, finns det mycket funktioner inbyggda i API:et för att underlätta just byggandet av spel. Det leder till att utveckling med XNA går relativt snabbt, speciellt om de många exempelprogram som redan finns används (ni kan se en bild från ett av exempelprogrammen i figur 2.3b). När det gäller att starta från internet har författaren inte hittat någon möjlighet till det, men det stora problemet med XNA är ändå att det endast stödjer Windows, Xbox360 och Zune Java3D (Java3D, 2009) är ett API som är ett utökat API till vanliga Java. Den bygger på OpenGL eller DirectX (beroende på plattform) och har precis som Microsoft XNA en del färdiga funktioner för vanliga problem samt att hantering av objekt har förenklats en del. När det gäller Java3D finns det inga problem med olika operativsystem, eftersom Java3D ska fungera på alla operativsystem. Java (inte Java3D) är även väl använt ute på internet, majoriteten av alla internetanvändare kommer redan att ha det installerat. Enligt (Microsoft announcement, 2008) finns Java redan på 91% av världens internetanslutna datorer och beräknas ha över 800 miljoner användare. Någonting som talar starkt emot Java3D är att det är få som använder det och det finns dåligt om exempel och guider att utgå ifrån. Det finns även lösningar för att starta Javaprogram via internet. Antingen används applets, som integreras i webbläsaren, eller Java Web Start där allt laddas ner till datorn och körs som ett vanligt program. När det gäller applets krävs det endast att användaren accepterar ett certifikat om man ska använda vissa typer av resurser (det vill säga bekräfta att de litar på de som skapat programmet). Samma sak gäller för Java Web Start, och sedan sköts all nedladdning av Java Web Start och ingen installation eller liknande krävs av användaren. Det finns både för och nackdelar med Java Web Start och applets, applets har fördelen att de kan integreras i en hemsida, men samtidigt körs de i en så kallad sandlåda. Det innebär att utvecklare inte kan komma åt hårdvaruresurser och annat på datorn som inte godkänts enligt Javas sandlåda. Det gör att programmets prestanda kan minska samt att vissa saker inte går att göra utan att användaren själv konfigurerar inställningarna för sin sandlåda (vilket inte är trivialt). Därför är Java Web Start ett bättre alternativ, då programmet körs som ett lokalt program på datorn jmonkeyengine JMonkeyEngine (jmonkeyengine, 2009) är ett API som, precis som XNA, är uppbyggt med målet att möjliggöra enkel och snabb utveckling av 3D-spel, se exempel i figur 2.3a. Det finns dock ett antal relativt stora skillnader mellan dem. För det första är Microsoft XNA utvecklat av Microsoft och det är de som står för utvecklingen 8

17 2.3. TEKNIKER (a) (jmonkeyengine, 2009) (b) (Microsoft XNA, 2009) Figur 2.3: Bilder från program gjorda i två av de tilltänkta teknikerna. av API:t, vilket innebär att de har ett kommersiellt intresse att allt fungerar så bra som möjligt, samt att de senaste funktionerna finns. JMonkeyEngine är däremot ett projekt i öppen källkod, vilket innebär att det utvecklas av frivilliga utvecklare som i det här fallet oftast har ett annat arbete och därmed endast arbetar med projektet på sin fritid. Det kan leda till att utvecklarna inte alltid följer kundernas krav på samma sätt som ett kommersiellt företag skulle göra. De kan istället rikta in sig på saker som de är intresserade av, men som kanske dess användare inte har så stor användning av. Man kan alltså inte räkna med att de senaste funktionerna finns implementerade. Däremot finns det fördelar som till exempel att all källkod är öppen, vilket innebär att koden läses av många personer och chansen att hitta problem med koden ökar. JMonkeyEngine är precis som Java3D skrivet i Java och bygger på OpenGL (jmonkeyengine använder dock bara OpenGL), vilket gör att det fungerar på alla operativsystem, till skillnad från XNA. Det har även högre abstraktionsnivå än Java3D med fler färdigskrivna funktioner, samt att det finns gott om bra exempelprogram och ett aktivt forum. Det här är saker som är viktiga, speciellt under projekt som måste utvecklas snabbt, eftersom applikationen då inte måste skrivas från grunden CityGML CityGML (CityGML, 2009) är en gemensam informationsmodell (en utveckling av GML) för representation av 3D objekt i städer som till exempel hus, vägar och broar. I CityGML är det inte bara den grafiska representationen som sparas, utan det finns även möjligheter att skapa semantisk och topologisk information. Till exempel går det att på ett hierarkiskt vis se alla olika delar som huset består av, från själva huskroppen ända ner till fönster och dörrar. Det kan vara användbart för att till exempel få veta hur många våningar ett hus har, hur många fönster det har och 9

18 KAPITEL 2. TEORI liknande information. Det går i CityGML att ha olika detaljnivåer på de objekt som finns representerade, där detaljnivån till exempel kan öka desto närmare man är ett objekt. Det kan också användas för att minska storleken på databasen eller minska den datorkraft som krävs för att visualisera objekten genom att ha en lägre detaljnivå. Det finns fem olika detaljnivåer, LoD 0-4 (Level of Detail), där man endast använder de detaljnivåer som anses behövas. I de fall en CityGML representation innehåller alla detaljnivåerna och mycket information på varje byggnad innebär det stora datamängder, och passar därför inte alltid att direkt visualiseras ifrån. Däremot kan representationen med fördel läsas in i ett annat program som bara läser in det som behövs för tillfället. 2.4 Modellering i 3D Allmänt om modellering i 3D Modellering i 3D är ett område där det är svårt att tillfredsställa allas krav och önskemål, mer än i många andra områden. Det beror på att 3D-modellering är ett mycket avancerat område och om man vill kunna skapa godtyckliga 3D-modeller krävs det mycket avancerade verktyg med många olika typer av funktioner (i alla fall har författaren inte hittat något verktyg som visar på motsatsen). Om ett system ska göras användarvänligt bör det undvikas att göra systemet för komplicerat, då det ofta har effekten att användaren blir förvirrad av alla möjligheter. Ett sätt att göra det mer användarvänligt är helt enkelt att begränsa användaren i vad den kan göra. Än så länge har författaren inte sett något program som lyckats vara ett avancerat 3D-modelleringsprogram och samtidigt vara enkelt och intuitivt för nybörjare, förutom för mycket begränsade områden. Ett annat problem som uppstår är om programmet riktar in sig på användare som aldrig använt ett 3D-modelleringsprogram förut. I webbdesign går det ofta att utgå från hur folk är vana att se hemsidor och då försöka att inte avvika för mycket från vad användarna är vana vid när systemet utformas. Problemet är att med 3D finns det inga sådana erfarenheter att utgå ifrån. Användarna har olika förväntningar på hur de vill/tror att programmet ska fungera och tolkar allt på olika sätt. Eftersom de inte har någon gemensam referensram som det finns i webbdesign blir skillnaderna mycket stora och samtidigt mycket svåra att förutsäga. Om programmet istället hade riktat sig mot erfarna 3D-modellerare hade det gått att, precis som i webbdesign, utgå från existerande program. Här nedan följer några olika exempel på vad som gjorts inom området. I tabell 2.1 på sidan 16 kan ni se de olika grundtyperna av modellering och vilka grundtyper de exempel som nämns nedan hör till Sketchbaserade system Sketchbaserade system riktar sig ofta antingen mot användare som är oerfarna, vill få ihop en modell snabbt eller bara göra en snabb ungefärlig skiss av något. Igarashi 10

19 2.4. MODELLERING I 3D (Igarashi och Hughes, 2006) skapade ett program som gissar vad användaren vill göra, se figur 2.4a. Om till exempel användaren ritar två vinkelräta linjer med gemensam utgångspunkt eller slutpunkt gissar programmet att användaren kanske vill göra en fyrkant baserad på de två linjerna. Förslagen kommer upp som förminskade bilder nere i ena hörnet och om användaren inte tycker att gissningen är korrekt är det bara för användaren att fortsätta rita som vanligt. De har implementerat ett antal olika regler för hur programmet skulle gissa. Igarashi noterar dock att det kan vara svårt att utforska möjliga val utan att ha någon typ av manual där alla val finns, då det inte finns några menyer att leta i. Andra problem är till exempel skalningsproblem som att det blir komplicerat att få bra och relevanta gissningar i avancerade 3D scener. Bae (Bae, Balakrishnan, och Singh, 2008) har istället gått en annan väg, där användaren kan skissa i 3D med hjälp av en pekskärm. För att komma nära känslan av att skissa med papper och penna i verkligheten används så få menyer och gestbaserade kommandon som möjligt. Istället tolkar programmet vad användaren antagligen vill rita samt i vilket plan, och ritar ut det i en 3D rymd. Det går självklart att rotera modellen i 3D medan användaren håller på att modellera. I figur 2.4c kan ni se hur det ser ut när man ritar skisser i programmet och i figur 2.4d hur den färdiga modellen blev. Funkhouser (Funkhouser, Kazhdan, Shilane, Min, Kiefer, Tal, Rusinkiewicz, och Dobkin, 2004) har gjort ett program där användaren kan modellera 3D-modeller utifrån ett bibliotek med existerande 3D-modeller. Det är dock inte begränsat till att bara sätta ihop olika färdiga modeller tillsammans, utan det går även att använda bara någon del av en modell. Användaren kan alltså bygga upp en ny 3D-modell genom att plocka olika delar från olika andra 3D-modeller. På det här sättet går det att göra avancerade 3D-modeller med utgångspunkt endast från enklare 3Dmodeller med minimal modellering, se figur 2.4b. Ett annat sätt är att använda en kombination av färdiga standardmodeller och bildanalys, vilket Sebe (Sebe, You, och Neumann, 2005) har gjort. Programmet läser först in en bild på det objekt användaren vill modellera (till exempel en bil), därefter väljs den standardmodell som ligger närmast. Denna standardmodell projiceras sedan ner på 2D-bilden så att den matchar denna så bra som möjligt (detta kräver viss handpåläggning av användaren). Därefter får användaren modifiera de delar i 3D-modellen som inte stämmer överens med objektet på bilden tills projiceringen blir korrekt. Programmet är fortfarande i ett tidigt stadium och det går exempelvis inte att ta bort delar från modellen, även om den önskade modellen på bilden saknar dem. Ett exempel på en sådan modell är när Sebe ville modellera en Honda Civic. Standardmodellen hade fyra dörrar medan Hondan endast hade två och därför fick modellen ha fyra dörrar i alla fall. Det finns även andra sätt att utgå från färdiga bilder i sin 3D-modellering. Tsang 11

20 KAPITEL 2. TEORI (a) (Igarashi och Hughes, (b) (Funkhouser m.fl., 2004) 2006) (c) En sketch i programmet(d) En modell i programmet av (Bae m.fl., 2008) av (Bae m.fl., 2008) Figur 2.4: Bilder från program gjorda i tre av de tilltänkta teknikerna. (Tsang, Balakrishnan, Singh, och Ranjan, 2004) har utvecklat ett program där programmet kan följa konturer/kanter i bilden och då analyserar vilken kant användaren följer, för att sedan anpassa linjen som användaren ritar till kanten i bilden. På så sätt går det att få en mer precis modellering av objektets grundform. Det går dock bara att modellera i två plan, det vill säga i det vertikala planet och det horisontala planet, där varje plan har en bild på objektet. Om det handlar om till exempel en bil, så finns det en bild från sidan i det vertikala planet och en bild på ovansidan/undersidan av bilen på det horisontala planet. Endast ett plan i taget modelleras och när båda planen modellerats färdiga har programmet åstadkommit en approximation av 3D-modellen som är åtminstone geometriskt korrekt i de två planen. Det finns även de som helt baserar sina 3D-modelleringsprogram på gester (olika mönster, utförda exempelvis med musen) som står för olika kommandon, däribland Zeleznik (Zeleznik, Herndon, och Hughes, 2007). Det här programmet är inte gjort för att göra exakta ritningar, utan just för att snabbt kunna få upp en approximativ prototyp. För att understryka det faktumet har Zelzenik valt att använda sig av icke realistisk rendering, genom att göra så att programmet ser tecknat ut. På så sätt är det ännu tydligare att programmet bara är tänkt som en första skiss, eftersom 12

21 2.4. MODELLERING I 3D (a) (C3 Technologies, 2009) (b) (Müller m.fl., 2006) Figur 2.5: Automatiskt genererade 3D-modeller från en riktig stad (till vänster) och från en fiktiv stad (till höger) det faktiskt nästan ser ut att vara skissat med papper och penna Automatiserade system På senare tid har det blivit rimligt att automatiskt generera 3D-modeller av till exempel städer, då både tekniska hjälpmedlen och algoritmerna för att skapa den typen av modeller har förbättrats avsevärt. Det har även blivit mer kommersiellt gångbart att göra det, då allmänhetens intresse ökat. Exempel på det är Eniros nya karttjänst där C3 Technologies (C3 Technologies, 2009) har utvecklat ett system som har 3D-modellerat hela Stockholm automatiskt i gatunivå, utan manuell handpåläggning, se figur 2.5a. Det har åstadkommits med hjälp av kameror med mycket hög upplösning samt ett positioneringssystem som ser till att en punkt på kartan mappas mot motsvarande punkt på de tagna bilderna. Modellerna på gatunivå är skapade med hjälp av en bil som åker runt med flera högupplösta kameror och tar bilder på vägarna. Allt det här görs sedan automatiskt om till 3D-modeller. Däremot om någon typ av semantisk information om byggnader eller liknande önskas, så måste det läggas till manuellt, eftersom det enda som skapas är själva modellen. På hitta.se har samma företag gjort en översiktlig 3D-modell av Stockholm där det går att se 3D-modellen från luften, dock i mycket lägre detaljrikedom och precision. Denna modell är uppbygg med hjälp av kameror som är fästa på flygplan istället för bilar. Det finns även andra städer än Stockholm modellerade med denna teknik. Franic (Franic, Bacic-Deprato, och Novakovic, 2009) har gjort ett liknande system för att skapa 3D-modeller av städer, men de har ett annat mål än C3 Technologies. Istället för att fokusera på den digitala modellen av 3D-modellen, var de mer intresserade av att skapa en fysisk 3D-modell över hela staden istället. För att samla data använde de en liknande metod som C3 Technologies använde för att generera 13

22 KAPITEL 2. TEORI en modell som var tänkt att ses från luften och också med begränsad grafisk kvalité. De använde sig av true orthofoto, vilket innebär att det går att få, med hjälp av flera olika flygfoton tagna från olika håll på samma plats, en bild där nästan inga byggnader är skymda av andra byggnader. Därefter analyseras höjder och takformer för att generera staden. Det hela är till stor del gjort automatiskt, men inte lika automatiskt som i C3 Technologies lösning. Den fysiska modellen byggdes med hjälp av en 3D printer och modellen ställdes ut i stadshuset i staden Zagreb, vilket var målet vid skapandet av 3D-modellen. Müller (Müller, Wonka, Haegler, Ulmer, och Van Gool, 2006) har en annan inriktning på automatiserad generering av byggnader, här utgår Müller inte från en befintlig stadsmodell, utan vill kunna generera en stadsmodell för användning i till exempel tv-spel eller filmer, se figur 2.5b. När programmet genererar de stora stadsmodellerna finns ett antal regler som används för att det ska se naturligt ut. Programmet utgår från grundläggande geometrier som till exempel kuber, cylindrar och liknande för att bygga husen, som sedan kompletteras med texturer. Även genereringen av texturerna måste följa vissa regler, eftersom risken annars finns att till exempel bara ett halvt fönster kommer med på grund av att hänsyn inte togs till byggnadens längd eller att det helt enkelt inte blev symmetriskt. Även snappning används, det vill säga att ytorna kopplas ihop till varandra på ett bra sätt, till exempel så att de kommer kant i kant Professionella system På marknaden finns det idag mängder med professionella system för 3D-modellering, men de är i allmänhet utanför räckvidden för en vanlig person utan större datorvana. Till viss del på grund av kostnaden som de flesta av dem innebär, men också på grund av att de har så mycket funktioner att inlärningskurvan blir mycket brant. Om en användare väl har lärt sig använda dem finns det inte så mycket begränsningar på vad som kan göras, men att komma till den nivån av kunnande i de här programmen tar lång tid. Exempel på professionella 3D-modelleringsprogram är Maya (Autodesk Maya, 2009), Blender (Blender Foundation, 2009) och AutoCAD (AutoCAD, 2009). I figur 2.6a kan ni se vad som kan åstadkommas i Maya och i figur 2.6b kan ni se vad som kan åstadkommas i Blender. AutoCAD är mer inriktat på tekniska byggnadsritningar av olika slag, medan Blender och Maya är mer inriktade på 3Dmodellering för användning i bilder, spel, filmer och andra visualiseringar. Maya och AutoCAD kräver en betydande investering i inköpskostnad och används därmed oftast bara av företag samt användare med stort intresse för 3D-modellering. Blender däremot är öppen källkod och därmed gratis att använda, men har fortfarande en hög inlärningströskel, precis som de andra två programmen. 14

23 2.4. MODELLERING I 3D (a) (Resident Evil 5, 2010), skapad med hjälp av Maya (b) (Kamil (maqs) Makowski, 2010), skapad med hjälp av Blender Figur 2.6: Här kan ni se vad som kan gå att åstadkomma med professionella system som Maya och Blender Andra möjligheter Det finns även förenklade versioner av 3D-modelleringsprogram som oftast använder de professionella 3D-modelleringsprogrammen som förebild. Däribland finns Google SketchUp (Google SketchUp, 2009) som på flera sätt fungerar som en begränsad version av de professionella 3D-modelleringsprogrammen. I programmet går det att ladda in kartbilder från Google Earth (Google Earth, 2009) och med de bilderna som grund kan användaren skapa sin modell, för att slutligen ladda in modellen i Google Earth. Det går även att använda färdiga 3D-modeller från Google Warehouse som går att kombinera ihop med det som skapats i Google SketchUp. Ikeas rumseditor (IKEA HomePlanner, 2009) har däremot gått en annan väg, de tillåter i princip inte användaren att verkligen modellera, utan endast använda färdigmodellerade objekt och placera ut dem. Verktyget används för att användare ska kunna inreda sitt kök, arbetsplats eller sovrum med möbler från IKEA. Då IKEA har ett visst sortiment med möbler som de vill att användaren ska ha i sitt rum är det enkelt att utgå från färdiga modeller av dem, men de har även exempelvis spisar och liknande med olika standardmått, så att det går att se helheten i köket, även om användaren har saker som inte är köpta på IKEA. En annan intressant detalj med programmet är att modelleringen sker i första hand i 2D och att det sen går att titta på det som modellerats i en 3D vy. Detta fungerar bra, eftersom att höjden på alla de färdiga modellerna redan är förbestämd. Både boplan.se (boplan.se, 2009) och Dragonfly AutoDesk (Dragonfly Autodesk, 2009) har liknande system som IKEA med färdiga modeller som placeras ut, men på boplan.se finns det än så länge ingen 3D funktion. 15

24 KAPITEL 2. TEORI Gissning Skissa i 2D Byggklossar Bildanalys Gester Regler Automatik Dragonfly - X X boplan.se - X X ikea - X X AutoCad D X X - - D D Blender D D X - - D D Maya D D X - - D D SketchUp D - X Müller - - D - - X X Franic X - - X C X - - X Zeleznik X - - Sebe - - X X - - D Funkhouser - - X Bae X X Igarashi X X - Tsang X - - D Tabell 2.1: I denna tabell går det att se vilka sätt de tidigare nämnda modelleringsprogrammen modellerar på. Detta är dock endast författarens personliga tolkning, då många av programmen ligger på gränsen mellan olika modelleringssätt, och ska därför inte tas som fakta. X = använder sig av det D = använder sig delvis av det - = använder det inte alls 2.5 Utvärdering och utveckling av prototyper Allmänt om utvärdering och utveckling av prototyper När system skapas som ska användas av en användare utan större erfarenhet inom det berörda området måste stor vikt läggas på hur programmet utformas, för att försäkra sig om att användarna kommer att tycka om programmet samt kommer kunna använda det som det är tänkt. Att följa designriktlinjer och genom hela utvecklingen av systemet och tänka på hur användaren skulle kunna reagera på förändringar är så klart viktigt, men det räcker oftast inte. Att ha användare som testar programmet under tiden är att rekommendera, och det görs bäst genom att flera olika prototyper utvecklas, följt av användartest, vilket ni kan läsa mer om nedan. 16

25 2.5. UTVÄRDERING OCH UTVECKLING AV PROTOTYPER Designprinciper Sharp (Sharp, Rogers, och Preece, 2007) nämner några viktiga designprinciper för design av program: synlighet återkoppling begränsningar koppling mellan kontroll och effekt konsekvent Med synlighet menar Sharp att det är bra att göra funktioner och information så synlig som möjligt. Om information göms är nämligen risken stor att användaren inte kan hitta den informationen de letar efter eller i värsta fall kanske användaren inte ens förstår att den informationen finns tillgänglig. Det ska även vara enkelt för användaren att förstå förhållandet mellan olika kommandon och deras funktion, annars kan användaren bli förvirrad. Sharp menar även att det är viktigt att användaren får en återkoppling på vad den gör i programmet. Om till exempel användaren använder en funktion och sedan inget händer på flera sekunder, så kommer användaren att börja undra om något verkligen hände eller om han/hon gjorde något fel. Därför är det viktigt att åtgärda dessa problem, för att säkerställa att användaren hela tiden vet vad som händer. Det kan göras genom att meddela användaren att en funktion håller på att utföras och även meddela hur lång den beräknade tiden för operationen är eller helt enkelt se till att funktionen utförs utan väntetid. Att begränsa vad användaren kan göra vid olika tillfällen är även viktigt enligt Sharp, eftersom det minskar risken att användaren försöker utföra en operation som inte är tillgänglig för tillfället, samt ökar användarens förståelse av vad det finns för valmöjligheter för tillfället. Med koppling mellan kontroll och effekt menas till exempel vad en knapptryckning får för effekt i programmet. Det innebär inte bara att det ska vara enkelt att förstå vilken funktion som ger vilken effekt, utan även att fastställda konventioner bör följas i de fall där det finns. Om användaren är van vid att en viss funktion aktiveras av en viss knapp i andra program kommer användaren anta att samma sak gäller i detta program. Att ett program är konsekvent innebär att en viss typ av kommandon alltid leder till samma funktion, till exempel är det konsekvent om markering av objekt alltid utförs på samma sätt. Ett typiskt exempel på inkonsekvens är när knappen 17

26 KAPITEL 2. TEORI för att avsluta programmet ibland heter avsluta, i andra fall heter den stäng, vilket kan få konsekvensen att användaren undrar om de faktiskt gör samma sak. Ett system som är konsekvent är lättare att lära sig att använda och det är lätt att åstadkomma i små system, men i stora system där många personer är inblandade krävs det bra samordning mellan de olika utvecklarna för att vara säker på att allt är konsekvent Utveckling av prototyper Prototyper är en viktig del av utvecklingen och redan på ett tidigt stadium bör prototyper användas. Till en början går det att till exempel göra en enkel pappersprototyp som bara visar hur menysystemet är tänkt att fungera samt demonstrera grundläggande funktionalitet. Därefter bör utvecklingen fortsätta med mer och mer avancerade prototyper och hela tiden ha kvar de lärdomar som kommit fram ur tidigare prototyper. Det finns två olika typer av prototyper som går att rikta in sig på, nämligen vertikala och horisontella prototyper. En vertikal prototyp är en prototyp som fokuserar på några enstaka funktioner och är relativt detaljerad på dessa funktioner (men inte färdig), medan övriga funktioner kanske inte fungerar alls. Denna typ av prototyp passar att använda om någon speciell del är extra viktig, förväntas bli problematisk eller liknande. En horisontal prototyp är mer inriktad på att se om en design i allmänhet är bra eller inte. Den går inte djupt in på någon funktion, som exempel går det att tänka sig ett menysystem där endast de mest grundläggande menyalternativen finns att välja, de som ligger längre ner i menyhierarkin är inte implementerade Utvärdering och användartestning Usability means that the people who use the product can do so quickly and easy to accomplish their own tasks. (Dumas och Redish, 1993) Användbarhet definieras som, vilket ovanstående citat pekar på, hur en produkt eller tjänst ska utformas så att användaren kan utföra sina uppgifter så snabbt och enkelt som möjligt, samt att de ska vara nöjda efter att ha gjort det. Dumas (Dumas och Redish, 1993) påpekar att det är lätt att som designer anta att man förstår hur en användare tänker, men det är sällan fallet. Designern är oftast mer tekniskt kompetent inom området plus att han/hon dessutom har designat produkten. Designern själv är medveten om hur allt ska göras på ett bra sätt, men det är inte alls säkert att användaren tänker på samma sätt. Figur 2.7 visar på ett bra sätt hur saker kan missuppfattas. Alla delar i bilden är så klart inte kopplade till 18

27 2.5. UTVÄRDERING OCH UTVECKLING AV PROTOTYPER användartestning, men flera av problemen skulle kunna minskas med användartestning. Man ska alltid komma ihåg att det är användaren som bestämmer vad som är användarvänligt enligt Dumas. Dumas menar att användarvänlighet integreras i produkter genom att hålla följande saker i tankarna: fokusera tidigt och kontinuerligt på användarna tänka på alla aspekter av användarvänlighet under designen testa versioner tidigt och kontinuerligt på användarna iterativ designfas Dumas menar också att användbarheten ska testas genom användartester, vilka oftast utförs av en användare i taget med en observatör som står i bakgrunden och passivt observerar och noterar vad användaren gör och hur användaren reagerar på olika delar i programmet. Det första som görs är att bestämma vilken målgruppen för produkten är och sedan hitta relevanta personer att ha som testpersoner. Det är viktigt att rätt målgrupp identifieras, eftersom det annars inte går vara säker på att resultatet blir korrekt. Nästa steg är att förbereda testet (om det till exempel behövs specifik utrustning eller liknande) samt att göra frågeformulär. Normalt sett inleds testet med ett frågeformulär då testledaren bekräftar att testpersonen är rätt målgrupp samt får extra information om det skulle behövas. Ett frågeformulär brukar också ges ut efter testet där lite frågor ställs om hur det gick under testet, vad testpersonen tyckte om produkten och liknande. Det kompletteras ofta med en intervju efteråt. Under själva testet håller sig observatören i bakgrunden och noterar allt av intresse som testpersonen gör, som till exempel om testpersonen går in i fel menyer när han/hon letar efter en funktion, om han/hon verkar vara tveksam eller likande. Oftast instrueras testpersonen att prata högt för sig själv och säga allt han/hon tänker på under testet, så att observatören får en inblick i hur testpersonen tänker. Ett alternativ till att stå passivt och lyssna är att gå in vid passande tillfällen och fråga testpersonen hur den tänker i just den situationen, men utan att ha ledande frågor som kan påverka svaret. Ett annat alternativ är att ha två testpersoner som testar en produkt samtidigt och sedan lyssnar testledaren på när de pratar om hur de ska göra. Det känns ofta mer naturligt för testpersonerna än att sitta och prata högt för sig själva. Dumas anser att användartestning är mycket viktigt, eftersom fel då kan upptäckas på ett tidigt stadium, då det fortfarande inte krävs så mycket arbete att fixa dem. Allra värst är det om produkten redan finns ute hos en kund när felet upptäcks. 19

28 KAPITEL 2. TEORI Figur 2.7: Det här är vad som kan hända om användartestning inte används, bild från (coactivate.org, 2010) Dumas menar att kunden får då sämre förtroende för företaget när de släpper produkter som inte fungerar ordentligt/inte är tillräckligt användarvänliga, samt att det troligtvis kommer bli flera gånger dyrare för företaget att åtgärda felet sent, än om det hade blivit upptäckt på ett tidigt stadium. Därför finns det mycket att vinna på att ha användartestning, även om det tar tid och kostar pengar. 20

29 Kapitel 3 Metod 3.1 Allmänt om val av metod Författaren har valt att använda sig av kontinuerlig utveckling av prototyper samt att göra användartestning på varje ny prototyp. Det är för att säkerställa att användare utan någon större förkunskap kan använda programmet och utnyttja dess funktioner på ett bra sätt. I det här fallet är det extra viktigt då de tilltänkta användarna i de allra flesta fallen inte har någon som helst tidigare erfarenhet av 3D-modellering. När det gäller till exempel hemsidor har användare redan en viss vana från hur hemsidor brukar se ut, men vanor av den typen går ej att utnyttja i det här fallet. Med hjälp av användartestning och prototyper går det på ett tidigt stadium att se om programmet är på väg åt rätt håll. Att testa nya funktioner tidigt är viktigt, annars kanske mycket tid och energi läggs ner på något som användaren i slutändan inte kommer att förstå/använda, vilket kan leda till att det måste göras om. När det gäller skapande av prototyper har författaren valt att sikta i första hand på horisontella prototyper, eftersom i det här fallet är huvudsyftet att se om ett program av denna typ skulle kunna vara värt att skapa. Då är det bäst att inrikta sig på att skapa ett program med de viktiga grundläggande funktionerna istället för att rikta in sig på att göra enskilda funktioner perfekta/fullständiga. 3.2 Val av teknik Författaren vill i det här fallet kunna göra flera prototyper snabbt inom en kort tid, där fokus i första hand ska ligga på att testa hur pass komplicerat det är för utvecklaren att implementera olika funktioner i modelleringsverktyget samt hur användarna reagerar på de olika funktionerna. Därmed anser författaren att det är viktigt att sikta på en utvecklingsmiljö som är snabb att utveckla i och där utvecklaren behöver lägga minimal tid på att sätta sig in i själva utvecklingsmiljön. Av det följer att OpenGL programmering direkt mot C/C++ inte är lämpligt i det 21

30 KAPITEL 3. METOD här fallet, då det är det krångligaste alternativet av de undersökta alternativen, eftersom utvecklaren skulle behöva utveckla allt själv från grunden. Nästa fråga som är viktig är att den valda tekniken är oberoende av operativsystem och helst att den ska enkelt gå att starta direkt från webbläsaren med minimal ansträngning från användaren. Här faller Microsoft XNA bort, på grund av att det endast fungerar på Windows, Xbox360 och Zune. Det lämnar endast Java3D och jmonkeyengine som alternativ. De bygger båda på en liknande grund och har flera likheter, men det finns en del betydande skillnader. En av de mest avgörande är att Java3D används mycket lite numera, vilket innebär att det finns lite information om hur det används samt få/inga aktiva forum. Samtidigt är jmonkeyengine relativt nytt och nya guider kommer hela tiden, samt att forumet är ovanligt aktivt. Det är saker som kan vara avgörande i hur snabbt det går att komma igång och börja göra prototyper. JMonkeyEngine har dessutom många färdiga funktioner som är bra även i allmän 3D programmering, medan Java3D endast har några få av alla de funktionerna. JMonkeyEngine visade sig alltså vara det bästa alternativet för det här projektet och är därför det som har använts. 3.3 Val av modelleringssätt Val av modelleringssätt är en viktig del, eftersom det kommer bestämma huvudinriktningen på projektet. Något som direkt går att utesluta är automatisk generering av 3D-modeller, då det inte fyller någon större funktion i det här fallet. Däremot är valet mellan olika skissbaserade applikationer och de mer professionella applikationerna för 3D-modellering svårare. De skissbaserade applikationerna som använder bland annat bildanalys och de som använder sig av gissningar på vad användaren ska göra är mycket intressanta. Det stora problemet med den typen av applikationer dock är att de kräver en betydande satsning då det är komplicerat att få det att fungera för allmänna tillämpningar. Därför går författaren åt samma håll som till exempel Google SketchUp gått, det vill säga mot en förenklad version av de professionella applikationerna för 3D-modellering. Det stora problemet med dessa program är att de inte är användarvänliga och har en hög inlärningskurva, vilket leder till att det måste utvecklas ett sätt att skapa saker enkelt och snabbt, men ändå kraftfullt. Att sätta begränsningar på vad användaren kan göra är en grundsten, då programmet annars skulle bli alldeles för komplicerat för användaren. 3.4 Användartestning Författaren har valt att efter varje färdig prototyp genomföra användartester för att utvärdera hur användarna tycker det är att använda programmet samt hur pass 22

31 3.4. ANVÄNDARTESTNING bra det går och vad de inte förstår. Tidigare nämnda teknik då testledaren står bakom testpersonen och observerar vad han/hon gör, men utan att ingripa om det inte absolut är nödvändigt valdes. Egentligen bör det finnas speciella personer som övervakar testen som inte har varit med och utvecklat programmet i fråga, men eftersom författaren är ensam i det här projektet går det tyvärr inte att göra. Det ska i övriga fall undvikas för att minska risken att utvecklaren går in i försvarsposition och försöker försvara sina lösningar istället för att ta till sig kritiken. Författaren valde även att använda både användartestning med endast en testperson (då testpersonen måste säga vad den tänker högt hela tiden) samt användartestning med två testpersoner, där det istället går ut på att testpersonerna ska prata om allt de gör i programmet och på så sätt låta testledaren veta vad de tänker och tycker. Anledningen till att välja båda är att författaren anser att båda sätten är intressanta samt att de möjligtvis kan göra att nya problem kan komma fram, som bara framkommer om testpersonen sitter själv/tillsammans med någon. De båda sätten motsäger inte heller varandra på något sätt, vilket innebär att det inte är något problem att göra dem parallellt, så länge inte en större undersökning ska göras, där statistik över testet ska sammanställas. I de fall statistik ska sammanställas bör användartesterna likna varandra så mycket möjligt, eftersom de ska vara jämförbara. I det här fallet anser författaren inte att en storskalig statistisk undersökning är rimlig att utföra. Anledningen är att programmet i sig inte kommer uppnå en sådan omfattning att det behövs (de flesta större problemen kommer att komma fram i relativt få användartester om testpersonerna är relevanta) samt att det då skulle krävas mycket tid till användartestning. När det gäller val av testpersoner har författaren valt att fokusera på testpersoner i års ålder, då de troligtvis är de som är vana vid att använda datorn dagligen som kommer att använda den här applikationen. Även några från åldrar över och under intervallet ska vara med i användartestningen för att se hur stor skillnaden är mellan åldrarna. Vissa kan ha tidigare erfarenhet av modellering, eftersom det kan vara intressant att se hur de reagerar på programmet, då även de ingår i en tilltänkt användargrupp. Egentligen är den möjliga användargruppen mycket stor, då det som i första hand testas är förståelsen för hur programmet fungerar, eftersom inga förkunskaper, förutom grundläggande datorkunskaper som hur en webbläsare fungerar och liknande, ska krävas för att använda programmet. 23

32

33 Kapitel 4 Genomförande 4.1 Planering av prototyper I normala fall skulle det varit bra att inleda arbetet med en pappersprototyp eller någon annan enkel prototyp, men i det här fallet ansåg författaren att det inte var värt det. Anledningen är att i ett 3D-modelleringsprogram kommer menysystemet, åtminstone till en början, få en underordnad roll. Menysystem är relativt enkla att göra pappersprototyper på, då testledaren ofta kan simulera effekten av en knapptryckning med hjälp av att byta papper. När det gäller 3D-modellering är det hela mycket svårare, eftersom det finns få fasta steg i skapandeprocessen. Troligtvis kommer testledaren inte att ha möjlighet att få till test som är tillräckligt relevanta för att de ska vara till någon större användning. Utav den anledningen gjordes det första användartestet först efter att den första riktiga prototypen var färdig. Författaren valde att utgå från de program som redan finns och fundera på hur det går att göra dem mer lättanvända och självklara för användaren, istället för att göra en enkel prototyp. Det ska också nämnas att utvärderingen av varje ny prototyp utfördes med nya testpersoner. 4.2 Prototyp och utvärdering Allmänt om prototyperna Mest tid ägnades åt prototyp 1, eftersom viss grundfunktionalitet måste finnas på plats för att det ska vara någon idé att göra användartester, samt att det krävdes en del tid att vänja sig vid programmerings-api:et. Vid användartesterna hade testpersonerna tillgång till en snabbguide för hur de skulle använda de olika funktionerna i programmet, men blev tillsagda att endast läsa guiden om de inte kunde förstå hur de skulle göra. I samtliga fall fick de dock läsa hur kameran skulle hanteras, då författaren redan innan visste att det inte var helt uppenbart hur den fungerar. I 25

34 KAPITEL 4. GENOMFÖRANDE övrigt fick de olika uppgifter att utföra i programmet under de tre användartesterna, där uppgifterna för varje prototyp blev lite mer komplicerade samt lite mer fria för tolkningar. Utav de olika modelleringssätt som nämns i tabell 2.1 på sidan 16 är det endast till viss del byggklossar och gissning som är implementerat i dessa prototyper, vilket påminner mycket om hur SketchUp fungerar Prototyp 1 Funktioner som var implementerade i prototyp 1: Skapa och ta bort grundläggande geometrier (boxar och cylindrar) av godtycklig storlek. Kontroll över kameran. Förflyttning av objekt. Snappning (om ett objekt användaren flyttar är tillräckligt nära ett annat objekt kommer programmet att föreslå att objekten ska placeras kant i kant, kanterna med kortast avstånd väljs). Förflyttning av flera objekt samtidigt. Uppgiften som testpersonerna skulle utföra i det här användartestet var att skapa en garageport, gärna med väggar, men en garageport med bara ett tak och fyra pelare var också godkänt. Under användartestningen av första prototypen hade samtliga testpersoner problem med att skapa objekt (förutom de som deltog i det sista användartestet av första prototypen, som hade fått en förbättrad version). Anledningen till det var att för att skapa till exempel en ny box ritar testpersonen först upp basen på boxen. Det åstadkoms genom att först välja en punkt som motsvarar ena hörnet på boxen och sedan håller testpersonen in musknappen och drar ut storleken på basen av boxen, för att till sist släppa musknappen när önskad storlek på basen är uppnådd. Medan testpersonen håller in musknappen och väljer storlek på basen ritas också basen ut för att det hela tiden ska gå att få en uppfattning om hur stor den blir. Problemet var att testpersonerna inte insåg att musknappen behövde hållas in och därmed skapade en minimal box som knappt syntes. Det ledde till att de trodde att det var något fel på programmet eller att de hade gjort fel. Även när höjden skulle bestämmas på boxen blev det problem, då höjden skulle justeras genom att testpersonen tar tag och drar i en röd pil som pekar uppåt, vilken uppenbaras ovanpå boxen när storlek på basen har blivit vald. Ingen av testpersonerna insåg att man skulle dra i pilen och eftersom programmet låste alla andra funktioner tills en höjd blivit vald ledde det till att testpersonerna trodde att programmet hade låst sig. 26

35 4.2. PROTOTYP OCH UTVÄRDERING Det problemet åtgärdade författaren innan sista användartestet i den här prototypen, då det var ett så pass uppenbart problem som alla testpersoner hittills hade upplevt. Lösningen var att musknappen aldrig behövde hållas inne, utan istället väljs första hörnet i basen, därefter börjar automatiskt storleken ändras i basen, vilket leder till att testpersonen ser att något händer om de börjar röra på musen. Nästa klick låser basens andra hörn och den går direkt över till att välja höjden på samma sätt, vilken låses av ett tredje klick. Efter den här ändringen var det aldrig några större klagomål på skapandet av objekt, flera tyckte även att det var bra och enkelt och insåg det snabbt genom att testa sig fram. En annan sak som testpersonerna ville göra var att kunna skapa objekt ovanpå andra objekt och när det inte fungerade blev vissa ställda, andra tog initiativet att skapa objektet på marken och sedan flytta upp det till rätt höjd. Förflyttningen av objekt medförde också vissa problem. Det implementerades genom att det var en pil i var och en av de tre koordinataxlarna, och om testpersonen drog i en av pilarna förflyttades objektet längs den koordinataxeln. Problemet var åter att förstå att det gick att dra i pilarna. Alla förstod det efter lite testning, men vissa kunde lista ut det direkt. De flesta önskade alternativa sätt att flytta saker på, helst bara genom att ta tag i objektet och röra på musen. Det kan också nämnas att de flesta professionella 3D-modelleringsprogram använder sig av liknande lösningar med pilar för att förflytta objekt. Alla ansåg att kameran var svåranvänd, men det hade författaren räknat med, eftersom den var baserad på en färdig kamera som egentligen var gjord för 3D-spel och inte för 3D-modellering. Anledningen till att författaren använde den här kameran trots allt var att det är svårt att göra en riktigt bra kamera samt att det tar lång tid, och därför ansåg han att det var bättre att satsa på själva 3D-modelleringen i stället. Andra mindre problem/önskningar: Mindre problem med menyknapparna. Markeringarna för när objekt dras till varandra vid snappning (det var en röd markering på var och en av de två kanter som skulle dras till varandra). Önskemål om en knapp i menyn för markering av flera objekt (endast personer med datorvana insåg att det gick att markera flera objekt med ctrl knappen). Önskemål om att kunna skapa till exempel fönster och dörrar. Önskemål om att få en undo/redo knapp för att kunna ångra utförda kommandon. Önskemål om möjlighet att kunna kopiera objekt. 27

36 KAPITEL 4. GENOMFÖRANDE Figur 4.1: Bild som testpersonerna skulle efterlikna i prototyp 2. Saker testpersonerna gillade under användartestet var till exempel förflyttningen och sättet objekt nära varandra dras till varandra vid förflyttning, även fast de hade svårt att förstå funktionerna från början. Även markering av vilket objekt som användes för tillfället ansåg de var bra. Överlag anser författaren att användartestet samt prototypen var relativt lyckade. För det första var de saker som testpersonerna hade störst problem med möjliga att åtgärda. För det andra var det bra att författaren fick kännedom om dessa problem tidigt i utvecklingen, då det är mycket lättare att åtgärda problemen i början innan mycket tid lagts ner på att förfina idéerna Prototyp 2 Förbättringar i prototyp 2 baserat på kritik från första prototypen: En kamera mer anpassad för 3D-modellering, dock fortfarande inte helt lättförståelig. En ny meny för att kunna ha fler menyalternativ. Från början var tanken att ha få menyalternativ för att det mesta skulle vara självförklarande, men det visade sig att testpersonerna föredrog att ha en meny att bläddra i, eftersom om de inte förstod något kanske de kunde hitta ett menyalternativ som gjorde vad de önskade. Skapande av fönster och dörrar. Antalet problem var uppenbart mycket färre i den här prototypen, vilket innebär att förbättringarna som infördes efter första användartestet gett effekt. Uppgiften testpersonerna fick var att försöka komma så nära som möjligt att modellera ett hus som författaren i förväg modellerat i samma program, se figur 4.1. Ett problem som uppkom var att de nya menyerna blir lite för små vid höga upplösningar, vissa upptäckte inte den först, andra missade ibland ett menyalternativ 28

37 4.2. PROTOTYP OCH UTVÄRDERING p.g.a. att menyn var för liten. Andra mindre problem/önskningar: Fortfarande problem med markering vid snappning. Omformuleringar av vissa menyalternativ som ansågs förvirrande av flera testpersoner. Önskemål om att få en undo/redo knapp för att kunna ångra utförda kommandon. Önskemål om möjlighet att kunna kopiera objekt. Skapande av boxar ovanpå/på sidan av befintliga boxar önskas fortfarande. Bortsett från några problem med den nya menyn och lite med den nya kameran uppkom inga direkta nya problem som inte redan kommit fram i föregående användartestning. Alla testpersoner visade att de hade kunnat skapa huset i figur 4.1 om de hade varit lite noggrannare (för att användartesterna inte skulle ta för lång tid behövde de bara visa att de förstod funktionerna och hur de skulle skapa huset, sen hur estetiskt snyggt det blev spelade ingen roll) Prototyp 3 Till den avslutande prototypen lades en hel del önskemål sen tidigare till: Möjligheten att skapa objekt ovanpå/på sidan av befintliga boxar. En enklare funktion för att flytta objekt för att komplementera den vanliga (den enkla har begränsningar). Den går ut på att objektet flyttas längs det plan det skapats, d.v.s. om objektet skapades på marken kan det endast flyttas Figur 4.2: Bild som testpersonerna skulle efterlikna i prototyp 3. 29