Informationstandard.pl - wspomaganie decyzji - link do strony głównej
wyszukiwanie:
Podziel się opinią o serwisie

reklama

Strefa Microsoft

Microsoft Dynamics

Microsoft Dynamics Zone

Microsoft Dynamics to dział firmy Microsoft oferujący zintegrowane systemy wspierające zarządzanie przedsiębiorstwem oraz relacjami z klientami. Rodzinę rozwiązań Dynamics tworzą w Polsce: Microsoft Dynamics NAV, Microsoft Dynamics AX i Microsoft Dynamics CRM. Zapoznaj się z materiałami.

WDROŻENIA

Oferta na zawołanie

Automatyzacja kampanii marketingowych w sieci Play pozwala na bieżąco reagować na zachowania klientów.

Coraz lepsza wiedza

Rozwiązania analityczne zastosowane w Systemie Informacyjnym Publicznych Służb Zatrudnienia "Syriusz" pozwolą na bardziej efektywne wykorzystanie instrumentów aktywizacji rynku pracy w naszym kraju.

ANALIZY

Informacje jak powietrze

Efektywne funkcjonowanie niemalże wszystkich obszarów życia społecznego i gospodarczego będzie w coraz większym stopniu zależeć od ich sprawnej obsługi informacyjnej.

W poszukiwaniu efektu synergii

Wdrożenie systemów podejmowania decyzji (DSS) wymaga zdecydowanie większych zmian organizacyjnych oraz kulturowych w organizacji, niż ma to miejsce w przypadku systemów ERP.

PRODUKTY

Szybko i prosto

Firma Antalis zdecydowała się na wdrożenie systemu QlikView m.in. ze względu na elastyczność jego działania i prostotę obsługi.

Nadchodzi zachmurzenie

Nadeszła idea chmury obliczeniowej, którą postanowił wesprzeć również Microsoft, ogłaszając projekt platformy Azure.

WYWIADY

Na rozstaju dróg

O Narodowym Programie Foresight Polska 2020 rozmawiamy z prof. dr. hab. Michałem Kleiberem, prezesem Polskiej Akademii Nauk.

Dojrzewający rynek BPM

Jeszcze w 2007 r. projekty z zakresu optymalizacji procesów gospodarczych koncentrowały się głównie na usprawnianiu procesów z punktu widzenia logiki biznesowej. Obecnie dużo większy nacisk kładziony jest na pomiar tych procesów.

powiększ tekst >
ARCHIWUM

Scalić sztukę z nauką

4 listopada 2008

Piotr Waszczuk
Prawidłowo skonstruowany interfejs użytkownika jest wspólnym rozwiązaniem dla problemów z zakresu IT, psychologii, ergonomii i grafiki komputerowej. Jest też istotnym czynnikiem decydującym o sukcesie rynkowym produktu.


Wygląd, sposób prezentacji i dostępność elementów interfejsu odpowiedzialnych za realizację poszczególnych funkcji są pierwszymi elementami oprogramowania, na które zwracają uwagę użytkownicy. Stworzenie wygodnego i funkcjonalnego interfejsu obsługi aplikacji jest więc zadaniem tyleż istotnym, co skomplikowanym. Musi on być bowiem odpowiedzią na odmienne, często wykluczające się, potrzeby użytkowników oraz możliwości i ograniczenia po stronie autorów. Przed zbliżonymi problemami stają twórcy klasycznego oprogramowania, serwisów internetowych oraz aplikacji przeznaczonych na urządzenia mobilne.

Wydaje się, że polskie firmy zaczęły doceniać znaczenie odpowiednio skonstruowanego GUI. Specjaliści w zakresie tworzenia oprogramowania oraz eksperci w analizowaniu funkcjonalności aplikacji są zgodni - rośnie znaczenie badań użyteczności i wyspecjalizowanych procesów projektowania interfejsów. Wywołuje to jednak lawinę problemów. Na temat zmian w postrzeganiu tego rodzaju analiz oraz czynników ograniczających ich popularność dyskutowali uczestnicy debaty zorganizowanej przez Computerworld i firmę Microsoft.

Programiści są z Marsa, graficy z Wenus


Często osoby techniczne nie rozumieją, dlaczego program jest zły, skoro algorytm działa. Podobnie jest w przypadku warstwy funkcjonalnej - mówi Piotr Czekała, właściciel Insys.
Wewnętrzne interesy grafików, programistów i architektów trudno pogodzić. Każda z grup zajmujących się tworzeniem aplikacji ma własne ograniczenia, możliwości, metody i przyzwyczajenia. Zwykle każda ma też odmienną wizję oprogramowania i działa na innym poziomie abstrakcji. Być może jednak trudniejszym zadaniem jest przekonanie członków zespołu do zmiany własnych wyobrażeń na temat konkretnego elementu funkcjonalnego, za który odpowiadają oraz podporządkowania się obserwacjom specjalisty ds. ergonomii. "Często osoby techniczne nie rozumieją, dlaczego program jest zły, skoro algorytm działa. Podobnie jest w przypadku warstwy funkcjonalnej" - mówi Piotr Czekała, właściciel Insys.

Szczegółowy podział obowiązków wiąże się również ze zmianami uprawnień w obrębie grup projektowych. Próby narzucenia określonych metod działania i wymuszenia konkretnego układu funkcjonalnego powodują dalszy wzrost napięć. "To zaś powoduje dodatkowe napięcia wewnątrz zespołu. Programiści czują, że coś im się zabiera" - zaznacza Wojciech Kuśmierek, prezes zarządu UseLab. Jego zdaniem ważne, aby analiza doświadczeń użytkowników oprogramowania stała się stałym elementem procesu deweloperskiego. "Cała sztuka polega na tym, aby designer i programista pracowali nad jednym projektem. Przykładowo, pierwszy rysuje ładny przycisk, a drugi wie tylko, że jest element, który da się kliknąć, i oprogramowuje jego działanie. Pracują nad jedną strukturą, która potem podlega kompilacji" - dodaje Tomasz Kopacz Senior Architect Evangelist w polskim oddziale Microsoftu. Podkreśla również konieczność separacji poszczególnych elementów projektu, przy jednoczesnym zachowaniu zależności między nimi. "Warto pamiętać, że programista ma zupełnie inne potrzeby, zwyczaje i umiejętności niż użytkownik. Jego sposób postrzegania technologii jest zupełnie inny. Stąd tak ważne, żeby w procesie produkcji oprogramowania połączyć osobę odpowiedzialną za user experience i programistę oraz dać im narzędzia do efektywnej współpracy" - dodaje.

Tymczasem - jak twierdzi Tymoteusz Chmielewski, wiceprezes K2 Internet - potrzeby użytkowników powinny mieć absolutny prymat już na początku procesu dewelopmentu. "Często zapominamy, że firmy programistyczne funkcjonują na zasadach podobnych do zakładów usługowych" - mówi. Według niego, w warunkach ostrej konkurencji rynkowej prowadzenie szczegółowych analiz poprzedzających produkcję oprogramowania staje się koniecznością. Ich wyniki mogą stanowić podstawę do stworzenia kompletnej specyfikacji oprogramowania lub choćby wytycznych określających jego użyteczność. "Dobry produkt jest nie tylko użyteczny, ale przede wszystkim realizuje założenia biznesowe" - potwierdza Dawid Liszka, Technology Manager w Making Waves Polska.

GUI badać i analizować


Potrzeby użytkowników powinny mieć absolutny prymat już na początku procesu dewelopmentu - mówi Tymoteusz Chmielewski, wiceprezes K2 Internet.
Każdą aplikację można podzielić na funkcjonalność, design i otoczkę graficzną. Wszystkie te elementy powinny być obiektem osobnych analiz. Badania nad funkcjonalnością i użytecznością dają niepowtarzalną możliwość dostrzeżenia błędów funkcjonalnych oraz przekonania twórców oprogramowania o jego niedoskonałościach. "Użyteczność interfejsu to tylko jedna z cegiełek składających się na tzw. customer experience. Dopiero suma wszystkich, odpowiednio zrealizowanych elementów procesu dewelopmentu owocuje pozytywnym odbiorem ze strony użytkownika" - mówi Marcin Charkiewicz, Project Manager w Telekomunikacji Polskiej.

Istotne jest szczegółowe zaplanowanie funkcjonalności tworzonego oprogramowania, jego interfejsu, a nawet zarysów wyglądu i tzw. wymagań niefunkcjonalnych. Te - tworzone we wstępnym etapie projektu - plany zwykle opierają się na analizie wymagań i potrzeb. Efektem szczegółowych badań jest zwykle specyfikacja zawierająca m.in. informacje na temat układu interfejsu, czy funkcji realizowanych za pośrednictwem poszczególnych jego elementów. Innym podejściem jest realizacja projektu wedle metodyki Microsoft Solution Framework, która bazuje na zarysach funkcjonalności i pewnej ilości scenariuszy użycia aplikacji. W iteracyjnym procesie MSF scenariusze te są realizowane równolegle z procesem produkcji.

Czas poświęcony na badania nad rozmieszczeniem standardowych elementów interfejsu oraz praktyczna realizacja zaleceń wynikających z analiz znajduje odbicie w satysfakcji użytkownika. "Projektowanie interfejsu to część procesu budowania interakcji z użytkownikiem" - zauważa Wojciech Kuśmierek. Istotny jest też wybór konkretnego problemu biznesowego, który ma być rozwiązany przy pomocy badań użyteczności i odpowiednie umiejscowienie procesu analizy użyteczności w produkcji oprogramowania.

Ergonomiczne problemy


Problemów wynikających z różnorodności zespołów programistycznych można uniknąć dzięki zastosowaniu odpowiedniej metodyki oraz narzędzi przeznaczonych dla poszczególnych osób zaangażowanych w proces tworzenia aplikacji - uważa Tomasz Kopacz, Senior Architect Evangelist w polskim oddziale Microsoftu.
Wraz z rozwojem narzędzi programistycznych, przybywa gotowych klas, bibliotek i elementów interfejsu. Spada zaś pracochłonność związana z opracowaniem biznesowej logiki aplikacji. Narzędzia programistyczne będą rozwijane pod kątem uproszczenia najczęściej powtarzanych zadań. Uczestnicy debaty byli zgodni, coraz więcej standardowych operacji będzie realizowanych bez pośrednictwa programisty, który z kolei będzie mógł skoncentrować się na dopracowaniu algorytmów i funkcjonalności aplikacji. Postępować będzie również ich integracja. Wprowadzane będą także dodatkowe rozwiązania ułatwiające pracę w zróżnicowanych zespołach projektowych. Tomasz Kopacz uważa, że problemów wynikających z różnorodności zespołów programistycznych można uniknąć dzięki zastosowaniu odpowiedniej metodyki oraz narzędzi przeznaczonych dla poszczególnych osób zaangażowanych w proces tworzenia aplikacji. Dzięki temu już po stronie narzędzi możliwe jest zmniejszenie nakładu pracy. Niezależnym zagadnieniem pozostaje jednak kwestia samego podejścia do użyteczności oprogramowania.

Pomimo postępu w dziedzinie normalizacji użyteczności, badania tego typu są obecnie dość trudno mierzalne. Brakuje spójnej miary jakości. Występują również problemy z doborem odpowiedniej grupy badawczej i rozpoznaniem celów analizy. Użytkownicy często odbierają tego typu badania jak testy inteligencji. To zaś wywołuje frustrację i utrudnia analizę. Pojawia się również problem z dostępem do wiedzy na ten temat. "Do niedawna brak było w Polsce miejsca, gdzie kształcić mogliby się specjaliści w tym zakresie. Większość z nich rozwijała umiejętności w oparciu o książki bądź odbywając praktyki za granicą" - mówi Hubert Turaj, Interaction Designer w Making Waves Polska. "Osobiście zetknąłem się z tematyką projektowania interakcji na uniwersytecie w Oslo. Przedmiot pod tytułem Man-Machine Interaction był tam wykładany na wydziale psychologicznym. Jest to w zasadzie optymalne rozwiązanie, gdyż psychologowie mają wiedzę z zakresu funkcjonowania poznawczego człowieka oraz podstawowy warsztat badawczy pozwalający realizować badania" - dodaje.

Niemniej ważna jest jednak wiedza z zakresu marketingu, komunikacji interpersonalnej, planowania i zarządzania projektami oraz znajomość narzędzi projektowych czy technik produkcji oprogramowania. "Projektanci interakcji pełnią role adwokatów użytkownika i wykonane przez nich testy powinny weryfikować, czy wytworzony produkt jest rzeczywiście zgodny z zamierzeniami projektanta. Wiedza na temat kontroli jakości i testów przychodzi tutaj z pomocą" - dodaje Dawid Liszka. Jednocześnie uczestnicy debaty podkreślali, że analizy wskaźnikowe i coraz silniej odczuwany nacisk na skrócenie czasu dewelopmentu nie sprzyjają procesom analizy użyteczności interfejsów. Tymczasem przysłowie, że szybciej i taniej nie znaczy lepiej, sprawdza się również w odniesieniu do projektowania i testowania interfejsów. "Ergonomiści nie są hamulcowymi" - konkluduje Wojciech Kuśmierek.

Tekst powstał po wspólnej debacie Computerworld i Microsoftu o designie i tworzeniu interfejsu użytkownika oraz użyteczności oprogramowania.

Metody badania użyteczności oprogramowania:

  • testy z użytkownikami,

  • eye tracking,

  • badanie architektury informacji,

  • audyt użyteczności,

  • testy funkcjonalne.


Źródło: UseLab








Wystaw ocenę:
   Średnia ocena (liczba głosów: 2)
wydrukuj wydrukuj wyslij do znajomegowyślij do znajomego rss

Komentarze

Redakcja Informationstandard.pl - wspomaganie decyzji nie ponosi odpowiedzialności za wypowiedzi Internautów opublikowane na stronach serwisu oraz zastrzega sobie prawo do redagowania, skracania bądź usuwania komentarzy zawierających treści zabronione przez prawo, uznawane za obraźliwie lub naruszające zasady współżycia społecznego. Osoby zamieszczające wypowiedzi naruszające prawo lub prawem chronione dobra osób trzecich mogą ponieść z tego tytułu odpowiedzialność karną lub cywilną.

Ten artykuł nie ma jeszcze żadnych komentarzy. Twój może być pierwszy...

logo IDG
04-204 Warszawa ul. Jordanowska 12
tel.: (+48 22) 321 78 00 fax: (+48 22) 321 78 88
© copyright 2009 IDG Poland SA