Ikonki towarzyszą nam od czasu kiedy na stałe zadomowiły się u nas systemy z graficznym interfejsem użytkownika. Ich zadanie jest proste: w czytelny dla użytkownika sposób przedstawić funkcjonalność/akcję do której jest ona przypisana.
Dzięki temu bez potrzeby czytania całego opisu wiemy w co kliknąć.
Postęp technologiczny sprawia jednak, że część ikonek zaczyna tracić sens i przestaje być zrozumiała dla młodego odbiorcy.
Zwróćmy uwagę na poniższą listę ikonek:
“Zapisz” prezentowane jako dyskietka.
“Filmy” prezentowane jako klisza filmowa.
“Szukaj” prezentowane jako lupa (szkło powiększające).
Wszystkie te znaki graficzne choć zrozumiałe dla starszego pokolenia i ludzi często przesiadających przed komputerem, dla młodszych osób mogą już nie być tak oczywiste.
Jaki jest najlepszy sposób na doprowadzenie ciekawego i przemyślanego projektu do sytuacji w której staje się on horrorem nie tylko dla jego twórcy ale i dla developerów którzy mają przy nim pracować?
Najlepiej zacząć wszystko unifikować. Tworzyć kod ogólnego użytku, tworzyć warstwę-warstwy-warstwy pośredniej, używać wielu klas abstrakcyjnych, przewidywać możliwe sposoby użycia dla wręcz paranoicznych przypadków. Poddać się naszej chęci do stworzenia kodu wręcz doskonałego. Kodu gotowego do zastosowania dla pierwotnej idei ale także do nieco bardziej rozbudowanych funkcji, a może i nawet do funkcjonalności której ten kod nie został z początku pomyślany… a dlaczego nie miał by on parzyć kawy i wyrzucania śmieci - w końcu skąd mamy wiedzieć czy docelowo do tego go nie użyjemy?
Jednym słowem najlepiej stworzyć kod, którego sam Bóg by się nie powstydził, a po naszej śmierci (jak to zwykle bywa z tego typu honorami) postawiono by nam pomnik w dowód naszego wkładu w budowanie lepszego świata.
Ale zacznijmy od początku.
W swojej pracy i poza nią spotkałem się z dwoma głównymi typami programistów, pod opisami którymi, mniej lub bardziej każdy z nas może się podpisać.
Pierwsza grupa to zadaniowcy. Programiści, którzy pracują nad projektem od zadania, do zadania. Rozwiązując na bieżąco problemy, które napotkają. Nie wnikając zbytnio w atomowe części projektu i skupiający się na uzyskaniu założonego celu.
Druga grupa to artyści. Programiści, którzy mają wizję i często dają się jej ponieść. A wtedy już nie trudno o to aby projekt stał się kolejną częścią koszmaru z ulicy wiązów.
Niestety często mogę podpisać się pod tą druga definicją.
Nie tak dawno wraz z kolegą omawialiśmy pewien projekt. Siedząc przy piwku sporządzaliśmy zestaw wymagań tego co ta aplikacja ma posiadać.
Wyszliśmy z podstawowego celu jakim była założona funkcjonalność, ale szybko doszliśmy do wniosku, że może się ona rozszerzyć o kilka innych, których powiązanie może nie do końca współgrać z tym co ustaliliśmy (a przynajmniej tak sobie wmawialiśmy).
Kanał ATOM
