Nápady na add-on aplikace pro specifické segmenty

Představa jednotného rozhraní
Toto téma jsem pojal spíše jako úvahu o tom, kam by se mohl SaaS pro běžné uživatele v budoucnu vyvíjet a o jaké funkce by se mohl rozšiřovat. Vycházel jsem z představy, že současné webové rozhraní nabízející běžné služby (jak to dělá např. Google se svým Google Account, se kterým máte přístup k mnoha aplikacím různého druhu) se bude nadále rozšiřovat a bude nabalovat další a další služby, až se z něj stane jedno velké „meta-rozhraní“. To bude rozšiřitelné o nejrůznější druhy aplikací ve formě modulů, a jednou z výhod bude možná synchronizace dat mezi jednotlivými moduly.V praxi si to představuji tak, že uživatel se do tohoto rozhraní přihlásí pod jediným, jednotným ID, a bez dalšího přihlašování bude mít jednoduchý přístup do všech modulů, a to odkudkoliv (z počítače, mobilních telefonů apod.).
Jaké moduly by mělo takové rozhraní obsahovat? Rozdělil bych je do dvou kategorií – do osobních a komerčních modulů. Do osobních by patřilo například: vyhledávání všeho druhu (web - fulltext, mapy, překlad, osobní data, data ze všech modulů; komunikace – e-mail, mobilní služby (hovory, SMS..), instant-messaging (ICQ, skype..), sociální sítě; osobní „diář“ – kontakty, kalendář, úkoly; dokumenty – úložiště + editace (kancelářský SW, fotografie); multimédia – hudba, video, TV+archív (i placený); finance – přístup k bankovním kontům (přímo či přes systém jako Paypal), evidence osobních financí; navigace + lokalizační služba (např. Google Latitude); osobní úložiště; zábava a další moduly. Mezi komerční moduly by pak šlo zařadit například stravování – parametrické vyhledávání (dle aktuální polohy, klíčových slov jídla, cenového rozmezí...) v databázi stravovacích; nakupování –parametrické vyhledávání v databázi internetových obchodů, aukcí, inzerce; cestování; státní správa; kultura a další komerční služby.
Zásadní vlastností rozhraní by bylo, že do žádného z modulů by nebylo nutné se opětovně přihlašovat a moduly by mezi sebou sdílely informace, takže například po vyhledání konkrétního zboží by mohl uživatel jedním tlačítkem zboží zaplatit, z jeho ID by se automaticky načetla adresa pro doručení, které by uživatel pouze potvrdil. Tento způsob by vedl k velkému zjednodušení a urychlení mnoha běžných úkonů, což by mohlo vézt k jeho snadnějšímu rozšíření mezi masy.

Specifický segment - restaurace
Po hrubé definici „meta-rozhraní“ si můžeme zkusit případ užití pro specifický segment – restauraci. Z pohledu restaurace (majitele, zaměstnance) by nejprve bylo nutné svou firmu zaregistrovat do databáze (viz např. Firmy.cz) – po zadání adresy by se začlenila do mapy, dále by se zadala například otevírací doba, kontakt, kapacita míst, stálý jídelní lístek a podobně. Všechny tyto údaje by byly v databázi indexovány a šlo by tedy podle nich restaurace vyhledávat. Dále by šlo pravidelně zadávat například denní nabídku jídel, informaci o mimořádných událostech a akcích. Pokud by měla restaurace nějaký svůj vlastní informační systém, dala by se s databází například synchronizovat informace o aktuálním počtu volných míst na určitý čas s možností online rezervací míst, jídla by šly také online objednávat a uživatel by mohl online rovnou zaplatit. Záleželo by pak na restauraci, zda by například online platby povolila a riskovala tak například vynechání spropitného.
Z pohledu zákazníka by pak průběh vypadal tak, že by si v jednotném rozhraní našel modul stravování, v něm vyhledal restauraci (ať už podle denní nabídky, místa či jiného kritéria). V restauraci by si zarezervoval místa na konkrétní čas. Vybral by si z nabídky jídel a pití a jedním tlačítkem vše rovnou i zaplatil. Po zaplacení by se uživateli automaticky vložila nová událost do diáře, zaevidovala by se mu platba do jeho osobních financí a zobrazila by se mu navigace do vybrané restaurace (včetně aktuální dopravní situace a odhadu doby příchodu).
Výhody tohoto postupu jsou především v jednoduchosti a svižnosti celého procesu, protože by díky jednotému ID odpadla nutnost se opětovně přihlašovat či vyplňovat nějaké údaje. Nevýhody by mohly pocítit především restaurace, kdy by například v databázi byly všechny na stejné úrovni (databáze by však šla rozšířit například o hodnocení uživatelů) a nemohly by se odlišit reklamou. Dále by restaurace musely mít svůj informační systém a v případě rezervací by bylo nutné vymezit určitou část volných míst právě pro online rezervaci a určitou část pro hosty nevyužívající internet, aby nedocházelo k rozporu mezi volnými a obsazenými místy. Další problém by mohl nastat v případě, kdy by se zákazník zdržel déle než pouze na předem zaplacený oběd, ovšem toto by řešila zmíněná rezerva ve volných místech, které nejde předem rezervovat.

Faktory bránící rozšíření
Proč takové rozhraní již neexistuje dávno? Potenciálních problémů lze nalézt několik. Bylo by nutné rozhraní opravdu masivně rozšířit mezi podstatnou část obyvatelstva. Toho je v současné době schopen snad pouze Google. Dále by bylo zásadní promyslet otázku bezpečnosti, jelikož pro všechny aplikace by stačilo pouze jedno ID. To by šlo vyřešit například kombinováním více zabezpečovacích prvků, jako je heslo, elektronický podpis, čtečka otisků prstu, bezpečnostní karty, či v budoucnu třeba očního či obličejového skeneru (pomocí webové kamery a detekce obličeje). Dalším předpokladem by byla masová dostupnost internetu kdekoliv a kdykoliv v odpovídající rychlosti přenosu a odezvy, což je ale (doufejme) otázka několika let. A v neposlední řadě je otázka, jestli by tento nový přístup k informacím a obchodu přijali i samotní obchodníci (jako v našem případě restaurace), což je podle mě největší hrozba tohoto přístupu.