Senaste inläggen

Av b4 - 3 april 2013 13:14

   Jag vill börja denna utvärdering med kritik eftersom det är psykologiskt tilltalande att börja med det negativa för att sedan gå över till något positivt och lämna läsaren med en naggande god sötma i sinnet snarare än tvärtom. Eftersom detta dessutom är en kurs i interaktionsdesign med användaren, läsaren i det här fallet, i fokus är denna handling ett exceptionellt gott sätt  på vilket jag manifesterar min entusiasm inför ämnet. Kamratbetyg är området jag ämnar kritisera och jag börjar med att ifrågasätta om det ens är regelrätt att belasta eleven med detta? Ibland misstänker jag att det är KTH's bristande resurser som gör att examinatorer tvingas till detta knep men oavsett om det stämmer eller inte anser jag att det är ett felaktigt sätt att examinera elever på och det som gör det hela ännu märkligare är att det även är betygsgrundande!? Så även om jag har utfört ett mycket gott arbete under kursens gång och behandlar ämnet med bravur men vägrar sätta betyg på mina kamrater får jag ett dåligt betyg? Då har man verkligen kommit till en punkt där man kan börja fråga sig vad kursens betyg egentligen är ett mått på...

    Om vi nu ska ta kursens gång i övrigt tycker jag att det har varit ett mycket intressant tillfälle att få prova på vad MDI är samt hur en designprocess går till. Så mycket mer än så är det inte rimligt att se det som när det handlar om en sexpoängskurs men så länge man ser det som det är jag ganska nöjd. Att göra ett seriöst och djuplodande förarbete till detta fanns det definitivt inom kursens ramar ansats till men huruvida man ska låtsas att detta i slutändan verkligen motsvarat en dylik undersökning på ett stort företag i dagens samhälle eller ej låter jag vara osagt. Jag kan föreställa mig att den fasen hade kunnat ta 2-3 månader bara den och för oss skulle den vara över på ett kick. Resten av processen kan jag tänka mig i sitt huvudutförande påvisade mer rättvist hur det i jämförelse med arbetslivet kan gå till ute i världen idag men eftersom det hela byggts på "instabil grund" så att säga anser jag ändå att man fick ta det hela för vad det var. Vi hade kunnat ha utförligare användarstudier som underlag till alla våra grundbeslut och detta känns bättre att vara öppen med snarare än tvärtom.

    Det viktigaste och mest intressanta under kursens gång var samarbetet med gruppkamraterna, hur olika roller uppstår och förmågan att inte bli förlamade och inte kunna ta beslut för att folk vill och tycker olika saker. Vikten av att kunna tänka ur ett annat perspektiv samt att bli varse dessa andra perspektiv i samband med att testpanelen fick komma med kritik var också en viktig del för att inte tala om den slutgiltiga prototypprocessen när det hela till sist kom till liv. Samarbetet i vår grupp har fungerat bra och jag tycker att alla på ett eller annat vis bidragit. Vi har kompletterat varandra men jag kan också lätt förstå att det i vissa mindre lyckade konstallationer kanske blir så att man inte kommer någon vart och nästan motarbetar varandra.... MDI handar mycket om psykologi; gruppsykologi när man arbetar och beteendepsykologi när man utformar. På så vis är det ett humanistiskt ämne i allra högsta grad men till viss del också godtyckligt och nästan kvasivetenskapligt i mina ögon eftersom människans förståelse för sin omvärld ständigt är under utveckling till följd av nya uppfinningar och konventioner och det därför egentligen inte finns något vetenskapligt "rätt" eller "fel" att falla tillbaka på som är vattentätt i alla lägen.

    Inför mitt framtida arbetsliv känner jag mig definitivt mer rustad för den här typen av process och jag kan känna att jag har förändrats i mitt tänk till följd av mycket som påpekats under kursen. Bara vikten av att sära på designprocess och implementationsprocess är en sanning som under lång tid framöver kommer att runga i mitt sinnes gröna dalar och förhoppningsvis i förlängningen innebära att det i ett framtida arbete blir lättare att skilja på arbetsrollerna som designer och programmerare... För om jag ska vara ärlig tror jag att det är möjligt att axla båda dessa roller samtidigt, även om kurslitteraturen menar att vi programmerare ska överlåta den renodlade designprocessen till någon med estetisk utbildning som tack vare denna kan komma att se och förstå saker som vi simpla tekniker blott kan drömma om!

 En anekdot... På mitt jobb har man köpt in ett väldigt dyrt arbetsfordon för närmare åtta miljoner kronor. Detta fordon är i sin funktion fulländat men användarvänligheten och -glädjen är i stort sett obefintlig. Tunn, billig ratt med plastiga knappar och symboler som betyder olika saker beroende på var man ser dem. För att inte tala om bristen på feedback till användaren när det gäller aktiverade och avaktiverade funktioner vilken är väldigt svår att dra några slutsatser av. Mörkrädd blir jag när jag inser att tyska ingenjörer inte förmår tillämpa sådana grundläggande tankar inom design som dem vi lärt oss inom loppet av några månader...

    Mina slutord blir att konstatera att jag är glad att jag fått lära känna och samarbeta med medlemmarna i min grupp och att detta ändå är en bra kurs väl värd sin tid men att kamratbetyg som del i examinationsmomentet är under all kritik. Den viktigaste kunskapen jag tar med mig på resan är blotta vetskapen om detta områdes existens och vikten av att dess plats i en arbetsprocess faktiskt bör vara upplyst och välkänd eftersom försummelse av denna i slutändan blir det där som förtar en genialisk skapelse all dess charm...

 

Med hopp om bättring och tack för vad som varit,

 

Elias

ANNONS
Av b4 - 2 april 2013 23:22

Under övningen fick vi titta på Grupp 3:s projekt. De har designat en mobilapplikation liknande vår, som ska ge förslag på platser som turister kan besöka under deras tid i Stockholm. Det är värt att notera att gruppen hade redan vid utvärderingstillfället en online-prototyp gjord i FluidUI.


För att utvärdera deras applikation använde vi oss utav diskussionspunkterna som var givna i övningen powerpoint. Vi började högst upp och arbetade oss neråt och diskuterade varje punkt.


För att utvärdera flödet men även designen och kompositionen i mobilappen klickade vi oss omkring bland knapparna, för att simulera en användare. Vi noterade de tillfällen då vi tyckte att en knapp saknades, eller då knappar inte ledde oss dit där vi trodde att de skulle leda oss.


För att utvärdera om huvudfunktionerna är i fokus började vi först fundera vilka funktioner som var huvudfunktioner utifrån målgruppen. Sedan jämförde vi våra tankar om huvudfunktioner och vad vi tyckte var i fokus i prototypen.

ANNONS
Av b4 - 31 mars 2013 19:45

Nu har utvecklingsuppgiften nått sitt slut och vi har redovisat vår produkt för klassen. Om vi hade varit ute i arbetslivet kanske detta blott hade varit en startpunkt för en ny process och nya försök att hitta förbättringar inför nästa genomgång, men i vårt fall är det snarare en slutpunkt på såväl kursen som ett gott och intressant samarbete gruppmedlemmarna emellan. Kanske förvånades vi alla av att vår produkt inte fick fler röster än den fick, men å andra sidan verkade det som folk snarare tenderade att rösta på det beprövade och realistiska snarare än på det innovativa och banbrytande vilket kanske var lite tråkigt när allt kommer omkring. Inte för att vår produkt är så fantastiskt progressiv, men en liten känsla av "nyhet" finns det i alla fall över den...

    Vår process började i flera svagt formulerade idéer vilka i mångt och mycket var kompromisser mellan vad som kunde tänkas behövas på marknaden och vad som var realistiskt att genomföra. Efter en omgång intervjuer slopade vi många förslag och ändrade dessutom målgrupp till en mer generell och omfattande sådan. Vår initiala målgrupp, barnfamiljer, var relativt liten och svår att möta i intervjusammanhang och eftersom ingen av oss själva hörde till denna målgrupp tror jag att vi hade svårt att tänka oss vad som verkligen efterfrågades av denna. Mer och längre intervjuer hade varit nödvändigt men varken vår tid eller den tid som avsatts för kursen räckte till detta varför vi istället bestämde oss för att nöja oss med att ha med barnfamiljer som delmålgrupp i en ny större målgrupp. Till slut försvann de dock helt och hållet från kartan. Vår nya målgrupp blev i stort sett alla som reser men med en viss lutning åt weekendresenärer och sådana som inte haft tid eller engagemang att avsätta lång tid till att i förväg avgöra vad som är vettigt att göra på ett besök i en främmande stad.

    Nu följde en lång period av iterativa processer. Vi tog beslut och skissade på dem för att sedan komma på saker som borde ändras och återigen påbörja nya diskussioner. Vidare fick vi feedback från en testgrupp vilket var mycket både nyttigt och sporrande. I slutändan hade vi enats i de flesta beslut och jag tror att vi alla var ganska nöjda med den mock-up som vi lyckats ordna. Det mesta som ändrats under den senaste månaden hade att göra med antingen åtgärder av saker som fått kritik från testgruppen eller med mer eller mindre praktiska lösningar vilket alltså innebär att vi ändå stått fast rätt väl vid den teoretiska grundprototyp som etablerades i ett relativt tidigt skede.

    Vid redovisningen deltog vi alla och produkten hade i stort sett blivit vad vi föreställt oss; en app för att hitta platser av alla de slag, underhållen och skapad av sina användare. För sina användare. "SpotShare -Turistinformation på ett socialt sätt" blev vår slogan och även om vi kanske hade tvingats eller velat ändra på en rad saker om vi fortsatt projektet och fått i uppgift att implementera det är övertygad om att det även som det ser ut idag skulle bringat såväl Benjamin som Krystyna mycken nytta och nöje!


Väl mött!


// B4


PS! Länk till PDF som användes vid redovisningen: SPOTSHARE-PDF

Länk till mock-up: MOCK-UP DS!

Av b4 - 25 mars 2013 12:08

  Här har vi Benjamin!

Av b4 - 18 mars 2013 10:25

I fredags träffades vi för att göra klart det sista på prototypen. Det visade sig att vi överskattat mängden tillgängligt utrymme på en mobilskärm, och vårt gränssnitt var definitivt för komplext för att få plats på skärmens yta på ett sätt som är funktionsdugligt. Vi kollade på den funktionalitet som erbjuds just nu av de olika delarna i vår applikation, och flyttade en del mindre viktig sådan till undermenyer för att användaren inte ska distraheras i onödan när de försöker utföra en central handling (visibility-principen). Nedan är en genomgång om de designändringar vi genomförde under slutförandet av prototypen, och varför vi genomförde dem.


Kartskärmen

Bild och beskrivning slopades från bubblorna som öppnas vid klick av kartnål på kartskärmen. Anledningen till att vi från början hade denna information där var för att möjliggöra enklare jämförelse av olika platser direkt på kartskärmen så användaren inte behöver växla lika mycket mellan skärmar. Även om idén är god i sig så var det utrymmesmässigt inte genomförbart, och dessutom kanske inte en jätteviktig funktion för varesig Krystyna eller Benjamin.


Postsidan

Sidan för en egen post fick sig en rejäl upprensning. En av de största skillnaderna var att vi valde att flytta "närliggande platser", "visa taggar" och "visa på extern karta" till en undermeny. Tyvärr var inte dessa funktioner med i rankningen av funktioner som vi tidigare gjode för respektive persona, men trots det så bedömdes dessa funktioner inte vara centrala för Krystynas och Benjamins viktigaste behov: att hitta information om en plats. ("Få upp resultat på karta" i den länkade posten syftar på den inkluderade sökfunktionaliteten, och inte denna funktion.)


En annan förändring är att vi bytt ut mycket text mot ikoner: "rapportera inlägg", "bra post" och "bokmärk post" har alla bytts ut mot enbart ikoner (istället för enbart text eller ikon+text), för att spara plats och därmed göra gränssnittet mindre plottrigt. Exakt hur ikonerna ser ut avgörs förstås i samband med plattformen i fråga (för att förenkla för användaren att förstå innebörden av knappen utifrån tidigare erfarenheter), men skulle exempelvis kunna vara en flagga, en tumme upp och en stjärna, respektive.


Vi valde också att slopa dupliceringseliminieringsfrågan, på grunden att det är ett tekniskt problem, och att det helt enkelt inte gick att trycka in på den ytan. Dessutom är det ju inte någon funktion som direkt hjälper någon användare, varesig Krystyna eller Benjamin.


De andra lite mindre förändringarna på postsidan var att göra fotot större samt att rotera röstningsindikatorn till att fungera som en vertikal "termometer" snarare än att vara horisontell. Att göra fotot större hjälper att lägga fokus på den, som tillsammans med rubriken och beskrivningen utgör huvudinnehållet i posten. Det är att få tag på denna information som är centralt för hela appen, så det känns rimligt att ge den relativt stort skärmutrymme. Att rotera röstningsindikatorn, som visar hur folk bedömt en plats, var främst för att kunna göra upp- och nerröstningsknapparna större och därmed enklare att klicka på. En annan potentiell fördel är dock att de kan designas som en metafor av just en termometer, som stiger när någon röstar upp posten och sjunker när någon röstar ner den.

Av b4 - 7 mars 2013 15:15

Idag hade vi ett möte för att påbörja jobbet på prototypen. Vi gick igenom varje skärm, och antecknade alla sätt som man kan interagera med respektive skärm och vad dessa interaktioner ska leda till, för att se till att vi alla är överens om vad som ska hända och för att ha det samlat på ett ställe nu när vi påbörjar arbetet på high-fidelity-prototypen.


 === Startsida ===
 
  * Klicka på Login             => Tar fram login-popup och dimmar det som är under
                                   för att informera användaren om att de undre
                                   knapparna är inaktiverade
  * Klicka Sök i sökrutan       => Tar fram kartresultat  
  * Skriva/Klicka i sökrutan
  * Klicka på Hjälp             => Mer popups! Enkel hjälpsida. Back för att backa.
  * Pinch-zoom i tagcloudet
  * Klicka på tags              => Skriver in taggen i sökrutan
  * Trycka på Bookmarks         => Till kartresultat-skärmen  
  * Trycka på Share             => Tar fram inloggning, sedan tar fram Share-sidan
 
 === Share ===
  * Klicka på bilden            => Ta bild från kamera/filsystem
                                   Bilden ändras till den valda.  
  * Gråtext "Name of place"     => Gråtexten försvinner och man kan skriva   
  * Gråtext "Description"       => -----||----
  * Klick på tag-område         => Får fram tag-popup (bild senare)
  * Tag-område är vertikalt scrollbart
  * Klick på kartområde         => Får upp karta där koordinat kan ändras
  * Lägg till klar-knapp        => Posten läggs till i databasen
  * Tryck på Find               => Till Startsidan
 
 
 === Login-popup === (Overlay)


  * Flytta login upp
  * Toggleknappar för Facebook och Google som
    vilket konto man loggar in med.
  * Skriva i username
  * Skriva i password
  * Trycka på Login
  * Lägg till avbryt-knapp som avbryter => (tillbaka till startsida)
  * Vid faillogin kommer det upp rödtext
  * Klicka under overlayet för att avbryta också



 === Kartresultat ===
  * Swipea ut lista från höger-sak eller klicka på flärpen
  * Pinch-zoom (och inte pinch-zoom) och panning  
  * Klick på blob               => Få upp google maps-bubbla
                                    För grupper är det en lista på platser samt zoom-knapp
                                    För enskild plats fås bild fram samt beskriving och gå till post-knapp
                                   De bubblor som är öppna hamnas överst i listvyn och highlightas på något
  * Kryssknapp för bubblor
  * Inloggningsknapp            => Ta fram login-popup
  * Bakåt-knapp                 => Gå till startsidan
  * Sök-knapp                   => En popup (sökruta, innehåller den senaste sökningen)
  * Min positions-knapp         => Fokusera kartan på ens plats
 
  * Tryck på listelement        => Gå till post
 
 === Postsidan ===
  * Tryck på Koordinat-knapp    => Öppna i extern kartapp
  * Trycka på upvote/downvote
  * Tryck på "sök på närliggande platser" => Gör ny sökning med centrum på aktiva posten.  
  * Swipe till höger/vänster    => Ändra aktuell post
  * Klick på taggar             => Sökning?
  * Scroll på taggar (vertikal och horisontell/marqueeee?)
  * Tryck på Rapportera inlägg  => Öppna rapport-popup
  * Tryck på Rekommendera besk.
  * Tryck på Ja/Nej i Frågan    => Ta bort Frågan (ersättning med
  * Tryck på bokmärke           => Knappen ändrar utséende
 
  * Tryck på Bakåt              => Resultat
  * Inloggningsknapp            => Ta fram login-popup
 
 
=== Rapportera inlägg-popup ===
  * En rullgardin där kategorier kan väljas
  * Textfält för kommentarer under.
  * Avbryt och Rapportera-knappar
 
 
=== Allmänt för popups ===
  * Skärmen under dimmas
  * Klicka utanför för att stänga.
  * Swosha ner eller poppa upp?  
 
=== Beslut om bakåt-knapp === (åter igen)

Från en skärm så länkar bakåtknappen alltid till en annan specifik skärm. Den varierar inte baserat på historik. Vi valde detta för att vi inte vill att man ska behöva backa igenom en massa sökresultat för att komma dit man vill, och göra det tydligt hur man kommer tillbaka till t.ex. hemskärmen


Sökhistoriken löste vi istället genom att lägga in den i sökdialogen.


Ex:

Inne på Vasamuséet. Väljer närliggande platser och den gör en ny sökning. Nu är Vasamuséet centrerad och dess bubbla är öppnad från början så man kan enkelt gå tillbaka till Vasamuséet igen. Bakåt gör alltid en sak, som en riktad graf. Nu är det beslutat att bakåtknappen inte är en stack.


 
   
Vi började evaluera olika wireframe-verktyg bland annat Fluid UI (på bild), Balsamiq samt klipp-och-klistra-HTML+javascript. Just nu verkar vi luta mot Fluid UI, men innan vi fattar ett slutgiltigt beslut så ska vi titta lite noggrannare på vad som rekommenderas av bland annat boken, föreläsningarna och Google.

Av b4 - 4 mars 2013 17:59

Expertpanelen från den 27/2 som kom med feedback på vår produkt hade följande punkter att förmedla. Under varje punkt finns även vår uppföljning av frågan med. Röd text visar frågor som är viktiga eller kan vara viktiga för gruppen att betänka.


1. Listan behöver kopplas ihop med punkterna på kartan.

Detta var den klart mest omdebatterade frågan under dagens diskussion och den tog väl nästan halva tiden i anspråk. Vi hade tidigare debatterat frågan grundligt och utan att vara helt tillfredsställda nått beslutet att inte ha någon numrering av punkterna på kartan. Dessa skulle kopplas enbart till kartan då man valt en punkt eller en post i listan och skulle då markeras på såväl kartan som på listan. Detta visade sig dock vara lite ointuitivt och testpanelen tyckte alltså att detta var oklart vilket fick oss att ta upp frågan igen.


Vår problemformulering består i att vi vill indexera de fristående platserna i kartan som en sökning ger upphov till. Problemet är att i vissa fall ska ett kluster av funna punkter grupperas ihop och då ska en större punkt visas samt en siffra som anger hur många ihopklumpade punkter som denna representerar. Detta innebär ju att det skulle bli svårt att använda siffror både som indexering samt angivelse för antal ihopklumpade punkter varvid vi då beslöt oss för att helt och hållet avstå från indexering vilket vi nu alltså skulle diskutera igen. 


I stort har vi kravet att varje punkt ska vara statisk på vis att vi inte vill ändra punkters indexering beroende på var på kartan vi är, utan samma angivelse ska bestå. Detta gör att alfabetet inte räcker till. Vi funderade på färger vilket verkade vara en bra lösning (varje punkt skulle ha en specifik färg men eftersom inte alla skulle visas på skärmen samtidigt skulle det då kunna finnas flera gröna, flera rosa och så vidare... Detta skulle för övrigt också vara tillämpbart på bokstäver så här i efterhand). Vissa anmärkte att det skulle vara svårt att urskilja mot kartan, andra tyckte att det kunde vara hattigt och rörigt med olika färger och i de fall fler än tio färger fanns skulle man behöva urskilja nyanser vilket skulle kunna vara lite tidsödande. Plötsligt kom tanken att färgblindhet inte var alltför ovanligt varvid vi skrotade idén om färgindexering. Dessutom hade vi en potentiell idé om att använda färger för att markera olika kategorier med träffar i de fall kartan visade olika kategorier samtidigt (nämligen då man visar ett objekts närliggande platser samt vid visning av en användares favoriter). Denna idé kunde på detta vis också kvarstå även om vi inte utvecklade den till slut under denna sittning.

    I slutändan kom vi fram till att använda sifferindexering för platser samt markera grupper med en speciell gruppsymbol följt av en siffra i det fall det skulle finnas flera kluster av platser utmärkte på kartan samtidigt. På så vis kan vi indexera alla fristående platser men ändå använda en typ av gruppindex parallellt med detta. Den stora frågan var avgjord men fortfarande fanns många oenigheter om hur kartan och listan skulle hänga ihop.

    En röst ville att man skulle kunna markera flera platser på kartan för att sedan kolla upp dem i listan. En annan ville att man med ett enkelt klick från såväl listan som kartan skulle kunna ta sig direkt till en post. Vissa tyckte att endast ett urval av platser skulle visas så att det inte blev för plottrigt. Vi diskuterade länge och väl och röstade oss fram då oenighet rådde. Innan denna diskussion hade kartan visat punkter som man markerade och vars beskrivningar man sedan via listan kunde nå. Detta var en viss skillnad mot en tidigare design vi använt där listan och kartvyn var parallella med varandra och båda kunde ta användaren vidare till platsinfo. En viss oenighet rådde rörande huruvida kartan och listan var för tätt sammankopplade för att man skulle få känslan av att de var alternativ till varandra eller ej. Viss information ville en del i gruppen att man skulle placera i både listan och kartan medan andra menade att detta kändes för redundant när de två kändes så sammankopplade. Vi pratade om situationer där man ville skaffa sig en överskådlig bild av vad som fanns, situationer där man ville läsa mer ingående info innan man gick vidare för att leta mer info samt vikten av att båda dessa scenarior var möjliga och att det därför var bra om båda fungerade. Vi tog till sist ett beslut som innebar att vi placerade kartan och listan på ett mer jämlikt alternativt plan där båda kunde ta en till platsinfo. Följande beslut togs:


Efter att en sökning gjorts visas en karta centrerad kring användarens nuvarande situation med en cirkel som visar omgivningen med en 2-kilometersradie. Kartan visar punkter markerade med en siffra och en större punkt med en gruppsymbol följt av en siffra om punkter är ihopklumpade vilket sker enligt ett specifikt kriterium då de är för nära varandra. Drar man fram listan visas punkterna på kartan i en ordning som baseras på hur nära de är (sifferordningen anger en sorts ranking baserat på precision i träff samt betyg med mera men de sorteras efter hur nära dem är). I listan visas indexeringssiffror för ensamstående punkter samt gruppsymbol och gruppnummer för platser som befinner sig i en grupp på kartan. Trycker man på en post i listan kommer man till objektet och beskrivning. På kartan zommar man in och ut och sträckan som cirkelradien representerar varierar allteftersom. Klumpar på kartan benas ut och klumpas ihop beroende på zoom samt vissa tekniska kriterier. Varje punkt på kartan (oavsett om den syns eller ej) har ett unikt id (nummer) och detta ändras ej beroende på var man har kartans fokus. Ett tryck på en ensamstående punkt på kartan göra att en bubbla åker upp ovanför med samma info som posten skulle visat i listan. I bubblan finns ett kryss som stänger den samt en länk till platsens beskrivning. Trycker man däremot på ett punktkluster zommar kartan in på klustret så att de separata punkterna visas. Som extrafunktion i kartan kan man hålla inne en punkt varvid denna tänds upp. Man kan markera flera punkter på detta vis om man vill och i det fall någon eller flera punkter är markerade på kartan visas de högst upp i listvyn med en lätt markering av något slag i listan. Punkterna avmarkeras på samma sätt som de markerats. 


Det enda som kvarstår att prata om i denna fråga är nu huruvida vi ska använda färgdistinktion för att göra skillnad på kategorier då man använder funktionen "Visa närliggande platser" eller "Favoriter".


2. "Lägg till favoriter"-knappen ska vara kopplad till en specifik beskrivning, ej en plats (i vår lösning ska en plats idealiskt vara unik medan beskrivningar för en plats kan finnas hur många som helst) vilket det ser ut som nu.

Vi bestämde att vi skulle placera denna knapp inom den tydliga avgränsningen där beskrivningen håller hus för att tydligare visa att det är beskrivningen (och därmed indirekt också platsen) som man lägger till sina favoriter. Man kan alltså lägga till flera beskrivningar av samma plats till sina favoriter.


3. "Lägg till favoriter"-knappen missförstods av textpanelen som trodde att den va en betygsindikator på platsen som sådan.

Vi beslöt att förhindra ovanstående dels genom att flytta knappen till en annan plats och på så vis mindre förknippa den med platsens betyg (vilket håller hus i omgivningen där aktuell knapp befann sig tidigare). Dessutom förtydligar vi knappen så att det uttryckligen står "BOOKMARK" vid sidan om stjärnan. Om platsen redan är tillagd till användarens favoriter står det "BOOKMARKED" istället och knappen samt stjärnan ändrar färg till grön resp. gul för att tydligt visa knappens nuvarande läge (tips till oss som grupp: om man ska ta bort en favorit då? Ska denna knapp kanske gå att gå tillbaka med också eller?) .

 

Nedan följer skisser som kantade vår diskussion:

  

 

4. Koordinater kopplade till varje plats


Ovanstående bild visar också ett förslag till koordinatknapp. Eftersom vårt system bygger på att man försöker koppla ihop platser med gemensamma koordinater, ergo man använder en koordinat som indikator på att ihopkoppling behövs, framstår koordinaten som en unik och avgörande parameter. Från början var idén att detta som en grafisk sak skulle kunna inkluderas i en platsbeskrivning som attraktiv "feature". Vissa menade att det fanns ett utrymme i anslutning till platsnamnet som i vår skiss behövde fyllas vilket andra var strängt emot. Under diskussionens gång kom vi fram till att vi även kunde tänka oss en funktionell nytta med en dylik knapp, nämligen att den kunde vara en länk som öppnade användarens egen kartapplikation där användaren sedan kunde få anvisningar om kör- eller gångväg. Detta i kombination med att det var en "cool feature" gjorde att vi bestämde oss för att ha en sådan koordinat med samt med en kartsymbol bredvid. Trycker man på knappen öppnas koordinaten i den egna kartapplikationen och den koordinat som visas är "snittkoordinaten" som angivits på alla beskrivningar som finns att tillgå för en aktuell plats (alltså, koordinaten är unik i denna representation för varje plats och byts inte ut allt eftersom beskrivningarna byts).

 

5. Visualisering av popularitetsröster

Textpanelen tyckte att vår lösning för en plats popularitet var oklar. Vi visade en siffra som var den siffra som man fick om man tog alla positiva röster och subtraherade alla negativa röster. Detta var dock inte representativt och man hävdade att det var en viss skillnad mellan en plats som hade 100 positiva och 0 negativa votes i jämförelse med en som hade 1 000 100 positiva votes och 1 000 000 negativa.

      Vi beslöt oss för att representera rösterna i en mätare och fylla i siffror motsvarande antal röster i varje del (BRA / DÅLIGT) antingen i eller utanför ändarna på mätaren. Vissa fyndiga förslag med en termometer med mera kom fram och vi beslöt oss att vi skulle ha en mer detaljerad representation av denna art men lät beslutet rörande exakt hur denna skulle utformas bero tills vi såg vilken typ av lösning som passade bäst för det utrymme som skulle finnas att tillgå för denna artefakt. 

 

Skisser på representationsmöjligheter för popularitetsröster:

     

 

6. Man har inte tillgång till Internet när man går runt på stan i främmande länder eftersom detta troligen är svindyrt, hur ska man då kunna använda denna applikation?

En mycket berättigad fråga vilken fick oss alla att tänka efter. Efter en diskussion kom vi dock fram till att väldigt många av de mobilapplikationer som finns idag skulle vara onödiga i ett sådant sammanhang eftersom de bygger på konstant nätverksåtkomst. De inhemska kartapplikationerna till exempel bygger på detta och därmed såg vi inte det som någon speciell svaghet hos just vår produkt och accepterade därmed denna tanke. Dock tänkte vi vidare och konstaterade att det på fler och fler ställen finns tillgång till trådlösa nätverk vilket då ändå skulle göra att vår produkt här och var med lite vilja skulle gå att använda. Slutligen bestämde vi oss för att vi, detta är dock inom ramen för det tekniska, skulle "casha" data enligt vissa normer. Dels skulle alltid favoriter "cashas" men sedan skulle också exempelvis de tio senast besökta platserna "cashas" så att de gick att kolla upp utan nätverksåtkomst vid ett senare tillfälle. Därmed frångick vi också ett tidigare förslag som gick ut på att man i förväg skulle kunna ladda ner vissa städer som man visste att man skulle besöka och därmed ständigt ha tillgång till dessa trots att mobilen skulle vara utan mobildatanätverk.

 

7. Om ett evenemang är tidsbaserat måste man kunna lägga in tiden. Hur ska vi hantera tidsbaserade evenemang?

Frågan gäller exempelvis fotbollsmatcher, festivaler med mera som är tidsbegränsade. Till en början funderade vi på hur det skulle kunna implementeras men i slutändan bestämde vi att detta dock är utanför vad vi vill göra med appen. Vi tror på att rikta in oss på att fylla ett specifikt syfte och i detta fall är det att hjälpa folk att hitta platser att besöka. Det får gärna vara anspråkslösa platser såsom en utsiktsplats eller så men tidsbaserade evenemang är en helt annan kategori attraktioner och vi väljer att inte ha dem med i vår applikation. Frågan som följde denna huvudfråga gäller dock fortfarande, nämligen hur man tar bort en plats som tidigare funnits men inte längre finns? Denna fråga behandlas senare.

 

8. Om man tar en bild på en plats långt ifrån får man felaktiga GPS-koordinater i fotot, hur ska man avhjälpa detta?

Självklart var detta en svaghet vilket fick oss att tänka om. En svaghet som vi eventuellt tidigare hade tänkt på var att man var relativt utlämnad åt de GPS-koordinater som finns när man tar en bild med sin telefon... Tänk om man ville använda en bild utan GPS-koordinater? Det hela ledde till att vi omstrukturerade vyn för hur man delar med sig av material. Denna fick en liten karta längst ner där man kunde klicka och ändra eller lägga till GPS-koordinater. Om inga koordinater angivits (alltså om man inte lagt till en bild eller om bilden saknade koordinater) skulle denna ruta ha ett frågetecken i sig och så länge detta fanns kvar skulle man inte kunna slutföra sitt inlägg. För att lösa frågan skulle man behöva klicka på kartan och sedan ange en plats på kartan varifrån koordinater skulle plockas in. Här skulle man givetvis också kunna ändra koordinater som man ansåg var felaktiga. Kanske kunde man tänka sig någon funktion som automatiskt föreslog en koordinatändring baserat på om ens platstitel påminde om en annan som entydigt hade koordinater som inte stämde överens med dem man angivit?

 

Nedan en skiss på hur "lägga till"-vyn skulle kunna se ut med kartan längst ner till höger:

    

 

9. Rapportera inlägg

Hur tar man bort ett inlägg? Hur rapporterar man att ett inlägg har felaktiga taggar? Hur rapporterar man text som innehåller direkta fel? Hur skiljer man på alla dessa olika sorters fel och ser till så att användaren hittar till rätt ställe? Uppenbarligen skulle vi behöva lösa detta. Alla i gruppen tyckte att vi skulle ta hand om allt på en och samma plats och att en supportavdelning skulle lösa det baserat på hur många klagomål som sade samma sak (eftersom en supportperson kanske inte kan veta allt om alla ställen men om tio klagomål säger att en text innehåller ett fel kanske man kan tro på dem). Klagomålen skulle samlas i en länk och denna hette tidigare på svenska "Rapportera inlägg" vilket en del tyckte var lite missvisande då det lät som att det handlade om att hela inlägget skulle plockas bort eller ej. Den engelska översättningen "Flag post" tyckte dock alla lät mer som det vi ville att det skulle låta som och därigenom bestämde vi att länken skulle heta så. Denna skulle befinna sig längst ner till vänster i varje beskrivning och leda till en pop-up där man kunde rapportera fel i fritext baserat på en rad kategorier, nämligen...

 

1. Missbruk av tjänst - Rena tramsposter där exempelvis porrbilder eller politisk propaganda lagts upp

2. Felaktiga taggar

3. Felaktiga koordinater / Platsen finns ej

4. Missvisande text

5. Övrigt

 

Dessa svar skulle alltså sedan vår supportavdelning gå igenom. Ett förslag som röstades ner var att integrera detta system i vårt tidigare användarbaserade korrektionssystem och ställa frågor om felaktiga taggar och dylikt även där (alltså längst ner på varje platsbeskrivning). Vi pratade även om att länken till höger om denna som heter "Good description" och som är ett slags positiv röst för beskrivningen (ej platsen) inte fick uppfattas som motsats till denna rapporteringslänk och att man därigenom skulle tro att man skulle klicka på denna om man tyckte posten var dålig och på den andra om den var bra. Till gruppen: Vi har valt "Flag post" men vad sägs om "Complaints"?

 

10. Antal beskrivningar

Vi beslöt oss att till höger om bilden i varje beskrivning ha ett område där man överst ser vilken beskrivning i raden som är den aktuella, allltså något så enkelt som "1 / 20" med pilar åt varsitt håll runt omkring så att man ser att dessa siffror bläddras i takt med att man bläddrar bland beskrivningarna. Under denna skulle den renoverade "Lägg till favoriter"-knappen inhysas och därunder en vertikalt blädderbar lista av taggar kopplade till beskrivningen (egentligen platsen).

 

11. Antal personer som tycker beskrivningen är bra

Om flera beskrivningar av samma plats finns avgörs vilken som visas först av vilken som fått flest "Good description"-röster. Detta tänkte vi åskådliggöra och vi beslutade att detta skulle ske genom att på knappen "Good description" sätta en parentes efteråt med antalet användare som tryckt på den. Om den trycktes ned skulle då antalet öka med en och kanske kunde man tänka sig att knappen ändrade färg till grön i analogi med hur "Bookmark"-knappen fungerar? Framför "Good description" ska en liten "tummen upp"-symbol finnas. Vi tror att detta ska stå ut på ett annat sätt än platsens totalomdöme och därigenom inte misstas för denna. Tilläggas bör också att vi nu gjort om så att båda dessa länkar som berörs ovan nu är knappar och inte textlänkar som tidigare.

 

Skisser gjorda på den tidigare platsbeskrivningen:

    

 

12. Inloggning på flera sätt

Testpanelen tyckte att det var lite futtigt att enbart logga in med Facebook. Vi diskuterade frågan och kom fram till att vi tror att man inom vår målgrupp har Facebook. Vi beslöt oss dock för att även lägga till inloggning via Google-ID och därigenom bredda oss något. Egna användare eller andra inloggningsmodeller är dock fortfarande inte aktuella.

 

13. "Community" med kommentarer och möjligheten att följa andra användare?

Siter med "community" är tydligen enligt delar av vår grupp det som lyckas bäst eftersom "communityn" håller kvar användare. Detta blev en lång diskussion. Vi talade om olika nivåer där produkten kan lyckas. Vi talade om "satisfaction"-nivån då produkten gör sin grundfunktion till belåtenhet samt om "desirability" där produkten är rogivande och lustfylld att använda och bestämde oss för att "community" var en finess som hörde den senare kategorin till. Vi kunde enas om att det hade varit en bra funktionalitet för användaren men valde att se till storleken på detta projekt och efter detta bestämma att magnituden av produkten inte skulle rättfärdiga konstruktionen av en community i dagsläget varvid idén, tillfälligt i alla fall, skrotades. Förslag om att implementera "community" vid ett senare tillfälle efter lansering eller exempelvis som komplement på web-applikationen av produkten luftades också.

 

14. Språkproblem, vilka språk ska saker och ting vara på?

Ett intrikat problem eftersom man inte kan tvinga alla att skriva på samma språk. Vi diskuterade "Google Translate"-översättningar samt om det skulle bli ett problem att en arabisk beskrivning skulle dyka upp överst i ett sökresultat. Vi tittade på exempelvis Youtube.com där alla språk är tillåtna i viss utsträckning och höll med varandra om att det skulle vara synd och dåligt att begränsa oss i den frågan. En gruppmedlem trodde att "Google Translate"-översättningar skulle sätta en "billig" stämpel av negativ typ på produkten och att det skulle vara bättre att försöka ha bra beskrivningar snarare än engelska översättningar. Dessutom skulle det vara svårt att veta om översättningen eller själva beskrivningen i själva verket var dålig i så fall och eventuellt skulle bra beskrivningar rapporteras som dåliga på fel grunder. Vidare skulle det i stort bli svårt och kanske omöjligt att hålla ordning på allt detta och i slutändan skulle det leda till irriterade användare som lämnade produkten för någonting annat. Vi beslöt oss för att vårt gränssnitt i nuläget ska vara på engelska men att både vad gäller taggar samt beskrivningar ska alla språk vara tillgängliga. (Gruppfråga: Vilket språk ska tagmolnet i början visa då? Blandat eller kanske på det språk man ställt in i appen eller så? Om man nu gör några inställningar... Man kan också diskutera vilket språk som platsnamn ska skrivas på... försöka göra ett baserat på vanligast förekommande eller? Dock är båda dessa teknikaliteter och därmed kanske försumbara i nuläget?). Vi tror att användarna kommer att styra vilka språk och taggar som blir populära på vårt vanliga användarbaserade "renhållningssätt" och därmed är det onödigt att göra ett problem av det. Vidare behöver man inte SKYLTA med att man får skriva på vilket språk som helst men man behöver heller inte begränsa det på något vis.

 

___________________________________________________________________________________________

 

Många frågor med intressanta och givande diskussioner. Nästa möte blir torsdag den 7:e mars. Ytterligare kvarstående fråga för gruppen: Hur ska vi göra initialt för att få en startkvantitet av platser och beskrivningar och på så vis locka folk till oss? Teknikalitet dock men kanske värt att begrunda?

 

 EDIT: Ändrade bilderna till miniatyrer. Klicka på bilderna för att se på dem. 


Av b4 - 4 mars 2013 08:09

Denna dag var det dags att demonstrera vår produktlösning för en annan grupp som skulle agera experter och sedan komma med ris och ros avseende vad vi kommit fram till. Vi hade gjort bilder som på ett ungefär i alla fall skulle ge en vision av hur vi tänkt oss gränssnittet som Krystyna och Benjamin i slutändan ska använda. Fyra bilder hade vi som i turordning visar startsida, inloggningssida, vy efter sökresultat samt slutligen presentationen av en aktivitet eller tänkt sevärdhet. Så här såg bilderna ut:


__________________________________________



STARTSIDA

När SpotShare (arbetsnamnet för vår produkt) öppnas ser man ett tagmoln och en sökruta. Är man inloggad är rutan uppe till höger grön och ens användarnamn står i den. Annars står "LOGIN" mot en röd bakgrund och vissa funktioner i produkten är ej tillgängliga. Man kan söka på en text eller klicka på en tag för att nå en sida med träffar. För den mer avancerade användaren finns även en särskild söksyntax som man får mer information om genom att trycka på frågetecknet. Trycker man på "Bookmarks" får man en resultatlista med alla ens sparade platser, men denna funktion kräver att man loggar in först.


  




__________________________________________



LOGIN

Om man trycker på "Login-"knappen når man en ruta där man kan logga in med sitt Facebook-ID. I nuläget är detta den enda inloggning som vi accepterar. 


  



__________________________________________



SÖKRESULTAT

Nu är användaren inloggad och vi har nått en sida med sökresultat. Kartan är centrerad kring där man är för tillfället och en träff visas som en blå prick. Om flera träffar ligger nära varandra och det blir för plottrigt att visa dem alla på kartan samtidigt (i den skalning man då använder) visas istället en större blå prick med en siffra som anger antalet träffar i det närområdet. Förstorar man bilden över det området kommer denna större prick att fördelas ut på flera specifika platser istället. Till höger ser vi också den flik som går att dra ut där alla träffar finns i en lista.


  

__________________________________________

 

SEVÄRDHET / AKTIVITET

Här ser vi sevärdheten Vasamuséet. Sidan visar platsens namn samt betyg, det vill säga hur många fler (eller färre) positiva röster som platsen fått. Man kan även lägga till platsen till sina favoriter eller se platser som ligger i närheten av denna (utan specifikation rörande vilken kategori man vill ha). I den blåa ramen är en framställning eller användarpresentation av platsen. Dessa bläddrar man mellan genom att gå till höger eller vänster. En presentation innehåller en bild, en text samt taggar avseende innehållet. Man kan rapportera en presentation eller rekommendera en presentation. I den nedersta rutan visas objekt med samma GPS-koordinater men som inte än är ihopkopplade med det aktuella objektet och man frågar användaren om detta är samma objekt som det som den besöker. Man kan svara om man vill men man behöver inte. Om man svarar kommer det inte upp fler frågor utan endast en fråga per presentation.


    


__________________________________________

 

SUMMERING

Expertgruppen gav VERKLIGEN upphov till många reflektioner rörande en hel del saker, vissa inom områden vi berört men också mycket som vi inte alls tänkt på. Gruppen var uppmuntrande men pekade ändå ut brister och i grupp B4 tror jag att jag talar för alla om jag säger att vi kände oss sporrade att arbeta vidare med projektet. Redovisning av frågor som lyftes samt ställningstagande från våran del rörande dessa redovisas i nästa bloggpost som kommer att handla om det spännande schemalagda mötet den 4 mars.


EDIT: Ändrade bilderna till miniatyrer och fixade de horisontella avdelarna. 



Skaffa en gratis bloggwww.bloggplatsen.se