Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

Zmiana paradygmatu, czyli o GUI słów kilka

Mały paradoks oprogramowania

Kiedykolwiek programista pragnie uszczęśliwić stałego użytkownika, oferuje mu bądź ulepszoną funkcjonalność produktu bądź nowy, "ulepszony" a zarazem urzekający interfejs graficzny (ang. GUI, Graphical User Interface). Czasami dochodzi do sytuacji, w której funkcjonalności rozszerzyć się nie da. Czasem też jakakolwiek próba pójścia w tym kierunku mogłaby nawet zostać stanowczo odrzucona przez zagorzałych użytkowników-tradycjonalistów. Coż w takich sytuacjach może zrobić biedny twórca?... Może rok w rok, te same - co do wartości merytorycznej - aplikacje obdarzać coraz to nowymi numerkami, choć z zasady różnić się będą tylko wyglądem. A my to kupujemy, choć (co prawda) nie wszyscy.

Należę do grupy osób skoncentrowanych wyłącznie na funkcjonalności. W swojej pracy zawsze staram się korzystać z jak najbardziej ogólnych wzorców projektowych. Dzięki temu, pod napływem "chwili olśnienia", znaleźć można nowe zastosowanie dla wysłużonych już produktów bądź tych części programu, które - po nieznacznej tylko modyfikacji - mogłyby funkcjonować całkiem udanie na innym polu, w innej gałęzi gospodarki. Programista też człowiek, więc nierzadko zdarza się, że pewne przyjęte przez niego (i przeze mnie) wzorce można zamienić na inne, sprawniejsze, a wszystko to co było dawniej po prostu wyrzucić do kosza.

Z GUI sprawa wygląda nieco inaczej. Choć osobiście nie wykorzystuję tanich chwytów marketingowych z numerkiem lub z nowymi ikonkami to jednak uważam, że interfejs graficzny odgrywa kluczową rolę w procesie przygotowywania oprogramowania. Zawsze uważałem, że interfejsem graficznym powinni się zajmować graficy, tak jak programowanie leży w gestii programistów. Problem jest jednak bardziej złożony i często to na barkach programisty spoczywa obowiązek wykonania "atrakcyjnego interfejsu". Kiedy tak się dzieje, cierpią na tym wszystkie te aspekty oprogramowania, na które nie można było poświęcić więcej czasu (m.in. wydajność i niewłaściwe działanie w wyjątkowych sytuacjach). Katastrofa.

Programista zajmuje się GUI

W dzisiejszym świecie nie ma miejsca dla brzydkich produktów. Wszystko powinno być ładne a priori. Znając tę "najprawdziwszą z prawd" programista często sięga po rozwiązania firm trzecich, które przy pomocy jednego magicznego przycisku (albo jednej linijki kodu) zmieniają standardowe okienka i nieatrakcyjne "kontrolki" w świecące, kolorowe atrakcje. Mowa tu o czymś co nazywamy potocznie skórkami. Niejednokrotnie same skórki nie świecą już wielkim przykładem geniuszu. Wtedy implementujemy nieco inne rozwiązania. W przypadku platformy .NET taką alternatywą dla Windows Forms jest technologia Windows Presentation Foundation wespół z językiem XAML. Zainteresowani bez trudu znajdą informacje na ich temat, więc nie poruszę tu kwestii za i przeciw tym rozwiązaniom.

Obecnie prawie każda pełnoprawna platforma programistyczna wspiera w pewnym zakresie wysiłki programistów mające na celu uatrakcyjnienie wyglądu projektowanych aplikacji. I choć cel jest słuszny - w mojej opinii wiele z nich idzie drogą pełną anachronizmów i sprzeczności.

  • Wygląd kosztem nauki nowego języka opisującego interfejs użytkownika (na przykładzie XAML)?
  • Narzędzia przeznaczone tylko i wyłącznie do budowy GUI eksportujące serię nic nie mówiących (niewtajemniczonym) znaczników?
  • Dwucyfrowy wzrost zużycia cennych zasobów komputera kosztem kilku bajeranckich (jak dla kogo) okienek?
Proszę...

Pewnego razu w Menedżerze zadań

Do czego służy Menedżer zadań wiedzą chyba wszyscy. Poza nim istnieje szereg narzędzi obrazujących i rejestrujących pracę aplikacji w systemie Windows (na przykład wbudowany Monitor wydajności, w skrócie perfmon). Zużycie zasobów nowych wersji oprogramowania z reguły ma tendencję wzrostową i każdy ma możliwość sprawdzenia tego faktu. Dzieje się tak przeważnie tuż po wprowadzeniu widocznych zmian w interfejsie graficznym aplikacji. Inaczej jest natomiast gdy programista swoją uwagę skupia na problemie wydajności. Wtedy prawie każda zmiana pozytywnie wpływa i reguluje zasobożerność oprogramowania. Od powyższego zawsze są wyjątki, ale jak wiadomo nieliczne. Wszyscy znamy przecież aplikacje, które po pewnym czasie obecności na rynku stają się po prostu "bloated".

Do pamiętnego dnia wykorzystywałem zbiór popularnych bibliotek pozytywnie wpływających na wygląd wdrażanych aplikacji .NET. Krzywdzącym byłoby podanie nazwy producenta tego pakietu, więc pominę ją milczeniem. Istotnym jest bowiem fakt, że posiadając deweloperską licencję zawsze mogłem i nadal mogę liczyć na szybkie wsparcie techniczne i miłą obsługę. Niemniej z wersji na wersję, mimo pozytywnego - wizualnie - postępu, zasobożerność (tu zużycie pamięci) wykorzystywanych komponentów wzrastała co najmniej liniowo. Podczas gdy standardowa aplikacja wykorzystująca jedynie wbudowane w .NET komponenty zużywała niewiele ponad 15MB pamięci operacyjnej, to już samo puste, nic nie robiące okienko w technologii "skórek" zużywało jej 40MB. Rozumiem, że postęp technologiczny jest nieunikniony, ale będąc osobą w pewnym sensie ukształtowaną przez system z rodziny AmigaOS i mając na względzie obecne cztero- i pięcioletnie komputery osobiste typu PC i klasy "refurbished", nie mogłem nad taką sytuacją przejść obojętnie. "Bo później Pani Jadzia narzeka, że jej komputer działa wolno...". Skórki poszły do kosza. Bynajmniej w większości przypadków. A dalej było tak...

Stare pomysły w nowym wydaniu

Wykorzystanie WPF i XAML w nowych projektach byłoby ryzykownym przedsięwzięciem, biorąc pod uwagę ówczesną (i obecną) politykę Microsoftu. Poza tym wiązałoby to się z koniecznością współpracy z grafikiem znającym się na "tej dziwnej rzeczy". Kiedy na drodze programisty pojawiają się przeciwności, rozsądek karze uprościć problem i szukać odpowiedzi w oczywistym miejscu. I choć tym razem Microsoft Developer Network nie przyniósł upragnionej odpowiedzi to jednak sama technologia służąca jej poznaniu była strzałem w dziesiątkę.

Trident (czyt. Internet Explorer), jakiżby inny komponent systemu, czy to wbudowany czy doinstalowany lepiej miałby spełniać rolę ze wszechmiar modyfikowalnego GUI dowolnej aplikacji. I choć użyłem tu konkretnej nazwy nie bez powodu Ty sam możesz przywołać zupełnie inną np. Webkit (czyt. Chrome, Safari) lub Gecko (Firefox) oraz wiele innych.

Przeglądarka internetowa to podstawowe narzędzie pracy interauty i zawiera (to prawda!) doskonale zoptymalizowany silnik wyświetlający interaktywne (dynamiczne) treści. Mając za sobą wyczekiwany od dawna upadek IE6 powoli nastaje czas spokoju i "wspólnych standardów". Akceleracja sprzętowa zaimplementowana w silnikach popularnych przeglądarek a co za tym idzie coraz szybsza obsługa JavaScript, ale także obsługa SVG czy HTML5 - to wszystko sprawia, że powtórne wykorzystanie komponentów umożliwiających osadzanie odpowiednio spreparowanych stron internetowych, pełniących tu rolę wyłącznie interfejsu użytkownika w aplikacjach windowsowych (ale także i linuksowych), to czysta przyjemność. Co więcej, separując interfejs graficzny aplikacji (wykonany chociażby w HTML'u z domieszką jQuery) od właściwego kodu źródłowego przy użyciu specjalnie skonstruowanych klas opakowujących zyskujemy naprawdę dużą swobodę. Zmiany interfejsu graficznego mogą być wtedy dowolne i jedynie w znikomym stopniu wpływają właściwą część tworzonego przez nas programu. Komunikacja pomiędzy typowym kodem a stroną (GUI) przebiega w niezwykle prosty i klarowny sposób a samą oprawę wizualną jest w stanie przygotować każdy porządny grafik internetowy znający podstawy HTML i JavaScript. A takich osób na rynku wiele, więc można skoncentrować się na jakości a nie dostępności wykształconych jednostek. Zużycie zasobów tak przygotowanego GUI w porównaniu do tradycyjnych skórek jest niewielkie a możliwości rozbudowy niczym nieograniczone.

Oczywiście to od producenta danego komponentu zależy czy sprawnie będzie zachowywał się w środowisku produkcyjnym, ale nie oszukujmy się: przeglądarki internetowe (ich silniki) znajdują się pod stałą presją milionów użytkowników, tu wszystko musi grać jak należy. Nie ma mowy o technologicznym zastoju.

Na koniec - idziemy z duchem czasu. Ostatnio coraz więcej mamy przecież usług "web-enabled" - oczywiście nie w tym sensie :) Ale mówiąc szczerze, obserwując wielkich graczy rynku IT, właśnie w tym kierunku zmierzamy!

Wykorzystanie silnika Trident (klasa WebBrowser) w aplikacjach Windows Forms:http://msdn.microsoft.com/en-us/library/a0746166.aspxCałkiem udana implementacja Chromium (Awesomium) umożliwiająca tworzenie GUI opartego na HTML:http://awesomium.com/

P.S. Zdaję sobie sprawę, że nie we wszystkich przypadkach taki interfejs się sprawdza. Niemniej polecam tego typu rozwiązania... i pozdrawiam wszystkich, którzy dotrwali do końca.
 

windows porady programowanie

Komentarze

0 nowych
Airborn   8 #1 13.03.2012 15:38

Sam ostatnio męczę się z podobnym problemem, tyle, że od strony Javy. Wybraliśmy wersję polegającą na modyfikacji Look and Feel poprzez sporawy plik XML + trochę dodatkowego kodu rysującego wszystko jak należy. O wersji z przeglądarką wciąż myślimy, chociaż osobiście dochodzę ostatnio do wniosku, że takie rozwiązanie jest w stanie rozwiązać większość problemów. W przypadku jJvy jest jeszcze JavaFX2, ale w przypadku Linuxa jest to niestety jeszcze Developer Preview więc wypychać to do klienta trochę strach.

Draqun   9 #2 13.03.2012 15:38

Bardzo ciekawy wpis. Szczerze powiem, słyszę o tym po raz pierwszy ale bardzo mi się podoba pomysł. Może kiedyś przyjdzie mi to wykorzystać a tymczasem zajmę się Javą.

alucosoftware   7 #3 13.03.2012 16:21

@Airborn
Jeśli zależy nam na Look and Feel to wybór silnika przeglądarki jako komponentu renderującego GUI jest bardzo dobrym pomysłem.

@Draqun
Licencja Awesomium jest bardzo przychylna początkującym deweloperom. Jeśli ich przychód nie przekracza pewnej ustalonej kwoty to możemy tu mówić o darmowym wykorzystaniu komponentów.

djfoxer   18 #4 13.03.2012 17:50

Problem tworzenia GUI przez programistów znany jest od zawsze :P Dla osoby piszącej kod, jej interface, zawsze będzie intuicyjny i piękny. Z tego co zdążyłem zauważyć, rzadko to jednak jest prawdą :) Uważam, że jak ktoś to pięknie określił odnośnie aktorów, którzy biorą się za reżyserie: "Du.a jest do sran.a, a aktor do grania" :D Wiec niech programista tworzy funkcjonalności, a projektant interejsu/grafik niech tworzy UI.

Co do HTMLa. Coraz częściej aplikacji tworzonych jest jako www. Jak wspomniałeś jest to lepsze do zarządzania jeśli chodzi o UI, ale jeśli wykorzystamy zwykłą przeglądarkę jako "odbiornik", nie wiążemy klienta z jednym, słusznym systemem no i mamy kolejny argument za wyborem przedstawianego produktu. Również dostęp z zewnątrz w tym przypadku działa na naszą korzyść. Dodamy do tego jeszcze HTML5 i CSS3 można stworzyć aplikację przewyższające w wielu zastosowaniach, nawet te desktopowe.

alucosoftware   7 #5 13.03.2012 18:16

@djfoxer
Otóż to :)
Dobrze, że można liczyć na fachowe uzupełnienie. Pozdrawiam

iluzion   5 #6 13.03.2012 18:44

Graficzny interfejs jest ważny. Przede wszystkim nie może razić użytkownika... nieintuicyjnością, niedoskonałością rozmieszczenia kontrolek czy widgetów, kolorami czy wodotryskami. Moje ulubione motto to "less is more". Preferuję tę zasadę również jako amator programowania i użytkownik komputera.

Dlaczego Google Chrome odniósł duży sukces w krótkim czasie? Bo tam prawie nie ma GUI ;) Jest "internet", czyli to czego oczekujemy klikając w ikonę przeglądarki. Gdy Chrome się pojawiał, Internet Explorer czy Firefox miały już paski zakładek i "samoinstalujące się toolbary" do połowy ekranu. A tu nagle taki powiew przestrzeni, interfejs który nie "razi", bo nie ma czym, a spełnia swoją funkcję.

Mówi się, że Microsoft inwestuje w najlepszych programistów i zatrudnia cały sztab ludzi pracujących nad każdym produktem. Niewątpliwie tak jest, ale czy zawsze rezultaty tej pracy są zawsze dobre? Czy Windows Media Player jest najlepszym odtwarzaczem muzyki dla systemu Windows? Interfejs Foobara ma stopnień złożoności Notatnika, a jednak (wg mnie) jest dużo wygodniejszy niż WMP. Wystarczyło dodać karty i zrobić użytek z rolki myszy, która umożliwia zmianę kart i precyzyjną regulację głośności, equalizera itd., bez celowania kursorem. Również programy napisane w Qt domyślnie umożliwiają zmianę kart rolką. Microsoft wykorzystał to rozwiązanie tylko w we wstążce.

To jest oczywiście moja prywatna opinia, ale wracając do atrakcyjności GUI... Kiedyś przeczytałem, że przyszłością (również) aplikacji desktopowych jest "interfejs Web 2.0". Dla programistów na pewno jest to wyzwanie, bo jak wynika z wpisu wymaga to zmiany pewnych przyzwyczajeń, nauki nowych rozwiązań, wyczucia estetyki (tego niestety nauczyć się nie można, ale można korzystać ze schematów). Ciekawym przykładem jest QtQuick i QML, czyli skrótowo rzecz ujmując programowanie atrakcyjnych wizualnie aplikacji w JavaScript z wykorzystaniem dobrodziejstw Photoshopa. W tym wypadku odpada nauka nowego języka (bo QML to praktycznie JavaScript, a ten język nowy nie jest i wciąż zyskuje na popularności) i programu graficznego, bo chyba każdy miał jakąś styczność z Photoshopem. Czy autor wpisu ma jakieś zdanie na temat QtQuick?

  #7 13.03.2012 19:10

Nie na darmo się mówi, że osoby najbardziej nienawidzące oprogramowania to sami programiści. Reszcie to zwisa.

Frankfurterium   10 #8 13.03.2012 20:10

Od pewnego czasu bawię się Javą i tak jak nigdy nie miałem talentu do interfejsów, tak wszystkie poznane J biblioteki graficzne przyprawiały mnie o myśli samobójcze. Po przerzuceniu się na aplikacje webowe nie było wiele lepiej (awersja do HTML-a :P), aż nagle znalazłem Google Web Toolkit. Tak logikę, jak i interfejs pisze się w najczystszej Javie, odpowiednie widgety oprawiając jedynie CSS-em. Technologia ma plusy i minusy. Przede wszystkim komponentów nie ma zbyt wiele i są one raczej graficznie proste (w stylu Google'a), chociaż powstało kilka zewnętrznych rozszerzeń zmieniających ten stan rzeczy. Druga sprawa - cała warstwa prezentacji to Java przekompilowana do Ajaxa, co aż tak optymalnym rozwiązaniem nie jest (z drugiej strony mamy asynchroniczność - robimy, co chcemy, bez konieczności przeładowania strony).

djfoxer   18 #9 13.03.2012 20:44

@Frankfurterium
Ja ze swojej strony polecam jQueryUI (http://jqueryui.com/demos/) + nieskończona ilość wtyczek do jQ. Nie bawisz się w sztucznie wrzuconego ajaxa do kontrolek Javowych. Na urządzenia mobilne idealnie nadaje się jQuery Mobile z rewelacyjnymi kontrolkami pod rządzenia dotykowe (już niedługo finalna wersja 1.1!)

gowain   19 #10 13.03.2012 22:35

@djfoxer - Tak jQueryUI to coś pięknego :) Ładnie, szybko i przyjemnie

sanurss   4 #11 13.03.2012 22:48

@djfoxer
Z webową aplikacją jest wszystko fajnie, dopóki nie zajdzie potrzeba przetwarzania dużych ilości danych, na przykład obróbki metadanych plików. Przesyłanie znacznych ilości danych przez sieć w celu wykonania kilku prostych operacji jest zwyczajnie bez sensu.
Niestety tworzenie GUI do aplikacji desktopowych nie należy do przyjemnych. Z jednej strony Windows Forms, który wykazuje spore ograniczenia, ale może zostać uruchomiony na Mono, z drugiej strony WPF o większych możliwościach, ale też większych wymaganiach. Z pisaniem aplikacji umieszczanych w WebBrowser też nie jest za fajnie, bo trzeba taki program testować na komputerach z różnymi wersjami IE (kontrolka korzysta ma UserAgent z wersji zainstalowanej na komputerze, ale renderuje mniej więcej w trybie zgodności - bo i to nie zawsze daje ten sam wynik :/). Można zawsze skorzystać z wspomnianego Awesomium, ale to znacznie zwiększa rozmiar całej aplikacji. Generalnie lipnie strasznie...

alucosoftware   7 #12 14.03.2012 01:13

@iluzion
Obawiam się, że implementacja "interfejsu web 2.0" w aplikacjach desktopowych nie jest możliwa z definicji. W web 2.0 to użytkownik końcowy jest współ- bądź wyłącznym twórcą treści. Nie widzę tego typu zastosowania w dziedzinie UI, ale może to tylko takie moje ograniczenie :)

Jeśli chodzi o QtQuick to nie mogę Tobie przedstawić "oficjalnego" stanowiska, bo nie miałem z nim styczności, ale po wstępnym przejrzeniu dostępnych na stronie informacji prywatnie uważam, że "QML to prawie JavaScript", a prawie... robi różnicę. Składnia QML na pierwszy rzut oka wygląda jak mieszanina notacji JSON z elementami różnych języków. Widzę tu "konieczność" nauki nowej składni (o nieee! która to z kolei?!). Wspomniałem o tym we wpisie lekko ironizując konieczność nauki XAML'a w kontekście WPF. Obawiam się, że w tym przypadku QML nie wyjdzie obronną ręką ze starcia z duetem HTML+jQuery (które wszyscy znają i kochają). Ale to tylko taka mała opinia i zapewne nie dotyczy aktywistów Qt.

alucosoftware   7 #13 14.03.2012 01:34

@sanurss
Jako wymaganie możesz przecież określić min. IE8/IE9 czyż nie? Wszyscy na tym skorzystają i zaktualizują niezdatne do użycia oprogramowanie. W przypadku klasy WebBrowser, będącej tylko prostą klasą opakowującą interfejs udostępniany przez IE, nie jest tak tragicznie jak to przedstawiasz.

IE6 i mniej pominę milczeniem. Domyślnie WebBrowser udostępnia silnik zainstalowanej w systemie wersji IE7/8/9/10 z tym, że uruchomiony w trybie zgodności (patrz: IE7). Można wymusić wykorzystanie zainstalowanej wersji przez:
- dodanie odpowiedniego wpisu do rejestru zawierającego nazwę naszej aplikacji i preferowaną wersję IE (tzw. FEATURE_BROWSER_EMULATION)
- wykorzystanie znacznika META w nagłówku preparowanej strony określającego kompatybilność dokumentu z wersją przeglądarki (X-UA-Compatible)
- odpowiednie wykorzystanie dyrektywy !DOCTYPE

Głowa do góry!

iluzion   5 #14 14.03.2012 02:06

@alucosoftware

Celowo zapisałem interfejs web 2.0 w cudzysłowie. Wystarczy zapytać google o "web 2.0 interface", a wyskoczą wyniki, które opisują to co miałem na myśli. Np.

"Their are many trends in modern web design, often referred to as part of web 2.0. Web 2.0 design often features textures, drop shadows, clean grid layouts, icons, and other design elements. (...)"

Brzmi bardzo ogólnie, ale coś w tym jest.

alucosoftware   7 #15 14.03.2012 02:53

@iluzion
No właśnie, brzmi to bardzo ogólnie. I nikogo za to nie winię. Całe zamieszanie pojawia się gdy ktoś w sieci "often refer to something" i nierozważnie przypisuje pewne atrybuty danemu zagadnieniu, choć z definicji nie powinien. Ale nie dziwię się, Web 2.0 wprowadził trochę zamieszania w mediach internetowych...

djfoxer   18 #16 20.03.2012 18:16

Kiedy i o czym następny wpis? :)

  #17 12.08.2015 16:32

"bynajmniej" nie znaczy "przynajmniej".