15. 2. 2017

META Web #1: Manifest

Úvod do konceptu technologie META Webu.

Už ani nevím, kdy to začalo. Před pár lety, když jsem začal vyvíjet “informační systém” pro naši firmu (který byl ovšem od té doby asi tak 10x předělán od piky, než spatřil světlo světa), vnímal jsem spoustu zbytečné práce při vývoji webových aplikací. A od té doby jsem to vnímal čím dál tím více, až se před skoro dvěma roky zrodila myšlenka META Webu, kterou jsem v soukromí rozvíjel až do dnes, kdy jsem se rozhodl tento koncept pustit do světa.

A co je vlastně META Web?

META Web je koncept webové technologie definující univerzální API protokol a jazyk pro tvorbu uživatelských rozhraní, který má za cíl nahradit dnešní způsob, jakým se vytvářejí webové aplikace a to globálně.

A teď trochu laicky a pak podrobněji. Ale ještě předtím vám chci popsat svou motivaci a důvody, proč jsem toto začal vytvářet.

#Problémy dnešní doby webu

Jako vývojář webových stránek a aplikací vnímám následující zásadní problémy, které mě neustále provázejí.

#Různorodé a nečitelné API - jazyk aplikací

Ruzné aplikace a webové služby mezi sebou komunikují pomocí aplikačních rozhraní - API. Existuje mnoho protokolů (JSON, XML) a způsobů komunikace (REST, RPC). Ovšem pokud chceme integrovat dvě aplikace mezi sebou, musíme dodržet jejich RŮZNÉ protkoly a nastudovat dokumentaci, abychom pochopili, jak fungují.

Je to takový babylonský problém. Určitě jste už slyšeli ten příběh, jak bůh nás lidi potrestal tím, že každý národ mluví jiným jazykem - viz Babylonská věž. A komunikace mezi aplikacemi je to stejné, každá mluví v podstatě jiným jazykem a je potřeba “slovníků”, aby se efektivně domluvily. Ajťáci mi prominou tento laický výklad.

Konkrétně má každá aplikace ruzný přístup k datům, různý způsob volání metod, strukturu dat, datové typy a mohl bych pokračovat. Vývojáři poté musí psát specifický kód téměř pro každou službu, kterou chtějí integrovat.

Poznámka: určité standardy již samozřejmě existují, ale zaměřují se na velmi specifické oblasti - např. OAuth

#Náročnost uživatelských rozhraní

Druhou částí většiny aplikací je uživatelské rozhraní. Tedy to, s čím se setká uživatel. Máme v dnešní době mnoho platforem - Windows, Linux, OS X, Android, iOS, apod. Každá platforma je velmi specifická a pokud chceme vytvořit aplikaci pro všechny z nich, máme jen pár možností. Použít nějaký framework, který nám umožní napsat aplikaci jednou a přeložit pro všechny platformy. A také zde máme web - technologii dostupnou na všech platformách prostřednictvím webového prohlížeče.

Mně osobně vždy nejlépe vycházelo vytvořit aplikaci jako webovou. Zde ovšem nastává dalším problém.

Webová platforma je sice univerzální a na první pohled jednoduchá, ale pokud se jí více věnujete, zjistíte, že je to docela chaos. Máme mnoho jazyků pro různé učely (HTML, CSS, JavaScript) a různé frameworky, které se nám snaží usnadnit práci (React, Angular). V tom je ale ta potíž, v tom, že práce s webovou platformou není jednoduchá a efektivní sama o sobě, ale musíme si pomáhat hromadou kódu. A do toho nám ještě vstupují další nástroje, jako jsou různé dialekty jazyků (TypeScript, CoffeeScript, LESS) a nástroje pro sestavení (build) výsledné aplikace ze všeho předchozího. Prostě mnoho povyku pro jednoduchý cíl.

A co je cílem? Cílem je vytvářet webové aplikace, které toho mají mnoho společného - navigaci, formuláře, výpisy, obrázky, textový obsah a napojení na data. A proč tedy potřebujeme desítky jazyků, frameworků a nástrojů pro něco tak jednouchého? Vždyť starý web sám o sobě (teď myslím HTML) byl vytvořen téměř za stejným účelem. V základu máme tagy pro obsah, obrázky, formuláře, tabulky… Ale to, co už nám nestačí, jsou jejich základní funkce, a proto je musíme suplovat vlastním kódem.

JENŽE dnešní frameworky pro uživatelská rozhraní mají opět téměř ty samé funkce - pokročilou validací polí, filtrování výpisů, zobrazování živých dat, komunikace se serverem pomocí API a nejlépe bez přenačítání stránky.

A na co vlastně potřebujeme design? Ty aplikace vypadají všechny téměř stejně - stejné komponenty, čistý a přehledný vzhled. Čím dál více se podobají desktopovým a mobilním aplikacím než webovým stránkám.

Malá odbočka

Dalším obecným problémem uživatelských rozhraní ať u aplikací či webových stránek, o kterém se dočtete od mnoha UX expertů, je právě jejich různorodost. Lidé nemají rádi změny. Zvykají si. Dříve bylo například zvykem, že vpravo byla vždy navigaci. Dnes mnohdy najdete u stránek primární navigaci na horní liště.

Pokud uživatelům prezentujete něco, na co nejsou zvyklí, mají problém se orientovat. Třeba starší lidé nebo lidé s určitým postižením mají problém rozpoznat tlačítko na webu, pokud nevypadá jako to výchozí systémové.

#Náročnost aplikačního vývoje a DRY

Programátoři jistě znají pojem DRY (Don’t Repeat Yourself), což v praxi znamená, že se máme snažit, abychom co nejméně kódu opakovali. Tím se dosáhne efektivnější práce a hlavně přehlednosti kódu.

Jak ale vypadá realita? Vezměme si třeba jednoduchou aplikaci na správu kontaktů - takový adresář. Obsahuje jednotlivé záznamy - kontakty. A každý kontakt má určité položky - jméno, příjmení, adresu, email, telefon, apod. Taková aplikace se skládá z následujících částí:

Databáze - u klasické aplikace máme databázi, ve které jsou záznamy uložené a kde je definována tato struktura, tedy jednotlivé položky kontaktu.
Aplikační server - dále máme aplikační server, který nám zajišťuje komunikaci mezi databází a webovou aplikací, plus může přidávat nějakou tu logiku. Ale hlavně zde řešíme validaci jednotlivých požadavků. Tedy, když uživatel (nebo i útočník) pošle neplatná data, tak musíme vrátit chybu.
Webová / mobilní aplikace - uživatelské rozhraní, ve kterém máme výpis kontaktů, jejich zobrazení a formuláře pro přidání nového nebo editaci stávajícího kontaktu.

Co mají všechny tři části společného? Definici položek kontaktu. V každé části musíme do kódu vypsat zpracování všech položek. Musíme je definovat v databázi, musíme je definovat na aplikačním serveru a musíme je definovat a zobrazovat v uživatelském rozhraní. Pokud tedy máme u kontaktu 6 položek, tak je musíme definovat celkem 18x na 3 různých místech.

A přitom je jejich definice všude téměř stejná. Specifikujeme název položky, její typ (text, číslo, e-mail), validační pravidla (max. délka, vzorec, formát), zda je povinná či nepovinná, zda se jedná o návaznost na jiné záznamy, apod.

Proč to musíme psát vše 3x (mnohdy i vícekrát)? Vždyť na základě jednotné definice můžeme vytvořit jak databázové schéma, validovat požadavky na úrovni aplikačního serveru, tak i vykreslit a validovat formulářová pole v uživatelském rozhraní.

Ačkoliv se všichni snažíme praktikovat pravidlo DRY, tak dnešní technologie nás ho nutí porušovat.

#Řešení? META Web

Cílem META Webu je najít řešení na předchozí a související problémy. V rámci konceptu definuji následující prvky:

META API - cílem je definovat jednotné a univerzální API pro komunikaci mezi webovými službami a též mezi uživatelským rozhraním a serverem.
META UI - cílem je definovat univerzální jazyk (podobný HTML), který umožní efektivní tvorbu uživatelských rozhraní bez nutnosti porušovat pravidlo DRY a bez nutnosti používat různé frameworky a balasty přebytečného kódu.
META Script - cílem je vytvořit jednoduchý funkcionální skriptovací jazyk ve stylu např. vzorců v Excelu, který umožní dynamické vyhodnocování dat na úrovni META UI.
META Dictionary - cílem je definovat seznam (slovník) standartně použivaných typů objektů a vlastností, může vycházet ze schema.org.

#META API

Jednotný protokol META API si klade za cíl definovat univerzální způsob, jakým popisovat webové služby. A tím zajistit možnost efektivní komunikace mezi aplikacemi a vyhnout se tím babylonskému problému.

Protokol v rámci webové služby popisuje jednotlivé zdroje (resources), jejich vlastnosti, schopnosti a metody.

Samozřejmě již existují podobné projekty - Swagger, WSDL, Hydra nebo JSON-LD. Ale vidím v nich různé problémy a nezapadají do konceptu META Webu.

META API musí být určitým způsobem striktní. Zvolil jsem JSON pro výměnu dat a je inspirováno metodologií REST.

META API v podstatě definuje formát pro výměnu dat - kolekce a objekty. Ale navíc přidává popisnou složku, která ve strojově čitelné podobě popisuje daný zdroj webové služby.

Cílem je tedy:

Definovat způsob výměny dat
Definovat způsob popisu vlasností a schopností zdroje webové služby

#META UI

Jednotný jazyk META UI má za cíl umožnit efektivní a jednoduchý způsob, jak vytvářet uživatelská rozhraní webových aplikací, a to multiplatformě.

META UI definuje vždy konkrétní pohled (view) aplikace. Tedy například výpis kontaktů či detail kontaktu. Dále přidává navigační vrstvu, ale o tom až jindy.

Pohled v META UI definuje:

Datové zdroje - tedy odkud načíst data a kam je případně uložit
Visuální komponenty - jak data zobrazit

Na tom není nic tak zvlášního, až na to, že komponenty by měly splňovat požadavky aktuální doby a odpadne tím nutnost používat knihovny či komponenty programovat ručně.

Síla ovšem přichází v propojení s META API. Pokud definujeme propojení s datovým zdrojem META API, znamená to též, že máme k dispozici popis daného zdroje. Tedy u kontaktu od serveru víme, že má jméno, příjmení, email, jakého jsou datového typu a jaká mají validační pravidla. Prohlížeč tedy v tu chvíli ví, jaké položky má zobrazit, jak je pojmenovat, jak je má validovat, a nebo podle jakých položek lze filtrovat výpis.

V META UI tedy již nemusíme jednotlivé položky znovu definovat, maximálně určíme jejich rozložení. Pokud tedy na serveru přidáme telefoní číslo nebo změníme podmínky pro zadání jména, změny se automaticky promítnou do uživatelského rozhraní a všech dalších propojených aplikací bez nutnosti vše přeprogramovat ručně.

Dále zná prohlížeč akce, které lze se zdrojem provádět. Ví, jak zobrazit titulek stránky, jaké jsou další návaznosti, to vše z datového modelu popsaného pomocí META API.

Pozor: META UI nepočítá s ničím podobným jako je CSS, visuální podoba je čistě v roli prohlížeče, programátor specifikuje jen prvky a jejich rozložení. Což umožní to, aby byl vzhled co nejvíce přizpůsoben visuálu dané platformy. O tom ještě níže.

Nyní praktická ukázka - neprogramátoři mohou přeskočit.

#Praktická ukázka

Uvedeme si praktickou ukázku na výše zmiňovaném příkladu s adresářem.

Jedná se jen o ukázku, reálný koncept je rozvinutější a stále dost živý!

#Webové služby - META API

Webová služba nám na bude poskytovat následující zdroje. Uvádím ukázkové URL adresy, HTTP metodu, požadavek a odpověď.

#OPTIONS /contacts

Kolekce kontaktů. Popis definuje uživ. název zdroje a jednotlivé položky záznamu. Dále akce, které můžeme s kolekcí provádět.

1 2	Response: Content-type: application/json+x.metaapi

{
	"@doctype": "meta.schema",
	"type": "meta.collection",
	"title": "Kontakty",
	"record": {
		"first_name": {
			"type": "meta.text",
			"label": "Jméno",
			"required": true,
			"maxLength": 128
		},
		"last_name": {
			"type": "meta.text",
			"label": "Příjmení",
			"required": true,
			"maxLength": 127
		},
		"email": {
			"type": "meta.text.email",
			"label": "E-mail",
			"required": false,
			"maxLength": 255
		}
	},
	"filters": [ "first_name", "last_name", "email" ],
	"methods": [
		{
			"method": "GET",
			"label": "Načíst záznamy"
		},
		{
			"method": "POST",
			"label": "Vytvořit záznam",
			"primary": true
		}
	]
}

#GET /contacts?offset=10&limit=2

Vrátí záznamy v kolekci.

1 2	Response: Content-type: application/json+x.metaapi

{
	"@doctype": "meta.collection.records",
	"records": [
		{ "@id": 1, "first_name": "John", "last_name": "Doe", "email": "[email protected]" },
		{ "@id": 2, "first_name": "Jack", "last_name": "Doe", "email": "[email protected]" }
	],
	"offset": 10
	"count": 42
}

#POST /contacts

Vytvoří nový záznam v kolekci.

Request:
Content-type: application/json

{
	"first_name": "Jiří",
	"last_name": "Hýbek",
	"email": "[email protected]"
}

Response:
Content-type: application/json+x.metaapi

{
	"@doctype": "meta.response.collection",
	"type": "success",
	"message": "Kontakt byl úspěšně přidán.",
	"record": {
		"@id": 3,
		"first_name": "Jiří",
		"last_name": "Hýbek",
		"email": "[email protected]"
	}
}

#OPTIONS /contacts/2

Záznam kontaktu. Popis definuje uživ. název zdroje a jednotlivé položky záznamu. Dále akce, které můžeme se záznamem provádět. Všiměte si interpolace u titulku, která prohlížeči umožní zobrazit název dynamicky v závislosti na datech.

1 2	Response: Content-type: application/json+x.metaapi

{
	"@doctype": "meta.schema",
	"type": "meta.object",
	"title": "#{first_name} #{last_name}",
	"parent": "/contacts",
	"previous": "/contacts/1",
	"next": "/contacts/3"
	"properties": {
		"first_name": {
			"type": "meta.text",
			"label": "Jméno",
			"required": true,
			"maxLength": 128
		},
		"last_name": {
			"type": "meta.text",
			"label": "Příjmení",
			"required": true,
			"maxLength": 127
		},
		"email": {
			"type": "meta.text.email",
			"label": "E-mail",
			"required": false,
			"maxLength": 255
		}
	},
	"methods": [
		{
			"method": "GET",
			"label": "Načíst záznam"
		},
		{
			"method": "PUT",
			"label": "Uložit záznam",
			"primary": true
		},
		{
			"method": "DELETE",
			"label": "Smazat záznam"
		}
	]
}

#GET /contacts/2

Vrátí záznam z kolekce.

1 2	Response: Content-type: application/json+x.metaapi

{
	"@doctype": "meta.object",
	"first_name: "Jack",
	"last_name": "Doe",
	"email": "[email protected]"
}

Poznámka 1: to, že je jsou jednotlivé položky definovány jak u kolekce, tak u záznamu, je z toho důvodu, že položky vytvořeného záznamu s dynamickým schématem se mohou lišit od položek vrácených z kolekce.

Poznámka 2: ještě je potřeba vyřešit situaci, kdy se vlastnosti nutné pro vytvoření záznamu v kolekci budou lišit od vlastností, které vrací kolekce. Toto by šlo řešit např. vytvořením nového zdroje jen za účelem vytváření položek a na tento zdroj odkázat v definici akcí, což ale porušuje principy REST. Nápady jsou vítány.

Poznámka 3: server při vracení schématu rozhoduje o tom, které akce povolí, takže pokud je kolekce jen pro čtení, nevrátí akci pro přidání nového záznamu.

Aktualizace záznamu či jeho smazání je řešeno klasickým způsobem, jako je tomu u příkladu s vytvářením záznamu a jak je zvykem u RESTu, takže jej zde nebudu popisovat.

#Uživatelské rozhraní

V rámci uživatelského rozhraní potřebujeme definovat výpis kontaktů a zobrazení / editaci.

#GET /list.meta

Výpis kontaktů.

1	Content-type: application/xml+metaui

<?xml version="1.0" encoding="UTF-8"?>
<meta-ui>
	<link rel="nav" src="/nav.meta" />
	<datasource id="collection" src="/contacts" />
	<collection datasource="@collection" filters="true" />
</meta-ui>

Nebo můžeme specifikovat jen některé položky, které chceme vypsat a zároveň říci, jak zobrazit detail záznamu.

<?xml version="1.0" encoding="UTF-8"?>
<meta-ui>
	<link src="nav" src="/nav.meta" />
	<datasource id="collection" src="/contacts" />
	<collection datasource="@collection" filters="true" export="selection:$selection">
		<property name="first_name" label="Jméno" />
		<property name="last_name" /><!-- popisek je prevzat z datoveho zdroje -->
		<link rel="detail" src="/detail.meta?id=#{id}" /> <!-- interpolace predava vlastnost 'id' zaznamu do adresy -->
	</collection>
</meta-ui>

#GET /detail.meta?id=2

Detail kontaktu.

1	Content-type: application/xml+metaui

<?xml version="1.0" encoding="UTF-8"?>
<meta-ui>
	<link rel="nav" src="/nav.meta" />
	<datasource id="record" src="/contacts/${id}" />
	<!-- polozky jsou automaticky zobrazeny podle datoveho zdroje -->
	<fields datasource="@record" />
</meta-ui>

Nebo můžeme specifikovat rozložení jednotlivých položek.

<?xml version="1.0" encoding="UTF-8"?>
<meta-ui>
	<link rel="nav" src="/nav.meta" />
	<datasource id="record" src="/contacts/${id}" />
	<group title="Personal">
		<field name="@record.first_name" />
		<field name="@record.last_name" />
	</group>
	<group title="Contact" scope="@record">
		<field name="email" />
	</group>
</meta-ui>

Poznámka: pokud je záznam jen pro čtení (neposkytuje metodu PUT), pole se zobrazí jako text, v opačném případě jako vstupní pole s validací dle datového zdroje.

#GET /index.meta

Můžeme také vytvářet komplexní dynamická rozložení pomocí embedování. Toto je příklad, kdy se nám vlevo (na desktopu) zobrazí seznam záznamů a vpravo detail vybraného záznamu.

1	Content-type: application/xml+metaui

<?xml version="1.0" encoding="UTF-8"?>
<meta-ui>
	<link rel="nav" src="/nav.meta" />
	<layout-sidebar>
		<aside>
			<embed src="/list.meta" id="list" />
		</aside>
		<main>
			<embed src="/detail.meta?id=#{@list.selection}" />
			<!-- id je prevzato z exportovane hodnoty komponenty kolekce z pohledu vypisu -->
		</main>
	</sidebar>
</meta-ui>

#GET /nav.meta

Nakonec příklad navigačního manifestu aplikace, který definuje navigační strukturu, kterou lze zobrazit například po straně prohlížeče jako navigační strom.

1	Content-type: application/xml+metaui

<?xml version="1.0" encoding="UTF-8"?>
<meta-nav>
	<title>Moje aplikace</title>
	<link src="/index.meta" label="Adresář" icon="/media/addressbook.svg">
		<!-- pod polozka seznamu, label si prohlizec muze nacist dynamicky -->
		<link src="/list.meta" />
	</link>
</meta-nav>

Poznámka: META UI nenahrazuje HTML, HTML je skvělý jazyk pro formátování textu a je plánováno jeho využití právě pro tento účel, avšak bez skriptů a CSS.

#Využití

Využití této technologie vidím ve všech oblastech webových i moblních aplikací včetně prezentačních webových stránek.

#Webové aplikace

U tohoto bodu se snad nemusím rozepisovat. Webové aplikace jsou převážně tvořeny výpisy a formuláři.

#Webové prezentace

Webové prezentace se v dnešní době mnohdy bliží svou formou i vzhledem k aplikacím. Vždyť i takový blog nebo e-shop je formou aplikace, která prezentuje data a umožňuje uživatelskou interakci.

Zde ovšem narazíme na problém designu a marketingu, o tom níže.

#Webové služby

Jak jsem již zmiňoval u popisu META API. Webové služby mezi sebou dnes stále více komunikují, ať je to přihlašovní se na weby pomocí Facebooku nebo komunikace jednotlivých aplikací v rámci firemní IT infrastruktury, což je s popularitou microservices stále aktuálnější.

META Web by umožnil jednotnou komunikaci mezi těmito službami.

#IoT - internet věcí a embedded zařízení

Tady se trochu pozastavím. Možná stále více slýcháte termín IoT. A je to tím, že přibývá stále více “chytrých” zařízení, které jsou připojeny k internetu.

Vezměte si, že si domu koupíte termostat a výrobce jeho ovládání postaví na META Webu. Tím získáte následující:

Desktopovou aplikaci
Mobilní aplikaci
Možnost ovládat termostat pomocí vlastní aplikace

A to vše bez nutnosti cokoliv instalovat nebo studovat nějakou dokumentaci.

To samé platí nejen pro termostaty, ale i domáci routery, úložiště nebo ovládání chytrého domu.

#Offline aplikace

Dnes máme standardy umožňující práci s webovými aplikacemi offline, hlavně v mobilech a tabletech. I META Web s tím počítá. Výhodou je opět META API, které definuje specifikaci pro datové zdroje, což by umožnilo efektivní synchronizaci dat.

#Kritika, úskalí a FAQ

Mnoho lidí z oboru se do mě určitě bude chtít pustit, a proto bych rád některé veci osvětlil.

#Proč nepoužít stávající webové technologie? Třeba webové komponenty…

Z jednoho prostého důvodu - a to je výkon. Představte si, že celý ten kód nutný pro vykreslení uživatelského rozhraní META UI napíšete též jako webovou aplikaci pomocí HTML, CSS a JS. A pak to zkuste otevřít na průměrně výkoném moblu. Aha! Ono se to načítá pomalu a ono se to seká. Nehledě na to množství kódu, co se musí načíst.

Jsem například zastáncem psaní mobilních aplikací pomocí webových technologií (do příchodu META Webu), máme na to skvělé knihovny a frameworky. Ovšem oproti nativní aplikaci to bude vždy pokulhávat, už jen z důvodu, kolik kódu se kvůli tomu musí interpretovat. Bylo by to jako z bláta do louže.

Dalším argumentem, který se týká výkonu je využití v embeded zařízeních, kde ten výkon pro masivní webovou aplikaci opravdu není.

Bude tedy potřeba pro META Web vytvořit něco jako webový prohlížeč pro každou platformu. Což přináší i tu výhodu, že uživatelské rozhraní může být snadno integrováno do designu a zvyklostí dané platformy.

#Jednotný koncept nemůže obsáhnout všechny případy použití

Ano, bylo by potřeba vytvořit specifikace pro mnoho komponent uživatelského rozhraní, aby pojalo většinu praktických použití.

Pro velmi specifické případy se ovšem počítá s možností využít stávající webové technologie pro vytvoření samostatné aplikace, kterou půjde vložit do META UI a komunikovat s ní.

#Jak, že vývojář nemůže ovlivnit design?

Ano, META Web je zabijákem grafiků, designerů a marketérů.

Ale ne tak docela. Když se podíváte na vývoj webových stránek za posledních pár let, tak zjistíte, že poslední dobou se čím dál více používá minimalistický design a stále se stránky více podobají mobilním aplikacím. Je to trend, který bude stále silnější už jen z toho důvodu, že více a více lidí přistupuje na web přes mobil nebo tablet a záměrem UX designerů je to, aby interkace byla co nejpodobnější interakci s mobilní aplikací.

A jak se řeší design v mobilní aplikaci? Nijak přeci. Smysluplným rozložením prvků, hezkými ikonami a obrázky. Přesně to stejné by umožnil i META Web.

#To nemá šanci uspět

S tím částečně souhlasím. Jedná se o dosti futuristický a možná i utopický koncept, pokud by jeho primárním cílem bylo změnit způsob, jakým se dnes pracuje s webem. To ale neznamená, že ho nelze použít alespoň pro efektivní vývoj (nejen) business aplikací.

#Závěrem

Mým cílem je vyřešit problémy, které mě jako vývojáře pálí a v META Webu vidím cestu.

Projekt vzniká jako open-source a byl bych rád, pokud by se do jeho tvorby zapojili i další lidé z oboru. A třeba se to jednoho dne dostane mezi ty spravné lidi a rozšíří se to jako globální standard.

Osobně si myslím, že pokud to nebude META Web, tak časem vznikne podobná technologie, která bude řešit stejné problémy.

Tento článek i přes jeho délku byl pouhým úvodem do konceptu a jeho problematiky, určitě se budu časem věnovat konkrétním detailům.

Aktuálně jsem ve fázi návrhu detailů specifikace a chystám se vytvořit prototyp “webového” prohlížeče META UI, aby se dal koncept otestovat v praxi.

Chystám se brzy uveřejnit koncept konkrétní specifikace pro META API a META UI.

Pokud byste měli zájem, založil jsem fórum na adrese http://flarum.metahub.cloud/, kde je zatím možné diskutovat obecně o konceptu a později o detailech specifikací. Také chystám anglický překlad tohoto manifestu, aby se mohlo zapojit více lidí.

Nakonec ještě uvedu odkaz na starou specifikaci, kterou jsem kdysi sepsal - http://metaweb.hybek.cz/.

Tento manifest je také již dostupný v angličtině na webu projektu http://metahub.cloud/.