14 Mar 2009 10:30
TAGS: dev polish pomysły przeglądarki
Nie będzie dzisiaj o żadnych standardach, wsparciach dla CSS-ów i innych bzdurach, tylko o rzeczy najważniejszej dla użytkownika. Czyli o interfejsie użytkownika. Konkretnie o kartach (tabach). W reszcie posta będę używać słowa tab.
Historia
Kiedyś nie było kart. Przeglądarki miały swoje okno, w którym wyświetlały jedną stronę. Jeśli chciałeś otworzyć dwie strony, musiałeś otworzyć dwie przeglądarki. (Nie będę się zagłębiał w różnice pomiędzy dwoma oknami przeglądarki, a dwoma przeglądarkami.)
Miało to swoje plusy. Można było otworzyć sobie dwie strony "side by side", czyli jedna obok drugiej i np. porównywać dwa teksty.
Potem, pewnego magicznego dnia, pojawiła się przeglądarka, która otwierała strony w tabach! Zaraz pod wszystkimi paskami narzędziowymi, a nad wyrenderowaną treścią strony pojawił się (czasami znikający) pasek tabów. Niczym klon paska okienek z systemu okienkowego, pokazywał otworzone w przeglądarce strony, pomiędzy którymi można się przełączać.
Technologia wnosi takie ciekawe i ważne opcje jak:
- otwieranie linków w nowym tabie zamiast w nowym oknie
- otwieranie nowych tabów w tle — niech się załadują, zanim skończę czytać aktualną stronę — bardzo sprytne i przydatne
- minimalizuje chaos na pasku zadań — po co osobny kwadracik dla każdej otworzonej strony
Teraźniejszość
Każda ważna przeglądarka posiada taby. Nawet Internet Explorer w wersji 7 ma taby. Ale ewolucja tabów idzie krok naprzód. Przeglądarki Chrome i Safari 4 posiadają taby na samej górze okna:
Czy powinno to kogoś dziwić? Według mnie nie, ponieważ taby zmieniają nie tylko wyświetlaną stronę, ale również adres wyświetlany w pasku adresu (URL) oraz znaczenie przycisków wstecz i dalej (bo cofamy się tylko w danym tabie). Oznacza to, że taby przełączają nam kontekst prawie całej przeglądarki.
Przyszłość
Skoro taby przełączają kontekst całej przeglądarki, to co byśmy powiedzieli na wyodrębnienie tabów do osobnych okien?
Ups! Przecież od tego wyszliśmy i myśleliśmy, że taby to krok naprzód, więc dlaczego mielibyśmy się cofać?
Taby odegrały ważną (jeśli nie bardzo ważną) rolę w systemach operacyjnych. Dziś znajdujemy je nie tylko w przeglądarkach, ale również w edytorach tekstu (GEdit, Kate), narzędziach developerskich (Eclipse), terminalach (Konsole, Gnome Terminal) oraz w innych programach.
Czy rola tabów w różnych aplikacjach jest inna? Według mnie nie. Zawsze chodzi o to, żeby (podobnie jak w przeglądarkach):
- grupować podobne zadania
- oszczędzić chaosu na pasku aplikacji
- pozwolić na szybkie przełączanie pomiędzy tabami (w odróżnieniu od przełączania między aplikacjami)
- pozwolić na otwieranie czegoś w tle (bez otwierania wkurzających okienek)
Tylko dlaczego w każdej z wymienionych przeze mnie aplikacji taby realizowane są inaczej? Firefox ma taby nad stroną, Chrome zupełnie na górze, Safari jako fragment paska tytułowego aplikacji, Konsole na dole strony, Kate jako listę plików po lewej stronie…
Proponuję, aby istotnie przenieść ideę taba na poziom zarządzania okienkami, a nie poszczególnych aplikacji.
Moje postulaty dla menedżerów okien:
- wyróżnienie aplikacji (czyli to, co teraz jest oknem) i jej okien (czyli to co teraz jest tabem)
- mechanizm otwierania nowego okna w tle
- możliwość prostego przełączania się między oknami jednej aplikacji w odróżnieniu od przełączania się między aplikacjami
W tym miejscu przychodzi mi do głowy jeszcze jedna funkcjonalność tabów, która bywa różnie implementowana w różnych aplikacjach: możliwość odrywania tabów do osobnych okien i późniejszego ich łączenia.
W Firefoksie jeśli dobrze się rozeznałem takiej możliwości nie ma, w Konsole możemy odrywać taby, ale nie możemy ich z powrotem łączyć, czyli nie ma pełnego mechanizmu przenoszenia tabów pomiędzy oknami danego typu.
Zamiast kazać się wysilać twórcom aplikacji, zróbmy to raz a dobrze! Dodajmy do listy postulatów dla menedżerów okien następujący punkt:
- swobodne przenoszenie okien pomiędzy aplikacjami tego samego typu
Implementacja
Z ciekawością obserwowałem możliwość grupowania okien i późniejszego przełączania się między nimi na zasadzie tabów w Compizie.
Brakuje natomiast jednej bardzo istotnej rzeczy, która pozwala zastąpić poszczególne mechanizmy tabów w aplikacjach jednym mechanizmem z Compiza wyjętym.
Otworzenie nowego okna przez okno z danej grupy okien powinno powodować automatyczne przejęcie tego okna przez tę grupę. Musimy sami "doklejać" nowo-otwarte okna do grupy. I to jest główny ból tego rozwiązania. Ciekaw jestem jak z punktu widzenia protokołów i bibliotek można zaimplementować moje postulaty oraz jak daleko posunięte zmiany musiałyby nastąpić, żeby to dało się zrealizować.
Czy warto?
No i pozostaje pytanie, czy warto. Zacznę od wad:
- prawdopodobnie potrzeba przebudowy (lub rozbudowy) kilku elementów systemu okienkowego (takich jak menedżery okien i API do nich)
- konieczność aktualizacji aplikacji, żeby korzystały z natywnych tabów, zamiast ze swoich implementacji
- być może utrata pewnych możliwości (takich jak "podczepienie" swojego menu do zakładek) przez aplikacje
Zalety:
- zunifikowanie tabów w całym systemie (!)
- możliwość przebudowy mechanizmu "grupowania podobnych zadań" na pasku zadań — teraz wiemy dokładnie jakie zadania są powiązane — być może będzie ktoś odważny, kto wprowadzi dwupoziomowy pasek aplikacji
- znaczne uproszczenie kodu aplikacji
- łatwiejsze pisanie nowych aplikacji (mechanizm tabów mamy od razu za darmo, nie musimy się tym przejmować, ani zastanawiać się czy będzie kiedyś potrzebny)
- możliwość połączenia zmiany okien danej aplikacji z pewnym efektem graficznym
- możliwość prezentowania wszystkich okien danej aplikacji naraz tak jak to robi Safari dla tabów (tylko, że u nas to będzie za friko i dla każdej aplikacji):
Czekam na Wasze opinie!
i oto notka dla zwykłego śmiertelnika.
Pomysł ciekawy, chociaż grupowanie okien tej samej aplikacji już jest w Windows. Nie jest on jednak tak rozbudowany jak twój. Mniej więcej chodzi o to, że aplikacje (jeśli jest ich wystarczająco dużo uruchomionych, by zająć cały pasek zadań(?)) są grupowane w jedno. W sumie to koniec tego co jest.
Dodatkowo twój pomysł wymaga dopracowania samych koncepcji - co zrobić, gdy uruchomię Write'a i otworzę w nim dwa pliki (ok, taby), a jeśli uruchomię jeszcze jednego Write'a? Osobny tab, czy nie? Osobna przestrzeń adresowa czy nie? Osobne zajmowanie pamięci czy nie? No dobrze - to teraz coś podobnego z jakąś aplikacją, która zajmuje dużo CPU…
Wydaje mi się, że nie jest potrzebne przepisywanie aplikacji, tylko jakiś menadżer okien, który umożliwi sklejanie okien w jedno i pracę w stylu Operowym (wiele "okien" jednego okna)… Jakoś ten mechanizm się nazywa w WinAPI, ale nie pamiętam jak.
@faramir:
W Linuksie też, ale tak jak napisałeś generalnie mechanizm jest mało inteligentny (skleja często rzeczy, których nie chcemy sklejać). Generalnie chciałbym mieć — podobnie jak w firefoksie — kontrolę nad tym co będzie sklejone (np. kiedy kliknę otwórz w nowej karcie) a co nie (otwórz w nowym oknie).
MDI?
Piotr Gabryjeluk
visit my blog
Tak, to mniej więcej MDI :). Dzięki. Miałem zamiar napisać MPI wcześniej, ale coś mi nie pasowało :).
Ogólnie to jeśli system otwiera nowe okno danej aplikacji, to ma być w osobnym oknie, chyba, że się sklei (coś w stylu tego co na filmiku), a jeśli aplikacja sama otworzy nowe okno, to zacznie "mrugać" i to nowe okno będzie w tabie. Jeśli przeniesie się okno poza obszar to się odłącza.. albo jakiś inny sposób (np. menu kontekstowe tabów).
Wydaje mi się, że Opera mogłaby być inspiracją rozwiązania tego problemu ;p
@faramir
Generalnie, to aplikacja powinna móc decydować, czy otwierana jest nowa grupa, czy nowe okno w grupie. I wtedy aplikacja prezentowałaby różne metody otwierania, np. przez menu kontekstowe. Dodatkowo aplikacja powinna móc otwierać okna w trybie "domyślnym" i wtedy użytkownik wybiera na poziomie jakichś ustawień systemu, czy woli tak, siak czy inaczej. No i oczywiście w każdym przypadku, raz otworzone okno może być oderwane/doklejone/przeniesione do innej grupy.
To by było super.
Albo Pidgin. Ma niezłe właśnie odklejanie/sklejanie tabów.
Piotr Gabryjeluk
visit my blog
Post preview:
Close preview