Symulacja procesu trzeźwienia, UX/dylematy/ocena

Cześć wszystkim,

w ramach nauki JS, postanowiłem odświeżyć stary projekt i chciałbym prosić Was o cenne uwagi.

link: https://alq.app/pl

To (kolejny) wirtualny alkomat, tym razem w formie aplikacji PWA (Progressive Web App), z naciskiem na działanie mobile i offline. (z tym jeszcze walczę)

Cel projektu:

Aplikacja ma za zadanie jak najdokładniej oszacować stężenie alkoholu we krwi (BAC) w czasie rzeczywistym i wskazać przybliżony moment, w którym będzie można bezpiecznie prowadzić pojazd z możliwością wyboru kraju w którym będziemy korzystać z tego pojazdu mechanicznego.

Priorytetem była dla mnie prostota i intuicyjność obsługi na urządzeniach mobilnych, świadomie na tą chwilę zaniedbując desktop.

Założenia i technologia:

Podstawą kalkulacji są sprawdzone modele farmakokinetyczne:
Wzór Widmarka do obliczenia teoretycznego maksymalnego stężenia alkoholu.
Wzór Watsona do precyzyjnego oszacowania całkowitej ilości wody w organizmie (na podstawie płci, wieku, wagi i wzrostu).
Własna implementacja symulacji, która modeluje proces wchłaniania i metabolizmu alkoholu w czasie. Dzięki temu krzywa BAC jest bardziej realistyczna (płynnie rośnie i opada), a nie skokowa.

Aplikacja uwzględnia również takie czynniki jak tempo picia oraz spożyte posiłki, co przekłada się na wiarygodniejsze wyniki.

Główny dylemat: UX vs. SEO w aplikacji wielojęzycznej

Docelowo aplikacja ma wspierać kilka języków i być dostępna pod domeną alq.app (dla angielskiego) oraz w podkatalogach (alq.app/pl, alq.app/de itd.). W związku z tym mam dylemat dotyczący pierwszego kontaktu użytkownika z aplikacją, który ma spore implikacje zarówno dla UX, jak i SEO.

Rozważam dwa podejścia:

• Automatyczne przekierowanie: Po wejściu na główną domenę alq.app skrypt wykrywa język przeglądarki (np. pl-PL) i automatycznie przekierowuje użytkownika na alq.app/pl.

  Plusy: Wygoda dla większości użytkowników.
  Minusy: Może być problematyczne dla botów wyszukiwarek i irytujące dla osób, które świadomie chcą używać innej wersji językowej.

• Landing page z wyborem języka: Użytkownik trafiający na alq.app widzi prostą stronę z flagami/nazwami języków do wyboru (pokazywany wyłącznie przy niezgodności języka przeglądarki z wybraną wersją językową)

  Plusy: Pełna kontrola po stronie użytkownika, rozwiązanie bardziej „bezpieczne” dla SEO.
  Minusy: Dodatkowy, niekonieczny krok (kliknięcie), który może zniechęcić część osób.

Które rozwiązanie Waszym zdaniem jest lepsze w kontekście aplikacji webowych?

Dodatkowo, wielka prośba o feedback:
Byłbym wdzięczny, gdybyście mogli rzucić okiem na aplikację i podzielić się swoimi spostrzeżeniami

Interesuje mnie głównie:

• Intuicyjność: Czy cały proces dodawania alkoholu, posiłków i śledzenia wyników jest zrozumiały bez czytania instrukcji?
• Klarowność interfejsu: Czy wszystkie elementy są oczywiste? Czy w którymś momencie można się „zgubić”?

Ogólne wrażenia: Czy widzicie jakieś rażące błędy, niejasności lub elementy, które j mogły mi umknąć?

Tomek.

Możesz robić sprawdzanie z przekierowaniem na podstrony tylko na alq.app. Utwórz sobie dodatkowo podstronę alq.app/en gdyby użytkownik chciał i tak przejść na język angielski. Pomysł ze stroną główną która od razu każe wybrać język to strzał w kolano.

Nie można dodawać, albo tego nie widzę np. 2x piwo o różnej zawartości procentowej alkoholu. W zasadzie jesteśmy ograniczeni do 4 trunków.

Całość jest przejrzysta i schludna, ale zauważyłem niespójne zachowanie sliderów :) Przeważnie w sliderach wartość można wybrać na dwa sposoby - złapać i przeciągnąć za "główkę" lub kliknąć w odpowiednie miejsce na suwaku. Działa to tak w sekcji "Parametry konsumpcji" (nic / mało / dużo ...), ale paski wagi wzrostu i wieku można zmieniać tylko poprzez przeciąganie:

Czemu ustawianie procentów jest takie głupie zamiast zwykłego inputa? Ta lista do wyboru wartości się automatycznie natywnie pojawi na telefonach a na komputerze to jest niewygodne.
Ograniczenia wieku, wagi, wzrostu też bym zmienił - rozumiem że ma sens z prawnego punktu widzenia ale zabiera use case'y - nie można się tym pobawić symulując różne sytuacje, albo użyć tego np żeby zobaczyć czy dziecko które przypadkowo wypiło drinka ze stolika będzie miało niebezpieczne stężenie alkoholu, poza tym alkohol w innych krajach jest legalny od wcześniejszego wieku, np od 14 lat w Niemczech, w USA można iść do baru w wieku 21 lat, ale w większości stanów w domu rodzice mogą legalnie częstować swoje dzieci alkoholem bez dolnego limitu wieku.

Narzędzie ogólnie mało użyteczne - jak wspomniano można dodać tylko 4 trunki, na stałe ustalona godzina początku i końca picia. Kto notuje takie rzeczy i pije jednostajnie? Lepiej by było na osi czasu nanosić drinki, bo to czy się wypiło wódkę na "początku picia" czy na końcu i czy się sączyło piwo przez 4 godziny po czym skończyło na obaleniu butelki wina ma duże znaczenie dla wyniku.
Jako ciekawy feature mógłbyś dodać skanowanie barcode'ów i automatyczne dodawanie trunków do osi, fajne by było gdyby apka pamiętała wzrost, wagę itp i można było ją włączyć, zeskanować piwko przy każdej butelce i na koniec po paru godzinach odczytać tylko aktualny wynik żeby wiedzieć czy rano w razie czego jechać szrotem czy normalnym autem.

Gdybym szukał takiej apki to raczej bym ją od razu wyłączył i szukał czegoś innego, ale rozumiem że to tylko projekt do szafy.

Tomasz Jaworski napisał(a):

Docelowo aplikacja ma wspierać kilka języków i być dostępna pod domeną alq.app (dla angielskiego) oraz w podkatalogach (alq.app/pl, alq.app/de itd.).

a po co w ogóle te podkatalogi? Zrób normalnie jedną aplikację używającej języka z przeglądarki i z możliwością wyboru języka w rogu, zmiana języka nie powinna powodować resetu wprowadzonych danych.

Na samej górze masz opcję wyboru płci - kobieta albo facet. Są wpisane jakieś wartości domyślne (u mnie się pojawiło 30 lat, 178cm i 78kg). Nie wiem, czy te wartości są tak wpisane z czapy, czy są to jakieś wartości średnie/z czegoś-tam wynikające. Ale dobrze by było, żeby przełączając płeć, te wartości się przełączały. Bo inną mamy średnią wagi i wzrostu dla niewiast, a inną dla ziomali.