🚀 go-pugleaf

On 07 Mar 2011 12:28:06 GMT, Andrzej Rosa wrote:

> On 2011-03-06, Michał Gancarski <michal@gancarski.com> wrote:
>> On 06 Mar 2011 18:33:49 GMT, Andrzej Rosa wrote:
>>
>>>>> Dla przykładu - "złapałeś" pędzel w paintcie i upuszczasz na pulpit.
>>>>> Jak masz kursor wiadomo co robić (w tym wypadku nic).
>>>>
>>>> To dokładnie tak samo jak z przeciąganiem palcem.
>>> 
>>> Niedokładnie.  Dokładnie byłoby gdybyś miał dostępne menu kontekstowe,
>>> kilka przycisków i kursor o jasno określonym stanie.
>>
>> Czyli jest prościej, bo możliwości mniej. I nie rozumiem w jaki sposób w
>> dotykowym interfejsie nie ma ustalonego stanu. Dotykasz albo nie dotykasz.
> 
> Dotknąłeś pędzel w paincie i podnosisz palec.  Jaki stan i w ogóle stan
> czego masz w tej sytuacji?  

Jaki znowu "stan"? Klikasz w obszar malowania - malujesz (masz wybrany
pędzel). Poza obszarem malowania nie malujesz. To chyba logiczne?


> Użytkownik _z kontekstu_ oczekuje, że jak dotknie palcem obszaru na
> rysunku to będzie malował dotkniętym _wcześniej_ pędzlem.  Nie oczekuje,
> że jak dotknie obszaru poza rysunkiem to też będzie malował.
> Programista musi _przewidzieć_ oczekiwania użytkownika i je odgadnąć.
> Nie ma kursora o jednoznacznie określonym stanie.

Bo trudno się przecież domyślić, że pędzel to pędzel tylko tam gdzie
pędzlem ma być, tzn. na obszarze malowania.


>> Jeśli dotykasz, to dodatkowo możesz przeciągnąć i tyle. Różnica jedynie
>> taka, że w multitouchach może się to dziać w kilku miejscach.
> 
> A to dodatkowy problem, w który w ogóle nie chce mi się wnikać.

Jaki "problem"? Tak jak analizujesz ruchy żeby np. pisać obsługę gestami w
przeglądarce, tak samo analizujesz przejeżdżanie po ekranie, tyle, że masz
więcej możliwości. Co nie zmienia faktu, że masz obsłużyć jedynie niektóre,
tak samo jak nie każdy gest robi "coś" w przeglądarce.


>>>> Huh? Andrzej, powiedz, że żartujesz. Właśnie stwierdziłeś, że obsługa
>>>> tabletów na desktopie jest w zasadzie jakimś kompletnym chaosem. A to jest
>>>> dokładnie to samo (nie licząc takich bajerów jak nachylenie piórka czy
>>>> stopnie nacisku). Różnica jest taka, że naciskasz piórkiem na miejsce na
>>>> tablecie, a nie palcem na ekranie. Co niczego nie zmienia.
>>> 
>>> Zmienia, bo kursor jest zawsze na ekranie i czasami się go klika, a
>>> palec jest zawsze w powietrzu i tylko czasami czegoś na ekranie dotyka.
>>
>> No i? W jaki sposób to komplikuje?
> 
> W taki, że użytkownik podnosząc palec w wielu wypadkach będzie
> oczekiwał, że system zapamięta co wcześniej dotknął i zastosuje tę
> informację w innym miejscu.

To wstrząsające, dokładnie tak jak z myszką.


>  Tak jak to opisałem powyżej, gdzie
> dotknięcie pędzla i podniesienie palca ma działać tak samo jak
> kliknięcie pędzla i przesunięcie kursora na obszar rysunku.

Dokładnie ten sam poziom (braku) komplikacji.


> Innymi słowy, w wielu wypadkach programista musi obsłużyć sekwencję
> dotknięć, nie pojedynczą akcję. Sekwencja ma sens jedynie w konkretnym
> kontekście, którego programista musi być świadom.

Nie ma tu żadnej "sekwencji dotknięć", jest "wybrany pędzel", więc "nad
obszarem malowania malujemy, a poza obszarem malowania nie malujemy". Nie
ma żadnej "sekwencji", jest jedynie wybrane ostatnio narzędzie.


>> Co daje "ciągła obecność kursora na
>> ekranie"? Nic. W znakomitej większości przypadków liczą się tylko momenty,
>> w których wciśnięty jest przycisk myszy, co jest równoważne z dotknięciem
>> palcem.
>>
>>>>> nie ma przycisku myszy, który możesz upuścić,
>>>>
>>>> Za to jest palec, który możesz podnieść?
>>> 
>>> Możesz podnieść?  Superancki ten twój interfejs, który wymaga trzymania
>>> palca cały czas na ekranie...
>>
>> No właśnie nie wymaga, bo można podnieść palec.
> 
> Może teraz udało mi się zilustrować przynajmniej niektóre problemy?

Raczej stworzyć nieistniejące.


-- 
Michał Gancarski