FELda ­ dialogová aplikace pro tvorbu rozvrhů 

D4 ­ Hi­fi prototyp  

Autor: Michal Roch         

       Cvičící: Ing. Jan Balata Cvičení: Pondělí, 14:30 ZS 2015/2015 

 FELda je dialogová aplikace, která má jediný cíl ­ pomoci studentům vytvořit si svůj rozvrh. Snadno, rychle a přirozeně. A právě těmto třem pravidlům byla při designu věnována největší péče.  Test: https://felda.eu­gb.mybluemix.net/watson­movieapp­dialog/dist/index.html#  

● Jednoduchost ­ FELda musí být jednoduchý na pochopení a velice intuitivní.  ● Rychlost ­ vytvoření kompletního rozvrhu musí zabrat jen několik málo minut ● Přirozenost ­ vytvoření rozvrhu musí být takové, jak nad ním přirozeně přemýšlíme 

 Jak to funguje? 

● Zapnete aplikaci ● Zodpovíte tři základní otázky ● Upravujete podle požadavků ● Na e­mail obdržíte paralelky ● Zapíšete si je v univerzitním IS (KOS) 

 FELda při generování rozvrhu aplikuje heuristický přístup a nevěnuje velké úsilí hledání ideální kombinace. Ani když si rozvrh tvoříme my sami, nikdy dopředu přesně nevíme, jaká kombinace nám bude vyhovovat nejlíp. FELda je proto navržen tak, aby tento proces podporoval a usnadňoval namísto toho, aby hledal domnělé ideální řešení.  

   

I. Technologie a nasazení aplikace Prototyp je vytvořen za pomocí technologií IBM v prostředí Bluemix. Jako backend aplikace využívá IBM Watson Dialogue Service, která poskytuje rozhraní pro kontrolu rozvrhu dle stanovené struktury a pravidel. Frontend je realizován jako upravená kopie oficiální demo aplikace “What’s in theaters”  What’s in Theaters je Java EE aplikace na frameworku Angular JS. Instrukce ke zprovoznění vývojového prostředí jsou k nalezení na oficiálních stránkách původní aplikace: https://github.com/watson­developer­cloud/movieapp­dialog. S výjimkou umístění zdrojových kódů je postup instalace totožný.   Aplikace je konfigurována v režimu bez Natural Language Analyzéru. Použitý XML pro Dialogue Service je k nalezení v adresáři souborů aplikace v umístění: src\main\resources\dialog_files\felda.xml.   Přiložen je také war soubor pro okamžitý deploy. Aplikaci lze nasadit buďto v prostředí Bluemix, nebo na lokálním serveru dle instrukcí v oficiální dokumentaci. Před nasazením na server je potřeba nastavit proměnné prostředí: 

● DIALOG_ID ­ ID dialogu, který obdržíte po importu XML souboru dialogu v Dialogue Service. 

● TMDB_API_KEY ­ API klíč, který obdržíte po registraci na https://www.themoviedb.org/. Vyžadováno původní aplikací, v upraveném prototypu nebylo odfiltrováno, ačkoli výsledná aplikace z databáze žádná data nenačítá. 

 Pro nasazení na lokální server budete potřebovat: 

● IBM Bluemix účet ● Java Development Kit 1.7 nebo novější ● Eclipse IDE for Java EE Developers ● Apache Maven 3.1 nebo novější ● Git ● Websphere Liberty Profile server 

 Pro konfiguraci server.env využijte konfiguraci bez Natural Language Analyzéru, tedy: VCAP_SERVICES={"dialog": [ { "name": "dialog‐service", "label": "dialog", "plan": 

"standard", "credentials": { "url": "https://sampleplatformurl.net/samplePath", 

"username": "username","password": "password"  }  } ]} 

DIALOG_ID=dialog_id 

TMDB_API_KEY=tmdb_api_key 

 

   

V případě nasazení na vzdálený server na Bluemix prostřednictvím CloudFoundry terminálu je nutné správně konfigurovat také soubor manifest.yml: 

● applications: ● ­ disk_quota: 1024M ●   host: <hostname> ●   name: <appname> ●   path: target/movieapp­dialog.war ●   domain: eu­gb.mybluemix.net ●   instances: 1 ●   memory: 512M 

  II.    Implementační problémy 1. Návrh dialogu a komplexní podmínky 

Při testování předešlých prototypů jsem často narážel na nestandardní vstupy od uživatelů, které souvisely především s jejich nedočkavostí. Měli tendence zadávat do aplikace všechna data najednou a proces učinit co nejkratší. Bylo proto nutné navrhnout, jakým způsobem budou jednotlivé sekvence vyhodnocovány, aby bylo možné zadávat všechny potřebné vstupy v co nejmenším množství zpráv a redukovat tak časovou zátěž na aplikaci. Čím větší volnost ovšem uživatle u vybrané zprávy dostal, tím snažší byla milná interpretace a tím složitější také specifikace podmínek pro vyhodnocení.   Největší problém v tomto ohledu představovala kombinatorika a stromová struktura dialogu. Typicky se jednalo o situace, kdy uživatel mohl zadat 2 a více vstupů najednou, aplikace tyto vstupy musela zachytit, zpracovat a podle obdržené kombinace dat také patřičně odpovědět (například dotaz na zadání dnů, ve kterých chce student výuku). V některých případech počet možných kombinací dosahoval až řádů desítek či stovek a v těchto momentech jsem musel rezignovat na méně dokonalé řešení (např. namísto vypsání obdržených dnů v kalendářním pořadí (což by vyžadovalo logiku řazení) jsem je pouze každý jeden z nich zaznamenal a podle celkového počtu obdržených zpráv zobrazil jednu z pěti odpovědí, který vykreslovali dny v pořadí, v jakém je zadal uživatel).   Stromová struktura pak představovala problém zejména z hlediska redundance. Aby bylo možné uživatele v případě nesprávného vstupu správně nasměrovat s ohledem na aktuální stav dialogu, ošetřování neplatných vstupů se v dialogovém stromu objevuje téměř všude.  Zajímavý problém představovalo, jakým způsobem parsovat v rámci jednoho vstupu několik různých dat, aby je uživatel nemusel zadávat jeden po druhém. Nakonec jsem využil tzv. entities, konkrétní způsob je popsaný v dokumentaci pro vývojáře níže.   

 Obr. 2 ­ ukázka stromu z nástroje na tvorbu dialogů 

 2. Úprava existující aplikace Protože jsem chtěl zajistit příjemné uživatelské rozhraní a uvěřitelný dojem z aplikace, aniž bych musel vyvíjet složité řešení a nastavovat architekturu pro komunikaci s dialogovou službou, rozhodl jsem se využít existující aplikaci What’s in Theaters. Je to ale Java EE webová aplikace v Eclipse prostředí na Maven frameworku a bylo potřeba proto nastavit kompletní vývojové prostředí a deployment pipelines. Přísná omezení maven projektu překladače a integrované unit testy navíc znemoňovaly jakoukoli úpravu bez důkladného zkoumání existujícího kódu.  3. Generování a vykreslování rozvrhu Částečně také z důvodu číslo 2, jako náročný problém se ukázalo vykreslování a generování rozvrhu s napojením na Dialog Service. Původní návrh počítal s lokálními proměnnými, ale ani po dlouhých hodinách se mi nepodařilo přijít na to, jakým způsobem aplikace komunikuje s dialogovou službou a umožňuje vzdálenou úpravu enviromental variables, které jsou pro generování rozvrhu nezbytné. Nakonec jsem na tuto funkci rezignoval a nahradil původně zamýšlený generovaný rozvrh placeholder obrázkem.      

III. Testování V průběhu tvorby hi­fi prototypu proběhly tři testovací cykly. Každý proběhl na desktopu nebo na notebooku, mobilní zařízení byly z testu vyřazeny pro absenci speech­to­text. Testování probíhalo s náhodnými studenty na kolejích.   Jednotlivé kola proběhyl v těchto fázích vývoje: 

● Early protoyp samotného dialogu v nástroji dialog­tool ● Vylepšená verze dialogu v upravené aplikaci What’s in Theaters ● Finální verze dialogu a aplikace 

 Cílem prvních dvou fází bylo rychlým iterativním procesem získat dojmy tzv. hands­on experience a optimalizovat dialog o nové vstupy a poznatky. Cílem testování poslední fáze bylo důkladné otestování všech případů a možností a sběr komplexní zpětné vazby. 

Test setup Protože se jedná o webovou aplikaci spustitelnou na vzdáleném serveru z webového prohlížeče, testování probíhalo v přirozeném prostředí u participantů doma na jejich osobním počítači.   V prvních dvou fázíchj testování se ještě žádný rozvrh nezobrazoval (ani placeholder) a tetování proto probíhalo také s papírovou pomůckou. V místech, kde dle dialogu aplikace údajně zobrazovala rozvrh, jsem ručně aranžoval podle insturkcí uživatele rozvrh na papíře: 

 Obr. 3 papírový prototyp uživatelského rozhraní rozvrhu 

 V poslední fázi se již zobrazoval placeholder rozvrh, který ale na vstupy uživatele nereagoval. K použití papírové pomůcky už ale při testování nedošlo. 

Testovací procedura Každé testování se drželo následujícího protokolu: 

● Participant obdržel odkaz na aplikaci a byl obeznámen s tím, že účelem testování je ověřit fungování aplikace a získat podklady pro semestrální práci 

● Participant obdržel informaci o tom, že účelem aplikace je pomáhat s vytvořením rozvrhu 

● Participant obdržel informace o tom, že aplikace se ovládá komunikací psaným textem 

● Participant obdržel informace o otm, že testování může kdykoli ukončit, bude­li mu jakkoli nepříjemné nebo nepohodlné. 

● Participant poté obdržel zadaný testovací scénář. 

Testovací scénáře Scénář #1 Tvým úkolem je s aplikací se seznámit a vytvořit si rozvrh, který se ti bude líbit.  Cíl: ověřit schopnost uživatele se v aplikaci zorientovat, analyzovat vstupy v dialogu Pokrývá use cases: 

● 2.2.1. Vytvořit rozvrh ● 2.2.5. Zobrazit rozvrh předmětu 

 Scénář #2 Tvým úkolem je vytvořit rozvrh, který bude splňovat tvé požadavky.  Metoda: pomocí papírového prototypu byl předvytvořen rozvrh, který záměrně neodpovídá požadavkům uživatele, aby musel vyvolat alespoň 4 změny.  Cíl: ověřit schopnost uživatele se v aplikaci zorientovat, analyzovat vstupy v dialogu Pokrývá use cases: 

● 2.2.1. Vytvořit rozvrh  Scénář #3 Tvým úkolem je s aplikací komunikovat a hrát si  Cíl: sledovat snahy uživatelů ve snaze aplikaci rozbít nebo přiměř k netradičnímu chování a sledovat dopad na prožitek z aplikace. Ověřit hypotézu, zda implementace smalltalku je prospěšná pro design řešení.  

 

   

Závěry z testování Obecně  z testování vyvystalo velké množství dalších vstupů, které by dialog měl ošetřovat (např. na otázku “ano / ne” odpovídali také výrazy jako “jasně”, “tak určitě” apod.).   

1. Uživatelé mají problém s odpovědí delší než dvě věty / dva řádky a. Pokud aplikace odpovídala příliš dlouhým výstupem, participanti zbystřili a 

vyjadřovali frustaci. Bylo zjevné, že participanti kladou důraz na vyváženost rozhovoru a jsou rádi, když mohou “mluvit” stejně dlouhou dobu jako “poslouchat” 

2. Uživatelé rádi zkoušejí aplikaci rozbít a. Kdykoli se objevila nová otázka, jako první uživatelé vyzkoušeli odpověď, 

kterou podle nich aplikace čeká nejméně. Mnohdy se taková odpověď redukovala na strohé “nerozumím ti”, což ale uživatelé vnímali jako “výhru nad systémem”. Má přítomnost a kontext testování mohl způsobit, že testování neberou vážně. Přesto je zřejmé, že odchytávání netradičních vstupů netradičním způsobem má pozitivní dopad na prožitek z aplikace. 

3. Uživatelé jsou v odpovědích někdy zbrklí a. Uživatelé často bez přemýšlení zadali odpověď na otázku, která již byla 

nevratná. Aplikace na toto nebyla připravená. Měla by být implementována procedura, která umožňuje rozeznávat příkazy na revert operací. 

Fotodokumentace  

 

Obr. 4 participant č. 1 při testování

 Obr. 5 participant č. 2 při testován 

 Obr. 6 záznam obrazovky z komunikace participanta 

IV. Dokumentace pro vývojáře 

Validace vstupů a proměnné dialogů Samotný dialogový strom je rozvětvený a komplexní, většina těchto větví existuje z následujících důvodů: 

● ověření, zda aplikace správně pochopila požadavek nebo dotaz ● potvrzení uživateli, že aplikace správně přijala zadané instrukce ● ošetření krajních podmínek a případů ● přirozené a čtivé odpovědi s ohledem na velké množství možných kombinací ● zpracování většího množství dat najednou v rámci jednoho vstupu 

 Dialog vuyžívá standardní knihovny odpovědí, které klasifikuje jako “Ano” a odpovědí, které klasifikuje jako “Ne”. Mimo to definuje také řadu entit: 

● Days  ­ rozpoznává a pojmenuje zadaný den ● Hours ­ rozpoznává a pojmenuje zadanou hodinu rozvrhu. Umožňuje kombinovat 

vnímání hodinové (ve tři hodiny) podle času s hodinovým podle rozvrhu (čtvrtá hodina), s denním obdobím (odpoledne, večer) s pořadím (první, poslední). 

● Subjects ­ rozpoznává a pojmenuje zadaný předmět ● Paralels ­ rozpoznává a pojmenuje paralelku předmětu 

 Kromě entit využívá také následující enviromentální proměnné:  

Název / varianty proměnné  Datový typ  Význam 

d_mo / d_tu / d_we / d_th / d_fr    bool  Chce uživatel v tento den výuku? 

subj_nur / subj_pal / subj_pur / subj_tur / subj_tpj 

bool  Jsou tyto předměty pro uživatele důležité? 

input1 / input2 / input3 / input4 / input5 

text  Dynamické odchytávání vstupů pro validaci prostřednictvím entit 

freedays  Number  Kolik dnů chce uživatel volno? 

 Mimo to je pro každý předmět definována sada proměnných ve tvaru <kód>_sufix 

● <kód>_h ­ hodina přednášky aktuálně zvolené paralelky ● <kód>_hc ­ hodina cvičení aktuálně zvoleného paralelky ● <kód>_dc ­ den konání cvičení aktuálně zvolené paralelky ● <kód>d ­ den konání přednášky aktuálně zvolené paralelky ● <kód>p ­ kód aktuálně zvolené paralelky předmětu ● <kód>dis ­ flag zda se zobrazují překryvy dalších paralelek pro tento předmět 

 S použitím těchto informací jsou pak jednotlivé uzly diagramu vyhodnocovány následujícím způsobem: 

● KOS ­ uzel, kde se očekává kontrola napojení na KOS a test, zda je uživatel vpuštěn do rozvrhu. Prototyp napojení na KOS neimplementuje a odpověď je proto zde vždy kladná. 

● Kolik dnů volných ­ akceptuje vstupy 0 ­ 3 a rozeznává také vstupy 4 a 5. Vstupy je možné zadávat číselně i textem v různých variacích (pět, pětka, pet…). 4 a 5 nepřijme s požadavkem na zadání nižší hodnoty, protože rozvrh nebude možné generovat. 

● Které dny školu ­ ze zadného vstupu extrahuje 0 ­ 5 vstupů, které odpovídají patternu entity days. Jejich výskyt potom uloží do proměnných d_mo / d_tu aj. a zadané dny uživateli vypíše. Uživatel tak může zadávat vstupy jako “Pondělí, čtvrtek a úterý” a systém rozpozná pondělí, úterý i čtvrtek. 

● Které předměty důležité ­ dle stejné logiky jako u zadaných dnů kontroluje výskyt entity subjects a ukládá je do proměnných subj_nur / subj_tpj aj. 

● Vygeneruj rozvrh ­ viz. generování rozvrhu ● Zobrazit návrh ­ zobrazí vygenerovaný návrh rozvrhu. Uživatel může libovolně 

vznášet námitky a požadavky na úpravu, které aplikace zpracuje a zobrazí nový rozvrh. Typ požadavku rozeznává podle výskytu klíčových slov a ověřuje si, zda vstup rozeznala správně. Uživatel tak může zadávat přímé požadavky jako “Změň paralelku předmětu pur” stejně jako postupné jako “změň paralelku”, “předmět pur”, nebo dokonce i “změň”, “ano paralelku”, “předmětu pur” (kód paralelky se zde nerozeznává protože se neočekává, že ho uživatel zná z paměti).  

○ Změň paralelku ­ nabídne možné varianty a zobrazí dočasně překryvy v aktuálním návrhu. Po zvolení paralelku permanentně nahradí a zobrazí nový návrh. Rozeznává podle klíčových slov typu “změň” následovanými názvem předmětu. 

○ Zaplň mezeru ­ nabídne předměty, které disponují vhodnými volnými paralelkami na zaplnění mezery. Po zvolení předmětu je dotaz konvertován na požadavek na změnu paralelky. Umožňuje zadání také prostřednictvím entity days a hours (např. “zaplň sedmou hodinu v pondělí”). 

○ Zobraz varianty ­ permanentně zapne vykreslování zadaného předmětu. Kontroluje, jestli už vykreslování zadaného předmětu není zapnuté a případně odpoví varováním. 

○ Skryj varianty ­ permanentně skryje dříve zapnuté zobrazení varianty. Kontroluje, jestli vykreslování variant zadaného předmětu bylo zapnuté a případně odpoví varováním. 

○ Co můžu ­ odpoví jednou větou, která napovídá uživateli možné typy dotazů a požadavků 

● Poslat na e­mail ­ uživateli se zobrazí seznam finálních paralelek vytvořeného rozhovoru a uživatel má možnost si je nechat poslat na e­mail. 

   

  

Obr.1: kostra sekvenčního diagram dialogu 

Algoritmus generování rozvrhu Algoritmus generování rozvrhu si neklade za cíl najít ideální řešení, ale spíše optimální cestou dojít k zajímavému a přibližnému návrhu. Pochopitelně je snahou se v návrhu uživateli maximálně přiblížit a odhadnout jeho preference, není tak činěno za každou cenu. Důležité je zachovat rychlost a jednoduchost procesu komunikace a to i na úkor získání menšího množství dat a nepřesnějšího návrhu.  V následujícm textu pracuji s termíny důležité dny a důležité předměty. Těmito termíny mám namysli dny a předměty, které uživatel zadá v úvodních třech otázkách.   Při generování rozvrhu by aplikace měla postupovat následovně: 

1. Pro všechny důležité předměty vyber všechny kombinace paralelek těchto předmětů, kde žádná paralelka není umístěna mimo důležité dny a žádná paralelka nekoliduje s jinou. 

2. Pokud neexistuje alespoň jedna taková kombinace, sniž množinu důležitých předmětů o 1 náhodný předmět a proces opakuj. 

3. Pro každou kombinaci z kroku 1 vygeneruj a ohodnoť všechny kombinac e paralelek nedůležitých předmětů podle následujícího bodování: 

a. Bodový základ je 0 b. Výuka 1­2 nebo 13­15 hodinu ­5 bodů pro každý den c. Výuka 7­8 hodinu ­2 body pro každý den d. Chybějící výuka v důležitý den v 3­6 nebo 9­12 hodině ­1 bod za každou 

prázdnou hodinu pro každý důležitý den e. ­5 bodů za každou existující kolizi 2 a více předmětů v zadanou hodinu f. ­10 bodů za každý den nad rámec požadovaného počtu dnů docházky (za 

využití dne se počítá obsazení dne alespoń jednou paralelkou) 4. Vyber kombinaci s nejvyšším bodovým ohodnocením 

Funkční a nefunkční požadavky Hi­fi prototyp z hlediska uživatelského rozhraní kopíruje existující aplikaci What’s in Theater a upravuje pouze rozhraní pro zobrazení pravého vysouvacího menu, kde zobrazuje náhled rozvrhu (resp. placeholder grafiku).  Při dalším vývoji aplikace by však měly být implementovány následující prvky : 

● (priorita 1) Aplikace je napojená na KOS a usermap ○ aplikace komunikuje přes API s endpointy pro data z KOSu i usermapu a 

pracuje s nimi při tvorbě rozvrhu ● (priorita 1) Aplikace vykresluje dynamický rozvrh 

○ rozvrh se vykresluje souběžně s požadavky uživatele na úpravy a umožňuje přehledné zobrazení kolizí, vizuální odlišení variant paralelek od aktuálně nastavených, skrývání a odkrývání variant. 

● (priorita 1) Posílání nebo stažení rozvrhu ○ Aplikace umí výsledný rozvrh zaslat e­mailem nebo uložit do počítače 

● (priorita 1) Rozvrh je interaktivní ­ rozvrh by měl reagovat na doteky prstem (v případě mobilního zařízení), eventuelně pohyby myší, zejména pro následující akce: 

○ Zoom / unzoom / move ○ Kliknutí na rozvrh zobrazí varianty paralelek, kliknutí volnou variantu paralelku 

ihned změní. ○ Paralelku lze podržením “zvednout” ­ zobrazí se varianty paralelek ­ a 

přesunout do některého ze zvýrazněných  volných polí ­ tím se paralelka předmětu upraví. 

● (priorita 1) IBM Natural Language Analyzer ○ Integrován a rozšířen dialogový strom 

● (priorita 2) dialogový strom je optimalizovaný  ○ Dialogový strom obsahuje velké množství redundancí a nepracuje s  

● (priorita 2) Speech to text ­ text to speech ○ Podpora IBM services pro speech to text a text to speech 

● (priorita 2) Aplikace umožňuje pokročilé dotazy na úpravu rozvrhu ○ Mimo základních operací na nahrazení paralelky může uživatel zadávat také 

komplexní požadavky na vyplnění mezery, uvolnění konkrétního času, nahuštění většího množství výuky do jednoho dne nebo zakázání kolizí u specifických dvojic předmětů. 

● (priorita 2) Sdílení rozvrhů ○ Poslat vytvořený rozvrh kamarádov (qr kód a URL)i, aby ho rovnou mohl 

upravovat ● (priorita 3) Optimalizována pro telefony 

○ Na mobilním zařízení prohlížení rozvrhu musí být na šířku a dialogové okno snížit výšku na dva řádky.  

○ Podpora gest ● (priorita 4) Pamět a personalizace 

○ Aplikace si pamatuje preference uživatele a přizpůsobuje návrh jeho vlastnostem a zájmům. 

V. Design 

Vizuální design Grafický vzhled aplikace doporučuji jednoduchý a nerušivý. Velkou část informací zastoupí vykreslovaný rozvrh a vzhled aplikace by tedy měl podporovat čisté a jasné linky, které korespondují s mřížkou rozvrhu, nejlépe dle material designu. 

Interakční design (ovládání) Uživatelské rozhraní by mělo být čisté a jednoduché a obsahovat minimum aktivních prvků. Měl by se soustředit výhradně na dialogové okno s textem, sekci pro rozvrh a nastavení pro napojení účtů na externí systémy.   Uživatel bude moci ovládat aplikaci pomocí tří aktivních prvků, které reagují na dotyk nebo stisk myši: 

­ input text na psaní ­ push to talk na mluvení a vypnutí požadavku na push to talk ­ nastavení pro připojení do externích systémů ­ posouvání / částečné skrývání okna s rozvrhem na úkor okna s dialogem ­ posouvání a zoomování rozvrhu ­ výběr elementů a jejich přesouvání do volných slotů paralelek ­ trvalé zobrazení / skrytí paralelek předmětu 

UX  Uživatel by měl cítit z aplikace radost a budovat si k ní osobnější vztah. Měl by si ji zosobňovat, k FELdovi mluvit jako ke známému člověku a cítit k němu pocit důvěry. Rozhovor s FELdou by měl být zábavný, uvolněný a příjemný, aby uživatel snadno ztrácel pojem o čase, případně ho i rozesmát. FELda by měl ale zůstat stále nenucený a na uživatele působit ochotným dojmem.  UX principy pro design rozhovorů Při designu jednotlivých sekvencí musí být kladen velký důraz na jednoduchost a přirozenost ap roto bylo nutné zajistit dodržení následujících pravidel: 

● Je­li uživatel dotázán, vždy musí mít možnost zadat všechny potřebné informace v jedné zprávě. 

● Aplikace musí uživatele pravidelně utvrzovat v tom, že dělá to, co od ní očekává. ● Validace vstupů od uživatele musí mít dostatečně velké množství variací, aby bylo 

možné s aplikací komunikovat co nejpřirozeněji ● Pokud aplikace nepochopí vstup, uživatele na to musí vždy upozornit a požádat jej o 

upřesnění. ● Uživatelé musí mít vždy možnost upravit své zadání 

VI. Závěr Při práci na finálním produktu by bylo nutné klást velký důraz na průběžné testování, sběr dat a vylepšování dialogového stromu. Výroba prototypu prokázala velký prostor pro zlepšení, rozšíření možností a rozlišovacích schopností dialogu, stejně jako optimalizace struktury a rozhodovací logiky. Zapojení dalších služeb a technologií by potenciál aplikace mohlo rozšířit ještě více.  Za největší nevýhodu aplikace považuji nemožnost získat write práva do KOSu a uživatelé tak musejí stále opisovat paralelky ručně. Problémy mohou nastat také s psaným textem nebo “speech­to­text”. Při testování jsem často nabýval dojmu, že lidé nejsou příliš zvyklí mluvit na svůj počítač nebo telefon a raději by zůstali u standardního uživatelského rozhraní.