Dekalog projektanta od Googla

google_chick.jpg
Kilka miesięcy temu – a w zasadzie to już ponad pół roku – Google opublikował na swoich blogu dekalog projektanta . Został on opracowany przez dział UX (User eXperience) który zajmuje się głównie projektowaniem GUI i badaniem tego “co powie użytkownik”.

Prostota tego dekalogu i przesłanie jakie za sobą niesie zachęca mnie do przepisania go tutaj 🙂

 

  1. Skup się na ludziach – ich życiu, pracy, marzeniach.
  2. Liczy się każda milisekunda.
  3. Prostota ma wielki potencjał.
  4. Zainteresuj początkujących i zwab ekspertów.
  5. Miej odwagę wprowadzać innowacje.
  6. Projektuj z myślą o całym świecie.
  7. Planuj na dzisiaj i na przyszłość.
  8. Spraw wizualną radość bez rozpraszania myśli.
  9. Bądź warty zaufania innych ludzi.
  10. Dodaj coś od siebie.

Nie przypadkowo podkreśliłem tutaj punkt 3, którym staram się kierować tworząc wszystko co zaspokoja potrzeby innych i moje. Uważam, że tylko proste rozwiązania mają rację bytu, szczególnie jeżeli chodzi o rozwiązania IT. Programowanie nie powinno być sztuką dla sztuki, a jedynie środkiem do osiągniecia określonego celu.

Niestety każdy “prawdziwy” programista na pewnym etapie swoich umiejętności odchodzi od prostych rozwiązań i zaczyna “kombinować” – wydaje mu się, że dane rozwiązanie jest bardziej profesjonalne niż być powinno. Dzięki utworzeniu dodatkowej klasy, obiektu, funkcji wydaje mu się, że program będzie działał lepiej. Niestety w końcowym efekcie powoduje to maksymalne zaciemnienie kodu i spowolnienie jego działania.

Dobrym przykładem z innej beczki, są strony internetowe oparte na najnowocześniejszych standardach i flagowe hasło “zero tabelek” – z jednej strony jestem jak najbardziej za, ale… tabelki nie zostąpi nic – zawsze utrzyma ona odpowiednią pozycję i kolumny. Będzie tak samo wyglądała pod IE, FF, Safari i Operą, czego nie można powiedzieć o DIVach z atrybutem float 🙂

Oczywiście mają rację Ci, którzy twierdzą, że czasami nie da się zrobić prostej wersji. Czasami warto się jednak zastanowić czy nie zamiast szukać błędu w 100 liniach kodu, nie łatwiej napisać całość od początku i zrobić to w 20.