måndag 5 oktober 2009

Prototyp 3

Svar på föregående blogginlägg:

"Färger: Grönt. Ljusgrön bakgrund med mörkgrön eller vit text. Typ så här: http://arkland.files.wordpress.com/2007/07/green_pict0393.jpg"

Ok. Färger från bilden används nu.

Typsnitt: Arial, eller liknande sans-serif typsnitt.

Arial används nu som font.

Sökning: Ta bort kugghjulet (inställningar??) och ersätt med "Avancerad sökning" där användaren kan specificera vegetariskt/utan ägg/laktosfritt/etc...

Kugghjulet borta. Texten får inte plats. Lade dit ett blått plustecken istället.

Representation av sökresultat:
De resultat som hämtas från receptdatabaser visas med titel, betyg och/eller svårighetsgrad. Problemet som uppkommer med svårighetsgradering är förstås att olika receptsiter använder olika gradering men det är något som användaren själv kommer bli varse om vad det lider. Eftersom vi riktar oss mot en målgrupp med matlagningserfarenhet bör den själv kunna avgöra hur svårt någonting är att laga (ex. korv med bröd vs. citronkokt rostbiff med rosmarin).

Senaste sökresultat visas baseras på tidigare sökord och visar det delresultat som valdes utifrån den sökningen. Ex: Sökte tidigare på banan och får alla recept som innehåller banan, valde då banangryta. Det som visas vid "Senaste sökresultat" är alltså banangryta.

Högst rankade funktionen visas baseras på hur andra användare på Food fight skattat ett recept. Ju fler som röstat högt desto större sannolikhet är det att receptet visas högt upp.


Okej...så ni vill att vår databas a la 16 000 plus recept (vilket är ungefär den mängd som en respektabel matdatabas bör ha om den ska vara användbar?) ska presenteras i en lista med titel, betyg och svårighetsgrad? Visst, jag kan stoppa in en lista...men betänk att om man får plats med 10 recept på skärmen så har man i praktiken ingen överblick över de övriga 15 990 recepten som ligger längre ned i listan. Jag trodde mer på en lite mer avancerad informationsvisualisering a la treemap eller dynamic list eftersom hela syftet var explorativ utforskning, vilket en lista förhindrar tämligen omedelbart...men ok. Lista it is. Inlagt.

Planerare:
Planeraren bör göras i form av en kalender där användaren själv kan lägga till planerade maträtter. Bäst att göra så enkel som möjligt. Möjlighet kan finnas att koppla recept från SÖK eller FAVORITER till planeraren/kalendern och utifrån den utvinna inköpslista som exporteras till INKÖPSLISTA.


...No shit guys? Som en kalender? Kan man få lite hjälp med HUR den där kalendern ska se ut? :(
"Kalender" är inte en ISO-standard direkt...
HUR ska man koppla saker från SÖK och FAVORITER?
Jag kollar på era skisser imorgon och ser mer i detalj hur ni tänkt er.

Skafferi:
Skafferiet har visat sig skapa stora problem eftersom det är svårt att veta vad normalåtgången av en viss vara är. Torrvaror och frysta varor är dock mer permanent och ingenting som småäts av. Ett stort problem uppkommer i hushåll med mer än 1 person eftersom funktionen bör underhållas för att vara uppdaterad, det kräver att samtliga i hushållet har smartphone eller rapporterar till den familjemedlem med smartphone som uppdaterar skafferilistan så snart en vara använts. Det problemet går inte att komma runt med stora marginaler eftersom behovet kan växla.

Varför vi inte kommit på detta tidigare är en stor gåta! Tråkigt också eftersom det är en stor del av det vi byggt vårt koncept på.


Diskuterade vi inte detta en hel del i början? Sade vi inte att eftersom man kan komma åt databasen via PC så behöver inte alla i hushållet smartphones? Det är alltså ingen gåta att vi inte kommit på detta tidigare; vi har ju pratat om det på möten! Vi skulle ju ha tillgång till allt "via flera media" enligt brukskvaliteterna, bland annat av just den anledningen. Och vi sade redan från början...eller ja, jag uttryckte på ett par möten, sedan vilka som lyssnade/var där vet jag inte, att en databas av den här kalibern ALLTID kräver underhåll och lite småpill där man manuellt får ändra på saker man har hemma, har ätit upp, tappat bort, gett till hunden eller styvfar har kastat ut saker i fyllan och villan. Vi kan inte automatisera allt, och det har aldrig varit meningen. Tänk på era egna iTunes-bibliotek som exempel. Om de är alls som mitt, där man ändå har 50+ Gb av musik, så går det åt lite tid när man...köpt...en skiva och ska lägga till den med korrekta ID3-taggar etc. Det är ett underhåll som folk får ta. Så problemet så som ni beskrivit det här känns överdrivet, och vi har redan begränsat oss till att inte vara magiska wizards som tar hand om användarna via avancerade automagiska funktioner som känner av när användaren käkar upp den sista kakbiten, som vore de nyfödda barn utan möjlighet till överlevnad.

Dessutom; normalåtgång? Använder man det i recept så är ju det kopplat till receptet...annars så får man väl utgå från standardiserade siffror på hur mycket personer konsumerar (det finns mycket sån statistik, Livsmedelsverket måste ju ha något att göra om dagarna också...Svenskarna dricker X liter mjölk om året per person går ju att översätta till dagsranson om man så vill). Sedan kan man säkerligen ha smarta funktioner som anpassar sig och vet efter en månad eller två att mjök i snitt inhandlas var 3,453592 dag och kan då larma var 3:e dag eller så att kolla om det är slut på mjölk.

Jag vill fortfarande ha en skiss på hur det ska se ut dock. Eller så får jag motivera, designa och implementera hela skafferi-funktionen själv. Lagom skoj :(

Övriga kommentarer:
- Vara konsekvent med var plus-tecknet (lägga till) ligger (Till höger)
- Inga vita fyrkanter runt alternativ i nederkant
- Vad betyder anteckningsblocket som finns på vissa undersidor?


Plus ligger nu alltid till höger.
De vita fyrkanterna (som var där för att de fanns på en skiss) är nu borta.
Anteckningsblocket betyder "Redigera", dvs modifiera och ändra på saker på sidan (t.ex. recept eller motsvarande).

Här är länken till prototyp V3:
http://megaswf.com/view/dda20fb11649e8a06fc7101282b865bd.html

Inga kommentarer:

Skicka en kommentar