Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Vyšší odborná škola informačních služeb v Praze. Jan Šedivý.

Transkript

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í prezentace obrazových dat v prostředí Internetu Bakalářská práce 2009

2 <zadávácí list>

3 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 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 4 Obsah OBSAH...4 OBSAH CD-ROM...5 ABSTRAKT...6 ABSTRACT ÚVOD POPIS A SROVNÁNÍ STÁVAJÍCÍCH ŘEŠENÍ PREZENTACE FOTOGRAFIÍ V PROSTŘEDÍ INTERNETU Stručné historické okénko Obrazové formáty na Technologická řešení Úzká místa při prezentaci obrazových dat OCHRANA FOTOGRAFIÍ JAKO AUTORSKÉHO DÍLA STÁVAJÍCÍ ŘEŠENÍ PRO PUBLIKACI FOTOGRAFIÍ NA Testovací metodika, kvantitativní a kvalitativní kritéria Testované aplikace Výsledky IDEÁLNÍ FOTOGALERIE Výběr technologie Kritéria ideální fotogalerie SOUHRN DRUHÉ KAPITOLY VLASTNÍ NÁVRH FOTOGALERIE OBSAH Vlastní fotogalerie Ostatní obsah Kritéria návrhu obsahu UŽIVATELSKÉ ROZHRANÍ Panely Design Kritéria návrhu uživatelského rozhraní APLIKAČNÍ LOGIKA Struktura aplikace Volba technologie Generování obsahu Kritéria návrhu aplikační logiky REALIZACE NÁVRHU PROGRAMOVÝ KÓD Základní nastavení a inicializace aplikace Panely a maximalizace pracovního prostoru Změna velikosti fotografií Ovládací prvky fotogalerie Jednotlivá alba, MediaRSS a Cooliris...43

5 Vzhled prezentace, CSS Zobrazení fotografie TEST UKÁZKOVÉHO ŘEŠENÍ DISKUSE UKÁZKOVÉHO ŘEŠENÍ ZÁVĚR SHRNUTÍ TESTU HLAVNÍ BODY NÁVRHU SHRNUTÍ REALIZACE...47 LITERATURA A ZDROJE PŘÍLOHY... I 6.1 GRAFY VÝSLEDKŮ TESTOVÁNÍ...I Skóre efektivity...i Bodová hodnocení kritérií... II 6.2 OBRAZOVÁ DOKUMENTACE...VI Testované aplikace... VI Ukázková aplikace... X 6.3 ZDROJOVÉ KÓDY SKRIPTŮ... XII galerie-data.php...xii xmlgal.php...xii resimg.php... XIII index.php...xiv main.php...xvi vlevo.php...xxi gal.php...xxi Obsah CD-ROM [01-Text_BP]: o JanSedivy-BP.pfd text bakalářské práce ve formátu PDF. o programy.xls data získaná při testování. [02-Obrazova_priloha]: o [02.1-Testovaci_sada] Testovací sada fotografií. o [02.2-Snimky_obrazovek] Snímky obrazovek testovaných řešení. [03-Ukazkova aplikace]: o [03.1-Galerie] zdrojové kódy ukázkové aplikace ( Jan Šedivý). Info.txt informace o souborech a návod k instalaci ukázkové aplikace.

6 6 Abstrakt Jan Šedivý. Analýza a návrh řešení prezentace obrazových dat v prostředí Internetu 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 7 Abstract Jan Šedivý. Current Solutions Analysis and New Design of Web-based Image Presentation 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 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 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 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, , 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] 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 GIFF1 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. 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 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]. 2 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]. 3 Portable network graphic: volitelná barevná hloubka, bezztrátová komprese, možnost animace a podpora průhlednosti alfa kanálu a gamma korekce [6].

10 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 SWFF5, 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) 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 č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 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 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é) Úzká místa při prezentaci obrazových dat I. 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 12 Základním prostředkem pro zobrazení obrázků na WWW se stal jednoduchý HTML tag <IMG> 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 Navržený Marcem Andreeseenem v roce 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.

13 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ů obrazových bodů, při fyzických rozměrech 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 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 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. Přetažení pomocí myši z okna prohlížeče (drag & drop). 2. Uložení pomocí kontextového menu (po kliknutím pravým tlačítkem myši). 3. Uložení celé stránky a vyhledání souboru v příslušné složce uložené stránky. 4. 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ě. 5. Zachycení obrazovky pomocí klávesy PrintScreen či pomocí specializovaného programu. 6. 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 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.

17 17 V. Vložení copyrightu Uvedením copyrightu (značky, jména autora příp. roku vydání) je jasně sděleno, že obsah není volně šiřitelný (ač tomu tak bez výslovného svolení autora není nikdy). Značka může být umístěna přímo do obrázku (podobně jako vodoznak) či do textu v okolí obrázku. Umístění přímo ve fotografii je mnohdy nevhodné z estetických důvodů. Zajímavým řešením je nastavení fotografie o proužek s copyrightem a její zobrazení v prohlížeči pomoc stylů tak, aby byla zobrazena pouze část nad proužkem. V okamžiku, kdy si uživatel fotografii stáhne, je viditelná celá i s copyrightem [20]. Slabá místa: Oříznutí, případně retuš. Zároveň nepůsobí na uživatele, kteří porušují autorská práva vědomně. VI. Zapouzdření 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 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 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 Nahrání 1 fotografie Zobrazení galerie Nahrání ostatních foto Přidání popisku Vložení komentáře Editace alba Vyhodnocení kritérií Obr. 2-1 Testovací scénář. Vyhodnocovaná kritéria 1. Instalace/registrace: doba trvání, nadstandardně vyžadované osobní údaje, ověření u pokud byl vyžadován. 2. Nahrání první fotografie: doba vyřizování požadavku, kvalita změny velikosti. 3. Přidávání popisků: přehlednost a složitost procesu. 4. Vložení komentáře: doba trvání, vyžadované údaje, ochrana proti spamu (např. CAPTCHA 20 ), nutnost registrace. 5. Smazání fotografie. 6. Možnost základních úprav fotografií: otočení, ořez, doostření, korekce expozice apod. 7. Pokročilé možnosti: nadstandardní funkce (např. automatické promítání obrázků slideshow). 8. Editace alba: změny názvů, popisků, pořadí fotografií. 20 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 19 9. Rámečky: vzhled u náhledů/fotografií, pokud jsou automaticky přidávány. 10. Amatérské funkce: tzv. one click solutions (řešení na jedno kliknutí) jednodušší způsob editace. 11. Pořadí fotografií po přidání vs. pořadí při nahrávání. 12. 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). 13. Velikost náhledu. 14. Velikost základní fotografie: po kliknutí na náhled. 15. Velikost zvětšené fotografie: po kliknutí na základní foto. 16. 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. 17. Otevírání fotografií v novém či stávajícím okně. 18. 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í). 19. Ovládací prvky: textové/grafické, umístění vůči fotografii. 20. Skrývání prvků stránky: pro dosažení větší pracovní plochy fotogalerie. 21. Přítomnost reklamních prvků v prezentaci. 22. 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 [px] Výška [px] Poměr stran Velikost [kb] EXIF Poznámka 1 01_testchart.jpg :10 946,5 ne Ukazuje kvalitu resamplu. 2 02_nocni.jpg :3 117,5 ano Noční snímek. 3 03_cb-scena.jpg :3 81,8 ano Černobílý snímek. 4 04_krajina.jpg :3 132,5 ano Snímek krajiny. 5 05_detail.JPG :3 160,9 ano Přípona velkými písmeny. 6 06_sirokouhly.jpg :10 691,6 ano Širokoúhlý formát. 7 07_maly.jpg :4 63,9 ano Malá velikost obrázku. 8 08_velky.jpg :3 5468,1 ano Velký datový objem. 9 09_panorama.jpg :4 249,0 prázdný Extrémně širokoúhlý obraz 10 10_ctverec.jpg :1 248,4 ano Čtvercový formát. 11 Celkový datový objem: 7,97 MB 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 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 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 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 zpracoval dvě charakteristiky. Nejprve tzv. skóre efektivity vyjadřující do jaké míry využívá daná aplikace dostupný prostor zobrazovacího zařízení. Již zjištěné efektivity zobrazení pro náhled, fotografii a zvětšenou Měřená položka Váhy Náhled 10 Fotografie 20 Zvětšená fotografie 5 Náhled celá obrazovka 5 Fotografie celá obrazovka 10 Primární prostor 25 fotografii vůči oknu, celé obrazovce a pracovnímu prostoru 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 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 Celkem 100 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 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 v rámci pracovního prostoru pro fotogalerii (PP) a plochy PP vůči ploše okna, tedy stav, ve kterém uživatel pravděpodobně uvidí fotogalerii poprvé aniž by použil posuvníky, či celoobrazovkový 1 Kp režim. Bodové hodnocení efektivity (B E ) bylo zkonstruováno jako násobek plného počtu bodů a efektivity PP (tj. E PP ) 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 E F a E PP 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 B E 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. B E BP = E E PP E = E 10 BP F PP E Výsledky a jejich grafické zobrazení jsou uvedeny na konci kapitoly a dále v příloze 6.1 Grafy výsledků testování 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 To znamená, že pokud je pro galerii vymezeno 80 % plochy, získá 8 bodů. 26 Jednotlivé poměry stran fotografie znamenají různou efektivitu využití plochy monitoru při dané šířce fotografie.

22 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 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 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 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 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 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) 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 28 # Název Typ Samostatně Flash (X)HTML Java Script Server Side Úpravy Prezentace Online Offline 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 cz 11 Dpreview sample gallery www album o o o o en 12 Ladislav Kamarád umělecká galerie o o cz 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 o + Technologie je podporována / využívána: zcela částečně vůbec nelze Tab. 2-3 Využití jednotlivých technologií a určení účelu testovaných aplikací. # Kritérium/Aplikace Cooliris Jalbum Picasa Zoner LTR Rajče W4P CPG FA.cz 1 Skóre efektivity 5,1 6,9 6,0 3,8 7,8 4,5 5,0 4,2 3,3 Kritérium/Aplikace FA.eu Dpreview L. K. J. S. idnes Reuters NG NG-2 průměr 2 Skóre efektivity 4,9 5,7 6,1 2,4 2,8 2,1 2,5 1,9 4,4 Tab. 2-4 Skóre efektivity. # Kritérium/Aplikace Cooliris Jalbum Picasa Zoner LTR Rajče W4P CPG FA.cz 1 Efektivita 6,4 8,2 6,2 4,0 9,3 4,7 4,4 0,0 1,6 2 Technologie 10,0 8,0 9,0 7,0 10,0 7,0 5,0 7,0 1,0 3 Uživatelská přívětivost 6,0 7,0 9,0 7,0 9,0 10,0 8,0 4,0 3,0 4 Design 9,0 7,0 5,0 5,0 8,0 3,0 6,0 2,0 3,0 5 Přenositelnost a bezp. 4,0 3,0 6,0 5,0 5,0 4,0 6,0 6,0 6,0 Kritérium/Aplikace FA.eu Dpreview L. K. J. S. idnes Reuters NG NG-2 průměr 6 Efektivita 4,7 5,8 4,9 1,1 2,8 1,6 1,7 0,0 4,0 7 Technologie 6,0 3,0 2,0 5,0 10,0 5,0 5,0 8,0 6,4 8 Uživatelská přívětivost 7,0 7,0 8,0 9,0 10,0 9,0 8,0 7,0 7,5 9 Design 7,0 7,0 6,0 5,0 7,0 6,0 6,0 4,0 5,6 10 Přenositelnost a bezp. 5,0 7,0 6,0 6,0 7,0 6,0 6,0 4,0 5,4 Tab. 2-5 Bodové hodnocení jednotlivých kritérií.

29 Ideální fotogalerie Výběr technologie 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 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. Přizpůsobení velikosti fotografie dostupnému prostoru. (A, B, C) 2. Střídmý a jednoduchý design bez přemíry grafických prvků. (B) 3. Skrývání jednotlivých prvků stránky. (A, B) 4. 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 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 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) 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 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 jako text. 31 Výsledkem je mnohdy zobrazení pouze části fotografie, což vede k nedokonalé a zmatečné interpretaci takového obrazu divákem. Stejně tak u ostatních obrazových dat (grafy, schémata, obrazy apod.) ačkoli může být takový obsah značně zjednodušený a běžně používaný (např. graf), stále zde existuje množství různých variant prezentace téhož. 32 Divák pak velmi pravděpodobně nebude schopen přesně identifikovat a interpretovat předložený obraz, pokud z něj uvidí pouze část, ve které mohou chybět 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). Otevření galerie Zobrazení náhledů Kliknutí na náhled Otevření fotografie Zpět k náhledům Obr. 3-1 Diagram průchodu starší galerií. 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 Tilt- Viewer). 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é, [Ano] [Ne] Konec? Náhledy <<Úvodní foto>> [Ne] [Ne] <<Zobrazení>> Fotografie Kliknutí na náhled/navigace Změna fot. [Ano] Obr. 3-2 Schéma procházení navrhovanou aplikací. 31 Viz např. implementace Coppermine Photo Gallery v CMS systému United Nuke VIII. 32 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 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 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ů Kritéria návrhu obsahu 1. Zobrazení celých fotografií. 2. Základní zobrazení náhledů i fotografie s možností skrytí náhledů. 3. Možnost zobrazení náhledů v primárním prostoru a volitelné nastavení jejich velikosti. 4. Omezit obsahové rušivé prvky (např. reklamní proužky). 33 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 34 5. Na vyžádání zobrazovat textový kontext (minimálně název a popis) s možností opětovného skrytí. 6. Do textového kontextu automaticky zahrnout metadata. 7. Kvalitní obsah. 8. Umožnit zobrazení obecného HTML obsahu v prostoru pro primární sdělení (články, nápověda a další). 9. Zahrnout zdroj RSS podle standardu MediaRSS a tím i podporu Cooliris. 3.2 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 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- Obr. 3-4 Překrývání panelů. 34 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 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 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ě 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 Ukázková aplikace. 35 Stejně jako se chová hlavní nabídka (lišta) systému Windows pokud je nastavena na automatické skrývání. 36 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 Kritéria návrhu uživatelského rozhraní 1. Maximalizace pracovního prostoru formou panelů s možností skrytí/uzavření. 2. Zaměnitelnost obsahu panelů (uživatelsky konfigurovatelné). 3. Interaktivní zdůraznění právě používaných prvků stránky. 4. Jednoduchý a střídmý design zdůrazňující primární obsah. 5. Minimální použití grafických prvků pro zdůraznění vlastní fotografie. 6. Přístupný web. 3.3 Aplikační logika Struktura aplikace Všechny aktivity obsluhované aplikací jsou přehledně uvedeny v jednoduchém diagramu případů užití na Obr 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 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 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í 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 Tedy velice podobnou příslušným W3C standardům. 38 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 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) Kritéria návrhu aplikační logiky 1. Zajištění obsluhy aktivit dle Use Case diagramu (Obr. 3-5). 2. Technologie HTML (příp. XHTML) s využitím CSS. 3. Technologie generování obsahu serverem. 4. Nikoli esenciální využití klientského skriptu. 5. Nadstandardně možnost předložení obsahu ve Flash formátu. 6. Zajištění sledování stavu aplikace (relace). 7. Generování obrazu v dané velikosti na straně serveru.

39 39 4. Realizace návrhu V této kapitole je popsán postup realizace ukázkové fotogalerie umístěné na webové adrese 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 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 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&parametr2=hodnota2 apod. Blíže viz [47].

40 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 , , či pixelů. Toto oznámení je v těle stránky umístěno v elementu <NOSCRIPT>. V případě podpory skriptování je při nahrání stránky (onload) zavolána funkce initscr(), která otevře základní stránku main.php a předá serveru získané rozměry dostupného prostoru okna. Volitelně byly v rámci indexu testovány funkce pro automatickou maximalizaci okna a případné otevření základní stránky v novém okně v celoobrazovkovém režimu, které ale nejsou ve finální verzi aktivní Panely a maximalizace pracovního prostoru Základním kritériem při tvorbě aplikace byl požadavek na co nejefektivnější využití prostoru okna. Tzn. rozmístit panely k okrajům stránky a umožnit jejich skrývání a zobrazování. Tento úkol je poměrně dobře řešitelný pomocí kaskádových stylů využitím umisťování prvků (panelů) vzhledem k okrajům okna a nastavení jejich velikosti na 100 % šířky resp. výšky okna je dosaženo požadovaného efektu rozvržení panelů (viz obrázek 3-3 na str. 34). Skrývání panelů (tj. jejich minimalizace do podoby lišty) probíhá prostou změnou šířky resp. výšky panelu na danou hodnotu (zde 20 pixelů). Dále je nutné dopočítat rozměry pracovního prostoru, tj. volného místa mezi panely. Pak je již možné sestavit celou stránku skládající se z pěti DIV kontejnerů (čtyři panely a pracovní prostor). Jednotlivé panely jsou dále rozděleny na ovládací lištu a vlastní obsah. Obsah panelu je generován pouze při povoleném zobrazení celého panelu pomocí PHP konstrukce include, což umožňuje případnou uživatelskou konfiguraci panelů. Rozměry okna i pracovního prostoru jsou uloženy do příslušných session proměnných pro další využití. Vlastní skrytí či zobrazení panelu spočívá v zavolání main.php s parametrem určujícím akci a id panelu. Akce skrytí resp. zobrazení spočívá v prosté změně velikosti ze základní na minimalizovanou a naopak; při zavírání panelu je tato hodnota stanovena na nulu. Při generování HTML je pak panel s velikostí nula zcela vynechán a u minimalizovaného panelu je zahrnut pouze kód vypisující lištu. Zároveň je na základě aktuálního stavu panelu stanoveno pozadí lišty tak, aby značky ukazovaly správným směrem. Při maximalizaci panelu je tento stanoven jako aktivní (tj. zobrazen v popředí). Řízení překrývání panelů probíhá prostřednictvím JavaScriptu při události onmouseover je panelu přiřazena nejvyšší hodnota vlastnosti z-index (tj. je přenesen do popředí). Při

41 41 onmouseout získá z-index původní hodnotu. Pokud není JavaScript k dispozici, nejsou tyto funkce volány a panely jsou zobrazeny bez překrývání (horní a dolní panel jsou zobrazeny mezi pravý a levý). 41 Volitelně by bylo možné zvolit, zda zobrazovat panely s překrýváním, či staticky. V případě podpory JavaScriptu je možné, aby aplikace pomocí obsluhy události window.onresize reagovala na změnu velikosti zobrazovací plochy prohlížeče. Tuto událost vyvolá změna velikosti okna, skrytí ovládacích prvků prohlížeče (nástrojové lišty, stavový řádek, panel historie apod.) či přechod do celoobrazovkového režimu. V ukázce je po události onresize znovu zjištěna velikost dostupné plochy okna a zavolán skript main.php s novými parametry. Změnu velikosti fotografií zajišťuje samostatný serverový skript popsaný v následující sekci Změna velikosti fotografií Skript obsluhující změnu velikosti obrázků funguje velmi jednoduše. Prohlížeč odešle dotaz na obrázek ve tvaru skript.php?parametry a odezvou skriptu je buď příslušný obrázek (parametry specifikují originální soubor a požadované rozměry), nebo chybový kód HTTP 404 Nenalezeno. Skript je postaven na kódu Marca Oliva [48], který byl přepracován pro účely ukázky. (Stejnou problematikou se zabývá např. i projekt Timthumb [49].) V ukázce je využívána GD knihovna pro práci s obrazovými soubory, která je již v PHP zabudována. Základní funkce (načtení originálu, výpočet rozměrů obrazu dle originálu a parametrů, alokace paměti, zmenšení originálního obrazu, kopírování do nového a odeslání HTTP odpovědi s příslušným MIME typem) byly rozšířeny o kontrolu adresy odkazující stránky pokud nejde požadavek z vlastního serveru (případně serveru pic.lens.com viz dále) je maximální velikost vráceného obrazu redukována na 400 px v obou osách nezávisle na zadaných parametrech (ochrana proti získání obrazu ve vyšším rozlišení). Protože HTTP referer je možné podvrhnout, je maximální velikost odesílaného obrazu limitována rozměry px. Použitá funkce imagecopyresized byla nahrazena z hlediska kvality zřetelně výkonější funkcí imagecopyresampled, která ovšem obraz zpracovává déle. Jak již bylo zmíněno v části 3.3.3, pro zvýšení celkové rychlosti odezvy aplikace je nutné zařadit do kódu i ukládání vytvořených souborů do cache na serveru. Při požadavku na poskytnutí fotografie by pak skript nejprve zkontroloval, zda požadovaný (či velice blízký) soubor již není vygenerován v cache adresáři. V případě nalezení shody by pak místo nového 41 Situaci s vypnutým JavaScriptem lze simulovat stisknutím tlačítka Bez JS v horní navigační liště ukázkové galerie. Je pak zavolán index.php s již nastaveným atributem nojs. Aplikace se pak chová jako by prohlížeč klienta nepodporoval skriptování. Obnovit standardní chování aplikace lze tlačítkem Reset či opětovným zadáním základní URL. Při vytváření indexu jsou obnovena implicitní data v session proměnných.

42 42 generování obrazu vrátil soubor z cache. V ukázkové implementaci kódu taková cache zařazena není a proto mohou být reakce aplikace pomalejší. 42 Uživatel Prohlížeč Klientský skript Serverový skript Odeslání požadavku Příjem požadavku Zadání URI Odeslání skriptu [Ne] Podpora JS [Ano] Rozměry okna Zpracování rozměrů Volba rozměrů Výběr velikosti Odeslání Odeslání indexu Aktivita Zobrazení obsahu [Ne] Konec Změna velikosti AND JS [Ano] Zpracování změn [Ano] [Ne] OnResize Odeslání změn Obr. 4-1 Schéma obsluhy uživatelských vstupů s rozlišením klientské a serverové části skriptu. Dalším prvkem, který v ukázkovém skriptu není zahrnut, je omezení zvětšování malých fotografií. Pokud není originální fotografie k dispozici v dostatečném rozlišení, měl by být výstup omezen buď na originální velikost, případně na určitý maximální násobek původní velikosti tak, aby degradace obrazu vzniklá zvětšením zůstala na přijatelné úrovni Ovládací prvky fotogalerie A#vzad A#vpred Při návrhu ovládání galerie byl kladen důraz hlavně na neomezenou funkčnost (tzn. nezávislost na JavaScriptu). Design ovládacích prvků dále nesměl působit rušivě vůči prezentované fotografii. Inspirací pro částečně průhledné překryvné prvky bylo řešení používané v zobrazovacím skriptu Slimbox [50]. Nezávislosti na JavaScriptu bylo dosaženo využitím vlastnosti obyčejného tagu odkazu, <<< SPAN Obr. 4-2 Umístění ovládacích prvků ve vrstvě nad fotografií. <<< 42 Pomalejší odezva aplikace je také způsobena poměrně velkým datovým objemem některých fotografií. Je použita stejná sada jako při testování popsaném v části 2.3 (viz tabulka Tab. 2-1 na str. 19).

43 43 kdy se na úrovni prohlížeče rozlišují tři stavy: základní, aktivovaný kursorem myši a navštívený. Tyto stavy jsou v CSS dostupné jako pseudotřídy :link, :hover a :visited tagu A. Ve vrstvě nad vlastní fotografií jsou tedy umístěny dva odkazy o rozměrech % praproblémem při implementaci tohoto řešení byly tečkovanou čárou zdůrazněné okraje covního prostoru (viz Obr. 4-2). V těchto odkazech je v tagu SPAN 43 zobrazen vlastní navigační prvek (v ukázce pouze text naznačující směr posunutí v setu fotografií). Odkazy mají implicitně nastavenu 100% průhlednost, po aktivaci je pak průhlednost změněna na 20 % (může se lišit pro různá témata vzhledu). Navigační prvky jsou tedy zobrazeny pouze pokud uživatel pohybuje myší k pravému, či levému okraji fotografie. Pokud je zobrazena první resp. poslední fotografie, zobrazuje se pouze příslušný použitelný odkaz vpřed resp. vzad. Nevýhodou takového řešení je, že uživatel může být nejprve zmaten nepřítomností ovládacích prvků. Jediným odkazu, na který bylo právě kliknuto. V prohlížečích Opera i Firefox lze tyto okraje skrýt nastavením nulového obrysu daného odkazu (outline: none;), bohužel MSIE 7 stylování obrysu nepodporuje. Jediným funkčním řešením v případě této aplikace je volání funkce JavaScriptu blur() při události onfocus daného odkazu. Tedy v případě zakázaného JavaScriptu jsou tyto okraje v MSIE stále zobrazovány Jednotlivá alba, MediaRSS a Cooliris V ukázkové aplikaci je zobrazeno pouze jedno testovací album. Nicméně návrh počítá se zobrazením libovolného počtu galerií (ID fotogalerií určených k zobrazení pak budou v samostatném konfiguračním souboru). Data popisující jednotlivé fotogalerie jsou uložena do dvourozměrného pole (předpokládá se jeho vytvoření při nahrávání fotografií, v ukázce viz soubor galerie-data), ve kterém jsou uloženy tyto údaje: název fotogalerie popis fotogalerie údaje o jednotlivých fotografiích: o cesta k souboru o název fotografie o popis fotografie Z tohoto pole jsou při generování HTML zjištěny příslušné údaje i existence předchozí a následující fotografie. Z tohoto pole je také skriptem xmlgal.php automaticky generován RSS zdroj podle standardu MediaRSS. Tento pak slouží mimo běžné možnosti odebírání obsahu pomocí RSS čtečky i k poskytnutí údajů doplňku Cooliris. 43 Lze případně použít i tag IMG pro grafický navigační prvek, nebo kombinaci obou tagů.

44 44 Cooliris je v aplikaci implementován dvojím způsobem 44 v případě nainstalovaného Cooliris ve formě doplňku prohlížeče je spuštěn tento, jinak je ze serveru lite.piclens.com spuštěn skript a dále Flash prezentace, která zobrazí fotogalerii Vzhled prezentace, CSS Ukázková aplikace kombinuje stylování pomocí statického souboru kaskádových stylů připojeného z externího CSS souboru s dynamickým zapisováním tzv. in-line stylů přímo při generování HTML kódu PHP skriptem. Dynamicky jsou vkládány zejména atributy určující velikost a pozici jednotlivých elementů stránky. Externí soubor stylu pak obsahuje veškeré údaje o prvotním rozložení, písmech, ohraničení, barvách apod. Změnou externího souboru je tedy zajištěna celková změna vzhledu bez ovlivnění pozice jednotlivých elementů. V ukázkové verzi jsou zahrnuta tři témata vzhledu aplikace: Vzor 1: tmavý vzor s černým pozadím a světlým textem kombinující různé odstíny šedé. Dle názoru autora nejvhodnější pro prohlížení fotografií. Je také nejlépe použitelný při snížené úrovni okolního osvětlení. Vzor 2: inverzní varianta tmavého vzoru 1. Vhodnější pro čtení textů a světlejší fotografie. Vzor 3: testovací vzor využívající pouze dvě kontrastní barvy (černá a žlutá RGB hex. 000 a FF0). Během testování v různých prohlížečích vyšly najevo drobné odlišnosti od standardní specifikace CSS 2 (viz [12] a dále). Největším problémem byly odlišným způsobem vypočítávané hodnoty velikosti okna i jednotlivých elementů, parsování hodnoty velikosti 100% a umisťování elementů absolutně k okrajům okna. Pečlivý čtenář zdrojového kódu si jistě povšimne občasného přičítání či odečítání několika pixelů vše z důvodu rozdílného zobrazování v prohlížečích, či nekorektního zobrazování posuvníků. Jako další rozšíření se nabízí možnost uživatelské konfigurace prostředí aplikace prostřednictvím modifikace externího CSS souboru Zobrazení fotografie Fotografie zmenšená pomocí PHP skriptu do požadovaných rozměrů pracovního prostoru je zobrazena jako pozadí elementu DIV, který obsahuje průhledný obrázek nic.gif zvětšený na rozměry pracovního prostoru. Pokud by chtěl uživatel uložit fotografii pomocí kontextového menu, reaguje na kliknutí pravým tlačítkem buď zobrazený odkaz na předchozí/další fotografii, nebo právě prázdný obrázek. Po prozkoumání zdrojového kódu je možné získat 44 Jelikož z prostředí aplikace je možné spustit Cooliris pouze prostřednictvím JavaScriptu, zobrazuje se patřičný odkaz v horní navigační liště pouze pokud je JavaScript dostupný. Protože MS Internet Explorer vykazoval chybové chování při interpretaci externího skriptu a zobrazení překryvných dat, je cooliris spouštěn ze samostatné stránky slideshow.php.

45 45 adresu souboru resimg.php (nikoli cestu k originálnímu souboru fotografie). Při použití specializovaného programu, který umožňuje podvrhnout adresu odkazující stránky, je pak možné získat fotografii ve výše zmíněném max. rozlišení omezeném velikostí 1600 px. Zamezit takovému úniku by bylo možné použitím speciálního parametru kódu, který by se generoval např. z kombinace session ID (SID), požadovaných parametrů souboru a případně ještě časového razítka. Tento kód by byl ověřen skriptem resimg.php a podle výsledků ověření odeslána fotografie v příslušném rozlišení. Obtížnost získání fotografie by tak ještě vzrostla. Jak bylo diskutování v části 2.2 Ochrana fotografií jako autorského díla, je možné ke každé generované fotografii automaticky přidávat proužek s copyrightem. 4.2 Test ukázkového řešení Ukázková aplikace byla otestována podle stejného testovacího scénáře použitého v druhé kapitole (viz Obr. 2-1). Jedna varianta byla testována se zobrazením horního a pravého panelu, druhá při skrytí všech panelů. Výsledky jsou uvedeny v tabulkách níže (Tab. 4-1 a Tab. 4-2). Ukázková aplikace dosáhla nadprůměrných výsledků ve všech hodnocených aspektech. Skóre efektivity podle předpokladu dosáhlo vysokých hodnot. To ukazuje, že byl splněn hlavní cíl návrhu dosáhnout efektivnějšího využití prostoru obrazovky. Velice subjektivní je hodnocení uživatelské přívětivosti uživatelské rozhraní by mělo být podrobeno testům v dostatečně reprezentativní skupině respondentů a posléze upraveno podle jejich připomínek. # Název Typ Samostatně Flash (X)HTML Java Script Server Side Úpravy Prezentace Online Offline Online Offline Zdarma Jazyk 1 Testovací Galerie www album + o o o o o cz Legenda o + Technologie je podporována / využívána: zcela částečně vůbec nelze Tab. 4-1 Tabulka použitých technologií ukázkového řešení. # Kritérium/Aplikace Test 1 Test 2 1 Efektivita 6,3 8,5 2 Technologie 9,0 9,0 3 Uživatelská přívětivost 9,0 8,0 4 Design 8,0 8,0 5 Přenositelnost a bezp. 8,0 8,0 6 Skóre efektivity 5,3 6,7 Tab. 4-2 Tabulka dosažených výsledků ukázkového řešení. Srovnejte s výsledky na straně Diskuse ukázkového řešení Prezentovaná aplikace je důkazem existence funkčního řešení některých navrhovaných kritérií. Reálná použitelnost této aplikace je limitována zejména pomalejší odezvou serverové

46 46 části (zmenšování obrázků). Je také nutno zmínit, že ukázková aplikace nebyla testována z hlediska bezpečnosti kódu. Díky mechanismu testování cookies a zjišťování rozměrů okna také není aplikace přístupná pro vyhledávací roboty (řešením je mj. zpřístupnění dynamicky generovaných RSS pro jednotlivé budoucí galerie) a je třeba dořešit mechanismus odkazovnání aplikace v určitém stavu (např. zobrazení konkrétní fotografie). Je také nutné optimalizovat aplikaci pro zobrazení s vypnutými styly. 45 Před finálním nasazením je nutno dokončit vývoj následujících komponent aplikace: Obsah o Zahrnout více možností zobrazování náhledů. o Podpora více galerií. o Optimalizovat zobrazování EXIF, zahrnout podporu IPTC. o Navrhnout rozhraní pro konfiguraci prostředí. Uživatelské rozhraní o Revize parsování jednotlivých panelů vzhledem k obsahu (přizpůsobit výšku resp. šířku panelu jeho obsahu). Kontrola chování posuvníků. o Ovládání pomocí klávesnice. o Zahrnout přepínač pro uzamčení konkrétního panelu v popředí. o Možnost uživatelské konfigurace rozložení panelů a jejich obsahu. o Dynamická změna velikosti titulku stránky a navigačního menu vzhledem k dostupnému prostoru. Zmenšit titulek, pokud již byl zobrazen. Aplikační logika o Optimalizovat resimg.php: zavést cache (!), přidávání proužku s copyrightem, kódování předávaných parametrů. o Zavést modul pro nahrávání obrázků, tvorbu a úpravy jednotlivých galerií. o Implementovat uživatelskou konfiguraci prostředí i chování aplikace. o Celková optimalizace kódu jednotlivých skriptů (algoritmy, bezpečnost). 45 Jednotlivé prvky pak budou zobrazeny prostě za sebou obsah je nutno generovat v optimálním pořadí.

47 47 5. Závěr 5.1 Shrnutí testu Testování existujících řešení dobře ukázalo, že stávající fotogalerie nevyužívají dostupný prostor zobrazovacího zařízení efektivně. Zřejmě díky kladení důrazu na hromadné zpracování a automatizaci celého procesu publikace fotografií je upřednostňována funkční stránka aplikací oproti vlastnímu designu. Nejlepších výsledků dosáhla řešení na bázi technologie Flash a samostatné doplňky WWW prohlížečů, které byly schopny zobrazit obsah přizpůsobený celoobrazovkovém režimu tato řešení ovšem snižují přístupnost prezentace. Nekomerční řešení díky absenci reklamy působila lépe z hlediska zdůraznění fotografie jako primárního sdělení. Prezentace využívající technologii AJAX jsou velmi působivé z hlediska uživatelského rozhraní, ale zcela závislé na JavaScriptu. 5.2 Hlavní body návrhu Navrhovaná ideální fotogalerie by tedy měla zahrnovat zejména uživatelem konfigurovatelný mechanismus skrývání jednotlivých prvků prezentace tak, aby v daný okamžik byl zobrazen a zdůrazněn jen prvek, na který je soustředěna pozornost uživatele. Samozřejmé je zdůraznění fotografie v roli primárního obsahu, přítomnost metadat a textových popisků i celkově střídmý a nerušivý design uživatelského prostředí. Řešení musí být zabezpečeno takovými technologiemi, aby bylo zcela funkční i bez podpory nadstandardních funkcí na straně klienta. 5.3 Shrnutí realizace Realizace ukázkové aplikace prokázala existenci funkčního řešení postaveného na současných technologiích generování obsahu na straně serveru (PHP) s nikoli nezbytnou podporou skriptování na straně klienta (JavaScript). Je dosaženo dynamického přizpůsobení velikosti prostoru pro primární obsah i automatické generování fotografií s odpovídajícími rozměry. Řešení využívající rozdělení obsahu do panelů, které je možné minimalizovat či zcela zavřít, dosáhlo nadprůměrných výsledků v testu efektivity (metodika testu na str. 17). Autor hodlá pokračovat v dalším vývoji aplikace na základě teoretického návrhu uvedeného v této práci s úmyslem vytvořit vlastní autorskou fotogalerii.

48 48 Literatura a zdroje [1] Russell A. Kirsch [online]. [2002] [cit ]. Dostupný z WWW: < [2] KIRSCH, Russell A.. SEAC and the Start of Image Processing at the National Bureau of Standards [online]. 2007, [cit ]. Dostupný z WWW: < [3] The History and Principles of Digital Imaging [online] [cit ]. Dostupný z WWW: < [4] GIF Official Specifications [online]. 2006, [cit ]. Dostupný z WWW: < [5] JPEG JFIF [online]. W3C, 2003, [cit ]. Dostupný z WWW: < [6] Portable Network Graphics (PNG) Specification (Second Edition) : W3C Recommendation [online]. 2 W3C, 2003, [cit ]. Dostupný z WWW: < [7] HTML 4.01 / XHTML 1.0 Reference [online] [cit ]. Dostupný z WWW: < [8] TIŠNOVSKÝ, Pavel. Vektorový grafický formát SVG. Root.cz [online]. 2007, [cit ]. ISSN Dostupný z WWW: < [9] Flash Webdesign. Interval.cz [online] [cit ]. Dostupný z WWW: < ISSN [10] ASLESON, Ryan, SCHUTTA, Nathaniel T. Foundations of AJAX. New York: Apress s. ISBN [11] ANDREESSEN, Marc. Proposed new tag: IMG [online]. 1993, [cit ]. Dostupný z WWW: < [12] BERT, Boss. Cascading Style Sheets [online]. [ ], [cit ]. Dostupný z WWW: < [13] CHENG, Jackqui. Facial recognition slipped into Google image search [online]. 2007, [cit ]. Dostupný z WWW: < [14] MUFIN Demonstrations: MUFIN Image Search [online] [cit ]. Dostupný z WWW: < [15] Media RSS Module - RSS 2.0 Module [online] , [cit ]. Dostupný z WWW: < [16] HOLCOVÁ, Irena. Autorské právo [online]. [2005] [cit ]. Dostupný z WWW: <

49 49 [17] ŠPINAR, David. Přístupnost: web a weblog věnovaný přístupnosti webových stránek [online] [cit ]. Dostupný z WWW: < [18] COYIER, Chris. Techniques for Fighting Image Theft [online]. 2008, [cit ]. Dostupný z WWW: < [19] ALLINDER, Jan A.. Copyright - Image Protection [online]. 2007, [cit ]. Dostupný z WWW: < [20] POWAZEK, Derek. A Savvy Approach to Copyright Messaging [online]. 2008, [cit ]. Dostupný z WWW: < [21] CAPTCHA [online] [cit ]. Dostupný z WWW: < [22] Cooliris - discover more [online] [cit ]. Dostupný z WWW: < [23] Jalbum.net [online] [cit ]. Dostupný z WWW: < [24] Webová alba programu Picasa [online] [cit ]. Dostupný z WWW: < [25] Podmínky používání Služeb společnosti Google [online]. Google, 2007, [cit ]. Dostupný z WWW: < [26] Interval.cz: Syndikace obsahu - formáty, techniky, vývoj [online] [cit ]. Dostupný z WWW: < -formaty-techniky-vyvoj/>. [27] Zoner Photo Studio [online] [cit ]. Dostupný z WWW: < [28] Airtight interactive [online] [cit ]. Dostupný z WWW: < [29] Adobe Photoshop Lightroom 2 [online] [cit ]. Dostupný z WWW: < [30] The Turning Gate [online] [cit ]. Dostupný z WWW: < [31] Rajče.net : Místo pro vaše fotografie [online] [cit ]. Dostupný z WWW: < [32] Pravidla [online]. MAFRA a.s., [cit ]. Dostupný z WWW: < [33] Web4photo : Publikační systém pro fotografy [online] [cit ]. Dostupný z WWW: < [34] Coppermine Photo Gallery [online] [cit ]. Dostupný z WWW: < [35] Foto-Album.CZ [online]. [1995] [cit ]. Dostupný z WWW: <

50 50 [36] Fotoalbum.eu: Vytvořte si zadarmo své vlastní fotoalbum [online]. [2007] [cit ]. Dostupný z WWW: < [37] Samples Galleries: Digital Photography Review [online] [cit ]. Dostupný z WWW: < [38] Ladislav Kamarád: galerie [online] [cit ]. Dostupný z WWW: < [39] Jan Saudek: Fotografie [online] [cit ]. Dostupný z WWW: < [40] WebConsult.cz - Reference - saudek.com [online] [cit ]. Dostupný z WWW: < [41] Podyjí, jak ho neznáte. Unikátní pohledy z rakouského břehu. [online] , [cit ]. Dostupný z WWW: < [42] Reuters.com: Pictures [online]. c2008 [cit ]. Dostupný z WWW: < [43] National Geographic: Photography [online] [cit ]. Dostupný z WWW: < [44] Visions of Earth 2008 Photo Gallery [online]. Visions of Earth National Geographic Magazine, 2008 [cit ]. Dostupný z WWW: < [45] BARRY, Ann Marie. Visual intelligence: perception, image, and manipulation in visual communication. 1st edition. State University of New York Press, s. ISBN [46] TOPlist - globální statistika [online]. 2008, [cit ]. Dostupný z WWW: < [47] Apache Module mod_rewrite [online] [cit ]. Dostupný z WWW: < [48] OLIVO, Marco. ImageThumb [online] [cit ]. Dostupný z WWW: < [49] MCDANIELS, Tim, HOYT, Darren. Timthumb [online]. 2008, [cit ]. Dostupný z WWW: < [50] Slimbox, the ultimate lightweight Lightbox clone [online] , [cit ]. Dostupný z WWW: <

51 I 6. Přílohy 6.1 Grafy výsledků testování Skóre efektivity Skóre efektivity Lightroom 02 Jalbum 12 Ladislav Kamarád 03 Picasa 11 Dpreview 01 Cooliris 07 Web4Photo 10 Fotoalbum.eu 06 Rajče.net Průměr 08 Coppermine 04 Zoner 09 Foto-album.cz 14 idnes 16 National Geographic 13 Jan Saudek 15 Reuters 17 NG - flash Ukázkové řešení 1 Ukázkové řešení 2 6,9 6,1 6,0 5,7 5,1 5,0 4,9 4,5 4,4 4,2 3,8 3,3 2,8 2,5 2,4 2,1 1,9 5,3 6,7 7,8 Obr. 6-1 Graf dosažených skóre efektivity jednotlivých aplikací a ukázkového řešení (průměr se vztahuje pouze na testovaná existující řešení).

52 II # Aplikace Skóre efektivity 1 05 Lightroom 7, Jalbum 6, Ladislav Kamarád 6, Picasa 6, Dpreview 5, Cooliris 5, Web4Photo 5, Fotoalbum.eu 4, Rajče.net 4,5 10 Průměr 4, Coppermine 4, Zoner 3, Foto-album.cz 3, idnes 2, National Geographic 2, Jan Saudek 2, Reuters 2, NG - flash 1,9 Tab. 6-1 Skóre efektivity dle dosažených výsledků Bodová hodnocení kritérií Cooliris efektivita přenositelnost bezpečnost 4 2 technologie 0 design uživ. přívětivost Průměr Cooliris Obr. 6-2

53 III Generátory galerií efektivita přenositelnost bezpečnost technologie design uživ. přívětivost Jalbum Picasa Zoner Lightroom & TTG Obr. 6-3 WWW galerie efektivita přenositelnost bezpečnost technologie design Rajče.net Coppermine Photo Gallery Fotoalbum.eu Web4Photo Foto-abum.cz uživ. přívětivost Obr. 6-4

54 IV Umělecké a odborné galerie efektivita přenositelnost bezpečnost technologie design uživ. přívětivost Dpreview sample gallery Ladislav Kamarád Jan Saudek Obr. 6-5 Zpravodajství efektivita 10 8 přenositelnost bezpečnost technologie design uživ. přívětivost idnes Reuters NG NG - flash Obr. 6-6

55 V TEST efektivita 10 8 přenositelnost bezpečnost technologie design JHSG standard JHSG schované uživ. přívětivost Obr. 6-7

56 XI Obr Rozhraní se zavřenými panely maximální možný prostor pro fotografii. Obr Základní tmavý vzhled ukázkové aplikace. Obr Světlé téma.

57 XII 6.3 Zdrojové kódy skriptů galerie-data.php <?php $galimgpath = "./galimg/"; //cesta k originálním souborům $gal1 = array ( "nazev" => "Název galerie = Testovací galerie", "popis" => "Popis testovací fotogalerie.", array("01_testchart.jpg","testchart","testovací obrazec slouží k rychlému vizuálnímu zhodnocení kvality resamplu."), array("02_nocni.jpg","budapešť","hrad z vojenské pevnosti."), array("03_cb-scena.jpg","vltava","malý přístav v Podolí."), array("04_krajina.jpg","pálava","ze Stolové hory nad Mikulovem. 2007"), array("05_detail.jpg","designblok 2007","Skleněný objekt."), array("06_16x10.jpg","mechová krajina","tábor, 2007."), array("07_maly.jpg","bříza pro Báru","Malý snímek - test upsamplu."), array("08_velky.jpg","tržní náměstí","velký snímek - test downsamplu."), array("09_panorama.jpg","jordán","je fotogalerie nudlepřívětivá?<br>"), array("10_ctverec.jpg","dachstein","2007") );?> xmlgal.php <?php header("content-type: application/rss+xml"); // načtení popisků fotogalerie require_once("galerie_data"); // funkce pro odebrání tagů z popisků a názvů (nejsou definovány v příslušném dtd) function dt($co){ return str_replace(array("<br>","<p>","</p>")," ", $co); } // definice jmenného prostoru mediarss, zápis kanálu a jednotlivých položek echo '<?xml version="1.0" encoding="utf-8" standalone="yes"?'.'> <rss version="2.0" xmlns:media=" xmlns:atom=" echo ' <channel> <title>'.$gal1["nazev"].'</title> <description>'.$gal1["popis"].'</description> <language>cs</language>'; foreach (array_slice($gal1, 2) as $h): echo' <item> <title>'.dt($h[1]).'</title> <media:description>'.dt($h[2]).'</media:description> <link> <media:thumbnail url="resimg.php?f('.$h[0].')+x(400)+y(300)"/> <media:content url="resimg.php?f('.$h[0].')+x(1200)+y(800)"/> </item>'; endforeach; echo '

58 XIII </channel> </rss>';?> resimg.php <?php $base_img_dir = "galimg/"; // nalezení parametrů se strukturou parametr(hodnota) preg_match_all("/\+*(([a-z])\(([^\)]+)\))\+*/", $_SERVER["QUERY_STRING"], $matches, PREG_SET_ORDER); // nastavení platných parametrů (zde případně možnost dalšího kódování) $tags = array(); $check = array( "f" => "[0-9a-zA-Z\.\-_]+", //název souboru "x" => "[0-9]+", //šířka "y" => "[0-9]+"); //výška // kontrola platných parametrů a uložení do pole $tags for ($i=0; $i < count($matches); $i++) { if (isset($check[$matches[$i][2]])) { if (preg_match('/^('.$check[$matches[$i][2]].')$/', $matches[$i][3])) { $tags[$matches[$i][2]] = $matches[$i][3]; }}} function notfound() { //odeslání chybového hlášení 404 header("http/ Not Found"); exit; } // kontrola zadání jména souboru if (!isset($tags["f"])){ notfound();} // kontrola existence souboru if (!file_exists($base_img_dir.$tags["f"])){ notfound();} // načtení informací o souboru $imginfo = getimagesize($base_img_dir.$tags["f"]); // načtení obrázku do paměti příslušnou funkcí dle typu (soubor nemusí mít příponu) switch ($imginfo[2]) { case 2: // jpg $img_in = imagecreatefromjpeg($base_img_dir.$tags["f"]) or notfound(); if (!isset($tags["t"])) { $tags["t"] = "jpg";} break; case 3: // png $img_in = imagecreatefrompng($base_img_dir.$tags["f"]) or notfound(); if (!isset($tags["t"])) { $tags["t"] = "png";} break; default: notfound(); } //kontrola odkazující stránky $ref = isset($_server["http_referer"])?substr($_server["http_referer"], 7, strpos(substr($_server["http_referer"], 7), "/")):"neni ref"; $cizi = ($_SERVER["SERVER_NAME"]!== $ref && $ref!== "lite.piclens.com"); $pomer = imagesx($img_in)/imagesy($img_in); //nastavení globálního omezení rozměrů if ($tags["x"] > 1600): $tags["x"] = 1600; endif;

59 XIV if ($tags["y"] > 1600): $tags["y"] = 1600; endif; //vytvoření nového obrázku s cílovými rozměry do $img_out if (($tags["x"]/$tags["y"]) < (imagesx($img_in)/imagesy($img_in))): $ratio = $tags["x"]/imagesx($img_in); $img_out = $cizi? imagecreatetruecolor(400,400/$pomer) : imagecreatetruecolor($tags["x"], imagesy($img_in)*$ratio); //400px pokud neodpovídá referer else: $ratio = $tags["y"]/imagesy($img_in); $img_out = $cizi? imagecreatetruecolor(300*$pomer,300) : imagecreatetruecolor(imagesx($img_in)*$ratio, $tags["y"]); endif; //provedení změny rozměrů imagecopyresampled($img_out,$img_in,0,0,0,0,imagesx($img_out),imagesy($img_out ),imagesx($img_in),imagesy($img_in)); //nastavení kvality pro JPEG $jpq = 90; //odeslání HTTP odpovědi s vygenerovaným obrázkem, skript se poté ukončí a uvolní paměť switch ($tags["t"]) { case "jpg": header("content-type: image/jpeg"); imagejpeg($img_out, "", $jpq); exit; case "png": header("content-type: image/png"); imagepng($img_out); exit; default: notfound(); }?> index.php <?php //kontrola povolených cookies, kvůli uložení session cookie if (!isset($_get['tcok']) or $_GET['tcok']!= 'ht3'): setcookie ('cok', 'zkouska', 0); if (isset($_get['nojs'])): $ns = "&nojs"; else: $ns = ""; endif; header ("Location: index.php?tcok=ht3".$ns); else: session_start(); session_unset(); if (!empty($_cookie['cok'])): $_SESSION["cok"] = true; else: die('<!doctype HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"><link rel="stylesheet" href="base.css" type="text/css"> <title>fotogalerie JHŠ - CHYBA!</title></head><div id="obsah" style="text-align: middle; padding: 50px 200px"><h1>CHYBA</h1>

60 XV <p>serveru se nepodařilo uložit tzv. session cookie. Prosím povolte cookies ve Vašem prohlížeči! Session cookie jsou nutné pro určení stavu, ve kterém se aplikace nachází...<br>tato data nemohou vašemu počítači nijak ublížit a jsou po uzavření prohlížeče smazána.<br></p> <h3><a href="'.$_server["php_self"].'">obnovit stránku..</a></h3> </div>'); endif; endif; //nastavení úvodních session dat rozměry panelů, aktivní panel, velikost lišty, podpora JS $_SESSION["orig"] = array( "nahore" => 70, "dole" => 200, "vpravo" => 200, "vlevo" => 200, "a" => "nahore", "pw" => 20, "script" => true); //vypnutí podpory JS pokud bylo vyžádáno if (isset($_get['nojs'])): $_SESSION["orig"]['script'] = false; endif;?> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html><head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> <meta name="keywords" content="galerie"> <meta name="description" content="jhš galerie"> //připojení externího stylu <link rel="stylesheet" href="base.css" type="text/css"> <title>fotogalerie</title> <script type="text/javascript" language="javascript"> //automatické zavolání main.php s příslušnými rozměry function initscr(){ top.location='main.php?scrw='+getclientwidth()+'&scrh='+getclientheight()+' &b&r'; } //funkce pro získání rozměrů dostupného prostoru okna function getclientwidth() { return document.compatmode=='css1compat'&&!window.opera?document.documentelement.c lientwidth:document.body.clientwidth; } function getclientheight() { return document.compatmode=='css1compat'&&!window.opera?document.documentelement.c lientheight:document.body.clientheight; } </script> </head> <?php $nojsobsah = '<div id="obsah" style="text-align: middle; padding: 50px 200px"> <h1>fotogalerie test JHŠ</h1> Prosím zvolte velikost okna:<br> <a href="main.php?scrw=770&scrh=400&r&b&nojs"> </a><br> <a href="main.php?scrw=1000&scrh=570&r&b&nojs"> </a>

61 XVI <br> <a href="main.php?scrw=1250&scrh=600&r&b&nojs"> </a> <br> <a href="main.php?scrw=1570&scrh=1000&&b&nojs"> </a> <br> </p> <h2>není podporován JavaScript!<br>Některé funkce mohou být omezeny.</h2> </div>'; //výpis obsahu dle podpory JS if ($_SESSION["orig"]["script"]): echo '<body onload="window.settimeout(\'initscr();\',1000);"> <div id="pb"><img src="images/pb1.gif" border="0" alt="nahrávám aplikaci..."></div><noscript>'.$nojsobsah.'</noscript>'; else: echo '<body>'.$nojsobsah; endif;?> </body></html> main.php <?php session_start(); //kontrola session, jinak návrat na index.php if (!array_key_exists('orig', $_SESSION)): header ("HTTP/ Found"); der("location: index.php"); hea 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)):