Funkční okna, aneb jak by také mohlo vypadat moderní GUI

13.4.2006 22:58 | Přečteno: 2631× | Alternativní UI | poslední úprava: 13.4.2006 22:58

Je už delší dobu známo, že současný způsob ovládání počítače má svoje mouchy. Jaká jsou dnes nabízená řešení? Ve způsobu chápání počítače Plan 9 (kde je všechno soubor), Squeak (kde je všechno objekt) a ve způsobech ovládání počítače GUI, ZUI, CLI, a nějaké to 3D rozhraní. Každé se hodí na něco. Ale pro běžnou, precizní, rychlou, intuitivní a cílevědomou práci s počítačem je potřeba změnit jak přístup k chápání počítače tak i přístup k jeho ovládání.

Dobře, řeknete si, ale jak by to mělo vypadat? Tak co třeba takto...:

Základní představa

V systému existují zatím blíže nespecifikované modely, které se skládají z komponent. Velmi pravděpodobné je, že modely budou reprezentovány v XML standardizovaném formátu. Funkční okna jsou potom taková okna, která umožňují nějaký specifický pohled na tyto modely.

Pro představu například model kalendáře je složen z komponent, kterými jsou dny a uvnitř těchto dnů jsou komponenty textu (poznámky). Funkční okno (FW) stojí nad tímto modelem a je jistým náhledem na něj. Může existovat FW, které zobrazí kalendář jako sloupec dnů a poznámek vedle nich, stejně jako může existovat FW zobrazující standardní kalendář s vyznačenými dny.

Je zřejmé, že takto vznikají soubory (množiny) funkčních oken, které se hodí k prohlížení standardizovaných množin modelů. V základní představě je barevné rozlišení typů FW – grafika je ve spektru červené, kancelářské dokumenty mají světlé barvy, videa jsou v odstínech modré a podobně. Zkrátka nad jeden model může uživatel umístit různá okna, ale právě jen taková, která umí model přečíst. K jednomu typu modelu patří jeden typ okna – se stejnou barvou. Okna jediného typu se pak liší pouhým způsobem pohledu na stejný objekt.

Uživateli je dána volnost, jaké okno si pro práci s modelem vybere. FW ovšem není jen nějakou křišťálovou koulí vizualizující model schovaný v systému, je to zároveň i tunel, skrze který se uživatel může modelu dotknout.

Funkce FW

Mezi základní funkce FW patří samozřejmě změna „úhlu“ pohledu na model. Uživatel se může přesouvat nad různá místa modelu a do výřezu okna tím umisťovat ty komponenty modelu, které ho právě zajímají. FW by ovšem mělo nabízet i umisťovaní pomocných objektů (helpers - vodící lišty, mřížky, kurzory, atd...) a možnost výběru konkrétní komponenty, nebo množiny komponent.

Tím by ale měli schopnosti FW vůči modelu a uživateli končit. Jakoukoli modifikaci modelů – různé výpočty a transformace, kompozice a umisťování nových komponent, by měl zařídit editor.

Editory

Editor je vlastně množinou funkcí, které je možno aplikovat na nějaký model, nebo na komponentu modelu. Uživateli je dána možnost vzít oblíbený editor a přichytit ho k FW. FW předá editoru ukazatel na model, který je právě pod ním a naváže s editorem komunikaci v podobě předávání událostí.

K základní množině funkcí, které připadají funkčnímu oknu (a které mohou být reprezentovány tlačítky), přibudou další, které jsou vlastní vybranému editoru. Editor má jednu pevně danou nabídku funkcí, které souvisí s celým modelem, nebo které souvisí s administrativou editoru. Tyto funkce jsou přístupné v jakékoli fázi práci. Pak editor nabízí ještě další funkce, které souvisí s právě vybranou komponentou (nebo komponentami). Velmi praktické je tyto funkce nabízet v kontextovém menu, protože jsou pak rychle přístupné.

Základními funkcemi editoru je vznik nových komponent modelu, úprava stávajících komponent, mazání komponent a přesuny komponent.

Vzhledem k tomu, že existuje možnost, že komponenta je také modelem, stojí za zvážení aby editor vyvolával jiné editory na vybrané submodely (v podstatě jakási varianta objektového přístupu).

Hlubší úvahy

Naznačené vlastnosti FW jsou z velké části inspirované objektovými prostředími jako Smalltalk nebo Mac OS X. Aby práce s FW byla opravdu komfortní, je třeba dotáhnout úvahy o nich až do konce. O modelech se zatím hovořilo čistě akademicky ve smyslu toho, že uvnitř systému jsou reprezentovány XML souborem.

XML modely

XML je vhodný formát pro množství modelů z hlediska jeho standardizace a „čitelnosti“. Není však vhodný pro ukládání binárních dat, velkých objemů dat, systémových zdrojů (a v neposlední řadě konfiguračních souborů – „možná“ - o konfiguraci bude ještě řeč).

Pokud jde o velikost, lze XML bezztrátově zmenšit kompresí. Jsou ale případy, kdy je nutno k modelu přistupovat jako k proudu (řadě dat neboli streamu) a XML formát by pak práci nepříjemně zpomaloval. Stojí pak za zamyšlení, zda je možné vytvořit jakýsi „warp-XML“, což by byl neexistují XML obal dat, který by se choval trochu jako objekt – nebo něco na ten způsob.

V souvislosti s XML se ještě objevuje problém meta-informací. Čili informací, které s vlastním skutečným stavem modelu nemají mnoho co do činění, ale jsou výhodné pro budoucí editaci (v případě používání většího množství editorů by mohlo docházet ke kolizím).

V pozadí povídání o XML formátu stojí nevyřčená skutečnost, že model by byl uložen na disku a pokud by se nad něj postavilo funkční okno, asi by bylo výhodnější umístit jej do paměti.

Pohled do paměti

Umístění modelu do paměti by mělo být transparentní. Měla by existovat možnost jak do paměti nahlédnout a jak prolistovávat načtené modely. Velmi snadno tímto způsobem uživatel dosáhne například zobrazení jednoho modelu ve více oknech. Níže bude naznačeno, že v podstatě celý systém by měl být transparentní a modely a editory a funkční okna, tedy vše, co by mohlo být uloženo v paměti, by mělo být snadno přístupné a přehledně uspořádané (například do hierarchie, které by byla virtuálně připojena do systému souborů).

Důležitou otázkou je, jak a kdy se bude v paměti uložený systém zálohovat a jak budou vratné všechny provedené akce.

Verzování

Verzování, tedy ukládání rozdílových verzí editovaných modelů, je jednou z nejdůležitějších funkcí, jaké by měl systém podporovat. Verzování by nemělo být v kompetenci ani editoru a ani zřejmě formátu modelu, ale samotného systému. Mělo by být možné nastavovat množství vratných kroků pro modely uložené v paměti, po kterých následuje procedura „commit“, která nastavené množství kroků spojí do jediného výchozího modelu. Stejně tak by mělo být možné nastavit, jak často bude docházet k zálohování modelů na disk a kolik verzí takto vzniklých souborů se eviduje, než dojde k proceduře „commit“ tentokrát na disku. (Může se jedna například i o časové intervaly).

Předchozí odstavec ještě jednou a srozumitelně: Data jsou v systému ve dvou fázích: na disku a v paměti. Verzování v paměti je rychlejší a může být složeno z drobnějších kroků. Verzování na disku je pomalejší, ale výpadek proudu již data neohrozí. Proto by mělo docházet k pravidelnému kopírování dat z paměti na disk a verzování by mělo probíhat současně v paměti i na disku, ale na disku úměrně méně často.

Vše výše uvedené, by však uživatele nemělo znepokojovat a tato činnost by měla být před ním do značné míry skryta. Uživatel by měl vidět pouze jeden model, který může samozřejmě kopírovat, mazat, přesunovat (přejmenovávat), ale neměl by rozpoznat, zda je tento model na disku, nebo jen v paměti. Zůstává ovšem samozřejmě ta možnost, že bude moci snadno listovat ve verzích modelu a v případě ukončení práce s modelem, nebo i během práce bude moci sám ručně zahájit proceduru „commit“.

Spojení modelu, funkčního okna a editoru

Z pohledu uživatele budou v systému přítomny tři entity, které on může vzájemně spojovat. Jde o model, o funkční okno a o editor. Tyto tři entity by měly být v systému nějak reprezentovány. Na začátku úvah o FW byly zmíněny barvy – tedy typy modelů, oken a editorů, jež lze vzájemně kombinovat. Jak se budou zmíněné entity prezentovat záleží na konkrétním provedení, ovšem uživateli by měla být dána možnost otevřít FW, umístit ho nad konkrétní model a připojit k oknu editor.

Ovšem tím výčet možností zdaleka nekončí. Uživatel by totiž mohl vzít model, a použít na něj editor s jednorázovou účinností na celý model. Vzniklý upravený model by mohl snadno nahlédnout funkčním oknem a editor připojený k tomuto oknu by po dokončení úprav mohl nabídnout model k dalšímu zpracování, nebo uložení na disk.

Příkladem může být streamové zpracování zvuku. Modelem nechť je zdroj zvuku (mikrofon) a prvním editorem například odstraňovač šumu. Dalším modelem nechť je množina obrázků. Oba zmíněné modely budou vstupovat do editoru, který je spojí a výsledkem bude model video. Mezi model řady obrázků a video editor může uživatel umístit FW, které bude pouze zobrazovat právě probíhající obrázek. Čili uživatel se snaží okomentovat svoje fotografie z dovolené a vytvořit z nich video.

Tato vizuální práce s modely je moderní obdobou unixového shellu (přesměrování, roury, …), a není to poslední funkce shellu, kterou se nechávají FW inspirovat. Po tomto nástinu je třeba se detailně podívat na všechny zmíněné entity a probrat jejich možné funkce.

Editory

Jak již bylo řečeno, editor nabízí funkce specificky použitelné na nějaký model nebo jeho komponentu. Ovšem mohou existovat i editory, které spojují několik modelů v jeden a nebo naopak rozdělují jeden model na vícero. Jedny by bylo možné nazvat slučovači (joiner) a další rozdělovači (splitter). Existují také editory, které mohou samočinně (skriptovaně) pracovat na modelu, bez zásahu uživatele. Těmto editorům se říká stream editory.

Další neopomenutelnou variantou editoru by byl takzvaný kompozitér (composer). Vstupem do něj by bylo více modelů a uživatel s nimi pak zachází jako s komponentami, různě je vůči sobě časově nebo prostorově posunuje (za přispění pohledu skrze funkční okno) a nakonec sám určí jaký model, nebo modely se z nich mají stát.

Jeden editor může samozřejmě zvládat všechny výše zmíněné varianty editování, ale také nemusí. Spojování modelů s editory a jejich tok by mohl být graficky znázorněn šipkami mezi spuštěnými editory. Inspirace typicky programy Softimage nebo Blender. Což neznamená, že to nejde i jinak.

Modely

Modely jsou uloženy v paměti a je-li tak editor nastaven, jeho editací vzniká upravená verze modelu, která opět leží někde v paměti. Editory by měli umět zpracovávat i modely, které se chovají jako proudy (streamy) a tudíž nemusí být vždy přístupné jako celek. Tedy i prázdný model může mít nějakou dopředu neznámou délku a editor čeká než se v modelu objeví nějaká data, aby je mohl zpracovat a přeuložit.

Formát XML je vhodným formátem pro řadu editorů a pro zobrazení uvnitř oken, ale modelem by mohl být i nějaký systémový zdroj. Modelem by v unixovém pojetí mohl být jakýkoli soubor. A konečně modelem je i samotný systém.

Systém

Na model systém je možné podívat se skrze specifická okna a použít specifický editor. Vzniká tak uživatelské rozhraní implementující již zmíněné funkce: zobrazení třech základních entit v různých fázích jejich použití a práci s nimi. Systém je tedy zvláštním případem modelu. Jeho komponentami jsou například pevné disky, DVD, datum a čas, síť, zvuková karta, prostě vše, s čím by uživatel chtěl kdy pracovat. Vybrané FW, kterým se na tento model uživatel podívá, bude vlastně grafickým uživatelským rozhraním. Zvolený editor pak nabídne množinu funkcí pro práci se systémem.

Funkční okna

Základní vlastnosti funkčních oken již byly představeny, ovšem díky tomu, že FW jsou vcelku autonomní, lze snadno rozšířit jejich schopnosti. Například kromě změny velikosti a polohy na pracovní ploše (jde o plochu funkčního okna, které zobrazuje systém), lze snadno přesunou FW na jinou obrazovku, rozšířit jeho velikost na více obrazovek, nebo ho přímo směrovat na jiný počítač.

Za zmínku ještě stojí propojování funkčních oken. Je docela snadno představitelné, že nastane případ, kdy uživatel bude chtít pouhým vybráním jedné komponenty měnit obsah jiného okna. Bude například vybrán den v kalendáři a jiné autonomní okno zobrazí detaily tohoto dne. (Zde se již naráží na problém, jak mnoho funkcí a modifikací zobrazení bude dáno na starosti funkčním oknům a kolik se toho nechá na samotné editory.)

Zvláštním případem pohledu na model jsou pohledy typu dialogu (nastavování, konfigurace pomocí grafických prvků).

Dialogy

Výchozím předpokladem je, že konfigurace čehokoli je uložena v konfiguračním souboru (tedy model typu konfigurace). Například je třeba nastavit vlastnosti oken nebo editorů nebo jejich často používaných celků (kterým se říká aplikace, viz níže). Problematiku lze rozdělit na dvě části – problém zobrazení konfiguračního modelu jako dialogu a problém zobrazení konfiguračních modelů jako průvodce.

Obsahem modelu jsou samozřejmě proměnné, které lze nastavovat, ale současně i jejich jméno, stručný popis a hodnoty, kterých může proměnná nabývat. Vizualizace takového modelu se pak sestává z problému, jak rozmístit proměnné, aby spolu funkčně souvisely, jaký typ výběru pro proměnnou nastavit (radio buttons, check box, list atd...), které proměnné jsou důležité a které jsou spíše pro fajnšmekry. Jinak řečeno zkušený uživatel může editovat konfigurační soubor ručně, ale ostatním by více vyhovoval přehledný dialog.

Všem by se ale hodil inteligentní dialog, nebo průvodce (wizzard), který rozpozná i které kombinace hodnot proměnných jsou relevantní či vůbec možné a jakým způsobem se kombinace proměnných účastní na výsledku konfigurované funkce. Právě proto je XML formát nedostačující (možná). Mezi proměnnými by měly být uvedeny i jejich vzájemné závislosti (jakási inverzní algoritmizace vůči funkci, která se právě konfiguruje). Dialog, či průvodce by měl nejen nějakým způsobem ukazovat jak se ta či ona změna projeví ve výsledku, ale zároveň, jak nastavit určité proměnné, aby se došlo ke konkrétnímu výsledku.

Zkonfigurovaný editor a okno a spojení těchto dvou entity může být pro uživatele jednou a provždy dostačující rámec pro práci s typem modelů, které používá. Tak vzniká aplikace.

Aplikace

Aplikace je vlastně funkční okno s editorem (nebo editory), které je postačují na dlouhodobou práci s mnoha různými modely. Uživatel by měl mít možnost tuto kombinaci nějak uschovat a vyvolávat v případě potřeba třeba i mnohonásobně. V paměti může jít o model, který udržuje informace o použitém okně a editoru a o jejich konfiguraci. Tento model pak zobrazí jako komponentu FW, které právě zobrazuje systém.

Standardní události

FW zachytává vlastně všechny události, které uživatel nad tímto oknem provede (stisk myši, táhnutí myši, události klávesnice atd...). Systém by se měl dát nakonfigurovat tak, aby uživatel mohl za každou událost dosadit jakoukoli klávesu nebo kombinaci kláves (nebo myši). Ovšem nastavuje tak pouze to, jaká událost bude stiskem kláves nebo myši vyvolána.

Z principu je jasné, že FW bude zachytávat veškeré události (minimálně od uživatele, možná i od systému) a bude je překládat na standardní události, kterým rozumí editory (vyber komponentu, přesuň komponentu, vyvolej editor na tuto komponentu...).

Standardní výstupy

Posledním zajímavým tématem jsou standardní výstupy, které může produkovat editor. Editor, jak bylo zmíněno, může operovat nad stejným modelem, který je zobrazen v okně a současně může přeposlat model jinému editoru, nebo ho uložit. Přeposlání je jakýsi výstup z editoru. Tímto výstupem nemusí nutně být model stejného typu jako model nad kterým je právě operováno (editor typu splitter). Navíc ovšem editor může hlásit různé stavy svoje, nebo modelu. Těmto výstupům se říká standardní.

Jsou to kupříkladu informace o průběhu nějaké funkce, informace o výsledku funkce nebo například chybové hlášky a podobně. Uživateli je dána volnost, jak s těmito výstupy naloží. Ovšem v případě, že by bylo i chybové hlášky možno ignorovat, pravděpodobně by editor měl mít možnost jak ošetřit svou další práci nad modelem.

Závěr a otázky nutné k položení

Po přečtení je vám asi jasné, že jde o zaznamenaný proud myšlenek a ne o ucelenou představu, ale základní postřehy jsou asi celkem jasné: Bude-li mít uživatel v ruce myš a v hlavě mozek, bude počítač pracovat pro něj a ne naopak. Aplikacím je sebrána možnost vnucovat uživateli svou vůli, svoje ovládání, své formáty. Přitom je v základních rysech možné toto GUI s funkčními okny implementovat třeba na Linuxu.

Pokud jste se prokousali až sem, velmi by mě zajímal váš názor, postřehy i připomínky nebo návrhy. Zjednodušený náhled, jak by asi FW mohly vypadat je zde: GUI Function Window. Následující otázky jsou jistým vyjádřením toho v čem by z principiálního hlediska mohly být problémy:

• Měl by editor umět volat jiné editory? Mělo by okno obsahovat i jiná okna? Měly by komponenty modelu být spravovány autonomně již existujícími okny a editory, nebo vnějším oknem a editorem?
• Jak by měla být v systému udržována množina přítomných editorů, aby jiné editory věděly, který editor mohou vyvolat a co když uživatel preferuje jiný editor?
• Mělo by FW umět pracovat s helpery? A obecně, jak mnoho funkcí by mělo být dáno oknům a jak mnoho by se mělo ponechat editorům?
• Měl by model mít uloženy metainformace související s jeho editací?
• Jak by mělo být implementováno hierarchické vkládání oken do oken, nebo jejich vzájemné přichytávání.
• A konečně: Je vůbec představitelné, aby veškeré formáty souborů bylo možné nahradit několika málo desítkami modelů formátu XML?

       

Komentáře

[Ku8aZ]

Škoda, že už jsem maturoval, délkou by to slohovce odpovídalo

[Kníže Ignor]

Jenom jsem to prolít, číst to celé je nad mé síly. Ale "kompozitér"?????? Styď se!

[Adrin]

Mě se to slovo líbilo :) Sice evokuje jiné, ne nepodobně zvučně znějící, totiž slovo „kompostér“, ale neříkejte, že přesto není jeho tón lahodný. :)

[Jiří (BoodOk) Kadeřávek]

Jste si jisty, ze se na problematiku nedivate prilis schematicky. Resp. vy si skutecne myslite, ze to uzivatel, ktery je schopen pojmenovat si model 600 znakovym nazvem (1. odstavec textu, no a co) pochopi logicke vztahy v systemu. Ze lide, kteri i po 10 letech prace s PC rikaji adresari zluty ctverecek pochopi, co je to funkcni okno nebo model a co to jsou ruzne pohledy na model? Neverim tomu. Ale preji Vam at to s vasi predstavou dotahnete dal.

[Adrin]

Jistý si samozřejmě nejsem. S přístupem hrubé síly a vulgárních zvyků uživatelů tato představa stojí či padá. Respektive zůstane zapomenuta na akademické úrovni, nebo jí časem svět desktopů přijme. Řekněme si to upřímně, úspěch sebegeniálnějších projektů (ať už jde o Smalltalk, internet nebo Linux) závisí na marketingu a přístupu k uživatelům a to zhruba z 90%. Vždycky se hodí mít u projektu někoho jako Bill Gates, aby původní logickou a schématickou představu rozbil a uzpůsobil ji prostým lidem :)

[Jiří (BoodOk) Kadeřávek]

Ja jsem se stavem soucasneho GUI take neprilis spokojen. Jsem presvedcen, ze je malo diverzifikovatelne pro ruzne stupne cinnosti, ze treba GUI pro server, pokud nejake pouzit (a to samozrejme nejlepe vzdalene z klienta), by melo byt ovladacim panelem elektrarny, ze GUI pro kancelarskou praci by melo byt multifunkcnim psacim strojem atd. Kazda cinnost vyzaduje trosicku neco jineho.

Dnesni OS vlastne vubec nezajima, jakym zpusobem chcete pouzivat pocitac. Maximalne se Vas zeptaji na vybaveni SW, ale rozhodne nijak neresi prizpusobeni prostredi te ci one cinnosti.

Pamatuji si na Novell server, ten mel vlastni 'prostredi' v textovem rezimu, co obrazovka, to ovladaci panel nejake kriticke SW komponenty serveru. Idelani reseni. A netusim, proc zapadlo. Mozna, kdyby na abicku byly mozne nejake moderovane diskuse trvalejsiho charakteru, mozna by se dalo na toto tema trochu 'zabrainstormovat', ale v blogpostu to, obavam se, zapadne.

[Adrin]

Přesně takovou diskusi bych chtěl vyvolat. Ale v tomhle nejsem zrovna expert :) Dlouhé články nikdo nečte. Ovšem zřejmě by šlo navázat se na nějaká existující fóra například okolo ZUI (Piccolo) nebo tak něco.

[KS]

To ukázkové GUI mi hodně připomíná Squeak.

[pok]

Není mi moc jasný rozdíl mezi FW a editorem - FW je vlastně jenom takový osekaný editor, takový prohlížeč?

Řekněme:

1. v editoru (řekněme něco jako Access) zoložím nový model - nadefinuju jak má vypadat formulář, komunikace s databází, možné výstupy apod.
2. ten model si nějakým oknem otevřou ve skladu a budou přes něj zadávat data
3. stejný model si otevře ředitel a bude koukat kolik čeho prodali apod

Moc v tom ale nevidím rozdíl oproti současnému stavu - snad až na tu propracovanější abstrakci modelů/oken/editorů.

[Adrin]

FW a editor je něco úplně jiného. FW se stará pouze o zobrazení (plus výběr komponent či vkládání pomocných čar, jakýchsi fólií, nad zobrazený model), zatímco editor se již o zobrazení nestará a plní jen editovací příkazy.

Je to tak trochFW a editor je něco úplně jiného. FW se stará pouze o zobrazení (plus výběr komponent či vkládání pomocných čar, jakýchsi fólií, nad zobrazený model), zatímco editor se již o zobrazení nestará a plní jen editovací příkazy.

Je to tak trochu rozsekaný a hybridní model-view-controller. Cílem je standardizovat model, aby k němu mohl kdokoli, kdykoli a jakkoli (žádné uzavřené formáty a problémy konverzí) a standardizovat práci s tímto modelem (klávesová zkratka pro „zoom“ vyvolá zoom v jakémkoli okně).

V reakci na Váš příklad bych byl ovšem opatrnější, protože FW jsou opravdu spíš jen o ovládání desktopu, než o nasazení v databázích, distribuovaných objektech, nebo informačních systémech. Mel bych ale jiný příklad: Dejme tomu, že budete psát bakalářskou práci. Modelem je textový dokument. Jedním FW se na tento model podíváte jako na kontinuální text s XHTML značkami, kterým budete současně chtít editovat a proto si na toto okno „přilepíte“ editor textu, který vám umí doporučovat dokončení tagů a hlídá i syntaktickou správnost. Současně si chcete být jist, že píšete správně česky a přilepíte na toto okno ještě jeden editor kontrolující pravopis. Dalším oknem si otevřete tentýž model, ale nyní v zobrazení výsledného dokumentu. Ještě jedním oknem se podíváte jak vypadá současná osnova, seznam použitých obrázků, tabulek a grafů, citace a podobně. A hlavně si otevřete okno, které vám bude ukazovat kolik ještě znaků musíte napsat, aby jste splnil limit. u rozsekaný a hybridní model-view-controller.

[Lukáš Rýdlo]

Sice jsem se zasekl už u "hlubších úvah" , ale tento text mi hodně připomíná naše matematická skripta (PřF MU), která sotva trávíme my studenti. Člověk, jehož znalosti matematiky končí u malé násobilky to zahodí -- a řekněme si na rovinu: ten koncept je sice zajímavý, ale svou složitostí je odsouzen k zániku. Možná by to bylo ochotno používat pár nadšenců, kteří mají doktorát na FI MU, ale těžko by se to dostalo dál. Dokud to nebude zabaleno do podoby s obrázkem složky a čudlíkem s nápisem "Start" nepředpokládám, že se toho někdo chytne.

[Predator]

Logicky je to síce až extrémne čisté a postavené na exaktnom princípe, ale ... pochybujem, že by to používal niekto mimo matfyzu. Tá abstrakcia GUI je síce ako myšlienka pekným matematickým modelom, ale nezabúdajme, že 99 percent ľudí nemyslí analyticky, ale synteticky. U obyčajného usera s objektovým princípom nepochodíš, tí nechcú rozmýšľať nad väzbami jednotlivých komponentov v modeli, ale robiť. Neviem si predstaviť, ako by v tom pracovala sekretárka, alebo trebárs skladník, projektant, grafik, zvukár.... tí potrebujú kliknúť, spustiť aplikáciu a robiť.

Najlepšie GUI je teda také, ktoré sa nemusia vôbec učiť a prakticky si ho ani nejak neuvedomujú, je to pre nich iba pomôckou, ako sa čím jednoduchšie dostať k programu. Toto je klasický prípad, ako niečo postavené na efektnom "logicky čistom" modeli sa v praxi míňa účinku a spôsobuje viac komplikácií ako uľahčenia práce. Nie je to prvý prípad zrážky programátorského ideálu s realitou, spomeňme si na mikrokernelové systémy, u ktorých sa práve z dôvodu extrémnej čistoty dizajnu a dokonalej modularity objavili prakticky neriešiteľné problémy s výkonom a odozvou takéhoto SW. Toto je hodne podobný prípad.

Budúcnosť by som skôr videl v prispôsobovaní sa rozhraní človeku .... trebárs rozhrania vybavené umelou inteligenciou, reagujúce na povely písané v bežnej reči (napríklad užívateľ zadá "Chcem napísať list priateľke" a počítač mu nahodí textový editor a dá mu na výber z rôznych efektných grafických úprav), či rozhrania reagujúce na hlasom vydaný príkaz.

[Adrin]

Bohužel to tak asi být může. Při cestě ke zjednodušování principu práce s počítačem jsem se snažil, aby řešení bylo co nejideálnější, nejčistší a co nejlogičtější. Myslím si sice, že není problém tohle řešení „znásilnit“, tedy připravit pro obyčejné uživatele tak, aby jim vyskakovalo jen připravené řešení a aby se nemuseli zabývat tím, co je okno a model a tak, ale aby ostatní mohli dál využívat výhody nastíněného GUI, jenže on ten ideál ovládacího rozhraní může ležet trochu jinde. Zkusím nad tím popřemýšlet :)

[Predator]

Trošku by som ešte podiskutoval o tomto modeli. Ono slabinou tohto navrhovaného systému je práve jeho podstata.

Zober si napríklad aplikáciu tohto systému na strih zvuku. Podľa tohto princípu by sa to ťažko dalo realizovať. Audiostrižný systém totiž nie je o editovaní jedného súboru, ale o synchrónnom editovaní a nedeštruktívnom realtime efektovaní niekoľko desiatok súborov. Pritom v aranžovacom okne umiestnené jednotlivé tracky sú prehrávané po častiach, môžu sa ľubovoľne posúvať, kopírovať a strihať, pričom ten samotný nahratý súbor SA NEMENÍ - mení sa len spôsob jeho prehrávania v reálnom čase. Ak trebárs spevák naspieva jeden refrén perfektne, ten sa prehraje v skladbe aj niekoľkokrát bez toho, aby sa ešte niekam fyzicky kopíroval. Teda prakticky by sa princíp súbor - editor - okno nedal použiť. Nehovoriac už o tom, ako by si chcel ovládať niekoľko desiatok takýchto okien a synchronizovať ich medzi sebou, mixovať, routovať po efektových a signálových cestách atď ... aby to po spustení dalo dokopy finálny mix, nie nezmyselnú zmesku zvukov. Skús si nainštalovať trebárs taký Cubase alebo podobný soft a pochopíš, že tade cesta nevedie.

A čo potom aplikácie typu CAD alebo grafický rendering - už vidím, ako dizajnér spúšťa niekoľko miliónov funkčných okien, s ktorých každé počíta jeden pixel obrázku

Čiste teoreticky by to takto chodiť mohlo. Otázne je však, čo by sa s tým dalo reálne robiť (moc veľa vecí asi nie) a aká by bola efektivita a ergonómia ovládania takéhoto systému (pri trochu sofistikovanejšej práci tiež nevalná). A práve to je kameň úrazu.

Záver - tento prístup sa hodí iba pre jednoduché použitie pre aplikácie, ktoré spracovávajú súčasne iba malé množstvo súborov bez nejakej komplexnejšej práce s dátami v reálnom čase. Takto sa dá urobiť napríklad telefónny zoznam, textový editor či jednoduchý prehrávač multimédií, ale na serióznejšiu netriviálnu prácu s počítačom (CAD, profi audio, relačná databáza, grafika, riadenie výrobných procesov v reálnom čase atď ...) sa príliš nehodí. Bolo by to asi tak použiteľné ako auto so štyrmi volantami a sadou pedálov pre každé koleso zvlášť ....

Chyba je teda úplne na začiatku celého konceptu.

Celý koncept má svoju logiku a je dobre prepracovaný, ale základná téza, od ktorej sa odvíja, je chybná. GUI má spúšťať aplikácie, NIE SNAŽIŤ SA NAHRADIŤ ich funkcionalitu. To proste nejde, každá aplikácia je špecifická svojou štruktúrou a spôsobom, akým manipuluje s dátami. Nedá sa napísať GUI, ktorý nahradí rovnako dobre Oracle, AutoCad, ProTools, DreamWeaver, MS Office, Photoshop atď ... Vývoj GUI by sa mal snažiť práve to spúšťanie aplikácií čo najviac priblížiť človeku.

Sorry, nechcel som sa ťa dotknúť ani sa vysmievať. Iste si tomu konceptu obetoval hodne času a to si treba vážiť. Len sa tú vec snažím podrobnejšie analyzovať z hľadiska použiteľnosti.

[Adrin]

Děkuji za obsáhlou reakci - tak většinou začínají komentáře, které se vbrzku pokusí cosi vyvrátit - i já tak budu pravděpodobně pokračovat, ale Vašeho názoru si opravdu cením.

Začal bych asi kontra metaforou: Lidé zřejmě potřebují co nejjednodušší a nejúčinnější nástroje na práci, ale každý nástroj si žádá své a chce to porozumět mu a mít dost šikovnosti na jeho používání. Tak to je, ať už se jedná o sochaře, chirurga, hudebníka nebo třeba účetního. Počítač v jistém smyslu je takovým nástrojem . Vlastně spíš metanástrojem, opravdovým nástrojem je až spuštěná aplikace. Jenže jaký je aplikace nástroj? Zůstaneme-li u zmíněného sochaře, potom je aplikace nejen dlátem a kladivem, ale i samotnou sochou a i samotným sochařem. Můj koncept se snaží tyto tři části oddělit. Model je socha. Okno je umělcův pohled na sochu. Editor je nástroj. No a uživatel je potom oním umělcem.

Nemyslím si, že by pro uživatele bylo až tak obtížné tyto věci rozlišit a pochopit, protože korelují se zažitou skutečností. Tím bych odpovídal na vaši výtku, že se toto GUI snaží nahradit funkcionalitu aplikací. Nesnaží. Funkcionalita zůstává v kompetenci editorů. A pokud jde o způsob náhledu je třeba „pouze“ dobře vyvážit, jak mnoho druhů oken bude k dispozici a nad kolika modely se bude pracovat. Zobrazení oken se nemusí rozpadat až na prvočinitele (body obrazu), ale může zůstávat v racionálním přiblížení (zřejmě se tím porušuje jistá schematičnost, ale koncepci hloubky rozpadu modelu na komponenty jsem nikdy neměl zcela ujasněnou).

V problematice editování více vstupních modelů bych kontroval tak, že editor sám si určuje kolik vstupních modelů a kolik výstupních umí zpracovat a editování těchto modelů je opět v režii editoru. Jediné co udělá funkční okno je, že zobrazí vstupní modely například jako obdélníky o délce, která odpovídá třeba času. V původním textu bylo toto myslím také zmíněno (někde :)). Stav v jakém se vůči sobě budou vstupní modely nacházet a stav jakýchkoli efektů, jež se na ně použijí, je také model. Model kompozice a to buď textu, hudby, videa nebo všeho dohromady.

Audiostřižny jako Cubase nebo Ardour nebo jakékoli programy s téměř herním GUI jsou podle mě z hlediska ovládání předimenzované a často zbytečně imitují reálné přístroje. Pro hudebníky je asi snazší se je naučit, ale počítač by mohl jejich koncepci pravděpodobně velmi zjednodušit.

[Predator]

Osobne si fakt neviem predstaviť program, ktorý nahradí všetky ostatné, a k tomu ich nahradí na sto percent. To je jednoducho nonsens. Je to asi, ako keby som chcel konštruovať auto, ktoré bude excelovať v teréne aj na diaľnici. To proste moc dobre nejde. A ak celú funkcionalitu majú zabezpečovať editory, tak potom to vlastne už máme - systém, GUI a aplikácie, akurát terminológia je iná. Nehovoriac o tom, akú haldu "editorov" (teda aplikácií) by musel v sebe mať ten systém... to je fakt plytvanie priestorom na disku a výpočtovým výkonom.

K tým audiostrižniam - nemyslím si, že ich ovládanie je prehnané a zbytočne komplikované. Potiaž je v tom, že práca so zvukom je tak sofistikovanou záležitosťou, že ak má ten systém vyprodukovať perfektný výsledok, tak musí existovať celá hromada možností, ako s tým zvukom pohnúť, a musia byť jednoducho pochopiteľné a intuitívne. Pritom každá tá možnosť musí byť kedykoľvek modifikovateľná a reverzibilná, aby trebárs v prípade, že pridáš hall na spev, potom urobíš desať iných vecí a zistíš, že toho hallu treba dať o 3 dB menej, aby sa nebil s inými nástrojmi, sa to dalo urobiť a prípadne aj vrátiť späť, a to jednoduchým úkonom ...tam proste nemáš čas rozmýšľať, ako to počítaču zadefinuješ, proste siahneš na šabľu a stiahneš ten hall na primeranú úroveň. Jednoduché a priamočiare, ako u analógu. To, že sa to ovládanie podobá na zvukársku techniku, nie je chyba, ale zámer a ergonomické myslenie tvorcu. Ak niečo tvorím, nemám čas piplať sa s tým, ako to donútiť spraviť počítač a kde nájsť editor, ktorý mi vie stiahnuť hall z finálneho mixu, ale jednoducho musím s tým vedieť robiť intuitívne, tak, ako keď to robím na skutočnom zariadení na koncerte.

[Adrin]

Ono ale cílem opravdu není vytvořit všeobjímající aplikaci a univerzální program. Nebo jsem to tak alespoň nezamýšlel. Cílem je především vymezit aplikacím rámec působnosti. Tedy: vnutit jim standardizovaný formát, vnutit jim standardizovaný způsob ovládání, přimět je ke vzájemné spolupráci nad modely a otevřít jejich činnost tak, aby měl uživatel možnost hlubší kontroly.

Editorů by určitě nebylo málo, ale rozhodně by jich nebylo o moc víc, než kolik je nyní aplikací. Zkrátka editor je stále skrytá aplikace, ale zkrocená :)

Je jistě možné představit si velmi specifickou třídu úloh, se kterou by si tento koncept neporadil. Pravděpodobně takové, kde se model prolíná se způsobem editace a pohledu na něj. Například právě herní GUI. Realtimeové záležitosti, kde se model rychle mění a kde způsob editace a zobrazení závisí na stavu modelu. Práce s počítačem postavená na bázi událostí by ale měla být tímto GUI s funkčními okny řešitelná (jde o pouhý neodborný odhad :)).

A ještě k audiostřižnám. Nejsem v tom nijak zběhlý, Cubase jsem zkoušel jen jednou a poté co jsem otočil nějaký panel a viděl motanici drátů vzadu, jsem to vzdal :). Čili možná (a asi to tak bude) opomíjím jistá hlediska. Chtělo by to vzít aplikaci za aplikací a zkusit navrhnout a hlavně vyzkoušet jak by se dalo jejich ovládání transformovat do FW.

[Predator]

To, čo má vzadu "motanicu drátov", nie je Cubase, ale Propellerhead Reason ... a s jeho ovládaním je to asi fakt trochu prehnané. Neprišiel som mu na chuť. Ja používam ProTools LE 6.9 a motorizovaný pult s integrovaným AD/DA prevodníkom Digi002.

[Adrin]

To bude asi on. Já jsem dělal víc jen s Fruity Loops a už to mi stačilo :)

[Jiří Daněk]

GUI, které se nemusím učit je takové, se kterým jsem se už zžil.

[Adrin]

A ještě jedna taková... no taková věc. Jestli jste si všimli v ilustračním obrázku toho vymyšleného GUI je v levém horním rohu oken takový ovladač (trojúhelníky, čtverečky a kolečko). Když jsem to kreslil, tak jsem nevěděl, jak by měla být vyřešena minimalizace a maximalizace oken a tak vzniklo toto.

Funguje na stisknutí, ale i na mouse gestures. Prostě když to okno v tomhle místě chytíte a rychle s ním mrštíte v nějakém směru, tak ono se zmenší do ikony nebo náhledu a přilepí se na okraj obrazovky.

[Miroslav Prymek]

Paradni napad!

[Adrin]

Myslíte mouse gestures na minimalizace, nebo obecně celý článek? :) I kdyby se projekt jako celek neujal, obsahuje hodně nápadů, které, podle mě, rozhodně nejsou k zahození. Koketoval jsem s myšlenkou, část těch nejelpších nápadů ralizovat alespoň na úrovni desktopu pro X window, ale jen chvíli, než jsem zjistil, kolika věcem vlatně nerozumím :)

[Hark]

Clanek je zajimavy a podnetny, diky. Nesoudim vsak, ze je globalne realizovatelny jinak nez jako akademicky projekt, popr. maximalne do soucasne urovne projektu Plan9.

Trochu odbocim:

--------------------

Jsem presvedcen ze idealni forma lidske komunikace je pouziti slov - jazyka. Z toho logicky plyne, ze nejlepsi interface mezi nastrojem a clovekem, ktery jsem poznal, je prikazova radka.

V prikazove radce se clovek pouze uci jazykum - a diky tomu si rozsiruje a pretvari mysleni. Je to vec, na kterou jsme zvykli - dorozumet se s lidmi mluvicimi jinymi jazyky.

GUI-only interface nikdy nepostihne takove spektrum moznosti jako konzole. Podobne jako znakova rec hluchonemych ma naprosto odlisnou kvalitu od bezne reci hovoricich lidi.

Interface mezi pocitacem/nastrojem a clovekem by IMHO mel bych schopen plne vyuzivat kapacitu lidskeho nejvetsiho vynalezu - jazyka, myslenky.

Tozn. mys nemuze nahradit klavesnici, stejne jako krumpac nemuze nahradit jehlu. Jsou to separovane nastroje. Ale klavesnice ma nekonecno vyrazovych prostredku, coz se o mysi rici neda [pokud s ni nekreslim pismena a slova nebo znakovou rec].

Troufnu si zaprorokovat, ze klavesnici /a mys/ nahradi az interface neuralnich snimacu, ktery bude monitorovat mozkove povely a prekladat myslena slova - zase do textu.

Mys (ukazovatko) uz je skrze neuralni interface implementovana.

-----------------

A ted se vratim

-----------------

Otazkou je jak (a jestli vubec) vizualizovat proud slov a vyznamu a jake potom vytvaret nastroje/programy ovladatelne primo mozkem. Jake UI delat pro ovladani slovy, myslenkami? To je totiz urcite rychlejsi nez ukazovatko, ktere by se dalo simulovat treba mozkovymi prikazy pro pohyb prstu. Prilisna vizualizace vytvari vrstvy, ktere postupne znepruhlednuji funkcionalitu, kterou mozek vnima SLOVY. Hezkym prikladem jsou ikonky - ikonka mi nerika vubec nic o funkci, na kterou je namapovana. Je pouze ZKUSENOST, ze podobne ikonky mely kdysi podobnou (slovo) funkci (udelej tluste pismo od-do) ...

[Adrin]

Co říkáte, zní zajímavě a vyvolává to řadu otázek a asociací. Ovládání počítačů (programů) hlasem či obecněji lidským jazykem má jistě ohromný potenciál. Stačí vzpomenou Star Trek :) Ovšem nesouhlasil bych úplně s tím, že je jazyk nejefektivnější formou komunikace.

Vím, že pravděpodobně uvažujete jazyk spíš jako proud čistých myšlenek (jak bych tak řekl raw myšlenek), než jako slova a zvuky. Ale ani v tomto případě si nejsem jist, zda-li v lidském mozku proudí jen myšlenky formulované do jazyka.

Existuje teorie (která je mimochodem velice zajímavá), jež dokazuje, že jakémukoli jazyku se nelze naučit bez původní znalosti několika základních asociací mezi slovem a myšlenkou. Čili že člověk se rodí s jakousi základní bootovací výbavou pro další výuku jazyka. Kdyby jeho mozek tyto prvotní vzorce neobsahoval, nebylo by pro něj možné se naučit jakýkoli jazyk. (Doufám, že jsem to řekl srozumitelně a alespoň trochu správně).

Ale to všechno neznamená, že by myšlenky měly mít výlučně formu jazyka. Řekl bych, že častěji jsou reprezentovány jako obrazy. Do spekulace, jak to vlastně je, bych se nerad pouštěl. Ovšem jsem-li spisovatel, je to jazyk, co mi dovoluje se nejlépe vyjadřovat. Jsem-li ale malíř, potom je to obraz, kterým dovedu nejlépe vyjádřit své myšlenky a pocity. Matematik potřebuje vidět čísla a grafy, návrhář zase modely a tak dál.

Také se říká se, že jeden obraz vydá za tisíc slov. A v moderní komunikaci lidí převažují grafy a schémata. Jazyk je nejobecnější, ale neřekl bych, že nejefektivnější formou komunikace.

A zase zpět :)

Dovedou-li ony neurální skeny rozpoznat myšlenky, potom se asi stanou nejlepším možným rozhraním. Ale současně s tím si počítače uzurpují velkou část běžné reality (to nemusí být vždy úplně dobře, ale ani špatně). Ke studiu doporučuji Ghost in the Shell, který je takovou studnicí moudrostí o spojení člověka a počítače.

UI, které by potom počítač využíval, by asi pravděpodobně bylo nějakým simulátorem. Nevím. :)

[Hark]

Ovsem, jazyk a slova chapu jako komunikacni protokol mezi lidmi navzajem. Jakysi interface, ktery sice nevystihuje plne vnitrni obraz cloveka, ale dokazeme se na nem shodnout.

O co mi slo predevsim, ze ukazovat na obrazky zvlada po kratkem zaskoleni i male dite nebo opice. Pokud vladnu nastrojem - jazykem, reci, mohu ji brousit, cvicit a aplikovat prave skrze dalsi nastroj - pocitac. To me pak jako bytost muze posouvat dal, rozvijet. Synergie nastroju.

Idealni interface asi dokaze plne vyuzit vsech smyslovych bran do vedomi a take toku myslenek - slov (abstrakci). Takovy interface bude pravdepodobne metamorfni - prizpusobi se svemu uzivateli, nebo naopak uzivatel si jej prizpusobi svym pozadavkum, aby se v nem citil dobre. [Napriklad linuxovy desktop...ktery vypada temer u kazdeho uzivatele uplne jinak.] Muj nastroj je expresi mne sameho.

Takze ne pouze slova, ale slova jako zaklad a cokoli predstavitelneho jako rozsireni. Coz je paradigma prikazove radky / konzole jako zakladu pro reseni komplexnich a jazykove definovatelnych uloh a GUI nadstavby na ukoly, ktere lze jednoduseji vyresit ukazovatkem.

[Adrin]

Tohle povídaní je čím dal zajímavější, ale stále mi připadá, že musím oponovat.

Začal bych citací (i když už nevím koho cituji): pro uživatele je vždy snazší ukázat na to, co vidí a nikoli napsat, co si pamatuje. Grafické rozhraní (i s primitivním ukazovátkem) je mocným nástrojem právě proto, že kombinuje vizualizaci, interaktivitu a nápovědu v jednom.

Je to takové stavové prostředí, kde uživatel nemůže dělat všechno, ale pouze to, co je mu v onom stavu přístupné a uživatel to i vidí. Než nastane stav C, musí nastat stavy B a A. Uživateli sice dopředu není řečeno, jak se ze stavu A dostat do stavu C (musí to umět a nebo mu pomohou různí průvodci – ideální desktop by tohle měl zvládat bez průvodce), ale rozhodně se nestane, že uživatel použije nástroje, které jsou v aktuálním stavu irelevantní a nebo dokonce nebezpečné (opět by ideální grafický desktop tohle měl zaručit).

Grafické rozhraní je ale také svým způsobem myšlenková mapa. Takový šmírák. Programově datové (řekněme objekty) jsou vizualizovány a lze s nimi manipulovat a kombinovat je. Text je například list papíru a adresář šanon. Přesunutím jednoho listu papíru na jiný list papíru, vzniknou dva sešité listy :) a přesunutím dvou sešitých listů do šanonu jsou listy zařazeny a archivovány. Bez možnosti interakce a vizualizace, uživatel jen málo ví o tom, co se vlastně stalo (v ideálním desktopu by měl vždy vědět, co se děje). Myšlenková mapa je viditelné a pochopitelné rozmístění objektů na jakési ploše, kde má uživatel rozpracovánu svou práci. Vidí pak věci a souvislosti, které by jinak vidět nemohl a napadají ho kombinace, které by ho jinak nenapadli (ovšem v ideálním desktopu :)).

Netvrdím, že to nejde i jinak (v současnosti to vlastně takhle ani moc nefunguje), ale prosté asociace „obrázek papíru – text“ „pracovní plocha – stůl“ jsou vždy přívětivější (ergonomičtější), než abstrakce, ať sebevíc progresivnější.

Příkazová řádka je právě takový progresivní nástroj. Její výhody a klady asi nemusím příliš zdůrazňovat, ovšem já sám ji moc nepoužívám, protože často zapomínám příkazy (zapomínám i obyčejná slova a proto tak hustě používám ta nevšední – nevím proč, ale to je teď vedlejší :)). Jde prostě o to, naučit se nový slovník a novou gramatiku a navíc naučit se rychle psát na klávesnici. Dennodenním používáním se člověk s novým jazyk sžije a dokáže věci dělat rychleji a efektivněji, než přes grafická klikátka.

Ovšem jen do určité míry a pouze v některých oborech použití. Jak jste psal minule – oboje má svoje místo.

Do doby, než nám počítače budou rozumět bez toho, abychom se my museli učit mluvit (nebo psát) tak, aby rozuměli ony, je jazyk jako komunikační prostředek mezi počítačem a člověkem rozhraním úzkého spektra uživatelů. A i potom bude obtížné zkombinovat mluvení s vizualizací a interakcí. Než abych složitě vyjadřoval svojí představu jazykem, radši vezmu pero a tablet a několika kroužky a čarami vytvořím schéma, ve kterém se budou snadno orientovat i ostatní (včetně počítače) a navíc budu při jeho výrobě konfrontován s logikou věci, která mě donutí tvořit podle pravidel. Umím si představit, že v jazykovém rozhraní vznikne mezi mnou a počítačem složitý a dlouhý dialog o tom, proč takhle to jde a takhle zase ne.

Stručněji řečeno, když už jazykové rozhraní, potom s jasnou vizualizací jako odpovědí. Nemyslím si, že počítače budou kdy tak odpoutány od reality, aby se nesnažili realitu simulovat, nebo aby vnesly do významu slov víc, než může být zobrazeno.

Dovedeno k extrému: abstrakce, která by jedince obklopila tak, že by z počítače učinila jeho další orgán, jež by byl absolutně specializovaný na nějaký účel, nebo činnost, je velmi diskutabilním a současně absurdním tématem.

Jazyk sám hovoří o reáliích a jejich vztazích. Není něčím, co by nám dovolovalo vyjádřit něco nadskutečného. Vždy se sice ohne k potřebě konkrétního oboru, ale nikdy není logickým obalem pro ten samotný obor (snad jedině v případě filosofie a rétoriky a někdy i psychologie :)). Vizualizace naopak bývá velmi silným nástrojem pro korekci myšlenek.

Grafické rozhraní (schémata) se dopředu snaží říci, co je a co není možné. Zatímco jazykové rozhraní toto říká až zpětně a gramatika pomůže pouze z části (asi proto, že nenese logiku věci, ale jen logiku jazyka – možná). Například: „Otevřel jsem dveře a pak jsem je odemkl.“ Gramaticky dobře – jedna činnost následuje po další. Ovšem v gramatice chybí definice vzájemnosti těchto slov. Nestačí jen spustit parser. Musí se spustit i samotné popisované dění, aby se zjistilo, že dveře nejdou otevřít. Ale je to jen příklad na gramatiku jazyka, nikoli na sílu jazyka v porovnání s vizualizací.

[NoBody]

no neni to sice uz uplne aktualni ale mrknete na tohle je to prototyp idealniho desktopu -> http://www.youtube.com/watch?v=M0ODskdEPnQ nebo sem www.bumptop.com

[Adrin]

Aktuální to je :) Několik projektů zaměřujících se na GUI a ovládání počítače, jsem shrnul v tomhle článku: http://kf.hocke.eu/budoucnost-ovladani-pocitacu/ a Bumbtop tam je.

Jenže z několika důvodů si nemyslím, že by měl úspěch. Líbí se mi dotyková živá gesta, která používá. Ale pracovní 3D plocha je něco, co mělo přijít už dávno a nahradit 2D plochu, nyní je už poměrně pozdě. Existují abstraktnější pohledy na okna (či objekty) a jejich vztahy a propojení v počítači. To, jak se prostorové rozmístí už nepřínáší až tak moc užitku. Ale možná se mýlím :)

Samotná funkční okna jsem rozvinul zde: http://adrin.ic.cz/Wiki/index.php?n=GUI.GUI Výsledný koncept říká jen málo o tom, jak co zobrazovat a ovládat. Naopak říká hodně o tom, jak okna a objekty propojovat a transformovat. Takže i funkční okna by mohly být 3D.