Průvodce českou železnicí

Průvodce českou železnicí Semestrální práce z A7B39PDA

Pavel Dvořák [email protected]

D1 – Zadání Popis Jedná se o aplikaci pro zjištění spojení a vizualizace řazení vlaku včetně možnosti zobrazení interiéru vozu. Řazení vlaků by bylo možné vypsat v textové formě (např. kupé po 6/8 místech, velkoprostorový oddíl, ...) nebo zobrazení řad vozů (Bp, ABfbrdtn795, ...). Aplikace by také uměla najít a zobrazit případné výluky na trati. Uživatel by mohl lehce přejít na stránku se statistikou zpoždění za poslední 3 - 28 dní. API Idos neumožňuje vyhledávání aktuální polohy (tedy aktuálního zpoždění) vlaku, data by ale mohlo být možné získat vyparsováním HTML odpovědi z dotazu přes běžné webové rozhraní. V neposlední řadě by aplikace nabízela odhad, který vůz by přijel k vybrané části nástupiště.

D2 – Popis aplikace Uživatelé Uživateli aplikace by měly být osoby mezi 20-40 lety, pravidelně využívající mobilní technologie a kteří využívají pravidelně i nepravidelně železniční dopravu. Uživatelé by mohli aplikaci využívat za chůze nebo při čekání na nástupišti či v jiných prostředcích hromadné dopravy. Aplikace je vhodná také pro organizátory výletů větších skupin, kteří díky přehledu zpoždění mohou naplánovat nejvhodnější trasu.

Aktivity Pro zobrazení řazení vlaku musí uživatel zadat číslo vlaku nebo jeho jméno (může se zobrazit výběr konkrétního vlaku, pokud existuje více vlaků se zadaným jménem, typicky v obou směrech – např. „Sněžka“ je pojmenování pro jak pro R 850 Praha – Trutnov, tak i pro R 851 Trutnov – Praha). Pro zobrazení interiéru vozu musí uživatel vybrat konkrétní vůz v řazení, zobrazí se mu pořadí vozu v soupravě, číslo vozu a grafický přehled sedadel uvnitř. U vybraných řad může zvolit i zobrazení fotografie interiéru. Pro zobrazení aktuálního přehledu výluk na trase vlaku nebo pro zobrazení zpoždění z předchozích dní uživatel zadá, stejně jako v prvním případě, číslo nebo jméno vlaku. Po vybrání konkrétního čísla vlaku by měly být možnosti zobrazení výluk, zobrazení řazení a zobrazení statistiky zpoždění přístupné bez nutnosti znovu zadávat číslo vlaku. Při zobrazení statistiky zpoždění by měl uživatel zadat, za kolik posledních dní chce zpoždění zobrazit.

Pro zjištění spojení uživatel zadá odkud a kam chce jet, možná je i volba stanice, přes kterou má jet. Chce-li uživatel zobrazit odhad, který vůz přijede na místo, kde stojí, musí zadat číslo nebo jméno vlaku a označit přibližné místo na nástupišti, kde právě stojí.

Systém Support Primárním cílovým zařízením aplikace bude zařízení od společnosti HTC s operačním systémem Android. Aplikace by stahovala aktuální data z určeného webového serveru ve formátu XML. Rozdělení

souborů by bylo přibližně následující: -

Soubor se řazením a trasou jednoho každého vlaku Soubor s přehledem jmen vlaků a k nim příslušným číslům vlaků Soubor s údaji o vozech Soubory s údaji o zpoždění za posledních 3, 5, 10 a 28 dní (v plné verzi generované automaticky serverem, pro tvorbu této SP budou statické). Plánky nástupišť vybraných stanic Soubor obsahující aktuální výluky na trasách s jejich popisem Obrázky ke konkrétním vozům

Aplikace by uvnitř obsahovala obecné zobrazení exteriéru vozů a hnacích vozidel, aby uživatel nemusel čekat na stažení aktuálních dat. Uživatel by si také mohl vybrat, zda chce soubor se řazením uložit v paměti telefonu (a tím riskovat jeho neaktuálnost v případě změny řazení) nebo jej chce načítat pokaždé znovu. Soubor s plánky nástupišť by obsahoval strukturovaný popis nástupiště, aplikace by obsahovala obrázky těchto jednotlivých struktur. Určení místa na nástupišti by probíhalo pomocí jednoduchého algoritmu, vycházejícího z drážních předpisů – vlak má zastavit tak, aby jeho střed byl co nejblíže středu nástupiště nebo vstupu do pochodu. Tento algoritmus lze použít pouze u menších stanic (např. Poděbrady nebo Přelouč) a zastávek*. Ve větších stanicích (např. Praha hl.n.) je nutné předpokládat skutečnosti, že vlak přijede k pravidelnému nástupišti, ani toto však nemusí být směrodatné , protože souprava může stát na celé koleji a nebo jen u části nástupiště.

Kontext Aplikace je tvořena pro použití na cestách, v hromadných prostředcích a také při chůzi. Cílem je tedy nabídnout jednoduché, ale zároveň všeobjímající rozhraní. Při pravidelném hledání konkrétních vlaků by systém nabízel možnost uložení dat, aby je nebylo nutné pokaždé stahovat z internetu. Aplikace by nabízela možnost nestahovat grafiku a zobrazit pouze textovou verzi řazení.

D3 – prototyp Vlastní prototyp se skládá z vygenerovaných obrazovek a je přiložen v souboru dvorap39 – prototyp aplikace.pdf.

Návrh prototypu Návrh prototypu byl vytvořen pomocí nástroje Balsamiq Mockups. Aplikace umožňuje snadnou tvorbu uživatelských obrazovek, jejich vzájemné provázání a tedy i snadné uživatelské testování. Před tvorbu prototypu v Balsamiqu jsem si vytvořil hrubý náčrt obrazovek na papír, který mi později velmi usnadnil detailnější práci. Jednotlivé aktivity jsou číslovány vzestupně, desítky v číslech aktivit reprezentují jednotlivé možnosti použití, jednotková čísla reprezentují pořadí obrazovky při cestě uživatele za cílem.

Popis prototypu Na úvodní obrazovce (viz obr. 1) uvidí uživatel hlavní menu, které ho snadno naviguje do všech částí aplikace. Většina ikon zavede uživatele na aktivitu, kde zadá číslo nebo jméno vlaku, o kterém hledá informace.

Obr. 1 - titulní stránka aplikace

Obr. 2 - zadání čísla vlaku

Pokud uživatel zadá jméno vlaku je přesměrován na aktivitu s výběrem konkrétního vlaku. Jméno vlaku totiž obvykle reprezentuje dva vlaky na stejné trase, jeden ve směru tam a druhý ve směru zpět, viz obr. 3

Obr. 3 - výběr konkrétního vlaku po zadání jména

Na aktivitách, kde již aplikace zná číslo vlaku, je nabízen snadný přechod pomocí ikon horního menu k ostatním informacím o zadaném vlaku (viz obr. 4). Jsou-li pro přechod na danou aktivitu vyžadovány další informace, je uživatel nasměrován na aktivitu, kde je zadá. Typicky se to děje u přechodu na aktivity Poloha zastavení (nutno zadat stanici) a Statistika zpoždění (nutno zadat sledované období) – viz obr 5.

Obr. 4 - průchody mezi hlavními aktivitami

Obr. 5 - zadání dodatečných informací

V aplikaci se předpokládá zobrazení okna prohlížeče v okamžiku, kdy uživatel hledá spojení. Z funkčního hlediska je použití tohoto řešení oprávněné, neboť provozovatel portálu Idos nabízí API právě k hledání spojení. Více o API Idosu naleznete na stránce http://www.chaps.cz/idos-moznost-vyuziti-odkazu.asp.

Použitá řešení V aplikaci není plánováno využívání LBS (Location-based service, služeb na určení polohy), přestože jedna aktivita po jejich využití přímo volá. Konkrétně jde o aktivitu 52 „poloha zastavení“, která má za cíl odhadnout, který vůz vlaku zastaví na místě, kde uživatel stojí. Chyba LBS na nádraží ale může dosahovat řádově desítek metrů, viz kapitoly 4.3 a konec kapitoly 4.4 v následujícím článku: http://pernerscontacts.upce.cz/15_2009/Marek.pdf.

Odchylky v návrhu V návrhu jsou ikony v horní části obrazovky navigační ikony s popiskem. V naprogramované verzi se budu snažit vytvořit tak výstižné ikony, aby nebyly potřeba popisky a bylo tak k dispozici více místa pro vlastní data. Na místě aktivity 43 je v současnosti okno prohlížeče, při vlastním řešení ale budou zhodnoceny výhody a nevýhody tohoto řešení na zvolené platformě. Je možné, že data z webové stránky IDOSu budou parsována a zobrazena podobným stylem jako výluky na aktivitách 34a a 34b. Také je možné, že namísto aktivit 62 a 64 (aktuální poloha vlaku) bude uživateli naopak zobrazeno okno prohlížeče. V přiloženém prototypu není, až na výjimky, aktivní tlačítko zpět, které bude ve finální verzi řešit návrat na předchozí obrazovku. Řešení tohoto tlačítka i v tomto prototypu by mohlo být matoucí, neboť tlačítko zpět logicky povede na různé obrazovky.

Testování K otestování návrhu aplikace byla zvolena metoda heuristické evaluace s použitím sady Nielsenových heuristik. 1) viditelnost stavu systém musí informovat uživatele, co se děje zpětná vazba musí být podávána v reálném čase 2) aplikace musí vycházet z reálného světa systém mluví jazykem uživatele aplikace využívá reálné konvence. 3) uživatel musí mít kontrolu nad tím, co se děje uživatel má moc ovlivnit to, co systém dělá aplikace musí nabízet možnost „nouzového východu“ 4) konvence a standardy aplikace by měla dodržovat konvence prostředí 5) prevence chyb nevystavit uživatele možnosti dostat se do chybového stavu požaduje potvrzení 6) poznání spíše než pamatování si uživatel vidí relevantní objekty nepožadujeme po uživateli, aby si pamatoval informace 7) flexibilita a efektivita použití vhodné pro časté používání a zkušené uživatele nabízí klávesové zkratky 8) estetický a minimalistický design zobrazuje pouze relevantní informace 9) pomoct uživateli rozpoznat a opravit chyby aplikace zobrazuje srozumitelné chybové zprávy nabízí řešení 10) poskytujte návod a dokumentaci

Testované scénáře 1) Zjištění řazení vlaku „Sněžka“ ve směru do Prahy. 2) Zjištění statistiky zpoždění a aktuální polohy téhož vlaku s co nejmenším úsilím, když mám nalezeno řazení vlaku 3) Vyhledání spojení z Jaroměře do Lysé nad Labem 4) Zjištění, který vůz zastaví v prostoru, kde stojím u vlaku 850 ve stanici Malé Svatoňovice.

Nálezy 1. expert

1. scénář: Nález: Problém nastal na obrazovce se samotným zobrazením řazení vlaku. Horní menu je nepřehledné a na první pohled se v něm špatně orientuje. Porušuje to heuristickou evaluaci v bodě 4 a 5. Možné řešení: Upravit velikost ikon a textu, aby na obrazovce bylo více místa a uživatel měl tak větší přehled. Druhá varianta je vložit vhodné ikony, které celé menu zpřehlední. 2. scénář Nebyl zaznamenán žádný problém. 3. scénář Nebyl zaznamenán žádný problém. 4. scénář Nebyl zaznamenán žádný problém. 2. expert

1. scénář: Nebyl zaznamenán žádný problém. 2. scénář: Nález: Bylo zaznamenáno různé pořadí ikon na jednotlivých aktivitách. Toto porušuje Nielsenovy heuristiky v bodech 4 a 7, protože pořadí ikon není konzistentní a to také nepomáhá efektivitě používání. Možné řešení: Stanovit jednotné pořadí ikon na aktivitách a z něj vypustit ikonu té aktivity, na které se uživatel právě nachází. 3. scénář: Nebyl zaznamenán žádný problém. 4. scénář Nález: Uživatel může při zadávání textu zadat název stanice špatně. Porušuje heuristiku 5. Možné řešení: Zobrazit uživateli seznam stanic na trase vlaku, uživatel si jen vybere svoji stanici. Komentář k řešení: Je třeba zvážit, zda zobrazit stanice v pořadí na trase vlaku nebo abecedně. Obě možnosti mají své logické klady i zápory. Doporučujeme toto nechat na volbě uživatele.

Doporučení pro další vývoj -

Upravit, případně zredukovat počet ikon v horním menu Důkladně zvážit používání prohlížeče a vhodně začlenit prohlížeč do aplikace. Na aktivitě 52 zobrazit scrollovací menu se seznamem stanic na trase vlaku. Na aktivitu 52 přidat přepínací tlačítko mezi zobrazením stanic abecedně a zobrazením stanic v jejich pořadí na trase vlaku.