1 Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Vyšší odborná škola informačních služeb v Praze Jan Šedivý Analýza a návrh řešení p...
Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Vyšší odborná škola informačních služeb v Praze
Jan Šedivý
Analýza a návrh řešení prezentace obrazových dat v prostředí Internetu
Bakalářská práce
2009
Prohlašuji, že jsem bakalářskou práci na téma Analýza a návrh řešení prezentace obrazových dat v prostředí Internetu zpracoval samostatně a použil pouze zdrojů, které cituji a uvádím v seznamu použité literatury. V Praze dne 5. 1. 2008.
Poděkování Zde bych rád poděkoval mému vedoucímu doc. Ing. Stanislavu Hornému, CSc za trvalou podporu a připomínky během psaní této práce. Také děkuji celé mé rodině za trpělivost i povzbuzení během studia. V neposlední řadě patří dík i všem vyučujícím z VOŠIS i VŠE, u kterých jsem měl tu čest v minulých letech studovat.
4
Obsah OBSAH........................................................................................................................... 4 OBSAH CD-ROM......................................................................................................... 5 ABSTRAKT...................................................................................................................6 ABSTRACT ................................................................................................................... 7 1. ÚVOD .................................................................................................................... 8 2. POPIS A SROVNÁNÍ STÁVAJÍCÍCH ŘEŠENÍ.............................................. 9 2.1 PREZENTACE FOTOGRAFIÍ V PROSTŘEDÍ INTERNETU ........................................ 9 2.1.1 Stručné historické okénko........................................................................... 9 2.1.2 Obrazové formáty na WWW ....................................................................... 9 2.1.3 Technologická řešení................................................................................ 10 2.1.4 Úzká místa při prezentaci obrazových dat ............................................... 11 2.2 OCHRANA FOTOGRAFIÍ JAKO AUTORSKÉHO DÍLA ........................................... 14 2.3 STÁVAJÍCÍ ŘEŠENÍ PRO PUBLIKACI FOTOGRAFIÍ NA WWW ............................17 2.3.1 Testovací metodika, kvantitativní a kvalitativní kritéria .......................... 17 2.3.2 Testované aplikace ................................................................................... 21 2.3.3 Výsledky .................................................................................................... 27 2.4 IDEÁLNÍ FOTOGALERIE .................................................................................. 29 2.4.1 Výběr technologie ..................................................................................... 29 2.4.2 Kritéria ideální fotogalerie....................................................................... 29 2.5 SOUHRN DRUHÉ KAPITOLY ............................................................................ 30 3. VLASTNÍ NÁVRH FOTOGALERIE ..............................................................31 3.1 OBSAH ........................................................................................................... 31 3.1.1 Vlastní fotogalerie .................................................................................... 31 3.1.2 Ostatní obsah............................................................................................ 33 3.1.3 Kritéria návrhu obsahu ............................................................................ 33 3.2 UŽIVATELSKÉ ROZHRANÍ ............................................................................... 34 3.2.1 Panely ....................................................................................................... 34 3.2.2 Design....................................................................................................... 35 3.2.3 Kritéria návrhu uživatelského rozhraní.................................................... 36 3.3 APLIKAČNÍ LOGIKA........................................................................................ 36 3.3.1 Struktura aplikace .................................................................................... 36 3.3.2 Volba technologie ..................................................................................... 36 3.3.3 Generování obsahu................................................................................... 37 3.3.4 Kritéria návrhu aplikační logiky .............................................................. 38 4. REALIZACE NÁVRHU.................................................................................... 39 4.1 PROGRAMOVÝ KÓD........................................................................................ 39 4.1.1 Základní nastavení a inicializace aplikace............................................... 39 4.1.2 Panely a maximalizace pracovního prostoru ........................................... 40 4.1.3 Změna velikosti fotografií......................................................................... 41 4.1.4 Ovládací prvky fotogalerie ....................................................................... 42 4.1.5 Jednotlivá alba, MediaRSS a Cooliris...................................................... 43
5 4.1.6 Vzhled prezentace, CSS ............................................................................ 44 4.1.7 Zobrazení fotografie ................................................................................. 44 4.2 TEST UKÁZKOVÉHO ŘEŠENÍ ........................................................................... 45 4.3 DISKUSE UKÁZKOVÉHO ŘEŠENÍ ..................................................................... 45 5. ZÁVĚR ................................................................................................................ 47 5.1 SHRNUTÍ TESTU ............................................................................................. 47 5.2 HLAVNÍ BODY NÁVRHU ................................................................................. 47 5.3 SHRNUTÍ REALIZACE...................................................................................... 47 LITERATURA A ZDROJE .......................................................................................48 6. PŘÍLOHY ............................................................................................................. I 6.1 GRAFY VÝSLEDKŮ TESTOVÁNÍ .........................................................................I 6.1.1 Skóre efektivity.............................................................................................I 6.1.2 Bodová hodnocení kritérií ......................................................................... II 6.2 OBRAZOVÁ DOKUMENTACE ...........................................................................VI 6.2.1 Testované aplikace ................................................................................... VI 6.2.2 Ukázková aplikace..................................................................................... X 6.3 ZDROJOVÉ KÓDY SKRIPTŮ ........................................................................... XII 6.3.1 galerie-data.php ......................................................................................XII 6.3.2 xmlgal.php ...............................................................................................XII 6.3.3 resimg.php ............................................................................................. XIII 6.3.4 index.php ................................................................................................XIV 6.3.5 main.php .................................................................................................XVI 6.3.6 vlevo.php.................................................................................................XXI 6.3.7 gal.php ....................................................................................................XXI
Abstrakt Jan Šedivý. Analýza a návrh řešení prezentace obrazových dat v prostředí Internetu. 2009. Na základě předpokladu, že současné WWW aplikace pro prezentaci fotografií (fotogalerie) nevyužívají efektivně prostor použitého zobrazovacího zařízení, je provedena srovnávací analýza 16 existujících řešení. Výsledkem analýzy je nejen potvrzení předpokladu, ale i seznam kritérií, která by měla splňovat tzv. ideální fotogalerie. Dle těchto kritérií je sestaven teoretický návrh nového řešení zaměřený zejména na mechanismus skrývání jednotlivých prvků prezentace a návazné dynamické přizpůsobení velikosti prostoru pro primární sdělení. Návrh je koncipován tak, aby zásadní funkčnost aplikace byla zajišťována serverem nezávisle na podpoře skriptovacích technologií klientem. V závěrečné části je popsána realizace ukázkové aplikace, která dokazuje uskutečnitelnost zásadních bodů návrhu aplikace pomocí současných technologií.
7
Abstract Jan Šedivý. Current Solutions Analysis and New Design of Web-based Image Presentation. 2009. A comparative analysis of 16 current web-based solutions of image presentation (virtual photo albums as an example) is carried out to prove the space provided by modern visual.devices is used ineffectively, as assumed. The analysis resulted not only in proof of the prior hypothesis, but also in a list of features of an ideal photo album (as an aggregation of all tested solutions). According to stated criteria a new theoretical design of such web-based application was made up. This new layout proposes the mechanism of hiding certain elements of presentation and a consequent dynamic change of the primary message area. The new design also demands independence of client-side technologies (e.g. JavaScript) hence it is based foremost on server-side content generation. Finally is described the implementation of a sample presentation, that illustrates feasibility of main criteria proposed in the new design (at present time and using current technologies).
8
1.
Úvod
V současné době se díky prosazování širokoúhlých formátů zobrazovacích zařízení a pokračujícímu mohutnému rozvoji užívání Internetu stále častěji setkáváme s nepřehlednými až chaotickými návrhy WWW prezentací. Jistý tradicionalismus v rozvržení ovládacích prvků, reklamního prostoru i vlastního informačního sdělení vede mnohdy ke stavu, kdy je prostor pro primární obsah velmi omezen vzhledem k možnostem použitého zobrazovacího zařízení. Možnosti prezentace obrazových dat (fotografie, ilustrace, grafy, plány atd.) jsou tímto fenoménem velmi omezovány. Digitální fotoalbum (fotogalerie) je specifickou aplikací, ve které by měl být kladen veškerý důraz na eliminaci rušivých prvků a maximalizaci prostoru pro vlastní prezentovaný obsah (fotografii). Cílem této práce je ukázat, že ve většině současně používaných řešení k tomuto žádanému efektu nedochází. Druhá kapitola se věnuje srovnání existujících řešení po stránce designu i použitých technologií, kdy je získáno dostatečné množství údajů pro návrh tzv. ideální fotogalerie (resp. jakékoli aplikace požadující využití maximální možné zobrazovací plochy pro primární sdělení). Zároveň jsou zde popsány techniky zabezpečení obsahu před neautorizovaným kopírováním použitelné právě pro fotografie. Na základě výstupů první části práce, teoretických poznatků i vlastních zkušeností autora z oblasti webdesignu a fotografie je ve třetí kapitole sestaven návrh nové aplikace včetně doporučené technologie řešení. Čtvrtá kapitola je pak věnována popisu realizace ukázkového řešení.
9
2.
Popis a srovnání stávajících řešení
V této části naleznete stručný popis stávajících technologií pro prezentaci obrazových dat na WWW a test 16 konkrétních Internetových aplikací. V závěru kapitoly jsou na základě výsledků testu shrnuty požadavky na „ideální fotogalerii“.
2.1
Prezentace fotografií v prostředí Internetu
2.1.1
Stručné historické okénko
Počátek digitalizace obrazových předloh (digital image processing, digital imaging) můžeme datovat do roku 1957, kdy tým Russela A. Kirsche [1] zkonstruoval první zařízení k digitalizaci obrazových předloh – skener [2]. V 60. letech pak agentura NASA vyvinula způsob digitálního přenosu obrazu z družic. (Do té doby musely exponované filmy přistávat na Zemi, což nebylo možné u plánovaných sond k vzdálenějším cílům – Voyager a další.) Tuto technologii rychle převzala armáda a tím i financování dalšího vývoje. V 70. a 80. letech proniklo počítačové zpracování obrazu do medicíny (tomografie, radiologie…) i státní správy. Přenos obrazových dat prostřednictvím sítě Internet (WWW, e-mail, FTP), nové tiskárny i nástroje pro pořizování a úpravy digitalizovaných obrázků umožnily masivní rozšíření této technologie od 90. let až do současného stavu [3]. 2.1.2
Obrazové formáty na WWW
Poměrně malá přenosová kapacita prvních Internetových připojení (zejména dial-up) i zpočátku velice drahá datová úložiště vyvolala vysokou potřebu nových komprimovaných formátů pro obrazová data. V poměrně krátké době se nejrozšířenějšími formáty (používanými v rámci WWW a podporovanými běžnými prohlížeči) staly GIF 1 a JPEG 2 . PNG 3 byl vyvinut tak, aby minimalizoval negativa obou předchozích formátů při zachování jejich předností, nicméně zřejmě díky o něco vyšším datovým objemům se rozšiřoval pomaleji než se předpokládalo. F
Zajímavou vlastností všech zmíněných „internetových“ formátů je možnost tzv. prokládání (interlacing), kdy je do prohlížeče nejprve načtena hrubá struktura celého obrazu, která se s dalšími příchozími částmi dat zpřesňuje. Naproti tomu načítání obrazu bez prokládání probíhá řádek po řádku odshora. 1
2
3
Graphics Interchange Format: 8 bitový formát, podpora max. 256 barev v jednom rámci, neomezený počet rámců, podpora animace a základní průhlednosti [4]. Joint Photographic Experts Group, či lépe JPEG File Interchange Format JIFF (tento název se neužívá, běžné je zkráceně JPG). JPEG: 24 bitů (RGB) + další možná rozšíření, statický, ztrátová komprese [5]. Portable network graphic: volitelná barevná hloubka, bezztrátová komprese, možnost animace a podpora průhlednosti alfa kanálu a gamma korekce [6].
10 Pro účely, kde je použití rastrových formátů z jakéhokoli důvodu nevhodné (nutnost neomezeného zvětšování, omezení velikosti souborů apod.), existuje i několik vektorových formátů. Například standardní CGM (Computer Graphics Metafile) používaný na WWW s využitím profilu webCGM (týká se zejména technických výkresů, map atp.), VML a SVG 4 , který je na rozdíl od CGM podporován i moderními WWW prohlížeči. Samostatnou kapitolou je zabalení obrazu do některého z kontejnerových objektů typu SWF 5 , který provede nezávisle na prohlížeči vlastní zobrazení obsahu i manipulaci s ním (animace, kombinace různých formátů, dynamické změny). F
2.1.3
Technologická řešení
Pro prezentaci obrazových dat v prostředí Internetu používáme zejména službu WWW a její protokol HTTP pro klient – server komunikaci. (Pro přenos jednotlivých souborů můžeme použít e-mail či FTP, ale tato práce se primárně zabývá prezentací ve významu zobrazování.) Zdrojová data jsou prezentována prostřednictvím jazyka HTML resp. XHTML (viz [7]) přímo, případně pomocí vnořených objektů typu Flash apod. První řešení se sestávala ze série statických WWW stránek, které server na požádání poskytoval klientovi. Tlak na interaktivitu, komfortnější systémy ovládání prezentací, přehlednější navigaci, zjednodušení správy obsahu na serveru a v neposlední řadě i na redukci datových objemů vedly k vývoji technologií dynamicky vytvářeného obsahu jak na straně klienta, tak na straně serveru. Z hlediska serveru jde zejména o oddělení struktury prezentace (vzhledu stránky) od samotných dat (obraz, text a multimédia). Obsah předávaný klientovi se automaticky generuje ze šablony stránky pomocí skriptu na serveru 6 spojením s požadovanými daty. Tento způsob umožnil mimo jiné i migraci dat z adresářů WWW serveru do samostatné databáze s jednodušší správou. Veškerá aplikační logika se uplatňuje na straně serveru (na základě různými způsoby předávaných požadavků klienta) a klientovi je předkládána de facto statická stránka. Toto je výhodné zejména z hlediska kompatibility prezentovaného kódu s různými verzemi WWW prohlížečů. Nevýhodou serverových technologií je vyšší zatížení serveru, opakovaný přenos dat po každé obsluhované události a v neposlední řadě i nutnost ošetřit přenášení požadavků na server. Dynamizace prezentace na straně klienta probíhá buď pomocí některé client-side skriptovací technologie (JavaScript), stažením vlastní aplikace bez využití WWW prohlížeče (např. Java, standalone Flash, spustitelný soubor), nahráním objektu v rámci WWW stránky do standardního prohlížeče (Java aplet, vložený Flash) apod. Pomineme-li samostatné aplikace
4 5
6
Jedná se vlastně o XML formáty pro popis vektorových objektů [8]. Adobe Flash, dříve i Macromedia či Shockwave Flash – technologie umožňující vkládání interaktivních animací a videa do WWW stránek. Podporuje vlastní skriptování pomocí ActionScript. Blíže viz [9]. Tzv. server-side scripting pomocí PHP, ASP a podobných běžících na standardním WWW serveru, nebo přímo pomocí vlastní serverové aplikace.
11 jejichž použití není vhodné zejména z bezpečnostního hlediska, zůstávají nám z hlediska přístupu ke klientově systému omezené (tzn. bezpečnější) skripty vykonávané na straně klienta (Jscript, JavaScript, ActionScript pro Flash). 7 Zásadní výhodou klientského skriptu je úspora objemu přenášených dat (přeneseme pouze předpis, jak se má naše aplikace chovat a veškerá interakce s uživatelem probíhá již v rámci jeho systému; z WWW serveru přicházejí pouze nová data). Nevýhodou je ovšem nutnost optimalizovat aplikaci pro běh na různorodých systémech klientů (velká škála WWW prohlížečů, rozdílná úroveň podpory skriptů včetně možnosti jejich zákazu). Samozřejmě nejpoužívanější variantou implementace dynamických prvků do prezentace je kombinace serverových i klientských skriptů, kdy generování obsahu zajišťuje server (např. dotaz do databáze a zobrazení dat v dané struktuře) a práci s vlastním obsahem v rámci prezentace klientský skript (např. kontrola formuláře před odesláním na server). Důraz je kladen na bezpečnost (zřejmě není vhodné, aby do naší databáze místo námi kontrolovaného serverového skriptu mohl přistupovat snadno napadnutelný klientský skript, kterému by musela být poskytnuta příslušná oprávnění). V posledních několika letech se do popředí posunuje i technologie prezentace dat v souborech založených na XML (zjednodušeně – data s vloženými tagy popisujícími jejich strukturu) a následné transformaci do (X)HTML již v rámci WWW prohlížeče nebo transformaci do jiných formátů (např. PDF) pomocí XSLT šablony. Využitím asynchronního přenosu požadavků a JavaScriptu vznikla technologie AJAX, kombinující zpracování požadavků na straně klienta a serveru s možností obnovy pouze části již nahrané WWW stránky (blíže viz [10] a obdobné). 2.1.4 I.
Úzká místa při prezentaci obrazových dat
Implementace v prostředí WWW
Při prvních návrzích protokolů Internetu, jazyka HTML a WWW prohlížečů nebylo ještě technologicky myslitelné přenášení obrazových dat v takové podobě, která by uspokojila naše současné potřeby. Zde nemyslím ani tak datový objem, ale zejména samotný přenos obrazových dat a dále jeho zobrazení v prohlížeči. Prvotně byla celá služba postavena na přenosu textových dat. Umístění obrázků na WWW se tak logicky odvíjelo od způsobů dosavadního nakládání s textem. Protokol HTTP nyní již umožňuje přenášení různě kódovaných dat (umožňují mu to mimo jiné standardizované MIME hlavičky určující typ souboru), ale způsob jakým jsou tato data zobrazena je zcela záležitostí WWW prohlížečů.
7
Nutno podotknout, že skripty interpretované WWW prohlížečem se přenášejí v podobě textu, nikoli binárního zdrojového kódu, takže potenciálně nebezpečný skript je mnohem snazší odhalit.
12 Základním prostředkem pro zobrazení obrázků na WWW se stal jednoduchý HTML tag 8 určující pouze zdrojovou URL adresu obrázku a alternativní text (pokud je zdroj nedostupný či nezobrazitelný). Prvotní myšlenka tagu IMG bylo včlenění obrázku do textu v podobě řádkového elementu (objekt představující část textu, bez možnosti obtékání). Posléze přibyly jednoduché možnosti řízení toku textu v okolí obrázku (atribut ALIGN). Protože okolní text byl zobrazen dříve než se dokončilo stahování obrázku, přibyly volitelné atributy pro určení rozměrů (WIDTH a HEIGHT) – při jejich zadání bylo ve stránce rezervováno místo pro obrázek. Zde nalézáme první úskalí zobrazování obrázků – tvůrci prohlížečů zvolili striktní dodržování rozměrů zadaných v atributech tagu IMG bez ohledu na skutečné rozměry obrazu v zobrazovaném souboru. To bylo užitečné z hlediska nových možností designu, 9 nicméně destruktivní z hlediska přesnosti zobrazování obrázků, které mohly být deformovány. 10 I když měl výsledný obrázek správný poměr stran, nízký výpočetní výkon tehdejších počítačů neumožňoval provést změnu rozměrů dostatečně silným algoritmem (kvalita výsledných obrázků nebyla uspokojivá). Navíc datový objem stále odpovídal původnímu souboru. Další vývoj vkládání obrázků do obsahu WWW se odehrál na úrovni přizpůsobování obsahu pomocí existujících jednoduchých prostředků (např. tabulkový layout 11 ) a vytváření různého obsahu pro jednotlivé prohlížeče (interpretace kódu nebyla jednotná). S nástupem kaskádových stylů (CSS) a kontejnerových objektů typu DIV se dostáváme do současné doby, kdy jednotlivé prvky stránky (včetně) obrázků jsou několikanásobně obaleny a poměrně složitě umisťovány vícenásobnými pravidly. Lze se jen dohadovat, nakolik je současný stav výsledkem nedostatečného odpoutání se od textové podstaty prvotního Internetu (resp. WWW). Osobně si ovšem dovedu představit implementaci odlišnou, používající více různých tagů, která by například řešila rozdíl mezi grafickými prvky designu a obrázky nesoucími význam (včetně např. implicitní podpory vkládání jejich popisků). Bohužel proces vytváření standardů v současnosti není tak jednoduchý jako před 15 lety – příkladem budiž CSS verze 3, jehož vývoj v posledních letech ustrnul ve fázi před doporučením standardu. Výsledkem je, že tvůrci jednotlivých prohlížečů opět zavádějí své vlastní „standardy“ a tím znovu tříští poměrně homogenní prostor, který vznikl po uvedení CSS 2 v roce 1996. 12
8
Navržený Marcem Andreeseenem v roce 1993. Viz zajímavá diskuse [11]. Pro plochu jedné barvy tak například stačí obrázek o rozměru 1 × 1 px a správná definice šířky a výšky v tagu IMG. 10 Většinou chybou autora WWW stránky, kdy ve snaze rezervovat místo obrázku a vyhnout se tak nesprávnému zobrazení zadal tyto atributy, ovšem použil nesprávné rozměry obrázku oproti skutečnosti. 11 Přesné umístění prvků na stránce bylo zajištěno umístěním obsahu do jedné či více vnořených tabulek s individuálně formátovanými buňkami. 12 Blíže ke kaskádovým stylům viz [12]. Za pozornost stojí zejména revize CSS 2.1 zavádějící např. automatické číslování apod. 9
13 II.
Limity zobrazovacích zařízení
V současné době je rozlišení největších v ČR nabízených 30" LCD panelů 2560 × 1600 obrazových bodů, při fyzických rozměrech 70 × 50 centimetrů. Laicky lze říci, že takovýto monitor umí zobrazit cca 4 miliony obrazových bodů. Nabízené digitální fotoaparáty běžně produkují fotografie mezi 7 a 14 mil. pixely 13 . Lze tedy snadno nahlédnout, že pro zobrazení celé fotografie je nutno původní obraz přepočítat. Tento příklad je extrémní a v několika ohledech nepřesný (fotografie jsou určené především k tisku), ale vezměme dále například složité technické plány, mapy ve velkých měřítkách apod. – zobrazení takovýchto obrazových podkladů bez ztráty detailů je stále spojeno s nutností posunovat zobrazovaný výřez po obrazovce. Situace je ještě složitější v prostředí Internetu, kde je plocha pro obraz dále omezena rozhraním WWW prohlížeče i vlastními prvky stránky. V současné době je jediným uspokojivým řešením mezi zobrazením celku a detailů obrazu dynamicky propojit oba tyto pohledy. Obraz je pak k dispozici v několika různých rozlišeních a aplikace na pokyn uživatele zobrazí vybraný region ve vyšším rozlišení, případně rozsáhlejší oblast v rozlišení nižším. 14 Dalším krokem je spojování snímků v jednotlivých vrstvách do panoramat (vč. sférických) a vytváření tzv. virtuálních prohlídek. Nejdetailnější vrstvy pak mohou dosahovat velikosti v řádu desítek mil. pixelů. Takový objem musí být nutně rozdělen do menších celků a tyto dynamicky načítány podle potřeby. III.
Vyhledatelnost
Vzhledem k nárůstu objemu dat prezentovaných v prostředí Internetu v posledních letech se stále více do popředí dostává otázka „Jak nalézt relevantní informace?“, skládající se z vlastního problému nalezení a problému ověření nalezeného vzhledem k realitě či jiným výsledkům. V případě textových dat poměrně úspěšně funguje systém indexování stránek, přiřazování klíčových slov a jiných metadat, automatické hodnocení relevance pomocí poměrně složitých algoritmů apod. Jakkoli jsou tyto metody pokročilé, v případě netextových dat, případně při skrytí textu do jiného objektu (Flash, obrázek), již indexování vyžaduje komplexnější přístup. Zavedení algoritmů pro rozpoznávání textu (OCR), dekompozici Flash animací, provádění skriptů a podobných úloh 15 bylo ovšem zpočátku natolik složité, že dosud u jednoduchých (a tím i rychlých) indexovacích robotů neprobíhá. Vyhledávácí služby se zatím vydaly cestou specializace a používají samostatné roboty pro konkrétní druhy obsahu.
13
Zdrojem těchto údajů je nabídka Internetového obchodu Czechcomputer.cz k 26. 11. 2008. Viz například mapové aplikace mapy.cz, mapy.google.cz či specializovaný portál panoramas.cz. 15 Například detekce a rozpoznání obličejů (Face Detection & Recognition), kterou od roku 2007 podporuje i Google image search viz. [13]. V současnosti lze v rozhraní vyhledávání obrázků google zvolit typ hledání: obličeje. Zajímavé je i vizuální hledání (pomocí podobných obrázků) na serveru live.com. Novou vyhledávácí aplikaci používající analýzu obrazových dat představila v polovině prosince 2008 Fakulta informatiky Masarykovy univerzity v Brně viz [14]. 14
14 Jelikož stávající vyhledávací služby vycházejí primárně ze získaných textových dat, i hledání obrázků je postaveno zejména na textových informacích z kontextu (tzn. okolní text, obsah atributu ALT a TITLE obrázku, odkazy na obrázek, okolní nadpisy a další texty). Zásadní tedy je publikovat obrazová data včetně textového popisu (min. v povinném atributu ALT tagu IMG). Další metodou je opatření souboru obrázků metadaty podle některého ze standardních systémů – např. MediaRSS [15].
2.2
Ochrana fotografií jako autorského díla
Zatímco na počátku 90. let byly digitální technologie zpracování a reprodukce obrazu dostupné pouze při využití poměrně drahého vybavení, rozvoj technologií zobrazení i tisku v posledních letech posunul tuto oblast na zcela jinou úroveň. Zejména tlak na vývoj „spotřebních“ (tzn. levných) zařízení usnadnil kopírování a tisk fotografií běžnými (amatérskými) uživateli. Tedy těmi konzumenty předkládaného obsahu, kteří na rozdíl od profesionálů mnohdy ani netuší, že stažením, užíváním a reprodukcí autorského díla mohou porušovat nějaké právní předpisy. V této oblasti se v ČR uplatňuje zejména autorský zákon (č. 121/2000 Sb.) a další předpisy 16 zaručující ochranu a nezcizitelnost práv autora. Bohužel je již na autorovi, aby tuto ochranu aktivně vymáhal (mnozí uživatelé Internetu tak spoléhají na poučku „kde není žalobce, není soudce“). Jednodušší, než spoléhat na případný soud, je opětovné (preventivní) odebrání možnosti kopírování autorských děl oněm „běžným“ uživatelům. Zásadním úkolem autora jako žalující strany by totiž v případném soudním bylo unést důkazní břemeno toho, že je autorem fotografie. Problematiku neřeší digitální podpis, který jednoznačně identifikuje (a na základě důvěry v certifikační autoritu i ověřuje) autora, nikoli však již dílo ve vztahu k autorovi. 17 Takovou službu by mohlo zastat ověřené a nenapadnutelné časové razítko (vlastně druh vodoznaku; viz dále). Bohužel zatím neexistuje dostatečně robustní řešení, které by bylo zároveň běžně rozšířené (tzn. zejména cenově dostupné širokému spektru uživatelů). V následující části textu jsou představeny některé základní techniky zabraňující uživateli jednoduše uložit fotografie v jeho počítači. U každé techniky je diskutován zejména její dopad na přístupnost stránky a způsob jejího překonání. Je nutné si uvědomit, že neexistuje způsob, který by při využití běžného prohlížeče zcela znemožnil získání zobrazeného obsahu. Jednoduše proto, že již v okamžiku zobrazení je obsah v nějaké podobě uložen v systému klienta. Dostatečně zkušený uživatel snadno dokáže jakýkoli takový obsah získat. V případě fotografií je pak možno např. zachytávat zobrazovaná data pomocí specializovaných
16
Např. tiskový zákon (č. 46/2000 Sb.) – dále viz odborná literatura z oblasti autorského práva či stručný článek [16]. 17 Ve fotografii ovšem autorovi nejde o to zamezit ostatním, aby prezentovali fotografie jeho jménem, ale o to, aby nemohli jeho fotografie prezentovat jménem svým.
15 programů (včetně systémové služby snímání obrazovky). Cílem prezentovaných technik je proto zamezit nezkušeným uživatelům získat obsah 18 v jiné formě, než autor zamýšlel. Nejlépe ovšem tak, aby nebyla snížena přístupnost prezentace (viz [17]). Nejčastějšími způsoby získání fotografie běžným uživatelem jsou: 1. 2. 3. 4.
5. 6.
Přetažení pomocí myši z okna prohlížeče (drag & drop). Uložení pomocí kontextového menu (po kliknutím pravým tlačítkem myši). Uložení celé stránky a vyhledání souboru v příslušné složce uložené stránky. Využití specializovaného programu pro stahování obsahu (např. FlashGet), příp. zabudovaných funkcí prohlížeče či jeho doplňku. To vlastně znamená automatickou analýzu zdrojového kódu, kterou může uživatel případně provést i ručně. Zachycení obrazovky pomocí klávesy PrintScreen či pomocí specializovaného programu. Vytištění stránky s obrázkem včetně tisku do souboru (i PDF).
Níže popsané techniky jsou většinou cíleny proti jednomu konkrétnímu způsobu a lze je obejít některým z ostatních. Vyšší úrovně ochrany je vždy dosaženo až použitím kombinace více technik. Pro podrobnější informace viz čánky [18] a [19], ze kterých bylo čerpáno. I.
Image overlay (překrytí obrázkem)
Podstatou techniky je překrytí celé fotografie jiným elementem, který bude při dané události (typicky kliknutí či tažení myší) nadřazen zakrytému elementu a tím bude identifikován jako cíl události. K zachycení události lze použít buď JavaScript (viz dále) či mnohem snadněji použít element stejného druhu jako je skrývaný. Tedy zakrýt obrázek obrázkem – uživatel při pokusu o kliknutí, či tažení myší zachytí horní obrázek. Většinou se používá zcela průhledný obrázek (tzn. formát GIF/PNG) o velikosti 1 × 1 px, který je použitím stylu či příslušných atributů zvětšen na dostatečnou velikost. Samotného překrytí je možné dosáhnou použitím stylů tak, že jsou oba obrázky umístěny na stejnou pozici do různých vrstev (z-index), nebo originální obrázek použit jako pozadí prvku, jehož obsahem je průhledný obrázek (typicky kontejner DIV, či tabulka). V případě použití tabulky je možné zcela obejít i použití kaskádových stylů. Slabá místa: Překryvný obrázek lze zablokovat pomocí filtru typu Adblock. Riziko nekorektního zobrazení průhlednosti obrázku a tím zakrytí obsahu stránky. II.
Využití JavaScriptu
Pomocí skriptu lze nadefinovat funkce obsluhující různé události, které mohou sloužit uživateli k získání obsahu. Jedná se zejména o události onMouseDown (při stisknutí tlačítka myši nad objektem; na rozdíl od události onClick je tato spuštěna i při pokusu o přetažení
18
Zde jmenovitě fotografie; některé techniky jsou ovšem použitelné i pro jiné druhy obsahu WWW prezentací.
16 objektu myší), onMouseUp (konec stisknutí tlačítka myši), onContextMenu (vyvolání kontextové nabídky), onSelectStart (počátek vybrání objektu) a onDragStart (počátek přetahování objektu myší). Pomocí příkazu return false lze zajistit ukončení obsluhy dané události (tj. zamezit standardní reakci prohlížeče). Lze kontrolovat i události zachycující stisknutí kláves, či pouhé najetí kurzoru myši nad objekt. Tyto způsoby ovšem nejsou doporučovány. Funkce obsluhující událost může být zcela libovolná. V případě fotografií lze uvažovat např. o oznámení, že daná fotografie je chráněna copyrightem, či občas používanou záměnu zdrojového souboru obrázku za jiný (zcizitelný). Slabá místa: Je nutná zapnutá podpora JavaScriptu (sic!). Různá podpora v prohlížečích. Snížení přístupnosti stránky (např. při zakázání tlačítek myši v celé stránce). Použití klávesy kontextová nabídka místo pravého tlačítka myši nad aktivním elementem. III.
Kontrola serverem
Na úrovni serveru se jedná nejčastěji o kontrolu, zda fotografie byla opravdu k zobrazení vyžádána stránkou z domovského serveru. Kontrola tzv. hotlinkingu (odkazování obrázků z cizích serverů) je nutná zejména v případě omezené konektivity serveru a v současné době se příliš nepoužívá. 19 Kontrola odkazující stránky (tzv. HTTP referer) může být provedena serverovým skriptem, či přímo serverovou aplikací pomocí modulu mod_rewrite či obdobných. Serverový skript může zároveň sloužit i k zakrytí skutečných adres originálních souborů (jako zdrojový soubor obrázku je pak určen skript s patřičným parametrem). Samozřejmostí by měla být ochrana adresářů s vlastním obsahem tak, aby k nim mohly přistupovat pouze serverové skripty (pomocí řízení přístupových práv v rámci serverové aplikace – např. jednoduchými pravidly v souboru .htaccess na serveru Apache). Pro ještě vyšší úroveň ochrany je nutno zahrnout dostatečně složité kódování parametrů předávaných skriptům. Slabá místa: Podvržení odkazující stránky. IV.
Watermarking (umístění vodoznaku)
Vodoznakem je zde myšlena buď viditelná značka (většinou poloprůhledné logo nebo nápis), či pouhým okem neviditelná úprava dat obrázku na úrovni jednotlivých pixelů. Takto „podepsaný“ obrázek je i po stažení uživatelem nadále možno identifikovat. Na tomto principu je postavena např. známá služba DigiMarc. Slabá místa: Retuš obrázku pro viditelné vodoznaky. Další úpravy pro neviditelné (např. změna velikosti, ořez, rozdělení do více souborů).
19
Z důvodu odkazování obrázků čtečkami RSS či některými vyhledávacími servery.
Umístění fotografie do objektu jiného formátu (např. Flash, video apod.), jehož stažení je obtížnější, případně u kterého je již uspokojivě vyřešeno digitální podepisování (resp. distribuce práv k přehrávání obsahu). Tato technika je většinou použita na úkor přístupnosti WWW stránky. Slabá místa: Dekódování kontejnerového objektu a získání obrazových dat či adres zdrojových souborů. VII. Rozdělení na více části Obraz je rozdělen na více částí, které jsou pak pomocí HTML (stylů či tabulky) složeny do podoby celistvého obrázku. Uživatel pak kliknutím či tažením myší cíluje pouze výseč obrázku. Slabá místa: Pracnost, resp. výpočetní náročnost přípravy dle úrovně velikosti částí. Zvyšující se datový objem kódu stránky. Různé výsledky v různých prohlížečích.
2.3
Stávající řešení pro publikaci fotografií na WWW
Zásadním úkolem při navrhování nové aplikace byly průzkum a analýza stávajících řešení, kterým se věnuje tato část práce. Nejprve je popsána metodika a pak jednotlivé testované programy. V závěru kapitoly jsou uvedeny souhrnné tabulky výsledků. Snímky obrazovek testovaných aplikací jsou k dispozici v příloze 6.2 Obrazová dokumentace. 2.3.1
Testovací metodika, kvantitativní a kvalitativní kritéria
Při průzkumu stávajících řešení používaných pro zobrazování obrazových dat v prostředí Internetu jsem se soustředil zejména na vizuální stránku prezentace a dále na technologie, jakými bylo výsledného efektu dosaženo. Za stěžejní při prezentaci obrazových dat (nejen fotografií) považuji maximální využití dostupného prostoru na obrazovce (resp. v okně prohlížeče) pro dosažení co nejlepšího rozlišení detailů obrazu.
18 Při testování jsem sledoval chování aplikací zejména z těchto hledisek: efektivita využití dostupné plochy okna prohlížeče (včetně případné reakce aplikace na celoobrazovkový režim a změny velikosti okna) akcentování primárního obsahu (fotografie) oproti ostatním prvkům prezentace (možnost skrývání nevyužívaných panelů, reklamní bannery, statické prvky odvádějící pozornost apod.) použité technologie (HTML, CSS, JavaScript, Flash, …) včetně funkčnosti v prohlížečích MS Internet Explorer 7.0 a Mozilla Firefox 3.0 kvalita změn velikosti fotografií při nahrávání na server a při prohlížení prezentace (pokud k takovým změnám dochází) popisování obrazových dat (názvy, popisky, komentáře, alternativní text, titulek stránky, metadata, RSS, …) uživatelský komfort (přehlednost, ovládací prvky, srozumitelnost atd.) Při testování jsem postupoval podle jednotného testovacího scénáře (viz Obr. 2-1), přičemž u každého kroku bylo ověřeno, zda aplikace tuto funkcionalitu podporuje, výsledek procesu (úspěch/neúspěch) a případné poznámky k průběhu. V případě neúspěchu daného kroku jsem pokračoval následujícím krokem až do konce scénáře. Registrace / Instalace Zobrazení galerie Vložení komentáře
Nahrání 1 fotografie
Nahrání ostatních foto Editace alba
Přidání popisku
Vyhodnocení kritérií
Obr. 2-1 Testovací scénář.
Vyhodnocovaná kritéria 1. 2. 3. 4. 5. 6. 7. 8.
20
Instalace/registrace: doba trvání, nadstandardně vyžadované osobní údaje, ověření e-mailu pokud byl vyžadován. Nahrání první fotografie: doba vyřizování požadavku, kvalita změny velikosti. Přidávání popisků: přehlednost a složitost procesu. Vložení komentáře: doba trvání, vyžadované údaje, ochrana proti spamu (např. CAPTCHA 20 ), nutnost registrace. Smazání fotografie. Možnost základních úprav fotografií: otočení, ořez, doostření, korekce expozice apod. Pokročilé možnosti: nadstandardní funkce (např. automatické promítání obrázků – slideshow). Editace alba: změny názvů, popisků, pořadí fotografií.
CAPTCHA Completely Automated Public Turing test to tell Computers and Humans Apart – metoda pro rozpoznání uživatele (člověka) od počítačového programu. Většinou spočívá v opisování strojově nečitelného kódu či vyřešení položené otázky. Dále viz [21].
19 9. 10. 11. 12. 13. 14. 15. 16.
17. 18.
19. 20. 21. 22.
Rámečky: vzhled u náhledů/fotografií, pokud jsou automaticky přidávány. Amatérské funkce: tzv. one click solutions (řešení na jedno kliknutí) – jednodušší způsob editace. Pořadí fotografií po přidání vs. pořadí při nahrávání. Zobrazení celé fotografie: zda je zobrazena celá fotografie bez nutnosti použití posuvníků, případně celoobrazovkového režimu (či většího monitoru). Velikost náhledu. Velikost základní fotografie: po kliknutí na náhled. Velikost zvětšené fotografie: po kliknutí na základní foto. Pracovní prostor: plocha přidělená v prezentaci fotogalerii (tzn. náhledům, fotografiím a ovládacím prvkům galerie). Tzn. velikost okna prezentace minus statické bannery, navigační prvky vlastní prezentace, reklamní prostor, nevyužité plochy okna atd. Otevírání fotografií v novém či stávajícím okně. Celoobrazovkový režim (fullscreen): zda se po přechodu prohlížeče do celoobrazovkového režimu prezentace přizpůsobí (nejlépe zvětšením pracovní plochy fotogalerie i fotografií). Ovládací prvky: textové/grafické, umístění vůči fotografii. Skrývání prvků stránky: pro dosažení větší pracovní plochy fotogalerie. Přítomnost reklamních prvků v prezentaci. Další poznámky.
Testovací sada fotografií Během testů byla použita vždy stejná sada fotografií s parametry zvolenými tak, aby odpovídaly situaci běžného uživatele 21 , a zároveň bylo možné určit limity aplikace a zhodnotit způsob, jakým upravuje zdrojová data. Podrobně viz následjující tabulka (Tab. 2-1). #
Název
Šířka Výška Poměr Velikost [px] [px] [kB] stran 4500 2798 16:10 946,5
EXIF
Poznámka
1
01_testchart.jpg
2
02_nocni.jpg
800
600
4:3
3
03_cb-scena.jpg
666
500
4
04_krajina.jpg
800
600
5
05_detail.JPG
1024
768
4:3
160,9
ano
Přípona velkými písmeny.
6
06_sirokouhly.jpg
2192
1370
16:10
691,6
ano
Širokoúhlý formát.
7
07_maly.jpg
300
400
3:4
63,9
ano
Malá velikost obrázku.
8
08_velky.jpg
3264
2448
4:3
5468,1
ano
Velký datový objem.
9
09_panorama.jpg
1875
500
15:4
249,0 prázdný Extrémně širokoúhlý obraz
10_ctverec.jpg 800 800 Celkový datový objem:
1:1
248,4 ano 7,97 MB
10 11
ne
Ukazuje kvalitu resamplu.
117,5
ano
Noční snímek.
4:3
81,8
ano
Černobílý snímek.
4:3
132,5
ano
Snímek krajiny.
Čtvercový formát.
Tab. 2-1 Parametry fotografií v testovacím souboru.
21
Tedy nikoli nereálné problémy typu poškozené fotografie, soubory bez přípony či s příponou neodpovídající typu souboru apod. Naopak uživatelé běžně nahrávají fotografie „tak jak jsou“ po stažení z digitálního fotoaparátu (tedy o velikosti několika MB) či amatérsky upravené fotografie s malými rozměry atd.
20 Po otestování všech vybraných aplikací jsem provedl výpočty související s efektivitou využití dostupné plochy zobrazovacího zařízení. Jak již bylo zmíněno v části 2.1.4-II velikost této plochy je v případě zobrazení na monitoru ovlivněna fyzickým rozlišením obrazovky a dále použitým prohlížečem, resp. zmenšena o plochu, kterou zabírají komponenty prohlížeče (okraje okna, lišta s titulkem, stavový řádek, ovládací panely aj.) Test byl proveden na LCD panelu s fyzickým rozlišením 1280 × 800 obrazových bodů. Jistě by bylo zajímavé zopakovat test i pro jiná rozšířená rozlišení. Od dalšího testování jsem ovšem upustil, protože jak již bylo zmíněno, samotné testování není těžištěm této práce a navíc v případě zájmu by se příslušné hodnoty daly zjistit i výpočtem na základě dat již získaných. Záměrně jsem pro test zvolil obrazovku s poměrem stran 16:10 z důvodu rozšíření širokoúhlých zobrazovacích zařízení v poslední době 22 a také proto, že starší koncepty tvorby WWW počítaly s obrazovkami s poměrem stran 4:3, což se odráží v nevyužití celého potenciálu novějších monitorů. Pro správné ohodnocení efektivity jsem zjišťoval poměr plochy zabrané po řadě náhledem, fotografií, zvětšenou fotografií a pracovní plochou galerie vůči dostupnému místu maximalizovaného okna prohlížeče i vůči celé obrazovce (zobrazení fullscreen). 23 Dostupná plocha okna měla šířku 1260 pixelů (zbytek obrazovky zabraly okraje okna) a výšku 655 pixelů (titulek 20 px, panely nástrojů 75 px, stavový řádek 30 px a okraje okna). Ze získaných údajů jsem pro vyšší přehlednost Měřená položka Váhy zpracoval dvě charakteristiky. Nejprve tzv. skóre Náhled 10 20 efektivity vyjadřující do jaké míry využívá daná aplikace Fotografie 5 dostupný prostor zobrazovacího zařízení. Již zjištěné Zvětšená fotografie 5 efektivity zobrazení pro náhled, fotografii a zvětšenou Náhled – celá obrazovka Fotografie – celá obrazovka 10 fotografii vůči oknu, celé obrazovce a pracovnímu proPrimární prostor 25 storu fotogalerie jsem ohodnotil body tak, že minimální Náhled (v primárním pr.) 10 hodnota absolutního rozdílu se 100 % 24 získala plný Fotografie (v primárním pr.) 15 Celkem 100 počet bodů, maximální body žádné a hodnoty mezi těmito extrémy příslušnou část. Skóre tedy vyjadřuje, jak si Tab. 2-2 Váhy skóre efektivity. daná aplikace vedla v porovnání s ostatními. Výsledná hodnota skóre je váženým aritmetickým průměrem jednotlivých hodnot s váhami dle tabulky vah (Tab. 2-2). Pro skóre efektivity byla použita škála 0 až 10 bodů.
22
Jednoduchou metodou pohledu do nabídek nabízených monitorů v internetových obchodech lze dle mého názoru zjistit, jakým směrem se ubírá poptávka spotřebitelů – výrobci se jí svou nabídkou zcela jistě pokoušejí přizpůsobit (což je jistě i výsledek rozsáhlých průzkumů). A širokoúhlé formáty zde zcela jasně dominují. 23 S potěšením mohu konstatovat, že současné verze obou použitých prohlížečů již v režimu zobrazení na celé obrazovce skrývají všechny prvky okna. 24 Nejlepší výsledek je samozřejmě nejvyšší procento, ovšem v situaci, kdy je obraz větší než zobrazovaná plocha (tj. když není obraz zobrazen celý a musí se použít posuvníky) a obraz zabírá např. 180 % plochy, je započteno |1,8 − 1| = 0,8 (ekvivalent 20 %). Čím více se zabraná plocha vzdaluje ideálním 100 %, tím více je penalizována. Takovýto způsob hodnocení považuji za dostatečně ilustrující sníženou přístupnost obrazu.
21 Druhou zpracovanou charakteristikou jsem se snažil vystihnout ostatní zjišťované údaje. V rámci zjednodušení jsem opět na škále 0 až 10 bodů ohodnotil těchto pět kritérií: Efektivita: zde se uplatňuje pouze velikost základní fotografie B = E ⋅10 − BP E PP E v rámci pracovního prostoru pro fotogalerii (PP) a plochy PP vůči EF − 1 ⋅ Kp ploše okna, tedy stav, ve kterém uživatel pravděpodobně uvidí BPE = E PP fotogalerii poprvé aniž by použil posuvníky, či celoobrazovkový režim. Bodové hodnocení efektivity (BE) bylo zkonstruováno jako násobek plného počtu bodů a efektivity PP (tj. EPP) 25 zmenšený o penalizaci za efektivitu využití PP vlastní fotografií. Tato penalizace je koeficient přísnosti (Kp) vynásobený absolutní hodnotou doplňku podílu EF a EPP do 100 % (takto zohledňuji menší i příliš velké fotografie, tedy ty, které nejsou zobrazeny celé, viz vzorec v rámečku na této straně). Koeficient přísnosti Kp stanovuje kolik maximálně bodů může být odečteno touto penalizací (zde to jsou 4 body). Celková penalizace je pak zjištěna jako vážený aritmetický průměr penalizací pro fotografie s poměrem stran 26 4:3, 2:3, 1:1 s váhami po řadě 4, 4, 2 (což má zohlednit použití různých formátů v dané fotogalerii). Toto kritérium tedy hodnotí jak velkou plochu obrazovky fotogalerie využívá a kolik tohoto prostoru využívají zvětšené fotografie. Také reflektuje stav, kdy není fotografie vidět celá – v případě, že pracovní prostor galerie je velmi malý a fotografie neúměrně veliká, může bodové hodnocení dosáhnout i nulové hodnoty (záporné hodnoty BE jsou převedeny na nulu). Technologie z hlediska stáří použitého řešení a množství inovací. Uživatelská přívětivost: zde se odráží zejména ovládací prvky, logika použití aplikace apod. Design. Přenositelnost mezi prohlížeči a bezpečnost z hlediska otevřenosti kódu aplikace. Výsledky a jejich grafické zobrazení jsou uvedeny na konci kapitoly a dále v příloze 6.1 Grafy výsledků testování. 2.3.2
Testované aplikace
V souboru vybraných řešení jsem se soustředil na tři základní typy aplikací: webové prezentace (fotogalerie) Samostatné galerie určené primárně pro prezentaci fotografií. V naprosté většině případů používají strukturu zobrazení malých náhledů fotografií (thumbnails), které představují odkazy na obrázky ve vyšším rozlišení. Do této kategorie jsem zahrnul 25 26
To znamená, že pokud je pro galerii vymezeno 80 % plochy, získá 8 bodů. Jednotlivé poměry stran fotografie znamenají různou efektivitu využití plochy monitoru při dané šířce fotografie.
22 čistě webové služby (jiné viz násl.). Testovány byly služby webových alb pro amatéry i fotografické nadšence (např. Rajce.net, Web4photo), rozsáhlé CMS systémy (Coppermine), řešení zpravodajských serverů (iDnes, Reuters) i umělecké fotogalerie (L. Kamarád). generátory fotogalerií Aplikace, které primárně slouží jako lokální správce fotografií a obsahují nástroj umožňující jejich publikaci na webu (Zoner Photo Studio), nebo jsou samostatnými aplikacemi pro vytváření webových fotogalerií (Jalbum). doplňky prohlížeče Rozšíření běžných prohlížečů související s prezentací obrazových dat (Cooliris). Při výběru testovaných řešení jsem se snažil vybrat řešení tak, jak se vyvíjela v průběhu posledních cca 10 let od statických HTML řešení (Konica, Zoner), přes počátky využívání JavaScriptu a serverových skriptů, až k současným moderním řešením s využitím Flash objektů a AJAXu. Online prezentace byly navštíveny v druhé polovině listopadu 2008, u samostatných řešení byly použity dostupné aktuální zkušební verze. I.
Cooliris
Doplněk WWW prohlížeče [22]. (Velikost stažených souborů cca 11 MB.) Cooliris (dříve PicLens) umožňuje pro stránky se známou strukturou zobrazit náhledy odkazovaných obrázků na virtuální „3D“ zdi, po které se může uživatel poměrně rychle pohybovat, přibližovat si vybrané náhledy, případně je zobrazovat na celé obrazovce. Velkou předností této aplikace je implicitní celoobrazovkový režim a dále kvalitní převzorkování obrázků do požadované velikosti (náhled, celá obrazovka) včetně zobrazení zvětšeného náhledu do doby, než je stažena varianta s vyšším rozlišením. Nevýhodou pak minimální možnost uživatelské konfigurace i neprůhlednost kódu (bezpečnostní riziko). Pokud není k dispozici jako nainstalovaný doplněk prohlížeče, je možné Cooliris vložit do prezentace v podobě Flash objektu. Přínos pro vlastní návrh: Zahrnout podporu tohoto doplňku. Skóre efektivity: 7,8. 27 II.
Jalbum
Generátor fotogalerií [23]. Samostatná aplikace distribuovaná prostřednictvím spustitelného instalačního souboru. (Velikost stažených souborů cca 14 MB, velikost po instalaci zhruba 45 MB.) Přehledný program umožňující tvorbu galerií s adresářovou strukturou. Obsahuje množství šablon vzhledu (skinů) pro různé druhy fotogalerií (statické i používající skripty 27
Počítáno bez hodnot pro běh v okně, protože Cooliris využívá pouze celou obrazovku.
23 nebo Flash). Uživatel se základními znalostmi HTML či skriptování si dokáže poměrně snadno upravit některý ze skinů pro své potřeby. Velké množství skinů vytvořených uživateli je dostupné i na WWW portálu programu [23]. Při testování jsem použil skiny Fotoplayer a Slim Box 2, které považuji za dostatečně pokročilé. Není ovšem problematické vytvořit pomocí tohoto programu i zcela jednoduchou statickou fotogalerii. Přínos pro vlastní návrh: Rozsáhlé možnosti konfigurace. Skóre efektivity: 6,9. III.
Picasa / webová alba Picasa
Generátor fotogalerií / webová služba [24]. (Velikost stažených souborů cca 6 MB, velikost po instalaci zhruba 35 MB + katalog.) Výkonný nástroj pro správu lokálních obrázků poskytovaný zdarma. Výhodou je přímé propojení se službou webových alb Picasa. Nevýhodou pak automatické vyhledávání obrázků v počítači, které nelze vypnout ani rozumně omezit. Program ani nenabízí příliš možností konfigurace. Bohužel používáním služeb souhlasí uživatel (podle čl. 11 Podmínek… [25]) mimo jiné s tím, že k obsahu poskytovaného uživatelem službám Google (např. vystavení obrázku ve webovém albu) poskytuje firmě Google „časově neomezenou, neodvolatelnou, bezplatnou a nevýhradní licenci platnou ve všech zemích světa, která ji opravňuje reprodukovat, přizpůsobovat, upravovat, překládat, zveřejňovat, veřejně předvádět, veřejně zobrazovat a šířit“ tento obsah ve spojitosti se službami firmy Google (tedy i například užít klientovu fotografii v reklamě na jakékoli služby Google). V testu jsem se zaměřil na webové rozhraní služby tzn. Webová alba Picasa, které lze používat i samostatně. Aplikace je postavena mj. na technologii AJAX a podporuje změnu velikosti fotografií na základě akcí uživatele (zvětšení okna, skrytí panelu s podrobnostmi o uživateli, přechod do celoobrazovkového režimu, …). Užitečná je i možnost volby velikosti náhledů pomocí posuvníku (stejně jako je obvyklé u samostatných aplikací typu Zoner Photo Studio) a otáčení obrázků. AJAX umožňuje i prohlížení načtené fotografie ve vyšším rozlišení pomocí přetahování myší (drag and drop) a skrývání jednotlivých prvků stránky – zde možnost „zasunutí“ pravého panelu (bohužel vzniklé místo je použito pouze u náhledů, samostatná fotografie jej již nevyužije). S technologií souvisí i skutečnost, že prezentace ztrácí svou primární funkci, pokud uživatel zakáže vykonávání JavaScriptu. V průběhu testování dokonce aplikace několikrát přestala reagovat. Přínos pro vlastní návrh: Změny velikosti fotografie a náhledů, automaticky generovaný RSS feed. 28 Skóre efektivity: 6,0. 28
RSS feed: zdroj strukturovaných informací o obsahu používaný pro indexování obsahu, kontrolu aktualizací apod. Blíže viz [26].
24 IV.
Zoner Photo Studio (ZPS)
Generátor fotogalerií [27]. (Velikost stažených souborů cca 60 MB, velikost po instalaci zhruba 125 MB.) Český program, vyvíjený od poloviny 90. let, nyní v aktuální verzi 11 opět jen mírně inovoval šablony pro webové galerie (firma se zřejmě soustředí na ostatní funkce programu). Novinkou je zde podpora několika Flash galerií (s využitím modulů firmy Airtight [28]). Generované statické HTML galerie jsou již od verze 5 takřka beze změn. Přínos pro vlastní návrh: Airtight Flash šablony fotogalerií. Skóre efektivity: 3,8. V.
Adobe Lightroom
Generátor fotogalerií [29]. (Velikost stažených souborů cca 35 MB, velikost po instalaci zhruba 40 MB + katalog.) Profesionální nástroj pro katalogizaci a úpravy digitálních fotografií. Obsahuje publikační modul pro tvorbu WWW galerií s možností použití HTML i Flash šablon (předdefinované, stažené z Internetu, vlastní). Oproti ZPS není publikační modul nijak podceněn a vyznačuje se stejnou komplexností jako ostatní moduly (zahrnuje prohlížeč generovaného obsahu, velké množství konfigurovatelných položek, EXIF i IPTC popisování). Zejména možnost vytváření uživatelských galerií (podobně jako u programu Jalbum) znamená, že existuje velké množství již otestovaných hotových řešení, které jejich autoři většinou distribuují zdarma (viz např. TheTurningGate [30]). Práce s programem je díky výbornému grafickému rozhraní rychlá a příjemná. Přínos pro vlastní návrh: Propracované uživatelské rozhraní. Skóre efektivity: 7,8 (maximum v testu). VI.
Rajče.net
Webová služba – galerie [31]. Český projekt webové služby poskytující prostor pro ukládání fotografií, tvorbu fotoalb i hosting těchto alb na doméně služby. Obdoba služby Webová alba Picasa (viz výše). Výhodou této služby je původní české prostředí. Nahrávání snímků na server prostřednictvím samostatného programu je sice pohodlné a rychlé (k převzorkování fotografií dochází již na počítači klienta), ale jiná možnost nahrávání fotografií či změny prezentace není možná. Podobně jako Google i Rajče v článku 21 svých podmínek požaduje „souhlas k použití fotografií k propagování služby Rajče“ [32]. Poněkud nevhodně formulovaný je i článek 19, ve kterém si provozovatel vyhrazuje jednostranně změnit smluvní podmínky s účinností od zveřejněn změn. Z hlediska designu trpí Rajče zejména vertikálním vrstvením obsahu, kdy by přesunutí některých prvků do stran zřetelně rozšířilo plochu využitelnou pro fotografie. Hlavní panel zabírá u náhledů takřka třetinu výšky okna (200 px), při prezentaci fotografie již jen polovinu, ovšem titulek fotografie a ovládací prvky (vpřed, vzad) zabírají dalších 70 px. Tyto by přitom
25 mohly být jednoduše umístěny kamkoli jinam. Tyto nedostatky vyvažuje podpora Cooliris a rychlé odezvy aplikace. Přínos pro vlastní návrh: maximálně zjednodušit nahrávání fotografií; omezit grafické prvky designu. Skóre efektivity: 4,5. VII. Web4Photo.cz Webová služba – galerie. Placená galerie resp. „publikační systém pro fotografy“ [33] navržený s důrazem na jednoduchost. Přestože se jedná o komerční projekt, není zde vidět přílišná snaha o inovace a modernizaci. Design stránek je střídmý s tmavým pozadím. Bohužel je horizontálně omezený na zhruba 800 pixelů a vlastní prostor pro fotografie pak vertikálně zmenšuje stále přítomný hlavní banner (100 px) a menu (30 px). Grafické ovládací prvky pro změnu fotografií a oranžové odkazy kazí dojem z čistého vzhledu prezentace. Přínos pro vlastní návrh: střídmý a jednoduchý design. Skóre efektivity: 5,0. VIII. Coppermine Photo gallery (CPG) Webová služba – galerie [34]. Komplexní CMS systém (postavený na platformě PHP a MySQL) pro prezentaci fotografií zaměřený zejména na správu uživatelů, komentování a hodnocení. Pro CPG existuje velké množství témat (šablon vzhledu), případně je možné upravit vzhled ručně (pomocí kaskádových stylů). Při testování jsem použil vzhled z webu Olympus Friends Site (olympus.digitalne.eu), který se příliš neliší od stylu základního, ale je příkladem nezvládnutého začlenění fotogalerie do WWW portálu (žádný důraz na primární sdělení, minimální prostor pro fotografii, neustálá nutnost posunování stránky). Další šablony vzhledu je možno vyzkoušet v demoverzi portálu [34]. Přínos pro vlastní návrh: možnosti propojení s databází, vyvarovat se chyb v rozložení prvků stránky. Skóre efektivity: 4,2. IX.
Foto-album.cz
Webová služba – galerie [35]. Starší projekt sponzorovaný firmou Konica. Čistě webové řešení – serverem generované statické stránky. Používá HTML a tabulkový layout omezený na šířku 770 obrazových bodů. Do testu jsem jej zahrnul jako příklad starší technologie. Skóre efektivity: 3,3. X.
Fotoalbum.eu
Webová služba – galerie [36]. Nová služba založená na technologii AJAX. Nabízí neomezený prostor pro fotografie a jednoduché prostředí. Podporuje přetahování náhledů myší,
26 jednoduché promítání obrázků (slideshow). Jako náhledy používá čtvercové výřezy středu originální fotografie, což může být matoucí. Portál je přeložen do více jak 20 jazyků. Přínos pro vlastní návrh: jednoduchý design, jazyková podpora. Skóre efektivity: 4,9. XI.
Galerie vzorků dpreview
WWW album. Technicky zaměřená galerie prezentující snímky z redakcí testovaných fotoaparátů [37]. Zde je nutné prezentovat nejen podrobný popis fotografií (EXIF) ale i snímky v dostatečné velikosti včetně originálů. Zajímavé je řešení náhledů v podobě horního obrázku s klikací mapou 29 , „slepeného“ horizontálně z jednotlivých náhledů. Nešikovné je řešení navigace pouze pomocí posuvníků. Přínos pro vlastní návrh: Extrakce metadat z fotografie (EXIF, IPTC). Skóre efektivity: 5,7. XII.
Ladislav Kamarád
Umělecká fotogalerie [38]. Prvním zástupcem této kategorie je galerie známého českého fotografa používající statické HTML (starší technologie; zřejmě vlastní tvorba). Jedna z mála galerií, která používá poměrně velké náhledy (šířka 200 px). Celkový design galerie ovšem působí poněkud nedotaženě. Ochranou proti nelegálnímu použití autorských děl je zřejmě jen poskytnutí snímků v maximální šířce 900 pixelů. Přínos pro vlastní návrh: raději větší než menší náhledy. Skóre efektivity: 6,1. XIII. Jan Saudek Umělecká fotogalerie [39]. Prezentace zpracovaná odbornou firmou (WebConsult.cz [40]). Serverem generované statické stránky místy využívající JavaScript. Ochranou obsahu je opět pouze nízké rozlišení fotografií. Zajímavé je hlasování o fotografiích. Rozvržení stránky není příliš efektivní. Přínos pro vlastní návrh: hlasování, možnost chronologického řazení. Skóre efektivity: 2,4. XIV. iDnes Zpravodajský server [41]. Moderní prezentace fotografií zahrnující mimo jiné i přizpůsobení velikosti obrazu rozměrům okna, ochranu proti jednoduchému ukládání fotografií uživatelem (overlay) i ovládání prezentace klávesnicí. Fotogalerie na iDnes využívají skriptování na
29
Klikací mapa: obrázek, který je rozdělen do definovaných regionů představujících hypertextové odkazy.
27 straně serveru i klienta (Active Server Pages a JavaScript). V oblasti zpravodajství je zřejmě zvykem zobrazovat fotografie i náhledy současně, iDnes přináší i možnost zvětšení fotografie v nové překryvné vrstvě pomocí AJAXu. Zde pak je umožněno např. skrývání komentáře či přizpůsobení fotografie rozměrům okna. Celkově velmi moderní a povedené řešení. Přínos pro vlastní návrh: skrývání prvků stránky, ovládání pomocí klávesnice. Skóre efektivity: 2,8 (základní rozhraní – stránka s náhledy a fotografií). XV. Reuters Zpravodajský server [42]. Tento známý server používá pro prezentaci fotografií tabulkový layout a množství JavaScriptu. Opět tedy starší (nicméně funkční) technologie, která ovšem nikterak neupřednostňuje primární sdělení. Skóre efektivity: 2,1. XVI. National Geographic Server časopisu. Ze serveru National Geographic jsem zahrnul do testu dvě ukázky – první technologicky starší (HTML + JavaScript) [43] a druhou používající Flash [44]. Zvláště ve druhé ukázce je vidět nevhodné umístění galerie ve stránce. Velkým přínosem by jistě byla možnost spustit tuto Flash fotogalerii v celoobrazovkovém režimu. Přínos pro vlastní návrh: Publikovat zajímavé fotografie. Skóre efektivity: 2,5 (základní verze), 1,9 (Flash verze – minimum v testu). 2.3.3
Výsledky
V tabulkách na následující straně jsou uvedeny klíčové charakteristiky testovaných řešení (Tab. 2-3) a dosažená bodová hodnocení skóre efektivity (Tab. 2-4) i jednotlivých kritérií (Tab. 2-5). Grafické znázornění dosažených výsledků dle těchto tabulek je uvedeno na stranách I až V přílohy (část 6.1 Grafy výsledků testování). Výsledky jasně ukazují, že běžně používané aplikace pro prezentaci fotografií na Internetu stále nevyužívají prostor zobrazovacího zařízení efektivně. Jen několik aplikací bylo schopno změnit velikost fotografií tak, aby byla v okně prohlížeče zobrazena celá. V následující části jsou popsána kritéria tzv. ideální fotogalerie, která vznikne kombinací přínosných vlastností výše popsaných řešení.
28 Úpravy #
Název
Typ
Samostatně
Flash
(X)HTML
Java Script
Server Side
Online
Offline
Prezentace Online
Offline
Zdarma
Jazyk
1
Cooliris
doplněk prohlížeče
+
+
×
×
×
o
×
o
en
2
Jalbum
generátor galerií
o
o
o
o
+
×
o
o
+
o
en
3
Picasa Web Albums
generátor galerií
o
o
o
o
o
o
o
o
o
o
cz
4
Zoner Photo Studio
generátor galerií
o
×
o
o
×
×
o
o
o
×
cz
5
Lightroom & TTG
generátor galerií
o
o
o
o
+
o
o
o
o
+
en
6
Rajče.net
www album
+
×
o
o
+
o
×
o
×
o
cz
7
Web4Photo
www album
×
×
o
+
o
o
×
o
×
×
cz
8
Coppermine Photo Gallery
www album
×
×
o
+
o
o
×
o
×
o
cz
9
Foto-abum.cz
www album
×
×
o
o
+
o
×
o
×
o
cz
10
Fotoalbum.eu
www album
×
×
o
o
+
o
×
o
×
o
11
Dpreview sample gallery
www album
×
×
o
×
o
o
×
o
×
en cz
cz
12
Ladislav Kamarád
umělecká galerie
×
o
×
×
o
×
13
Jan Saudek
umělecká galerie
×
o
+
+
o
×
cz
14
iDnes
zpravodajství
×
o
o
+
o
×
cz
15
Reuters
zpravodajství
×
o
o
+
o
×
en
16
National Geographic
zpravodajství
×
o
+
+
o
×
en
17
National Geographic - flash zpravodajství
o
×
×
+
o
×
en
Legenda Technologie je podporována / využívána:
o
+
×
zcela
částečně
vůbec
nelze
Tab. 2-3 Využití jednotlivých technologií a určení účelu testovaných aplikací.
Z testu vyplynulo, že návrh ideální fotogalerie se může ubírat v zásadě dvěma směry: 1. Implementace galerie pomocí vloženého objektu. Tzn. oprostit se od omezení webového prohlížeče, který využijeme pouze pro spuštění vlastního kódu prostřednictvím vloženého objektu. Takovýmto objektem může být samostatná aplikace, doplněk WWW prohlížeče či vložený objekt (Flash animace, silverlight nebo Java aplet). Všechna tato řešení nám umožní takřka neomezené a tvůrčí zpracování obrazu včetně dostatečně silného algoritmického zpracování (např. pro změny rozměrů, 3D navigaci). Omezení takového řešení je zejména v přístupnosti. Uživatel si musí náš produkt stáhnout a nainstalovat. V případě, že se jedná o samostatnou aplikaci musíme uživatele přesvědčit, že náš program je bezpečný. V případě doplňku prohlížeče lze spoléhat na systém hodnocení doplňků uživateli i tvůrci prohlížeče (nabídka našeho doplňku v rámci oficiálního webu prohlížeče). Speciální doplněk, který nám umožní spustit objekt Flash či Java aplet, již má většina uživatelů nainstalovaný. Bohužel tato technologie je spojena i s tvorbou reklamních prvků stránek, a proto ji mnohdy uživatelé záměrně blokují. Vystavujeme se tak riziku, že taková galerie nebude na některých systémech funkční. 2. Galerie v rámci klasické WWW stránky. Zde se nabízí technologie skriptování na straně serveru i klienta. Možnost vypnutí klientských skriptů nás ovšem nutí i k realizaci statického řešení. Nejlépe tak, aby galerie byla funkční i bez zpracování skriptů klientem (byť bez některých nadstavbových funkcí). V případě, že budeme chtít použít moderní technologii AJAX (umožňující např. tvorbu více interaktivních grafických rozhraní), musíme se smířit s faktem, že se bez zapnutého JavaScriptu neobejdeme. 2.4.2
Kritéria ideální fotogalerie
Následující seznam obsahuje shrnutí přínosů testovaných aplikací. Kritéria jsou rozdělena do tří okruhů, kterým se budeme věnovat samostatně v následující kapitole, Aplikační logika (A), Uživatelské rozhraní (B), Obsah (C): 1. 2. 3. 4.
Přizpůsobení velikosti fotografie dostupnému prostoru. (A, B, C) Střídmý a jednoduchý design bez přemíry grafických prvků. (B) Skrývání jednotlivých prvků stránky. (A, B) Podpora Cooliris (Doplněk WWW prohlížeče pro zobrazení fotografií na celé obrazovce. Vyžaduje zdroj metadat ve formátu MediaRSS viz dále.) (A, B) 5. Publikovat zajímavé fotografie. (C)
30 6. Maximálně funkční a přívětivé uživatelské rozhraní. (B) 7. Možnost uživatelské konfigurace rozhraní. (B) 8. Automatické generování RSS (tj. zdroje metadat pro doplněk Cooliris a případné odebírání obsahu pomocí tzv. RSS čteček – umožňuje upozornit uživatele na změny v obsahu prezentace. Blíže viz Interval.cz [26] a [15]). (A, C) 9. Možnost využití Flash fotogalerií z produkce Airtight studia (volně dostupné a efektní Flash aplikace pro zobrazení fotografií, které jsou poměrně snadno začlenitelné do struktury stránky viz [28]). (B) 10. Maximálně jednoduché nahrávání obrázků a editace alb. (B, A) 11. Možnost využití databáze jako úložiště dat. (A) 12. Vyvarovat se omezení místa pro galerii při jejím začleňování do větších portálů. (B) 13. Podpora více jazyků. (B) 14. Zahrnutí metadat získaných z EXIF/IPTC hlaviček fotografií. (A, C) 15. Nastavitelná velikost náhledů včetně větších rozměrů. (A, B, C) 16. Možnost hlasování (tj. hodnocení fotografií uživatelem) a komentářů. (A, C) 17. Možnost chronologického řazení (obecně filtrování dle metadat). (A, B) 18. Ovládání fotogalerie pomocí klávesnice. (A, B)
2.5
Souhrn druhé kapitoly
Vývoj standardů Internetu na základě prvotní textové komunikace i různé technologické aspekty způsobily nedostatečně robustní implementaci prezentace obrazových dat na WWW. Nejednotnost proprietárních řešení jednotlivých prohlížečů částečně odstranilo až zavedení CSS a nových technologií (např. Flash). V současnosti již není tolik problémem datový objem a nedostatek výpočetního výkonu, jako nedostatečné možnosti vyhledávání v obrazových datech a bezpečnostně právní rizika. Testování 16 různých řešení WWW prezentace fotografií ukázalo, že v současné době stále není kladen dostatečný důraz na fotografii jako primární sdělení, ani není efektivně využívána dostupná plocha zobrazovacího zařízení. Z hlediska technologie se používají kontejnerové objekty typu Flash či kombinace (X)HTML a skriptů. Bezpečnostní omezení skriptovacích technologií ale samozřejmě funkčně zvýhodňují řešení využívající instalaci samostatné aplikace (tzv. generátory galerií). V poslední době se objevují i řešení formou doplňku již nainstalovaného WWW prohlížeče. Ochrana fotografií proti neoprávněnému užití je pak prakticky omezena jen na nejjednodušší techniky zamezující přímému uložení fotografie. Následující kapitola je věnována návrhu řešení s důrazem na využití dostupné plochy a zdůraznění fotografie jako primárního sdělení.
31
3.
Vlastní návrh fotogalerie
V této kapitole je teoreticky rozebrán návrh aplikace pro prezentaci obrazových dat v prostředí Internetu z hlediska obsahu, uživatelského rozhraní a aplikační logiky. Z hlediska použité technologie je zvolena klasická serverem generovaná HTML prezentace s částečným využitím klientských skriptů. Těžiště programu je tak umístěno do serverové části aplikace. Technologie Flash je zahrnuta pouze jako doplněk a vlastní řešení je na ní nezávislé. 30 Aplikace je navrhována jako samostatná, případné začlenění do jiné struktury (např. WWW portál, fórum apod.) je z hlediska upřednostnění obsahu doporučeno řešit jednoduchým propojením odkazem, případně otevřením v novém okně nebo překryvné vrstvě, pokud je takové řešení k dispozici. Nejprve je popsán postup tvorby návrhu aplikace od určení obsahu, přes návrh uživatelského rozhraní až k technologickému řešení. V závěru každé části jsou shrnuty jednotlivé body návrhu.
3.1
Obsah
Předpokládaný obsah prezentace je pro zjednodušení rozdělen do tří kategorií: Ovládací prvky: tzn. navigace mezi jednotlivými sekcemi prezentace, odkazy pro změny stavu aplikace (např. skrytí panelu s navigační lištou), jejich popis a grafika rozvržení stránky (např. oddělující čáry). Tyto prvky obsahu jsou blíže popsány v části 3.2 Uživatelské rozhraní. Vlastní fotogalerie: fotografie, náhledy, ovládání fotogalerie, názvy a popisky, metadata (EXIF/IPTC). Ostatní data: články, nápověda a obdobné sekce. Zde je uveden i dynamicky generovaný obsah (metadata, RSS). 3.1.1
Vlastní fotogalerie
Předem je nutné zdůraznit, že na rozdíl od textu (psané formy řeči), který je čtenářem vnímán po částech, od předem definovaného počátku známým směrem k jasnému konci, obrazová data jsou vnímána zcela jinak. Obraz divák neidentifikuje vůči jasně danému „vizuálnímu jazyku“ [45]. Zatímco text je umělou reprezentací reality, fotografie je přímým (ač nedokonalým) zobrazením této reality. Proto divák vnímá obraz naprosto odlišným (přirozenějším způsobem). Nelze tedy uvažovat o prezentaci fotografií v „textovém“ kontextu, tedy tak, jako by tato data byla jednoduše zaměnitelná.
30
Zdůvodnění těchto voleb naleznete v sekci 3.3 Aplikační logika.
32 Nejčastější chybou z této oblasti byla u testovaných řešení právě snaha začlenit fotografie do zcela stejného prostoru Otevření galerie jako text. 31 Výsledkem je mnohdy zobrazení pouze části fotografie, což vede k nedokonalé a zmatečné interpretaci Zobrazení náhledů takového obrazu divákem. Stejně tak u ostatních obrazoKliknutí na náhled vých dat (grafy, schémata, obrazy apod.) – ačkoli může být takový obsah značně zjednodušený a běžně používaný Otevření fotografie (např. graf), stále zde existuje množství různých variant prezentace téhož. 32 Divák pak velmi pravděpodobně nebude Zpět k náhledům schopen přesně identifikovat a interpretovat předložený Obr. 3-1 Diagram průchodu obraz, pokud z něj uvidí pouze část, ve které mohou chybět starší galerií. sdělení zcela zásadní pro správnou interpretaci (například legenda grafu). Základní podmínkou je tedy předložení celého obrazu i za cenu ztráty některých detailů. Vyšší rozlišení je možné divákovi poskytnout posléze (kdy již je seznámen s celkový kontextem). Starší návrhy fotogalerií takřka bez výjimky používaly k navigaci náhledy s odkazy na větší variantu fotografie (viz diagram 3-1 nahoře). Dále byly přidány navigační prvky při zobrazení zvětšené fotografie (předchozí, následující, náhledy) ať již v grafické nebo v textové podobě. Zejména u moderních Flash galerií se setkáváme i s variantami bez náhledů (např. AirTight [28] AutoViewer), či pouze s náhledy (AirTight TiltViewer). V návrhu galerie je zvolena varianta současného zobrazení fotografií i náhledů s možností panel s náhledy jednoduše skrýt. Náhledy také mohou být zobrazeny na místě primárního obsahu (místo fotografie) – zde je také navržena možnost volby velikosti náhledů (viz schéma napravo). Při zobrazení fotografie jsou v případě existence předchozího či následujícího snímku zobrazeny i odkazy na tyto snímky. Je vhodné,
31 32
<<Úvodní foto>>
Konec? [Ano]
[Ne]
Změna fot.
[Ne]
<>
Náhledy
Fotografie
[Ano]
[Ne]
Kliknutí na náhled/navigace
Obr. 3-2 Schéma procházení navrhovanou aplikací.
Viz např. implementace Coppermine Photo Gallery v CMS systému United Nuke 2.3.2-VIII. Zatímco číst se všichni učíme již na základní škole, interpretace např. bublinového grafu či mapy pro orientační běh je již považována za nadstandardní znalost. Zjednodušeně řečeno není žádný standardní způsob, jak se „dívat“ na grafické vyjádření informací ekvivalentní „čtení“ textu. Každý čtenář přečte to samé, ale každý divák „uvidí“ obraz poněkud odlišně, protože interpretace obrazu je prováděna „více podvědomě“, neverbálně, na rozdíl od překladu čteného textu na slova.
33 aby tyto navigační prvky nebyly zobrazeny rušivě, nejlépe pouze jen tehdy, kdy jsou potřeba (pozornost diváka je určena navigaci, nikoli fotografii). Důležitou součástí prezentace obrazových dat je i textový kontext upřesňující individuální výklad obsahu divákem (pokud je to samozřejmě potřeba). Jedná se zejména o název a popis, případně vysvětlivky. Návrh je postaven tak, aby tento obsah byl poskytován pouze na vyžádání, resp. mohl být jednoduše skryt. Do textového kontextu jsou zařazena i metadata umístěná v zobrazovaných souborech (např. EXIF). Tato data je nutno automaticky extrahovat a převést do přijatelné podoby. V případě nahrávání fotografií s již vloženým popisem pak odpadá časově náročné opětovné popisování. V neposlední řadě je nutno zmínit i potřebu prezentace kvalitního obsahu z hlediska estetického případně odborného. 3.1.2
Ostatní obsah
Jak již bylo řečeno v úvodu kapitoly, návrh předpokládá implementaci jako samostatnou webovou aplikaci. Je tedy nutné umožnit i zobrazení jiného než obrazového obsahu (navigace, popis, nápověda). Serverová část aplikace musí být navržena tak, aby obsah jednotlivých částí prezentace byl zaměnitelný. Zejména to platí pro primární zobrazovací prostor, kde bude zobrazena buď fotografie, nebo jiný obsah – obecně jakékoli HTML. Pokud je cílem maximálně zdůraznit prezentované fotografie, je nutné se vyvarovat předkládání obsahu, který by vůči nim působil rušivě, odváděl divákovu pozornost či jinak znehodnocoval výsledné sdělení. Nevhodné jsou zejména reklamní proužky (zvláště pak pohyblivé), výrazné grafické prvky designu stránky, kontrastní či nepřiměřeně velké textové titulky. Je nutno vyvarovat se opakování stále stejného informačního sdělení. 33 U prvků, které se v prezentaci opakují, je vhodné umožnit jejich skrytí či vhodně umenšit naléhavost jejich sdělení (např. zmenšit logo, titulek). Galerie bude obsahovat metadata v podobě XML souboru podle standardu MediaRSS [15] umožňující spouštět doplněk Cooliris, případně odebírat obsah pomocí jakékoli čtečky RSS kanálů. 3.1.3 1. 2. 3. 4.
33
Kritéria návrhu obsahu Zobrazení celých fotografií. Základní zobrazení náhledů i fotografie s možností skrytí náhledů. Možnost zobrazení náhledů v primárním prostoru a volitelné nastavení jejich velikosti. Omezit obsahové rušivé prvky (např. reklamní proužky).
Pokud již jsme uživateli sdělili, jak se naše prezentace jmenuje, není důvod opakovat tento titulek na každé stránce stejně důraznou formou.
34 5. 6. 7. 8. 9.
3.2
Na vyžádání zobrazovat textový kontext (minimálně název a popis) s možností opětovného skrytí. Do textového kontextu automaticky zahrnout metadata. Kvalitní obsah. Umožnit zobrazení obecného HTML obsahu v prostoru pro primární sdělení (články, nápověda a další). Zahrnout zdroj RSS podle standardu MediaRSS a tím i podporu Cooliris.
Uživatelské rozhraní
Základním kritériem pro návrh uživatelského rozhraní je požadavek na maximalizaci pracovního prostoru fotogalerie. Splnění tohoto kritéria je dosaženo pomocí mechanismu, který umožňuje skrývání jednotlivých prvků prezentace. Dále je přihlédnuto k požadavku jednoduchosti a čistotě designu z důvodu přirozeného zdůraznění fotografií. Z hlediska přístupnosti je vhodné aplikovat pravidla návrhu přístupného webu (viz [17]) a dále vytvořit alespoň anglickou jazykovou mutaci. 34 3.2.1
Obr. 3-3 Příklady rozvržení panelů v zobrazeném i skrytém stavu.
Panely
Podobně jako v některých testovaných řešeních (např. Adobe Lightroom) je ostatní obsah rozdělen do čtyř panelů při okrajích obrazovky. Tyto panely je možné minimalizovat do podoby úzké lišty, případně je kliknutím na tuto lištu opět zobrazit v plné velikosti. Panely je také možno zcela zavřít (zde je nutné dát uživateli možnost znovuotevření panelu – tj. zobrazit příslušný ovládací prvek v jiném umístění). Příklady možných konfigurací panelů jsou uvedeny výše (Obr. 3-3). V zásadě nic nebrání tomu, aby obsah jednotlivých panelů byl konfigurovatelný uživatelem. Uživatel by si tedy mohl přizpůsobit rozhraní aplikace svým potřebám a preferencím. Jednodušší varianta umožňuje pouze záměnu obsahu svislých resp. vodorovných panelů, kdy není nutné provádět transpozici obsahu z horizontálního roz-
34
Obr. 3-4 Překrývání panelů.
Minimálně pro texty využívané při průchodu stránkou. Tzn. texty navigačních prvků, popisky, odkazy apod. Toto lze zjednodušit použitím srozumitelných piktogramů, které by ovšem měly být opatřeny nějakou formou nápovědného textu (v příslušném jazyce) pro případ, kdy nejsou zobrazeny obrázky či je uživatel přece jen zmaten.
35 vržení do vertikálního a naopak. Co se týče překrývání panelů v rozích obrazovky (viz Obr. 3-4), existuje varianta, kdy k překrývání docházet nebude, nebo využití veškerého místa na panelu s tím, že některé prvky nebudou vidět neustále (takto je vlastně prostor překrytí panelů využit dvakrát). Návrh počítá s řešením, kdy se aktuálně používaný panel (lze se řídit např. podle umístění kursoru myši) stane aktivním a zobrazí se celý v popředí. Po ukončení práce s panelem se tento vrátí do své výchozí pozice. Stejným mechanismem by bylo možné řešit i interaktivní skrývání a zobrazování panelů, kdy by se panel zobrazil po přesunutí kursoru myši k danému okraji obrazovky (či nad zobrazenou lištu). 35 Technické aspekty řešení těchto variant jsou popsány v sekci 4.1.2 Panely a maximalizace pracovního prostoru. V návrhu bylo v základním zobrazením zvoleno řešení, kdy lišty jsou zobrazovány po kliknutí myší, což odpovídá zažitému vzoru WWW prezentace a tím bude jednodušší první uživatelovo seznámení s prostředím aplikace. Jiné možnosti zobrazování panelů mohou být přístupné volitelně. 3.2.2
Design
Otázka designu prezentace je zřejmě nejsubjektivnější. Z testování řešení vyplynulo, že zvláštní důraz na design kladou spíše tvůrci Flash řešení (AirTight). Tyto šablony pak občas trpí právě přemírou efektů na úkor vlastních fotografií. Služby typu Picasa či Rajče jsou naopak dle mého názoru poznamenány tlakem na programovou stránku aplikace (nové funkce, robustnost, uživatelská přívětivost). Design vlastních stránek pak již vypadá jakoby druhořadý, resp. důraz na něj se přesouvá až do nadstandardních funkcí (např. slideshow). Design fotogalerie by měl dle mého názoru, podobně jako jakákoli prezentace, zdůrazňovat předkládaný obsah – nesnažit se ohromit a přitáhnou pozornost diváka přemírou různých efektů. V návrhu se navíc snažím omezit grafické prvky vlastní stránky (tzn. různé rámečky, pozadí, odrážky, stíny apod.) s úmyslem vytvořit u diváka dojem jedinečnosti prezentovaného obsahu, tedy fotografie, v kontextu celé prezentace. Stejně jako u jakékoli jiné WWW prezentace je nutné dodržovat zásadu přehlednosti a střídmosti. Návrh dále počítá s implementací více variant vzhledu. Základní sada by měla obsahovat tmavé a světlé téma 36 a motiv respektující elementární pravidla navrhování webu přístupného hendikepovanými uživateli (min. dostatečně kontrastní text oproti pozadí – dále viz [17]). Kritéria pro design jsem formuloval velice obecně, bližší vizuální podoba návrhu je uvedena v příloze 6.2.2 Ukázková aplikace.
35 36
Stejně jako se chová hlavní nabídka (lišta) systému Windows pokud je nastavena na automatické skrývání. Otázkou je např. nejvhodnější barva pozadí při prezentaci fotografií. Z estetického hlediska není příliš vhodná neutrální šedá, která ovšem omezuje přílišné střídání kontrastu při změně fotografie ze světlé na tmavou apod. Existující řešení běžně volí mezi černou a bílou barvou, proto jsou v návrhu zavedeny obě varianty.
36 3.2.3 1. 2. 3. 4. 5. 6.
3.3
Kritéria návrhu uživatelského rozhraní Maximalizace pracovního prostoru formou panelů s možností skrytí/uzavření. Zaměnitelnost obsahu panelů (uživatelsky konfigurovatelné). Interaktivní zdůraznění právě používaných prvků stránky. Jednoduchý a střídmý design zdůrazňující primární obsah. Minimální použití grafických prvků pro zdůraznění vlastní fotografie. Přístupný web.
Aplikační logika
3.3.1
Struktura aplikace
Všechny aktivity obsluhované aplikací jsou přehledně uvedeny v jednoduchém diagramu případů užití na Obr. 3-5. Aplikace zajišťuje tři druhy činností – vytváření, zobrazení a správu obsahu. Zároveň by měla být dostatečně odolná proti případnému napadení. Registrovat se Nahrát fotografie Fotograf
Divák
Zobrazit galerii
Upravit metadata Smazat fotgrafie
Spravovat
Získat cizí práva
Získat obsah
Webmaster
Hacker
Obr. 3-5 Diagram případů užití navrhované aplikace. Velikost symbolů odpovídá předpokládanému rozsahu dané aktivity resp. počtu uživatelů v dané skupině. Přerušované šipky naznačují nepřípustné aktivity.
3.3.2
Volba technologie
Jak již bylo zmíněno v závěrech testování (2.4.1), cílem je navrhnout aplikaci, která není závislá na konkrétní technologii volitelně podporované klientem. V současnosti většina uži-
37 vatelů Internetu používá jeden z následujících WWW prohlížečů: Microsoft Internet Explorer, Mozilla Firefox a Opera [46]. Je možné konstatovat, že všechny tyto prohlížeče přinášejí dobrou a velice podobnou 37 podporu technologií: (X)HTML, CSS, DOM, JavaScript, DHTML, XML+XSLT. Většina uživatelů má nainstalovány proprietární doplňky pro přehrávání multimédií, zobrazení Flash obsahu a spouštění Javy. Bohužel z hlediska bezpečnosti, případně kvůli individuálním potřebám, mají někteří uživatelé přístup k těmto technologiím omezen. Jedná se zejména o podporu technologie Java, Flash a JavaScript. Pro maximální přístupnost proto bylo zvoleno využití klasického HTML generovaného na straně serveru s nikoli esenciální podporou klientského JavaScriptu a možností zobrazení obsahu fotogalerie i ve formátu Flash. Technologii Flash navíc diskriminuje i nižší indexovatelnost vyhledávacími roboty. Z hlediska uživatelského rozhraní by bylo zajisté nejvhodnější použít technologii AJAX, kdy jsou požadavky serveru zasílány asynchronně a vyhodnocování odpovědí klientem nevyžaduje překreslení celé stránky. Tato technologie je ale postavena na JavaScriptu, což by sice na jedné straně znamenalo přenesení valné části vykonávání kódu na stranu klienta (např. veškeré změny rozložení uživatelského rozhraní – skrývání panelů, přenášení do popředí apod.), na druhé straně by zakázání vykonávání JavaScriptu bylo pro naši prezentaci fatální. 38 3.3.3
Generování obsahu
Jak již bylo řečeno, vlastní generování obsahu je prováděno na straně serveru. Zde je možné zvolit takřka jakoukoli technologii – od klasických (PHP, ASP.NET, JSP) až po proprietární serverové aplikace. Nabízí se i možnost volby mezi využitím databáze, či ukládáním fotografií přímo na server (např. rovnou s XML soubory s metadaty). Z hlediska vlastní funkčnosti aplikace je volba jakým způsobem server dané úkoly zajistí podružná. Server má v podstatě dva úkoly: zajistit transformaci dat do formy (X)HTML + CSS (styly je také možné generovat dynamicky) a zajistit ukládání informací o stavu aplikace – tzv. správu relace (session), aby bylo možné správně reagovat na požadavky klienta. Samostatnou otázkou je způsob přizpůsobení fotografie dostupnému pracovnímu prostoru. Lze to provádět na straně serveru, kdy server dynamicky generuje obraz v požadované velikosti, nebo na straně klienta, kde stejnou úlohu provede klientský skript (v případě, že je k dispozici) nebo vlastní prohlížeč. Zmenšení obrazu prohlížečem je zřejmě nejjednodušší variantou (stačí nastavit atributy WIDTH a HEIGHT tagu IMG), ovšem stále ještě nejsou výsledky zcela uspokojivé z důvodu
37 38
Tedy velice podobnou příslušným W3C standardům. Na AJAXu založený web zatím nelze (přes veškeré jeho masivní využívání v poslední době) označit jako přístupný. Jediným řešením je vytvářet dvě na sobě víceméně nezávislé varianty rozhraní aplikace podle dostupnosti podpory JavaScriptu – viz např. standardní a HTML rozhraní Gmailu.
38 použití rychlých algoritmů. Změna velikosti na straně klienta také znamená nutnost přenášení originálních dat, která tímto nejenže poskytneme uživateli, ale jejich objem může být velmi velký a tím zpomalit proces nahrávání stránky. Zmenšení klientským skriptem přichází do úvahy v případě použití robustních řešení s již implementovanými algoritmy pro změnu velikosti obrazu (např. Java). Vlastní řešení pomocí JavaScriptu by bylo nejen pomalé, ale i velmi pracné. Výhodou úprav obrazu na straně klienta je ovšem nutnost přenášet obraz pouze jednou (pokud správně funguje cache prohlížeče). Změna velikosti obrazu na straně serveru nám umožňuje plnou kontrolu nad výsledným obrazem i zavedení elementárních technik pro ochranu obrazu proti kopírování. Nevýhodou je vyšší zátěž serveru, kterou ovšem můžeme částečně eliminovat pomocí zařazení nějaké formy cache paměti pro již vygenerované obrazy (aby se obraz daných rozměrů mohl použít znovu – např. při opakovaném skrytí/zobrazení některého panelu, kdy se střídají pouze dvě velikosti obrazu). 3.3.4 1. 2. 3. 4. 5. 6. 7.
Kritéria návrhu aplikační logiky Zajištění obsluhy aktivit dle Use Case diagramu (Obr. 3-5). Technologie HTML (příp. XHTML) s využitím CSS. Technologie generování obsahu serverem. Nikoli esenciální využití klientského skriptu. Nadstandardně možnost předložení obsahu ve Flash formátu. Zajištění sledování stavu aplikace (relace). Generování obrazu v dané velikosti na straně serveru.
39
4.
Realizace návrhu
V této kapitole je popsán postup realizace ukázkové fotogalerie umístěné na webové adrese http://jhs.vlkov.eu/galerie. Ukázka je naprogramována s použitím PHP skriptu 39 na straně serveru a JavaScriptu na straně klienta. V průběhu popisu jsou diskutována alternativní řešení a také je poukázáno na některá problémová místa. Ukázka si neklade za cíl splnit všechna „kritéria ideální fotogalerie“ z minulé kapitoly, ale pouze ilustrovat, že základní koncept je správný a v současnosti bez problémů realizovatelný. Na konci kapitoly je zhodnoceno ukázkové řešení podle testovacích kritérií z druhé kapitoly (2.3.1) a diskutována další možná rozšíření a stávající nedostatky. Relevantní části zdrojového kódu aplikace jsou uvedeny v příloze 6.3 Zdrojové kódy skriptů. Schéma činnosti aplikace je k nahlédnutí v jednoduchém diagramu na Obr. 4-1 (str. 42).
4.1
Programový kód
4.1.1
Základní nastavení a inicializace aplikace
Nejprve byla vytvořena adresářová struktura oddělující data galerií od souborů základní prezentace – to bude využito při pozdějším automatickém nahrávání souborů na server k ochraně uložených dat (přístup do takových adresářů mají pouze PHP skripty z vlastního serveru). PHP obsahuje funkce pro správu relace (session), která zajišťuje identifikaci konkrétního klienta. Speciální ID každé session může být předáváno buď přímo v parametru URL nebo pomocí uložení tzv. session cookie u klienta (tyto session cookies se mažou při uzavření okna prohlížeče a nezůstávají tedy v systému klienta). Ukázka využívá v rámci zjednodušení session cookies, které mohou být v určitých případech zakázány (spolu s ostatními cookies). V zásadě by ale nebylo obtížné změnit způsob předávání tohoto parametru. V session datech jsou uloženy informace o současném stavu aplikace u daného klienta (např. aktivní panely, podpora JavaScriptu, viz dále). Požadavky klienta jsou serveru předávány prostřednictvím metody GET přímo pomocí parametrů v URL. Vzniklé adresy nejsou příliš efektní a bylo by možné je optimalizovat například pomocí modulu mod_rewrite serveru Apache. 40 Po otevření URL fotogalerie dojde k následujícím krokům: PHP skript ověří, zda lze na cílovém systému ukládat cookies a pokud uspěje, spustí relaci. Do session jsou v tu dobu uloženy následující implicitní údaje (tyto lze případně uživatelsky konfigurovat):
39
Prezentace běží na serveru Apache, instalováno je PHP verze 5.2.0-8+etch11, hosting: station.cz. Prezentace by měla být funkční přinejmenším do konce roku 2009, jinak využijte zdrojové soubory z přiloženého CD. 40 Tento modul se postará, aby např. adresa.stranky/hodnota1/hodnota2 bylo v serveru předloženo jako adresa.stranky?parametr1=hodnota1¶metr2=hodnota2 apod. Blíže viz [47].
40 rozměry jednotlivých panelů v otevřeném stavu (pro každý panel zvlášť) rozměr panelu v minimalizovaném stavu, tj. šířka resp. výška lišty podpora JavaScriptu (logická proměnná na základě které se vkládají funkce využívající klientský skript, počáteční hodnota je pravda) id panelu, který má být v popředí (horní panel) Dále jsou definovány funkce JavaScriptu pro získání rozměrů okna a nahrání hlavní stránky s předáním těchto parametrů – funkce initscr(). Pokud není JavaScript dostupný, musíme zkusit rozměry uhodnout, či se zeptat uživatele. V ukázce je zahrnuto řešení s oznámením o nefunkčnosti JavaScriptu a volbou zobrazení obsahu prezentace o rozměrech 800 × 600, 1024 × 768, 1280 × 800 či 1600 × 1200 pixelů. Toto oznámení je v těle stránky umístěno v elementu
';
//výpis obsahu dle podpory JS if ($_SESSION["orig"]["script"]): echo '
//kontrola session, jinak návrat na index.php if (!array_key_exists('orig', $_SESSION)): header ("HTTP/1.0 302 Found"); header("Location: index.php"); endif;
// získání popisu galerie a nastavení aktivní galerie (později engine pro různé galerie) require_once("galerie_data"); $agal = $gal1;
//kopírování originálních hodnot do pole, kde se budou měnit if (!array_key_exists('panely', $_SESSION)): $_SESSION['panely'] = $_SESSION['orig']; endif;
//kontrola nastavení vzhledu, podpory JS a ID obsahu if (isset($_GET['stl'])): $_SESSION['vzor'] = $_GET['stl']; elseif (!array_key_exists('vzor', $_SESSION)): $_SESSION['vzor'] = 0; endif; if (isset($_GET['nojs'])): $_SESSION['panely']['script'] = false; endif; if (isset($_GET['obsah'])): $_SESSION['panely']['obsah'] = $_GET['obsah']; endif;
//kontroluje který panel je aktivní a případně upraví pozici; argument: ID panelu function act($co){ if ($_SESSION["panely"]["a"] == $co): $out = "z-index: 9;"; else: $out = ""; endif; return $out; }
//definice externích CSS souborů vzhledu a funkce kontrolující existenci vzoru (dle pořadového čísla a vracející jméno příslušného souboru; argument: pole názvů stylů $stl = array("base.css", "base1.css", "terminal.css"); function vzor($kde){ if (array_key_exists($_SESSION["vzor"], $kde)):
XVII return $kde[$_SESSION["vzor"]]; else: return "base.css"; endif; }
//vypisuje JS kód pro vymazání okrajů aktivního odkazu pokud je JS povolen function ofa(){ return ($_SESSION['panely']['script'])?'onfocus="this.blur()"':'';} //vkládá správné pozadí do lišty dle stavu panelu function sz($co){ if ($_SESSION["panely"][$co] > $_SESSION["panely"]["pw"]): switch ($co): //skrýt case "nahore": return 'style="background-image: url(\'images/t.png\') !important;">'; break; case "dole": return 'style="background-image: url(\'images/b.png\') !important;">'; break; case "vpravo": return 'style="background-image: url(\'images/r.png\') !important;">'; break; case "vlevo": return 'style="background-image: url(\'images/l.png\') !important;">'; endswitch; else: switch ($co): //zobrazit case "nahore": return 'style="background-image: url(\'images/b.png\') !important;">'; break; case "dole": return 'style="background-image: url(\'images/t.png\') !important;">'; break; case "vpravo": return 'style="background-image: url(\'images/l.png\') !important;">'; break; case "vlevo": return 'style="background-image: url(\'images/r.png\') !important;">'; endswitch; endif; }
//na základě aktuální velikosti panelu jej minimalizuje nebo maximalizuje a nastaví jako aktivní, pak zavolá funkci pro změnu velikosti obsahu; argument: ID panelu function zmenstav($ceho){ if ($_SESSION["panely"][$ceho] > $_SESSION["panely"]["pw"]): $_SESSION["panely"][$ceho] = $_SESSION["panely"]["pw"]; else: $_SESSION["panely"][$ceho] = $_SESSION["orig"][$ceho]; $_SESSION["panely"]["a"] = $ceho; endif; resobsah(); }
//zavře / otevře panel; argument: ID panelu function skryj($ceho){ if (jepan($ceho,0)): $_SESSION["panely"][$ceho] = 0; else: $_SESSION["panely"][$ceho] = $_SESSION["orig"][$ceho]; endif; resobsah(); }
//vrací zda je panel vidět při $p = 0, či zda je minimalizovaný při $p = 1; argument: ID panelu, klíč dotazu; používá se pro určení zda vypisovat celý obsah panelu, jen lištu, či nic. function jepan($co, $p){
XVIII switch ($p): case 0: return ($_SESSION["panely"][$co] > 0); break; case 1: return ($_SESSION["panely"][$co] > ($_SESSION["panely"]["pw"])); break; default: return false; endswitch; }
//z dostupných rozměrů okna a velikosti panelů vypočte velikost prostoru pro obsah function resobsah(){ $_SESSION["panely"]["w"] = $_SESSION["panely"]["scrw"] ($_SESSION["panely"]["vlevo"] + $_SESSION["panely"]["vpravo"]+2); $_SESSION["panely"]["h"] = $_SESSION["panely"]["scrh"] ($_SESSION["panely"]["nahore"] + $_SESSION["panely"]["dole"]+2); $_SESSION["panely"]["ih"] = $_SESSION["panely"]["h"] - 2; }
//pokud jsou v URL zadány rozměry, provede aktualizaci session a změnu rozměrů if (isset($_GET['scrh']) and isset($_GET['scrw'])): $dores = true; $_SESSION["panely"]["scrw"] = $_GET['scrw']; $_SESSION["panely"]["scrh"] = $_GET['scrh']; resobsah(); endif;
//provedení skrytí/zobrazení panelů podle parametrů URL (je kontrolována pouze existence parametru, jeho případná hodnota se nikde nepoužívá) if (isset($_GET["l"])): zmenstav("vlevo"); $_SESSION["panely"]["a"]="vlevo"; endif; if (isset($_GET["r"])): zmenstav("vpravo"); $_SESSION["panely"]["a"]="vpravo"; endif; if (isset($_GET["b"])): zmenstav("dole"); $_SESSION["panely"]["a"]="dole"; endif; if (isset($_GET["t"])): zmenstav("nahore"); $_SESSION["panely"]["a"]="nahore"; endif; if (isset($_GET["a"])): $_SESSION["panely"]["nahore"] = $_SESSION["panely"]["pw"]; $_SESSION["panely"]["vpravo"] = $_SESSION["panely"]["pw"]; $_SESSION["panely"]["dole"] = $_SESSION["panely"]["pw"]; $_SESSION["panely"]["vlevo"] = $_SESSION["panely"]["pw"]; $_SESSION["panely"]["a"]="nahore"; resobsah(); endif;
// zavírání panelů podle parametrů v URL if (isset($_GET["ht"])): skryj("nahore"); $_SESSION["panely"]["a"]="vlevo"; endif; if (isset($_GET["hr"])): skryj("vpravo"); $_SESSION["panely"]["a"]="vlevo"; endif; if (isset($_GET["hb"])): skryj("dole"); $_SESSION["panely"]["a"]="vlevo"; endif;
//vypisuje ovládací blok pro zavření či otevření panelů (implicitně je umístěn nahoře v levém panelu) function dejPanely(){ $pan = array("ht" => "horní panel","hr" => "pravý panel","hb" => "dolní panel");//, "hl" => "levý panel");
'; } ?> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">Fotogalerie main
//pokud je zobrazena galerie, vkládá odkaz na mediaRSS feed pro Cooliris if (isset($_SESSION['panely']['obsah']) && $_SESSION['panely']['obsah'] == 'gal'): echo ''; endif;
//vložení propojení s vybraným externím stylem echo '';
//definice funkcí JS pokud je podporován if ($_SESSION["panely"]["script"]): echo ' <script type="text/Javascript" language="JavaScript"> function getClientWidth(){ return document.compatMode=='CSS1Compat' && !window.opera?document.documentElement.clientWidth:document.body.clientWidth;} function getClientHeight(){ return document.compatMode=='CSS1Compat' && !window.opera?document.documentElement.clientHeight:document.body.clientHeight ;} function doresize(){ top.location='main.php?scrw='+getClientWidth()+'&scrh='+getClientHeight(); }
//nastavení obsluhy události onResize window.onresize = doresize; '; endif;
// výpis obsahu primárního prostoru echo '
'; include 'obsah.php'; echo '
';
// výpis obsahu horního panelu if (jepan("nahore",0)){ echo '
// funkce pro ovládání překrývání panelů – přenesení do popředí při najetí myši echo '"onmouseover="document.getElementById(\'nahore\').style.zIndex=\'10\';" onmouseout="document.getElementById(\'nahore\').style.zIndex=\'5\';">'; else:
// výpis obsahu pravého panelu if (jepan("vpravo",0)){ echo '
'; else:
//nastavení pozice a velikosti panelu echo 'left: '.($_SESSION["panely"]["vlevo"]+1+$_SESSION["panely"]["w"]).'px !important; height:'.($_SESSION["panely"]["h"]+2 +$_SESSION["panely"]["nahore"]+$_SESSION["panely"]["dole"]).'px !important">'; endif; echo ''; if (jepan("vpravo",1)): echo '
XXI '.($_SESSION["panely"]["h"]+2+$_SESSION["panely"]["nahore"] +$_SESSION["panely"]["dole"]).!important">'; endif; echo ''; if (jepan("vlevo",1)): echo '
//volání funkce pro vypsání bloku pro otevírání/zavírání panelů dejPanely();
//odkaz pro minimalizaci všech panelů (parametr a) echo ' skrýt vše'; echo '
';
//pro každý záznam o souboru vzhledu zapíše odkaz, pro aktivní styl jen název foreach ($stl as $k => $h): echo $_SESSION["vzor"] == $k)?'<span id="stl">Vzor '.($k+1).'':''; endforeach; echo '
';
//výpis EXIF informací pokud je zobrazena galerie if ($_SESSION['panely']['obsah'] == "gal"): require_once("exif.php"); echo dejExif($galimgpath.$gal1[$_SESSION['gal']['akt']][0]); endif; ?>
6.3.7
gal.php
//kontrola nastavení aktivní fotografie (pořadové číslo v setu od 0), jinak nastavení na začátek if (!isset($_SESSION["gal"]["akt"])): $_SESSION["gal"]["akt"] = 0; endif;
//nastavení aktivní fotografie dle parametru gal v URL (možné hodnoty p, n a x) if (isset($_GET["gal"])): switch ($_GET["gal"]): case "p": $_SESSION["gal"]["akt"] += -1; break; case "n": $_SESSION["gal"]["akt"] += 1; break; case "x": $_SESSION["gal"]["akt"] = 0; break; default: $_SESSION["gal"]["akt"] = $_GET["gal"]+0; endswitch; endif; $acislo = $_SESSION["gal"]["akt"];
XXII //vypsání fotografie na pozadí DIV a odkazů na předchozí/následující foto, pokud existují. if ($acislo <= 0): $_SESSION["gal"]["akt"] = 0; $acislo = 0; else: echo '<span><<<'; endif; echo '
'; if (array_key_exists($acislo+1, $agal)): echo '<span>>>>'; endif; ?>
';