GPS Logger Semestrální projekt předmětu Y36PDA Jiří Zamazal, ČVUT FEL
Úvod Popis aplikace Program bude zaznamenávat trasu, kudy mobil (respektive jeho uživatel) “prošel”. Program bude sloužit především sportovně založeným uživatelů – například cyklistům, turistům, běžcům, běžkařům, apod. Uživatel si bude moci trasy pojmenovávat (např. „Pražský Maraton 2011“) a kategorizovat (např. „ Běhání“). Program bude trasy zaznamenávat do formátu GPX. Tento formát souboru umí přečíst většina aplikací, takže uživatel si může svojí trasu prohlídnout například v aplikaci Google Earth nebo v internetových aplikacích bikemap.net, trekview.cz a utrack.crempa.net, které umí spočítat zajímavé údaje (například výškové profily, rychlost, apod). Tento program může ušetřit nemalé peníze, protože hardwarové zařízení, které „jenom“ zaznamenává trasy do GPX souborů, stojí cca 1000 – 2000 Kč. Pokud uživatel vlastní mobilní telefon s GPS a operačním systémem Android, nemusí toto zařízení kupovat a použít program GPS logger. Aplikace bude pro android.
Popis uživatele -
Zkušenosti: Uživatel musí umět instalovat aplikace na Android. Program bude pro běžného uživatele, který již umí pracovat se svým zařízením (program bude mít intuitivní ovládání) Věk: Věk není omezený Pohlaví: Neomezeno Prostředí: Ve volném terénu (tedy ne v budovách), kde je dostatečný signál GPS. Cíle: Program může plně nahradit hardwarové GPS data trackery (loggery). Program umožní uživatelům zaznamenat si svojí trasu při výletě, běhání, cyklistice, apod. Handicap: Program nebude optimalizován pro nevidomé a ani pro jiné lidi s tělesným postižením.
Aktivity -
Uživatel si program GPS logger nainstaluje V mobilním zařízení musí být zapnuté (povolené) GPS Uživatel spustí program GPS logger Uživatel musí počkat, až bude určena GPS poloha (to může trvat i pár minut) Uživatel stiskne tlačítko „Start“ pro zaznamenávání trasy V průběhu zaznamenávání trasy může uživatel využít tlačítko „Pauza“ pro dočasné přerušení zaznamenávání trasy V průběhu zaznamenávání trasy může být program „shozen“ na pozadí Uživatel stiskne tlačítko „Konec trasy“, program se dialogovým oknem zeptá, jestli opravdu chce ukončit zaznamenávání trasy. Uživatel je vybídnut k tomu, aby si trasu pojmenoval Uživatel může danou trasu zařadit do kategorie (zařazení/odebrání kategorie může být provedeno i později) Uživatel si může kdykoliv trasu (GPX soubor) stáhnout do počítače (USB, paměťová karta) Pokud má uživatel přístup na internet (GPRS, EDGE, ...), může svoji trasu nahrát na server (bude specifikováno později)
Systémová podpora Podporován bude systém Android. U zařízení je vyžadováno GPS.
Kontext Program bude ovladatelný jednou rukou. Předpokládá se, že program bude využíván při aktivním pohybu (např. běhání), takže v průběhu zaznamenávání trasy budou k ovládání programu použity velká tlačítka „Pauza“ a „Konec trasy“ pro snadné ovládání. Uživatel si může telefon připnout na řídítka telefonu (pokud má držák) nebo může mít telefon v kapse a případě potřeby vytáhnout.
Testování uživatelského rozhraní Prototyp K vytvoření prototypu aplikace jsem použil software Balsamiq Mockups, protože práce v něm je rychlá a pohodlná. Mohl jsem tak vytvořit jednotlivé obrazovky aplikace včetně dialogových oken apod. Podle mého názoru je vytvoření prototypu aplikace rychlejší udělat v tomto programu, než například ručně kreslit na papír. Prototyp aplikace jsem mohl vyexportovat do klikatelného PDF souboru, takže testování aplikace je interaktivnější. Ukázka prototypu:
Úvodní obrazovka aplikace
Zaznamenávání trasy
Uložení GPX souboru
Příprava testování Vybraní experti k testování návrhu aplikace byli seznámeni s oblastí, pro kterou je tato aplikace navrhována. Po tomto seznámení jim byl předán/zaslán prototyp uživatelského rozhraní v elektronické podobě – ve formátu provázeného PDF. Na tomto prototypu provedli vyhodnocení heuristik.
Heuristická analýza Popis heuristik 1) Viditelnost stavu systému Systém by měl vždy uživatele informovat o tom, co se děje, a mít přiměřenou dobu odezvy. 2) Porovnání systému a skutečného světa Systém by měl mluvit uživatelským jazykem, na který je uživatel zvyklý z reálného světa. Měl by také zobrazovat informace v přirozeném pořadí. 3) Kontrola uživatele a svoboda Uživatelé si často vyberou systémové funkce omylem a mají proto potřebu opustit nechtěný stav aplikace. Je proto nutné podporovat příkazy „zpět“ a „vpřed“. 4) Konzistence a standardy Uživatelé by neměli muset zjišťovat, zda různá slova, situace nebo akce znamenají stejnou věc. Je proto důležité dodržovat jednotnost označení a zvyklosti.
5) Prevence chyby Lepší než kvalitní chybové zprávy je opatrný design, který zabrání samotnému vzniku problému. Při akcích náchylných k chybám je vhodné uživatele o tomto nebezpečí informovat ještě před zahájením této akce. 6) Raději poznávání než vzpomínání Systém by se měl snažit minimalizovat náročnost na uživatelovu paměť. Uživatel by si neměl muset pamatovat informace o tom, jak se dostat z jedné části aplikace do jiné. Použití systému by mělo být průhledné nebo snadno zjistitelné. 7) Flexibilita a výkonnost použití Systém by měl mít možnost být používán jak nezkušenými, tak zkušenými uživateli, ve smyslu být schopen zrychlit akce pro zkušené uživatele a zároveň zachovat jednoduchost pro uživatele nezkušené. Je dobré dovolit uživatelům přizpůsobit si časté akce. 8) Estetický a minimalistický design Dialogy by neměly obsahovat informace, které jsou nepotřebné či nadbytečné. Každá nadbytečná informace v dialogu ruší uživatele a zmenšuje viditelnost informací důležitých. 9) Pomoc uživatelům rozpoznat, vyhodnotit a opravit následky chyb Chybové zprávy by měly být vyjádřeny v jednoduchém jazyce, přesně ukázat problém a konstruktivně navrhnout řešení. 10) Nápověda a dokumentace Přestože je lepší, když je systém použitelný bez dokumentace, měl by ji obsahovat. Informace by měly jít snadno hledat v souvislosti s aktuální úlohou uživatele a vypsat konkrétní kroky k dosažení jeho cíle.
Expert 1 – Jiří Zamazal 1) Viditelnost stavu systému Stav systému je dobře viditelný – uživatel přesně ví, kdy se trasa nahrává a kdy je nahrávání pozastaveno. Při akcích jako je mazání nebo přidávání položek je uživatel buď informován, nebo změnu rovnou vidí. 2) Porovnání systému a skutečného světa V návrhu aplikace je použit přirozený jazyk a návrh aplikace splňuje požadavky k používání aplikace – tedy k zaznamenávání trasy při nějaké sportovní aktivitě. 3) Kontrola uživatele a svoboda Ze všech stavů aplikace je možné se vrátit. Pouze při nahrávání trasy na server OpenStreetMap, kde se dá očekávat delší prodleva, uživatel nemá možnost tuto operaci stornovat. 4) Konzistence a standardy Požadavek na konzistenci názvů a standardů v reálném světě je v aplikaci dodržen. 5) Prevence chyby V prototypu aplikace není zachycen případ, kdy GPS nezafixuje polohu nebo když není připojení k internetu. V těchto případech by aplikace měla uživatele upozornit na chybu. 6) Raději poznávání než vzpomínání Ovládání aplikace je intuitivní. 7) Flexibilita a výkonnost použití Při nahrávání trasy na server OpenStreetMap uživatel neví, jak dlouho bude nahrávání trvat. Pokud bude uživatel nahrávat trasu z dlouhého výletu, může být GPX soubor docela i velký a v tom případě by bylo dobré zobrazit
progressbar nebo alespoň dialog pro nahrávání, který by se dal stornovat. Při nahrávání velkého souboru by měl být uživatel upozorněn, aby zbytečně neplatil za mobilní internet nebo si plýtval FUP. 8) Estetický a minimalistický design Tento požadavek je splněn, aplikace je rozdělená na části, které jsou minimalistické a přehledné. 9) Pomoc uživatelům rozpoznat, vyhodnotit a opravit následky chyb V prototypu není zobrazen žádný chybový stav. Při nefunkční GPS nebo při výpadku internetu by uživatel měl být informormován. 10) Nápověda a dokumentace Aplikace bude obsahovat jen základní nápovědu, co program dělá a k čemu slouží. Žádná podrobná nápověda není potřeba.
Expert 2 – Luboš Mátl 1) Viditelnost stavu systému Stav systému „historie tras“, nemá žádný nadpis. Pokud by se uživatel vracel k programu z jiné činnosti (např. telefonování), nemusí si být úplně jistý, kde se nachází. Ve všech ostatních stavech systém správně a viditelně informuje uživatele, kde se nachází. 2) Porovnání systému a skutečného světa Systém se ovládá velmi intuitivně a měla by být každému uživateli srozumitelná. 3) Kontrola uživatele a svoboda Pokud uživatel nahrává svojí trasu, nemůže se žádným způsobem vrátit do menu, ani si zobrazit historii tras, nebo nastavit systém. Vždy musí ukončit nahrávání, vybrat zda ho chce uložit a až pak se může vrátit. Bylo by dobré, kdyby nahrávání běželo na pozadí aplikace. 4) Konzistence a standardy Vzhledem k jednoduchosti aplikace, je tento požadavek splněn. Aplikace používá správné komponenty na správných místech. 5) Prevence chyby Systém se správně ptá, pokud chceme ukončit nahrávání nebo když chceme smazat nahranou trasu, zda to opravdu chceme udělat. Bohužel prototyp neobsahuje stav, kdy není přístup k internetu nebo je GPS vypnuta. Proto to nemohu posoudit. 6) Raději poznávání než vzpomínání Aplikace je velmi jednoduchá a je dobře členěna, vyznat se v ní není problém. 7) Flexibilita a výkonnost použití Aplikace nemá žádné možnosti urychlení pro pokročilé uživatele. Ale vzhledem k jednoduchosti aplikace to není ani nutné. Nevím, jak rychle bude aplikace reagovat, pokud bude uživatel nahrávat trasu na server OpenStreetMap, možná by bylo dobré zobrazit dialog o nahrávání trasy. 8) Estetický a minimalistický design Tento požadavek je velmi dobře splněn, žádný stav systému není moc složitý, dobře se v něm orientuje a pracuje. 9) Pomoc uživatelům rozpoznat, vyhodnotit a opravit následky chyb V prototypu není zachycen žádný chybový stav, proto tento požadavek nemohu posoudit. 10) Nápověda a dokumentace Hned po zapnutí systému si uživatel může zobrazit nápovědu. Myslím, že pro takto jednoduchý systém je to dostačující a možná i nadbytečné.
Doporučení pro implementaci reálné aplikace (Seřazeno podle priorit vzestupně) 1) Přidat do historie tras nadpis, aby uživatel věděl, kde se nachází 2) Při nahrávání (zaznamenávání) trasy není možné se vrátit do úvodní obrazovky aplikace a tudíž není možné si zobrazit historii tras či jít do nastavení (námitka Experta 2 – Luboše Mátla). Myslím si, že je to tak správně. Předpokládá se, že se aplikace bude používat při sportovní aktivitě. Při zaznamenávání trasy uživatel nebude mít čas, aby si prohlížel historii tras a nahrával si trasy na OpenStreetMap, protože bude vytížen svojí aktivitou (Při běhání si nikdo nebude prohlížet historii tras). Naopak pokud bychom toto uživateli umožnili, bylo by pro něj o dost složitější zastavit nahrávání trasy pokud by si zrovna prohlížel detail trasy z historie tras. (Musel by se vracet zpět na hlavní obrazovku) Je lepší, když při nahrávání trasy bude uživatel aplikaci zatěžovat co nejméně. Pokud by aplikace nahrávala trasu a uživatel by zároveň chtěl nahrát jinou trasu na OpenStreetMap, aplikace by se mohla na chvíli vytížit a naměřit trasu špatně. 3) Při vypnuté GPS nebo při nezafixované poloze by tlačítko „Start“ mělo být neklikatelné do té doby, než bude nalezena poloha GPS. 4) Při vypnuté GPS nebo při nezafixované poloze by se tato skutečnost měla zobrazit v horní části aplikace. 5) Při nahrávání trasy na server OpenStreetMap by se měl zobrazit dialog. V případě potřeby bude možné přenos souboru ukončit. 6) Před nahráním trasy na server OpenStreetMap by se měla zobrazit informace o tom, jak je soubor velký (v kB nebo MB). 7) Při nahrávání trasy na server OpenStreetMap bude uživatel informován hláškou, pokud bude server nedostupný.
