Skip to content

Entries from August 2010.

"Usability" na przykładzie bankomatu

Niedawno miałem okazję przekonać się jak ukształtowanie interfejsu użytkownika może wpływać na sposób w jaki aplikacja będzie odbierana przez użytkowników. W skrajnym przypadku może prowadzić do odrzucenia systemu.

Czekając w kolejce do bankomatu zauważyłem, że dwie osoby przede mną odchodzą nie pobierając gotówki. Gdyby to była tylko jedna osoba pomyślałbym, że chodzi o brak środków na koncie. Gdy druga osoba odebrała kartę obstawiałem problem z bankomatem. Postanowiłem sprawdzić co jest przyczyną problemów.

Na pierwszym ekranie widocznym po włożeniu karty pojawiło się pytanie:

Czy potrzebujesz gotówki?

Poniżej znajdowały się dwa przyciski: TAK i NIE. Pytanie wydało mi się dziwne jak na bankomat sieci Euronet.

Kiedy użytkownik wybierał "TAK" (przecież po gotówkę przyszedł do bankomatu) kierowany był na stronę ze szczegółami reklamy kredytów gotówkowych i "głupiał". Użytkownik oczekiwał przecież pojawienia się menu bankomatu, dostawał coś mylącego. Rezygnował więc z transakcji ("bankomat zepsuty") i odchodził.

Aby móc dokończyć transakcję należało wybrać "NIE" - dalej procedura przebiegała już standardowo.

Tak oto z mojego małego doświadczenia można wnioskować, że prosty błąd popełniony na etapie projektowania interfejsu użytkownika potrafi zniechęcić większość potencjalnych użytkowników systemu. Nie był to błąd działania systemu (nie poleciał żaden wyjątek, salda zachowały poprawną wartość), ale operacja do której bankomat był stworzony nie doszła do skutku.

Stało się tak, ponieważ przy integracji komponentów (nowa wersja reklamy w istniejącym UI bankomatu) nie sprawdzono jak całość zostanie odebrana przez klientów. Nie dokonano "testów integracyjnych na poziomie interfejsów białkowych". Z moich doświadczeń wynika, że styk człowiek-komputer jest trudniejszy do oprogramowania niż interfejsy pomiędzy komponentami oprogramowania.

Change "origin" of your GIT repository

GIT is a distributed version control system - that means it doesn't require to have any central repository. It's possible to build system by exchanging commits between equal nodes. It's convenient, however, to mark one repository as the central one. Of course you can change your decision at any time. I'll show you how to do that.

If you created your repo copy by "clone" operation you will have "origin" remote branch defined. This remote can be used to pull/push changes.

$ git remote -v
origin zeus.aplikacja.info:cust-proj1

If you decide to change this definition later you can issue the following commands:

$ git remote rm origin
$ git remote add origin git@github.com:aplikacjainfo/proj1.git
$ git config master.remote origin
$ git config master.merge refs/heads/master

After this change you can push your commits to new repository location (origin is selected as default remote branch for master, it's configured in .git/config):

$ git push

That's all. Much simpler than moving Subversion repository.

UPDATE 2011-12-09: replaced sed command with much simpler "git config" replacement.