W ramach „radosnej eksploracji” tematu chatbotów pierwszym (i jeśli wystarczy czasu to niejedynym) projektem jaki zrealizuję będzie chatbot do… smogu.
Smog jest w ostatnich tygodniach realnym problemem, zwłaszcza w Krakowie, w którym mieszkam, toteż jest to dobry temat na chatbota, który umożliwi jednocześnie zaprezentowanie kilku fajnych patternów, m.in. związanych z personalizacją chatbota jak również z komunikacją zwrotną rozpoczynaną przez chatbota do użytkownika (tzw. proactive bot).
Chatbot vs aplikacje mobilne
Oczywiście istnieje masa aplikacji do sprawdzania stanu powietrza na komórki, natomiast chatbot ma nad aplikacją mobilną kilka zalet:
- Nie wymaga instalacji na urządzeniu – śledziłem ostatnio trendy w aplikacjach mobilnych i problem jaki regularnie jest dyskutowany to spadek ilości instalacji aplikacji na urządzaniach. Użytkownicy coraz mniej chętnie instaluję kolejną aplikację, która służyć będzie do jednej rzeczy. Chatbota nie instalujemy, wystarczy raz do niego „zagadać” i korzystać z niego wtedy, kiedy potrzebujemy, bez zbędnej zabawy w instalację czegokolwiek dodatkowego.
- Działa w chmurze, a nie na urządzeniu – co ma kilka istotnych zalet: nie musimy martwić się o to, że chatbot uzyska nadmierny dostęp do danych na urządzeniu (np. do listy kontaktów, listy sieci WiFi, lokalizacji etc.), dodatkowo chatbot nie zużywa baterii ani transferu danych na urządzeniu, nie zajmuje miejsca w pamięci ani na ekranie urządzenia. Dostępny jest wtedy kiedy go potrzebujemy, przez ulubiony komunikator.
- Nie musisz się go uczyć – dobrze zaprojektowany chatbot oferuje albo wygodne menu do nawigacji sugerujące kolejne kroki albo też rozumie mowę naturalną w takim stopniu, że możemy po prostu z nim porozmawiać, co jest bardziej naturalne niż wyklikiwanie aplikacji.
Założenia projektowe
SmogBot w pierwszej wersji powinien realizować następujące funkcje (wg metody MoSCoW):
- Musi integrować się z przynajmniej jednym źródłem danych o zanieczyszczeniu powietrza.
- Musi umożliwiać użytkownikowi sprawdzenie ostatnich przekroczeń norm zanieczyszczeń dla danego miasta.
- Musi dostarczać podstawową pomoc w postaci opisu działania, menu wyboru głównych opcji, sugestii co można zrobić.
- Powinien zapamiętywać określone przez użytkownika miasto jako jego domyślne, aby przy następnych sprawdzeniach nie trzeba było go określać.
- Powinien umożliwiać łatwą zmianę domyślnego miasta.
- Może obsługiwać funkcję dzielenia się lokalizacją z poziomu komunikatora do określenia miasta do zapytania.
- Powinien umożliwiać użytkownikowi zdefiniowanie godzin o których bot sam dostarcza informacje o przekroczeniach norm zanieczyszczeń, o ile takowe występują danego dnia dla zdefiniowanego domyślnego miasta – co załatwia wszelkie scenariusze typu „powiadomienie przed wyjściem do pracy”.
- Powinien umożliwiać użytkownikowi zdefiniowanie czy chce otrzymywać powiadomienia o znaczącym pogorszeniu lub polepszeniu warunków, tuż po ich zanotowaniu, niezależnie od zdefiniowanych godzin powiadomień – taki scenariusz jest przydatny będzie w sytuacji gdy w ciągu dnia warunki bardzo się pogarszają, a także dla użytkowników, którzy preferują mniejszą liczbę powiadomień i nie chcą codziennych raportów o stałych godzinach.
- Powinien oferować możliwość rozpoznawania nazw miast podanych w przypadkach innych niż mianownik – czyli obsługa wyrażeń w stylu „jaki smog jest w Krakowie” zamiast „sprawdź smog w mieście Kraków”.
- Może rozumieć mowę naturalną (jako uzupełnienie systemu opartego na menu i regułach).
- Może oferować przyjemne dla oka grafiki, urozmaicające konwersacje.
- Może oferować kilka wariantów szablonów odpowiedzi.
I dorzucę kilka wymagań pozafunkcjonalnych, jakie projekt powinien spełniać:
- Powinien być zaprojektowany jako rozwiązanie cloud native – aby był możliwie bezobsługowy i możliwie niskokosztowy w utrzymaniu.
- Powinien być zrealizowany w architekturze serverless – głównie, aby zaprezentować skalowalność rozwiązań chatbotów oraz… nauczyć się czegoś nowego :)
Pomóż w tworzeniu SmogBota!
O ile zasady DSP2017 nie pozwalają na tworzenie kodu przez kilka osób, o tyle… możesz napisać, jakie funkcje chciałbyś w takowym bocie zobaczyć – postaram się je w miarę możliwości uwzględnić :)
Jeśli ten wpis czytałby jakiś grafik lub znasz jakiegoś grafika, który mógłby zaoferować mi projekt drobnych grafik związanych ze smogiem (typu logo, ikonki symbolizujące poziom zanieczyszczenia), najlepiej na licencji beerware, to proszę o kontakt :)
W następnych wpisach…
… opowiem trochę o technologii, w jakiej SmogBot jest przeze mnie tworzony, o jego hostingu, wdrażaniu etc. Następnie omówię poszczególne komponenty, z których składać się będzie to rozwiązanie, by w końcu przejść do niektórych „smaczków” technicznych :)
Zapraszam więc do śledzenia tego bloga, czy to przez kanał RSS, czy też poprzez stronę na Facebooku.
Łukasz mar 01 , 2017 at 17:42 /
Ciekawy projekt! ;)
Co do tego , że zasady DSP2017 nie pozwalają na tworzenie kodu przez kilka osób to nie do końca prawda. Pozwolę sobie zacytować fragment regulaminu:
„b. Zarządzanie wkładem innych osób poprzez Pull Requests wchodzi w skład obowiązków twórcy projektu Open Source, więc zdecydowanie jest dozwolone
c. Dozwolona jest wieloosobowa praca nad jednym systemem z zastrzeżeniem, że każda z osób realizuje implementację odrębnego komponentu. Każda z osób musi wystartować w Konkursie osobno i prowadzić swojego bloga, rozwijając własny komponent na swoim repozytorium”
Pozdrawiam! :)
Grze gru 22 , 2017 at 08:36 /
Albo słabo widzę, albo brakuje linku do następnego artykułu (są powiązane wpisy).
Innymi słowy – tuż po przeczytaniu tekstu, chciałbym mieć możliwość łatwego przejścia do ciągu dalszego, nie zaś wracania się do pełnego spisu artykułów.