Inlägg publicerade under kategorin oschemalagt möte

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 - 26 februari 2013 23:12

Dagens diskussion gjorde ändrade vi på mycket som vi beslutade mötet den 21 feb.


* Startsidan
Består av två vertikala flikar. Den första är Sök där man det finns ett sökfält
och ett tagcloud. Trycker man på en tag i det så skrivs den automatiskt in i
sökfältet utan att göra sökning. Vi valde att göra så för att då kan man
på ett enkelt sätt söka på flera taggar. Man kan också skriva in egen text
att söka efter. När man trycker på sök så går man vidare till sökresultat.

Trycker man istället på dela åker expanderas dela-fliken istället. Där ser
man en knapp som tar en till kameran och man kan fota platsen. Man får sedan
skriva in en titel, beskrivning och taggar. Tagcloudet som är med på bilden är inte
med i den slutgiltiga designen.


   

Sök i första bilden upp till vänster. Dela på andra bilden. 



* Sökresultat
Vi tog beslutet att visa kartan när man trycker på sök istället för en lista
som var först tänkt. Kartan är centrerad på ens egna position, och markerar
ut ställen som matchar sökningen. När det är många sökningar runt samma plats
så blobbas dem ihop och man måste zooma in för att de inviduella platserna ska visas.

Från höger kan man även dra ut en lista över de platser som visas på kartan.
Vi diskuterade mycket om vad som skulle hända när man tryckte på ett listelement
i listan. Ska det ta en till posten om platsen, eller ska platsen
markeras ut på kartan? Efter mycket diskussion bestämde vi för att den ska markera ut platsen,
och det finns en ytterligare knapp i listelementet som tar en till själva posten.

Man måste inte dra ut listan för att få fram den. Trycker man på ett element i listan
så dras den ut och man ser titeln på bara den posten, eller så kan man trycka på en blob
och då visar listan alla platser i bloben.


   

Sökresultat karta till vänster, och med listan utdragen till höger. Man ska fortfarande kunna se kartan vilket inte 

framgår på bilden.


* Post
Posten visar främst titeln, en bild och en kort beskrivning (ungefär twitter-längd).
Man kan scrolla åt sidled för att visa andra poster på samma plats. Vi ser också
att under beskrivningen så kan man rapportera inlägg (t.ex. om någon postar porr/gore)
och sedan ser man att det finns en rating på både plats (bredvid titeln) och på posten
(Hjälpsam?, bredvid rapportera)

Under Rapportera/Hjälpsam ser vi ett område som inte alltid visas. Antingen så kommer det
vara tomt eller så kommer det att vara en "Är detta samma plats?"-fråga som ställs till användaren.
En liten bild visas och titeln på den posten. Problemet är att vi måste kunna avgöra som är dubletter
och inte, och då frågar användaren om posten i rutan beskriver samma plats som den riktiga posten.
Användaren kan då trycka Ja eller Nej och frågan försvinner och ersätts med ingenting eller kanske
"Tack för hjälpen!".


 


* Inloggning
Inloggningen fungerar som en popup. Användaren kan alltid ta fram den genom att trycka
på loginknappen i toppen av skärmen, eller så kommer den att poppa up då användaren
gör något som kräver inloggning (bokmärke, rösta, dela). Om användaren är inloggad så
loginknappen ersättas med den inloggade användarens namn.


 

Till vänster är innan man loggar in, och till höger har användaren Leif loggat in. 


Detta är vår bästa design och det är denna som vi kommer att fortsätta med. 


Litteraturtermer: Denna prototyp blev både en horisontell prototyp (fokus på många funktioner) och en vertikal prototyp (fokus på detaljer). Vi tycker att den blev rätt så komplett.  


 

Av b4 - 26 februari 2013 21:17

Scrappa communityskit
Communitysaker såsom kommentarer på poster, persongalleri och bevaka personer tar vi bort.
Vid närare eftertanke så tyckte vi inte det passade in med den enkla designen vi
ville göra, och mediumet kändes inte som att det var rätt. Det blir för mycket små knappar som 

måste ha en plats och ligga vilket kommer bli jobbigt för användaren och för oss som måste 

lägga dem någonstans. 


Favoriter/bokmärken
Var ska favoriterna sparas? Vi tänkte att de antingen kan sparas lokalt i mobilen,
eller så kan det sparas på någon server. Fördelarna med lokalt är att man inte behöver
logga in för att komma åt favoriterna, men om man sedan använder en annan persons mobil
så kan man inte komma åt den. De kan man om de istället sparas i cloudet.
Vi beslutade oss sen om att de skulle sparas i cloudet.


Inloggning 

Vi pratade mycket om inloggning och vad man kan göra utan att logga in samt
vad man göra efter inloggningen.
Vi har sagt nu iallafall att man loggar in med Facebook och endast Facebook.
Vi har inget lokalt konto. Genom att logga in så kan man dela saker (dvs posta platser)
och ratea (både platser och poster).


Bilder på pappersskiss

 

Av b4 - 21 februari 2013 20:07

Idag träffades gruppen för att börja diskutera de nya designförslagen utifrån de vi redan har tagit fram. Denna post är tänkt att sammanfatta vad som diskuterades och vad vi kom fram till. Vi började med att gå igenom de två designförslagen (se föregående post) och välja ut vilka detaljer som är bäst från de.


Någonstans under tisdagen/mellan tisdagen och idag så insåg vi att dubletter (flera poster kopplade till samma geografiska plats) är ett klurigt problem, och att vi måste ha någon form av plan för hur det ska lösas.


De oenigheter vi kom fram till var:


Bakåtknapp
Det visade sig inte vara helt trivialt att bestämma hur bakåtknappen bör fungera för att vara så intuitiv som möjligt för användaren. Som följd av dessa diskussioner så valde vi att slå ihop skärmarna för resultatlista och kartvy i design #1 till separata flikar i samma skärm, så bakåtknappen (som ligger utanför dessa flikar) får en mer lättförståerlig funktion.


Dubletter
Hur ska dubletter av poster identifieras? Hur ska de presenteras för användaren? Vi behandlade dessa problem i omvänd ordning, och började med presentationen.


Presentation av dubletter
Ett av förslagen var att ha en lista med dubletter. Ett annat var att kunna slide:a hela skärmen åt vänster/höger för att bläddra mellan flera poster knutna till samma geografiska plats (som då kommer från olika användare och har olika foton/beskrivningar). Vi beslutade oss att använda det senare förslaget, och vidare så flyttade vi upp titel och röstningsknappar till ovanför "post-delen" (den del som kan slide:as åt sidan för att växla mellan poster rörande samma plats).


Identifiering av dubletter
Vi ville helst av allt låta användare få sköta identifieringen av dubletter, men vill inte göra det till en jobbig uppgift utan presentera ett så lättanvänt gränssnitt som möjligt. Detta valde vi att lösa genom att låta den nedersta biten av resultatsidan då och då innehålla en ruta för en annan post, och fråga användaren huruvida den nuvarande posten är en dublett till denna andra post eller inte. Efter att användaren svarar på frågan så fylls området ut helt av det faktiska resultatet, utom en kort notis som tackar för bidraget.


För att hitta "potentiella dubletter" så jämförs GPS-koordinater, och närliggande platser blir automatiskt kandidater för användarfrågor.


Röstning
Ett annat problem är att man utöver att kunna rösta på en plats ("den här platsen är värd att besöka") också behöver kunna rösta på en post ("den här posten ger en bra beskrivning av platsen"). Detta valde vi att hantera med en "textlänk" där man kan tala om huruvida man fann beskrivningen hjälpsam.


Edit: Läs även fortsättningen, http://b4.bloggplatsen.se/2013/02/26/9524523-fortsattning-pa-dagens-diskussioner-21-feb/

Skapa flashcards