MyDebts – projektowanie

Przyglądałem się przez chwilę Xamarinowi, szukając podobieństw do Windows Phone, na którego umiem programować. Axml wygląda w miarę przyzwoicie, jedyne co mi się nie podoba to słówko ‚android’ przed każdą właściwością. Zaśmieca nam to strasznie czytelność:

Postaram się pracować głównie na code behind, bo ten Xml jest trochę brzydki 🙁
Ten kanał wygląda obiecująco. Możliwe że wystarczy do ogarnięcia całej apki.

Debugowanie na telefonie

PdaNet naprawił mój problem z telefonem (VS go nie wykrywał). Czasem warto poszukać głębiej na Stacku, bo nierozwiązane pytanie mi pomogło.

Wystarczyło wybrać sterownik od HTC podczas instalacji programu. Następnie zostałem poproszony o podłączenie urządzenia. Kolejna zgoda na zaufanie sterownikom i voilà!

Mockupy i UX

Zawsze staram się projektować ekrany w aplikacji – nawet najprostszej – zanim zacznę ją pisać. Dzięki temu widzę czy wszystko łączy się w spójną całość, czy uwzględniłem wszystkie guziki itd. Dzięki temu jestem w stanie lepiej zaprojektować swoje klasy. Kod musi być otwarty na rozszerzenie (Open/Closed principle), ale jeśli robimy coś od nowa to lepiej od razu uwzględnić większość.

Program będzie się z dwóch widoków. Główny ma za zadanie wyświetlenie długów:

Prosta sprawa, po co to w ogóle projektować. Tworząc taką listę rzuca się jednak w oczy parę spraw. Skupmy się na jej pojedynczym elemencie:

  1. Kolor – jaki jest jego cel? W tym wypadku oznacza nam flagę – czy ja jestem komuś winny pieniądze (czerwony), czy czekam aż wrócą z powrotem do mojego portfela (zielony).
  2. Do dyspozycji mamy 4 właściwości: kto, ile, kiedy, komu (kolor). Wypadałoby zrobić sortowanie po każdej z nich. Mogłoby być umieszczone nad listą.
  3. Komentarz – czy jest potrzebny? Czy muszę zapisywać co kto zrobił z moimi pieniędzmi? Może warto by mieć taką opcję, ale wiem że ja nie będę jej potrzebował, dlatego pomijam.
  4. Waluta – patrząc na powyższy obrazek, myślę że tekst ‚zł’ jest zbędny. Będzie tylko męczył wzrok. Warto zastąpić go ikonką pieniądza. Czy powinienem zrobić obsługę kilku walut? Znowu: piszę aplikację na własny użytek i wiem że nie użyję tej opcji.
  5. Wygląd. Należy pamiętać że jest to tylko makieta. Pola powinny mieć stałą szerokość, np. 50/25/25%. Tylko wtedy możemy nad nimi umieścić ikony sortowania.

Nie muszę poprawiać szkicu, bo to strata czasu. Pokazał mi jednak, że o kilku rzeczach nie pomyślałem na samym początku. Na pewno uwzględnię je przy implementacji.

Pora na ekran poboczny, czyli dodawanie lub edycję wpisu:

Po pierwsze – jeden widok zamiast dwóch. Po co dublować swoją pracę, jeśli możemy wykorzystać ponownie coś co już utworzyliśmy. Diabeł tkwi w szczegółach:

  1. Nazwa dłużnika. Można ją wyciągnąć z książki adresowej (podpowiadanie), ale lepiej będzie zostawić proste pole tekstowe. Prawdopodobnie i tak wylądują tam pseudonimy.
  2. Ikona waluty – Evolus Pencil jej nie posiadał, dlatego na szkicu ustawiłem losowy, dziwny obrazek. Następnym razem powinien zwrócić moją uwagę. Można zamiast tego było dodać komentarz tekstowy, ale do moich celów tyle wystarczy.
  3. Pole waluty powinno być liczbą całkowitą. Wartość po przecinku raczej nie będzie potrzebna. Jeśli ustawimy wszystko poprawnie – telefon powinien otworzyć klawiaturę numeryczną.
  4. Kolor. Do flagi tak/nie użyłbym checkboxa, jeśli etykietka sugerowałaby pytanie. Tu, mając do dyspozycji dwie różne opcje przełącznik będzie idealny.
  5. Przycisk usuń – jest niewidoczny jeśli jesteśmy w trybie dodawania nowego wpisu. Druga sprawa – nie umieszczam go na dolnym pasku akcji, bo służy usuwaniu danych. Nie chcielibyśmy go przypadkowo kliknąć. Ale co gdy niechący wciśniemy? Wtedy powinien wyświetlić się pop-up z potwierdzeniem: ‚Czy na pewno usunąć?’.

Chwilowo nic więcej mi nie przychodzi do głowy. Mając gotowe takie szkice, możemy na nie w każdej chwili spojrzeć i zauważyć kolejne brakujące funkcjonalości. Ich utworzenie zajęło mi między 5 a 10 minut. Chyba warto.

Niektórzy programiści nie zdają sobie sprawy, że po drugiej stronie siedzi użytkownik, który oczekuje intuicyjnego interfejsu. Dyskutujemy o tym jakich frameworków użyć, ale gdzieś po drodze, zapominamy że tworzymy program dla klienta. Może go zaakceptować i zapłacić, ale nie będzie go nigdy używał z jednego prostego powodu – zamiast ułatwiać, będzie on utrudniał pracę. Mam nadzieję że znajdę kiedyś chwilkę, aby porządniej opisać parę spraw od strony UX.