Dlaczego niektórzy programiści nienawidzą części interfejsu użytkownika związanej z opracowywaniem? [Zamknięte]

Wielu programistów, których spotkałem, zawsze mówi: „On nie jest facetem od UI”. Faktem jest, że obecnie programowanie, czy to web, Windows, Linux, OSX, czy jakikolwiek inny rodzaj programowania, obejmuje teraz oprogramowanie z dobrze wyglądającym interfejsem użytkownika. Dlaczego tak wielu programistów wydaje się nie lubić działania interfejsu użytkownika?

Nie jestem też użytkownikiem interfejsu użytkownika. Cóż, robię interfejs użytkownika na własnych projektach, ale w pracy nie mam z tym nic wspólnego - moja praca jest w trzewiach aplikacji, a nie w interfejsie.

Poza tym myślę, że to bardziej nuda niż nienawiść. Projektowanie interfejsu użytkownika jest trudną i wymagającą częścią. Wdrożenie to głównie cholerna robota. Jest bardzo niewiele wyzwań i innowacji w tym, jak można wdrożyć interfejs użytkownika, i tylko tyle razy można umieścić pole wyboru na ekranie, zanim przejdzie się nieco mentalnie. I to nawet nie dotyka spędzania godzin na dopasowywaniu pikseli „tak”.

Tworzenie dobrego interfejsu użytkownika wymaga wielu różnych umiejętności niż pisanie kodu zaplecza.

Wymagania dotyczące zaplecza można zwykle określić jak czarną skrzynkę, x wchodzi i oczekuje się, że y wyjdzie. Uruchomienie go wymaga implementacji logiki i można programowo przetestować, czy działa, czy nie.

Aby stworzyć dobry interfejs użytkownika, należy wziąć pod uwagę użyteczność, wygląd, układ i inne elementy, takie jak schematy kolorów. Posiadanie kreatywności artystycznej jest tutaj bonusem, a wielu programistów nie czuje, że mają to. Logicznemu mózgowi rozwiązanie problemu z interfejsem użytkownika może wydawać się subiektywne, ponieważ nie ma jednej poprawnej odpowiedzi lub łatwego sposobu zweryfikowania, czy zostało to zrobione „poprawnie”.

Myślę, że wielu programistów, którzy nie mają dużego doświadczenia z interfejsem użytkownika lub nie przeprowadzili zbyt wielu badań, nie zdaje sobie sprawy, że istnieją dobre zasady i nauka zarówno za dobry projekt interfejsu użytkownika zarówno z perspektywy użyteczności, jak i projektu (np. Kolor teoria).

Oczywiście niektórzy programiści nie mają problemu z tym aspektem, ale go nienawidzą, ponieważ wiele interfejsów użytkownika jest po prostu nudnych w kodzie. Mogą się składać z wielu powtarzających się prac, takich jak strony formularzy dla stron administracyjnych, gdzie muszą być tylko funkcjonalne i nie ma żadnych problemów projektowych.

Ludzie mają po prostu inne zainteresowania. Niektórzy programiści są bardziej zainteresowani strukturami danych i algorytmami, niektórzy architekturą, niektórzy użytecznością i projektowaniem interfejsu użytkownika - lub dowolną kombinacją tych i innych nisz. Każdy z nich wymaga różnych umiejętności i różnych sposobów myślenia o problemie. Jeśli lubisz niskopoziomowe nakrętki i śruby programowania, być może nie dbasz tak bardzo o to, jak myśli użytkownik, i odwrotnie.

Osobiście należę do tego drugiego obozu - wolałbym raczej zaprojektować interfejs użytkownika niż skomplikowany algorytm. To jest coś, co wydaje mi się interesujące.

To, czy dany projekt interfejsu użytkownika jest dobry, czy zły, jest dość subiektywne , co, jak sądzę, dla programistów ogólnie nie jest atrakcyjne. Kilkadziesiąt lat starań, aby określić ilościowo i zakwalifikować dobre techniki interfejsu, pomogło stworzyć pewne ogólne zasady, które można zastosować, ale często nie do końca ustalenie, czy interfejs jest dobry, wymaga wielu testów A / B i innych obserwacji użytkowników techniki.

Podczas gdy z pewnością istnieje subiektywność w programowaniu, zwykle można wskazać na jakąś obiektywną przyczynę, dlaczego jeden wybór jest lepszy od drugiego: szybkość wykonania, wymagania dotyczące pamięci, elastyczność w zaspokajaniu prawdopodobnych przyszłych potrzeb, praktyki, które okazały się bardziej skuteczne w przeszłość itp. Obrona danego wyboru interfejsu użytkownika - a więc nawet sam wybór - zwykle sprowadza się do „podoba mi się”, co jest zupełnie innym argumentem na poparcie.

Osobiście nie lubię opracowywać interfejsu użytkownika, ponieważ nie jestem w tym dobry. Istnieje ogromny element psychologii użytkownika, który po prostu nie jestem dobry w zrozumieniu. Myślę, że moim największym problemem jest to, że nie mogę postawić się w butach użytkownika. Nie wiem, jak tworzyć intuicyjne układy, głównie dlatego, że nie wiem, co jest intuicyjne dla użytkownika, ani nie wiem, jak sprawić, by wyglądały ładnie.

Niekoniecznie uważam, że niektórzy programiści nienawidzą projektowania interfejsów użytkownika tak bardzo, jak nienawidzą robienia rzeczy, w których nie są dobrzy. Zdarza się, że jest wielu programistów, którzy nie są dobrzy w tworzeniu interfejsu użytkownika.

Problem z projektowaniem interfejsu użytkownika polega na tym, że każdy ma opinię ... I nie ma właściwej ani złej odpowiedzi. Z drugiej strony programiści uwielbiają czarno-biały i logikę. W firmie dowolnej wielkości wszyscy się zgodzą 1+1=2, ale zapytaj, która czcionka ułatwia czytanie (Comic Sans Obviously)... przygotuj się na powódź. Dziesięć tysięcy różnych odpowiedzi i każdy ma rację, ponieważ każdy jest inny.

Jako programista, który naprawdę lubi pracę nad interfejsem użytkownika (konkretnie, zrobiłem uczciwy udział w projektowaniu stron internetowych), doceniam to, gdy ktoś, kto nie ma zestawu umiejętności, pozostaje poza tym.

Rozwijanie wymaga umiejętności przechowywania wielu danych w pamięci i radzenia sobie z wieloma z nich jednocześnie. Projektowanie interfejsu użytkownika wymaga umiejętności sprowadzenia go do minimum, bez poświęcania jego integralności. Ja kocham wyzwanie, że; i kulę się, gdy widzę, że ktoś tworzy interfejs użytkownika, którym nie da się zarządzać danymi na ekranie. (Jestem również totalnym maniakiem, jeśli chodzi o układ, teorię kolorów itp.)

Z drugiej strony nienawidzę rzeczy niskiego poziomu. Nigdy nie zmienię kodu sterowników, jąder ani niczego podobnego: wzdrygam się: pozostawię to „chłopakom spoza interfejsu użytkownika” i cieszę się, że ktoś lubi to robić, bo inaczej nigdy tego nie zrobi.

Myślę, że to zależy od tego, czy większość programistów używa lewej części mózgu.

Dobre źródło do dalszego czytania tego tematu.

Tworzenie interfejsu użytkownika staje się skomplikowane, ponieważ dostajesz zbyt dużo danych od niewłaściwych osób. Wszyscy są ekspertami od projektowania graficznego. Nie można ich znaleźć, gdy chcesz poznać formułę czegoś.

Nie wiedzą, czego chcą, ale wiedzą, kiedy to widzą, nie mają smaku, a ci z mocą decyzyjną i tak nie będą korzystać z aplikacji, ale są pewni, że powinna być zielona. Postępujesz zgodnie ze wskazówkami dotyczącymi dobrego interfejsu użytkownika, takimi jak ograniczenie liczby pól w formularzu i otrzymujesz prośbę o dodanie 50 dodatkowych pól, ponieważ „potrzebują” one wszystkie, a umieszczenie ich na osobnych kartach to zbyt duży wysiłek. Wiesz, to samo co Excel. Chłopi!

Nie możesz tego wymyślić. Siedziałem na spotkaniu, w którym dwie najlepsze osoby z działu księgowości (wynagrodzenie ok. 500 tys. Rocznie) dla dużej kancelarii prawnej spędziły pół godziny kłócąc się o etykietę na stronie internetowej rozliczeń używanej przez prawników. Miało to ułatwić prawnikom zrozumienie. Dlaczego nie zapytać prawników? Zbyt łatwe. Dlatego dział IT dostaje 50 telefonów od prawników, którzy chcą poznać WTF „Rezydualna kwota rozliczeniowa netto” i dlaczego znajduje się w formularzu zgłoszeniowym.

Niektórzy ludzie lubią brokuły, inni nie. Być może będziemy musieli to zjeść, ale nie musimy tego lubić i nie będziemy się nim cieszyć, kiedy jemy. Mało tego, unikniemy spożywania go tak dużo, jak to możliwe.

Istnieje wiele innych rzeczy do kodowania niż tylko interfejs użytkownika. Usługi sieciowe, usługi Windows, osadzone (niewiele z interfejsu użytkownika w kuchence mikrofalowej), żeby wymienić tylko kilka przykładów.

Może to wynikać z tego, że - w niektórych przypadkach - narzędzia, które są wyraźnie pomyślane, aby pomóc ci wyciągnąć interfejs użytkownika, zamiast tego ssać martwe małpy przez słomkę.

Są pewne rzeczy w rozwoju interfejsu użytkownika, które trudno jest naprawić.

Układ jest jednym z nich. Buduję interfejsy użytkownika od ponad 15 lat i jeszcze nie mam przyzwoitego rozwiązania do zarządzania układem.

Innym jest routing zdarzeń - nawet przy architekturze MVP i innych rzeczach wymaganych przez frameworki, argumentowałbym, że większość skomplikowanych interfejsów użytkownika ma problemy z routingiem zdarzeń - które można wykryć, jeśli którykolwiek z frameworków testowych mógłby rozwiązać je dobrze.

Wiem, że dla mnie nienawidziłem deweloperów interfejsu użytkownika, ponieważ uważałem to za bardzo żmudne i powolne, szczególnie pisanie kodu układu w celu pozycjonowania elementów w formularzu lub winow. Teraz dzięki narzędziom projektanta interfejsu użytkownika, takim jak Forms Designer w Visual Studio, prawie mi się to podoba . Inne powody do nienawiści, o których słyszałem od innych, to: „jest głupi”, „zawsze zmienia się za bardzo”, „nie jest wystarczająco wymagający”, „jest nudny / nudny”.

Dlaczego wszyscy gracze w szachy nie lubią projektować szachownic i elementów, którymi się bawią?

To nie jest dziwne, że niektórym się to nie podoba ... to dziwne, że oczekujesz tego.

Lubię pracować nad interfejsem użytkownika. Nie zawsze było to dla mnie prawdą, ale moje zadowolenie z pracy z interfejsem użytkownika wzrosło, ponieważ poprawiłem się w ciągu ostatnich kilku lat. Wiem, że niektórzy programiści nie powinni mieć dostępu do arkuszy stylów lub palet kolorów. To zdecydowanie inny zestaw umiejętności i nie wszyscy go mają.

Nie nienawidzę interfejsu użytkownika tak bardzo, jak nienawidzę niektórych ram interfejsu użytkownika. Np. Programuję .NET od ponad 10 lat. Struktury do tworzenia aplikacji internetowych są świetne (ASP.NET WebForms i ASP.NET MVC). Ale frameworki do pisania aplikacji komputerowych, cóż, nie przepadam za nimi (WinForms i WPF).

Pod tym względem pisanie aplikacji GUI jest raczej aspektem korzystania z frameworków, których nie lubię.

Jest jeszcze jeden aspekt. Często pracuję z aplikacjami w stylu „korporacyjnym”, tj. Aplikacjami, w których aplikacja komputerowa musi odbierać dane z serwera. W tym przypadku jest tak wiele warstw konwersji danych z jednego formatu na inny, że robi się to naprawdę bardzo nudne.

Np. Aplikacja otrzymuje informacje za pośrednictwem szeregu obiektów DTO. Następnie aplikacja tworzy własną reprezentację modelu danych (nie wykorzystując ponownie tych samych klas domen, które zostały utworzone na serwerze). Klasy modeli są wykorzystywane przez model widoku (we wzorcu MVVM WPF), który udostępnia właściwości modelu.

Wiele razy te same dane są reprezentowane przez różne klasy. I to się nudzi. Jest to jednak problem specyficzny dla tego typu aplikacji komputerowych.

Istnieją również interesujące wyzwania w tego typu aplikacjach, takie jak to, w jaki sposób otrzymujemy zmiany od jednego klienta do natychmiastowej aktualizacji na innym kliencie.

Nie jestem wielkim fanem rozwoju interfejsu użytkownika z następujących powodów:

1. Jako programista masz mniej swobody tworzenia: klient widzi i ma opinie na temat każdego aspektu interfejsu, na który musisz zareagować. Otrzymasz wnioski takie jak: zmień kolor tego; przenieś tam ten przycisk; nieważne, cofnij to. Kod zaplecza rzadko jest tak widoczny.

2. Interfejs użytkownika jest bardziej chaotyczny, a zaplecze bardziej „platońskie”. Chociaż widziałem brzydkie pomyłki w kodzie zaplecza, myślę, że częściej jest on czysty (z perspektywy kodu) niż kod interfejsu użytkownika. Interfejs użytkownika może być naprawdę czysty i dobrze zaprojektowany dla użytkownika, ale ponieważ jestem programistą i spędzam więcej czasu w kodzie niż go używam, bardziej lubię go oczyszczać.

3. Wydaje mi się, że interfejs użytkownika jest bardziej „hydraulikiem” niż zapleczem, tzn. Jest mniejsza szansa na sprytne algorytmy i naprawdę popychanie twojego mózgu do granic możliwości.

Zajmuję się zarówno interfejsem użytkownika (komputer, nie internet), jak i wnętrznościami.

Ilość, która mi się podoba lub nie, zależy od tego, ile mogę zrobić, używając czegoś takiego jak język specyficzny dla domeny (DSL).

W domenie interfejsu użytkownika to, co prezentuję użytkownikom, i złożoność informacji, które od nich otrzymuję, są takie, że oszalałbym, gdybym musiał użyć typowych narzędzi, takich jak projektanci formularzy, wiele programów obsługi zdarzeń, MVC , wszystkie te „najnowocześniejsze” rzeczy. Na szczęście kilkadziesiąt lat temu odkryłem, co moim zdaniem jest lepszym sposobem, czyli stworzenie do tego DSL i pracę nad tym. Obecnie nazywam to Dialogami Dynamicznymi i jest oparty na strukturze kontrolnej, którą nazywam Wykonaniem Różnicowym . Dobrą wiadomością jest to, że dla danej funkcjonalności kod źródłowy jest mniej więcej o rząd wielkości mniejszy, co pozwala mi na wprowadzenie znacznie większej funkcjonalności do interfejsu użytkownika. Zła wiadomość jest taka, że ​​o ile starałem się tego nauczyć, nie miałem zbyt wiele szczęścia w przenoszeniu technologii.

W domenie innej niż interfejs użytkownika wziąłem lekcję z szeregu produktów, które zaczęły się jako DSL użyteczne z wiersza polecenia, na którym później przeszczepiono interfejs użytkownika. Daje to ekspertowi coś, w czym może ominąć interfejs użytkownika, a przypadkowemu użytkownikowi coś, z czego może korzystać swobodnie. (Przykłady: R, SPlus, Matlab, SAS, WinBugs.) Zatem nasz produkt ma język wiersza poleceń dla ekspertów. Uwielbiam tworzyć takie rzeczy za pomocą analizatora składni, generatora kodu, prekompilatora i silnika modelowania w czasie wykonywania. Wysiłek włożony w to jest o co najmniej 10 razy mniejszy niż wysiłek włożony w interfejs użytkownika.

Jednym z powodów, dla których interfejs użytkownika jest tak duży, jest wciąż wiele „kleju”, którego nie można zrobić za pomocą DSL - zarządzanie siatkami danych, wszelkiego rodzaju sortowanie danych, wszystkie rzeczy, które wpadają w ziewający „crack” pomiędzy czystym interfejsem użytkownika a podstawowym językiem.

Więc twoje pytanie brzmiało: „Dlaczego niektórzy programiści nienawidzą części interfejsu użytkownika?”. Nienawidzę tego tylko z powodu tego „kleju”, dla którego nie mam DSL.

Szczerze mówiąc, uważam, że znalezienie najlepszego zestawu narzędzi GUI, a następnie faktyczne poznanie tego, to coś w rodzaju PITA ... nie wspominając o tym, że nie uczysz się dużo elementów interfejsu użytkownika na studiach i jestem nowicjuszem, więc ...... ya ..

Poza tym, co już powiedziano (nużąca, nudna, frustrująca praca nad kodowaniem, a projekt jest zwykle wykonywany z góry przez kogoś, kto nie ma pojęcia, jakie problemy powodują jego pomysły dla osób próbujących je wdrożyć), ważnym czynnikiem jest to, że ty „Muszę współpracować z ludźmi, których pomysły na temat tego, co powinieneś robić, ciągle się zmieniają, o wiele bardziej niż w przypadku backendu. W rezultacie strzelasz jeszcze bardziej przeciwko ruchomemu specowi, a ci ludzie też zwykle są podstępni. Dosłownie mam testy błędów interfejsów użytkownika, ponieważ komponent znajdował się 1 piksel od miejsca, które osoba testująca uznała, że ​​powinno być. Zadziałało? Tak. Czy to dobrze wyglądało? Tak. Zaczął jednak zliczać piksele i coś było o jeden piksel poza linią z resztą, więc odesłał go do przeróbki.

Jeszcze kilka punktów:

1) Projekt interfejsu użytkownika może być trudniejszy do przetestowania, możesz sprawdzić, czy ten przycisk robi to, co powinien, ale testowanie, czy jest łatwy w użyciu, jest trudniejsze. Co powiesz na testowanie, czy będzie to przydatne dla osoby niepełnosprawnej?

2) Wielu programistów nie jest do tego przeszkolonych i niewiele o tym wie.

Faktem jest, że wiele narzędzi interfejsu użytkownika / frameworka / interfejsu API jest złych, złożonych, daleko od nich intuicyjnych. Opracowałem z API Win32 w C / C ++, z javax.swing, CSS itp. Od tego czasu nienawidzę zajmować się tworzeniem interfejsu użytkownika ... Aż do frameworka Qt!

Jako student CS będziesz uczył się struktury danych, bazy danych, C ++ ... oprócz interfejsu użytkownika. Więc nie będziesz w tym dobry od samego początku . Jeśli nie jesteś w tym dobry, będziesz go nienawidzić.

Pracując po obu stronach monety, tj. Projekt interfejsu użytkownika i kod zaplecza, odkryłem, że obie strony monety są w zasadzie takie same.

Wymagania, które różnią się od tego, co robisz na co dzień, nie przychodzą przez cały czas, a teraz w erze, w której wszystkie usługi obracają się wokół CRUD, staje się nudne.

W każdym razie kodowanie frontendu pozwala na lepszą interakcję i szalone dynamizmy, które w zasadzie wkręcają niedoświadczoną rękę w projekt frontendu. Osobiście nauczyłem się ciężkiej drogi w interfejsie i mogę spokojnie powiedzieć, że projektowanie interfejsu jest o wiele bardziej interesujące i wymagające.