🚀 go-pugleaf

On 07 Mar 2011 15:56:18 GMT, Andrzej Rosa wrote:

> On 2011-03-07, Michał Gancarski <michal@gancarski.com> wrote:
>> On 07 Mar 2011 14:48:07 GMT, Andrzej Rosa wrote:
>>
>>> Nie rozumiem.  Na przykładzie.  Dotknąłem pędzla, aplikacja zapamiętała
>>> to dotknięcie, dotykam rysunku i rysuję.  Wszystko pięknie.  Ale gdy
>>> dotykam poza rysunkiem a aplikacja nadal rysuje jest wtopa.  
>>> 
>>> I dalej w tym samym stylu.  Załóżmy aplikację pełnoekranową, żeby nie
>>> było komplikacji.  Dotknąłem pędzla, aplikacja zapamiętała że ma być
>>> pędzel, po czym dotykam menu.  Aplikacja powinna dać mi się przeklikać
>>> przez menu a mimo to nadal pamiętać, że wyimaginowany kursor ma
>>> przylepiony do niego pędzel.  Nie powinna zapomnieć wybranego narzędzia
>>> zanim użytkownik z niego osobiście nie zrezygnuje.
>>
>> To dokładnie tak jak z myszką. Sam sobie musisz zapamiętać, które narzędzie
>> zostało wybrane.
> 
> No i fajnie.  Wybrałeś pędzel, wszystko jest oczywiste, a użytkownik
> przeciągnął selekcję z innej aplikacji na obszar rysunki i zamiast
> wklejenia dostał krechę, bo programista nie przewidział że przeciąganie
> to zupełnie inny event niż rysowanie, mimo iż realizuje się go
> absolutnie identycznie.

No popatrz, to tak jak z myszką.


>>> Problem w tym, że w przypadku interfejsu dotykowego warunki nie są
>>> konkretne.  Decyduje kontekst, który nie jest konkretem, bo istnieje
>>> głównie w umyśle użytkownika.
>>> 
>>> Na przykład.  Użytkownik klika w menu, system otwiera menu, użytkownik
>>> klnie.  Dlaczego?  Bo on przecież "dotknął i przeciągnął" a nie "dotknął
>>> menu".  "Komputery są gupie!" 
>>
>> Skoro dotknął i przeciągnął, to nie "po prostu dotknął". Proste. To tak
>> jakbyś narzekał, że nie wiesz co zrobić z dwuklikiem na elemencie menu. Bo
>> przecież użytkownik nie kliknknął, tylko dwukliknął i klnie. Olaboga,
>> musisz o tym pomyśleć.
> 
> To akurat proste.  Dwuklik jest rozwinięciem jednokliku, tzn. najpierw
> robi to co jednoklik (powiedzmy zaznacza), po czym realizuje dwuklik,
> jeśli faktycznie nastąpi.  Nie ma konfliktu.

Andrzej, znowu opowiadasz głupoty. Dwuklik to dwuklik, a klik to klik.
Jedno nie jest żadnym "przedłużeniem" drugiego. Należy je traktować jak
dwie osobne akcje i można je takoż oprogramowywać. Bo nie rozumiem czemu
dwuklik na narzędziu nie miałby otwierać opcji tego narzędzia zamiast go
wybierać. Albo odwrotnie - dlaczego tak dziać by się miało.

Tak się dzieje w Inkscape - sprawdź. Z myszą i kursorem masz znacznie
większy ból głowy, masz znacznie więcej możliwości do obsłużenia. BTW, co
się dzieje gdy kółeczkiem jadę nad menu z narzędziami? Bo nie rozumiem
czemu ono się nie skaluje odpowiednio. To przecież oczywiste, intuicyjne. W
końcu każdy może chcieć mieć ikony innego rozmiaru. Tylko projektant
aplikacji się nie domyślił. Albo nie - kółeczko powinno powodować
przeskakiwanie do kolejnego/poprzedniego narzędzia. Chociaż z drugiej
strony może lepiej żeby paleta z narzędziami się przesuwała? Jeszcze nie
tak - to powinno być kontekstowe, np. kółeczko nad ikonką pędzla powinno
regulować jego grubość. Albo stopień nacisku? Przezroczystość?

Rzecziwście - prostota i oczywistość kontekstu.


>>> No i obsłużył proste dotknięcie w sytuacji gdy powinien się domyślić, że
>>> powinien obsłużyć gest. 
>>
>> Albo obsłuży dwuklik w sytuacji, gdy powinien się domyślić, że to powinien
>> być zwykły klik. Albo nie klik, tylko przytrzymanie klawisza i
>> przeciągnięcie myszką. Albo może jednocześnie prawy i lewy przycisk?
>> Kółeczko? Trzeci przycisk? Przeciągnięcie z trzecim przyciskiem?
>> Przeciągnięcie z prawym?
> 
> Każde z tych zdarzeń jest jednoznacznie określone, bo kursor zmienia
> stan zależnie od sekwencji*.  Ale owszem, zdarzały się problemy w
> przypadków gestów myszy i to całkiem często**.  W przypadku interfejsu
> dotykowego jest po prostu gorzej.

Jest po prostu lepiej, bo jest mniej możliwości do obsłużenia albo
zignorowania. I to, że powtórzysz tę kwestię tysiąc razy nie zmieni niczego
- myszka plus klawisze to tysiące możliwości. Ekran dotykowy zaś daje
znacznie mniej możliwych ze strony użytkownika manewrów.

 
> *) np. prawy kliki, puszczasz -> menu kontekstowe, ale prawy klik,
>   przeciągasz daje gest myszy.
> 
> **) np. prawy klik, przeciągasz daje menu kontekstowe zamiast gestu.



>>>>> Nie ma kursora o jednoznacznie określonym stanie.
>>>>
>>>> Ale przecież w normalnych aplikacjach to Ci nie jest potrzebne. Po xuj
>>>> Ci pozycja kursora myszki jak nic nie wciskasz?
>>> 
>>> Jednoznacznie określa kontekst.
>>
>> Nie.
> 
> Podaj przykład.

Chyba Ty? To Ty postulujesz, że niewielki podzbiór informacji na temat
stanu interfejsu określa jednoznacznie kontekst. Jak?


>>>  Jak kursor jest nad rysunkiem,
>>> pracujemy w paincie.
>>
>> Jak bazgrasz palcem po obszarze malowania, to malujesz.
> 
> Naprawdę?  A jak użytkownik rozwinął menu, przejechał palcem po
> pozycjach i wyjechał poza, to też powinna być krecha?  Kursor nie robi
> krechy.

Oczywiście, że robi. To jest tylko i wyłącznie kwestia wyboru ze strony
projektanta aplikacji, a nie kwestii myszka/dotyk. W obu przypadkach
aplikacja może się zachować na oba sposoby.


>  Po wyjechaniu poza menu, menu się zwija,

Nie rozumiem dlaczego. Może tak właśnie ma nie być? Kliknij sobie w Windows
w ikonkę pokazania wszystkich ikonek na pasku.


> ale żeby coś narysować
> trzeba ponownie wcisnąć LPM.  Tutaj dotyk to dotyk, nie?

Tak samo jak klik to klik. Nie ma żadnegeo wynikania pomiędzy "stanem
kursora" czy czymkolwiek innym, a sposobem zachowania się aplikacji w takim
momencie. To nadal jest wybór ze strony projektanta aplikacji, bo
oprogramować można oba rodzaje zachowania dla obu rodzajów interfejsu.

 
>>>  Jak kursor jest poza rysunkiem, obsługujemy zwykłe
>>> kliknięcia.
>>
>> Jak dotykasz poza obszarem malowania, to nie malujesz. Trudne?
> 
> A co w sytuacji gdy chcesz przeciągnąć kreskę poza widoczny obszar
> rysunku?

W przypadku myszki? Trudny wybór.


> Użytkownik prawdopodobnie będzie oczekiwał, że program
> przesunie mu widoczny obszar w kierunku malowania.

To tak jak z myszką.


> Czyli wyjeżdżasz poza obszar rysowania, ale z kontekstu wynika, że
> użytkownik chce kontynuować rysowanie, a nie przejechać palcem w inne
> miejsce.  Najśmieszniej by było, gdyby po wyjechaniu poza rysunek system
> obsłużył gest. ;-)

To tak jak z myszką.


> [...]  
>>> W przypadku interfejsu dotykowego kontekst trzeba zgadnąć.
>>
>> To dokładnie tak samo jak z myszą.
> 
> Powiedzmy, podobnie do gestów myszy, które też lubią się rypać, więc
> niewielka to pociecha. 

Nie "gestów myszy" tylko prostego draga.


>>> Jak kursor w ogóle jest, sytuacja się upraszcza.
>>
>> Nie.
> 
> Nie?  Robię Ctrl-V.  Gdzie i co powinno być wklejone.

No właśnie, gdzie? Bo nie pod kursorem przecież. Użyj czasem jakiegoś
programu graficznego to zobaczysz jakie cuda się dzieją.


-- 
Michał Gancarski