Mało czasu

Czas goni, a rąk i głów i czasu do implementacji ficzerów brakuje. Co wtedy robić, od którego zacząć robić żeby było lepiej dla aplikacji i dla ludzi, a na końcu dla mnie i mojego portfela?

Zamiast zastanawiać się w ten sposób, może warto oddać głos użytkownikom? Niech oni klikają w system, system zbiera te informacje i w krótkim czasie można się dowiedzieć co było klikane najczęściej i właśnie na tym skupić kolejna działania rozwojowe.

Mój pomysł

Jak ja do tego podszedłem? W poprzednim wpisie pokazałem jak wygląda u mnie pasek pod każdym w rss (http://jaroslawstadnicki.pl/2016/04/font-awesome-w-mvc/).
Kod odpowiedzialny za wyświetlenie tego paska wygląda w taki sposób:

Są to małe elementy inline, które wyświetlają ikonę i tyle. Używając atrybutów data (dokładniej: data-rssaction-url) nadaje im od razu adres pod który mają zostać wysłane (ogromne dzięki dla Tomka Pluskiewicza – i jego sesji, wpisy dostępne http://t-code.pl/blog/2016/02/rest-misconceptions-0/). Obsługa kliknięcia jest wspólna dla wszystkich dostępnych akcji, dlatego że każdy element ma swój adres i podczas obsługi nie muszę się tym przejmować:

Na początku widać obsługę metod zwrotnych dla szczęścia i nieszczęścia (@1-@3). Potem właściwy kod, który wyciąga “guzik” (@7) (span pełni rolę guzika), potem url który jest tam zaszyty(@9). Potem usuwa klasę (@8) (za chwilę o tym dlaczego), aż wreszcie robi posta pod wcześniej odczytany adres url – cała filozofia ze strony klienta (przeglądarki). Trzeba dodać tylko jakiś komunikat dla użytkownika,  że opcja nie jest jeszcze włączona, ale już nie długo będzie działać – czy coś takiego. Jeszcze poniżej znajduje się oczekiwanie na kliknięcie elementu. Jeśli nie jesteś przyzwyczajony do takiego zapisu przeczytaj ten wpis: http://jaroslawstadnicki.pl/2016/03/przepowiedziana-obsluga-elementow-w-jquery-on/

Za dużo kliknięć?

Dlaczego usuwam klasę (@8)? Myślałem o tym jak rozwiązać problem zbyt częstego klikania w guzik, może throttle/debaunce. Może jakaś mapa, że dany guzik był kliknięty, może coś innego. Aż wreszcie postawiłem na prostotę. Usunięcie klasy która prowokuje sam event. Co to daje? Gdy nie ma klasy, event “click” nie zostanie wygenerowany, co za tym idzie ten sam użytkownik na tym samym elemencie rss, nie zostanie podwójnie policzony jako ten, który chce daną funkcjonalność. Dodatkowo sam element po przeczytaniu (wystarczy rozwinąć) zostaje oznaczony jak przeczytany, czyli ponownie się temu samemu użytkownikowi nie wyświetli (na razie nie ma opcji wyświetlania nieprzeczytanych rss) – wszystko co potrzebowałem mam. Bez dodatkowego kodu – czyli taniej i z mniejszą ilością błędów. Wiem że troli nie brakuje, a url jest jawnie podany – nie przejmuje się tym 😉

Co dalej?

Sprawa trafia do kontrolera (@1-@7), który przekazuje to dalej i na koniec mówi OK.
Serwis (@9-@14) pobiera aktualnego użytkownika i razem z identyfikatorem rssa przekazuje to jeszcze niżej do repozytorium, aby to zapisało to do bazy.
Na samym końcu tworzony jest obiekt (@19-@24),  który odzwierciedla akcję (@23) (brakującą funkcjonalność), łączy to z użytkownikiem i elementem i ostatecznie wrzuca do bazy(@26) i zapisuje zmiany (@27). Siup! Koniec.

Można powiedzieć, że szkoda czasu bo przecież głosowanie na tak / nie jest proste i zajęło by tyle samo czasu co implementacja tego co właśnie napisałem. Może i tak, ale ten system teraz będzie odpowiedzialny za te dwie i kolejne brakujące opcje:

Na bank pojawią się także inne opcje, które początkowo zostaną obsłużone w takim samo sposób: “Dziękuje za kliknięcie, opcja jest w trakcie implementacji. Powiadomimy Cie postępach oficjalnym kanałami – CTO”. Fajnie być CTO.

Alternatywy

Inaczej? Można założyć sobie uservoice i tam słuchać tego co napiszą użytkownicy. Można też napisać całą i gotową aplikację i nie słuchać w ogóle tego co chcą użytkownicy. Można wszystko.

Oczywiście dokładna implementacja dostępna w źródłach projektu na: https://github.com/jstadnicki/isthereanynews