Grzegorz Majewski Mija właśnie półmetek pracy nad projektem, więc postanowiłem podzielić się pierwszymi wnioskami oraz screenami. Cały projekt tworzony jest w technologii przyjaznej dla urządzeń mobilnych Responsive Web Design i to sprawia najwięcej problemów. Drugim problemem jest HTML i tworzenie kolejnych ekranów – zajmuje to za dużo czasu. Były też błędy projektowe oraz martwi mnie proces pobierania wolnych terminów – bardzo obciąża bazę danych. Ale po kolei.
Responsive Web Design – czyli o małych ekranach telefonów
Wydawać by się mogło że Responsive Web Design jest lekarstwem na małe ekrany telefonów i tak pewnie jest w przypadku treści o charakterze newsowym. Natomiast jeśli chodzi o bardziej skomplikowane aplikacje webowe nie jest tak pięknie. Kluczem jest tutaj słowo skomplikowane, ponieważ umieszczenie na małym ekranie telefonu sporej liczby funkcjonalności jest dość trudne. Można skalować elementy strony, jednak musimy pamiętać o wielkościach minimalnych aby rozmiar ikon nie utrudniała korzystania z aplikacji. Tak wiec zostajemy ze stosunkowo dużymi elementami na małym ekranie. Drugim problemem jest szerokość strony. Ekrany monitorów są poziome natomiast telefonów pionowe, więc cała treść z poziomej przekształcana jest w pionową. Efektem tego jest bardzo długa i wąska strona. Niestety nic na to nie jestem w stanie poradzić – oczywiście mogę ukrywać treści ale wolałbym aby wersja mobilna miała pełne funkcjonalności wersji na komputery.
HTML – szkoda że nie jestem webmasterem
Tworzenie aplikacji webowej składa się z 2 głównych części – backend i frontend. Backend to skrypty wykonywane po stronie serwera (pobieranie treści z bazy danych, przetwarzanie, generowanie HTML’a) natomiast frontend to technologie wyświetlane w przeglądarce (HTML, CSS, JS) – czyli to co widzimy. Pomimo tego, że korzystam z gotowego szablonu stworzonego w oparciu o Twitter Bootstrap, sporo czasu zajmuje mi dopracowanie elementów, zmiana szablonów oraz programowanie w JavaScript. Jeśli spojrzymy procentowo na cały proces to backend zajmuje 30-40% a frontend 60-70% czasu.
Błędy projektowe
Już kilka ładnych lat projektuje aplikacje webowe i pomimo tego ciągle popełniam błędy. Nie są to już błędy natury relacyjnej czyli np. złe rozłożenie danych i relacji pomiędzy nimi, są to błędy natury projektowej. Niestety podobnie jak wielu projektantów/programistów mam skłonność do wybierania bardziej uniwersalnych ale zarazem skomplikowanych rozwiązań. W tym projekcie przekombinowałem kwestie użytkowników i uprawnień. Stworzyłem dość mocno rozbudowany system uprawnień, który pozwalał na posiadanie jednego globalnego konta w całym systemie nakiedy.com i z jego poziomu zarządzać wieloma kalendarzami, różnych firm oraz występowanie w różnych rolach. Niestety, gdy zacząłem tworzyć pierwszą wersje rejestracji oraz zarządzania profilem, okazało się że musi być ona mocno rozbudowana i dość skomplikowana. Tak więc przeciętny użytkownik – w tym przypadku nie jest to osoba techniczna – może mieć z nim duże problemy. Nie pozostało mi nic innego ja mocno uprościć uprawnienia do kilku ról i wydzielić konto do zarządzania kontem od kont pracowników. Oczywiście zmiany nie ograniczyły się tylko do autoryzacji, musiałem poprawić też pozostałe, stworzone już moduły związane z ustawieniami, pracownikami i usługami aby współpracowały z nowym modułem uprawnień.
Sprawdzanie wolnych terminów, czyli jak nie zabić bazy danych
Od kilku dni pracuje nad kalendarzem i wyświetlaniem wolnych terminów. Prawdę mówiąc nie zdawałem sobie sprawy, ile rzeczy muszę sprawdzić aby potwierdzić że dany dzień i godzina jest dostępna do rejestracji. Generalnie proces wygląda tak:
- Sprawdzam czy firma nie ma wolnego dnia
- Sprawdzam czy firma tego dnia o tej godzinie pracuje
- Sprawdzam czy pracownik nie ma wolnego
- Sprawdzam czy pracownik pracuje danego dnia, w określonych godzinach
- Pobieram rezerwacje z danego dnia dla wszystkich pracowników
- Sprawdzam czy czas usługi nie nakłada się na czas innej usługi
Jeśli chciałbym sprawdzić czy są wolne rezerwacje dla każdego dnia miesiąca, za każdym razem gdy ładujemy stronę, to przy kilkuset osobach online, baza danych miałaby spore problemy. Tak więc muszę pomyśleć nad jakimś sposobem cachowania pojedynczych zapytań lub rezultatów całego procesu. Sprawa z cachowaniem też nie jest prosta, ponieważ warto robić to dla danych stosunkowo rzadko zmieniających się i oczywiście pamiętać o tym, aby cache był zawsze aktualny.
I na sam koniec to na co wszyscy czekają czyli screeny
Głównym założeniem projektu jest prostota i przejrzystość i tak właśnie wygląda interface. Niestety zaczynam zauważać że jest on zbyt ubogi, dlatego w najbliższy weekend postaram się wzbogacić logo i ikony górnego menu o jakieś kolory.
