Hieronder enkele belangrijke punten die ik meebracht vanuit Londen
Designing effective mobile interfaces
Met enkele cijfers toonde Megan Fischer (SimpleBits) aan dat mobiel internet aan een sterke opmars bezig is. Globaal is er een groei van 15 tot 20 % per maand, wat 8 X zo snel is als desktop internet toegang. De kans is dus groot dat je in de nabije toekomst geconfronteerd wordt met mobiel internet. Op het eerste moment lijkt ontwikkeling voor de mobiele markt een echte uitdaging. Er zijn enorm veel verschillende toestellen elk met hun eigen niveau van css ondersteuning en schermresolutie. Gelukkig zijn er al voldoende bronnen die je op weg kunnen helpen: bijvoorbeeld het boek Mobile Web Design door Cameron Moll.
niveau van ondersteuning
- Naked: Gebruiker doorverwijzen naar een mobiele versie waarvan de css en beelden verwijderd zijn. Dit zorgt voor snelle laadtijden. Door het ontbreken van extra bestanden is deze versie zeer onderhoudsvriendelijk. Pure html zorgt natuurlijk wel voor een saaie gebruikerservaring.
- Some style: Mobiel stylesheet zorgt voor een minimum aan stijl. Een header met logo en een basis pallet aan kleuren versterken in dit geval de branding van de site. Hierbij is het wel aan te raden om de grootte van beelden te beperken.
- Deck it out: Afzonderlijke website specifiek voor mobiel gebruik. Herschreven mark-up die aangepast is aan de noden van een mobiel gebruiker.
Typography on the web
opening the floodgates with @fontface
Het beperkte gamma aan fonts bij webdesign lijkt op het eerste moment een beperking. Met de komst van @fontface zou een einde komen aan dit tijdperk. Mark Bolton had hierbij enkele bedenkingen. Op technisch vlak zijn er nog problemen, browsers zijn het nog niet eens over de implementatie en rendering. Ontwerpers van lettertypes maken zich ernstig zorgen over licenties en copyrights. Maar er zijn nog enkele andere knelpunten:
- Meeste lettertypes zijn niet ontworpen voor schermweergave. “Times New Roman” werd bijvoorbeeld ontworpen voor krantendruk. De smalle schreven zetten uit tijdens het drukken door de snelheid van het drukprocédé en de lage kwaliteit van het papier. Op het scherm daarintegen werkt dit niet, bij kleine fontgrootte zijn de schreven amper zichtbaar.
- lettertypes zijn ontworpen voor een bepaald doel of sfeer. “Comic Sans” is technisch en estetisch gezien geen slecht lettertype, maar het is wel 9 op de 10 keer het verkeerde lettertype voor de opdracht.
making good design decisions
Studies hebben uitgewezen dat de verkoop van een product daalt naarmate het aantal varianten toeneemt. Mark Bolton gaf het voorbeeld van een experiment in een warenhuis. Klanten kregen een waardebon om een pot confituur af te halen. Wanneer 24 verschillende soorten tentoongesteld stonden ging slechts 3% over tot een aankoop. Toen het aanbod naar 6 soorten werd teruggebracht liep 30 % van de klanten met een pot confituur de winkel buiten. Hiermee werd aangegeven dat teveel keuze hinderlijk is voor een beslissingsproces.
Hetzelfde principe is van toepassing op webdesign. Een mooi voorbeeld hiervan is de interface van een rich text editor zoals TinyMCE. De gebruiker wordt een arsenaal aan verschillende opmaak mogelijkheden aangeboden waarvan niet alle combinaties even estetisch verantwoord zijn. Misschien is het beter om het aantal keuzes te beperken, bijvoorbeeld enkel fonten en kleuren aanbieden die binnen de branding vallen. De term “cascading style decisions” werd gebruik als een mogelijke oplossing. In plaats van alle mogelijkheden op een dienblad aan te bieden kan je stapsgewijs werken. Het lettertype kan je laten kiezen op basis van de sfeer die uitgestraald moet worden. Zakelijk, modern, speels zijn termen die meer aanspreken dan “Georgia”, “Arial”, “Comic Sans”. Kleuren kunnen op dezelfde wijze aangeboden worden.
Keuze is belangrijk, maar begeleiding in het proces is dus cruciaal om tot goede (design) beslissingen te komen.
Future Of Webstandards
Een fragment uit de TV-serie “the big bang theory” legde de basis van Molly Holzschlag haar presentatie.
Rock
Rock staat voor de basisprincipe van standaarden. Voor iedereen, overal beschikbaar, sociaal, gebruiksvriendelijk, … Dit hadden Tim Berners-Lee en zijn collega’s voor ogen toen ze de aanzet gaven voor het World Wide Web. Klinkt goed, maar dit is niet het internet dat we vandaag hebben. Net zoals de Amerikaanse grondwet zijn de beginselen idealistisch, maar de manier waarop ze toegepast worden minder mooi.
Paper
Het woord “markup” of opmaaktaal komt oorspronkelijk uit de uitgeverswereld, waar boeken met instructies voor de drukker werden voorzien. Het is geen nieuwe technologie, enkel gedigitaliseerd.
Momenteel zijn verschillende versies in gebruik: HTML 4.01, XHTML 1.0, XHTML 1.1, XHTML 2 en HTML 5. Aangezien XML niet ondersteund wordt in de MIME type van een belangrijke browser. XHTML heeft dus momenteel geen meerwaarde buiten de strengheid bij het schrijven van code (hoofdletters, onderkast,…). Rond HTML 5 is een misverstand dat het pas tegen 2020 zou afgewerkt zijn. Neem het voorbeeld van CSS 2.1 waar het voorstel in 1998 werd uitgewerkt en tot op vandaag nog geen definitieve versie beschikbaar is. De geïmplementeerde standaard wordt dus de “echte” standaard. Het wordt dus echt de moeite waard om de evolutie en mogelijkheden van HTML 5 te volgen.
Scissors (cut it out)
Er is een enorme evolutie in browsers, Internet Explorer inbegrepen. IE8 in standard mode is een goede browser met uitstekende css ondersteuning. Maar het loopt mis door de verschillende versies, IE8 kan een webpagina op verschillende manieren verwerken (Quirks Mode, Standards Mode, IE7 Compatibility Mode) wat voor webdevelopers die nog steeds met IE6 geconfronteerd worden een hindernis is. Versionering staat loodrecht tegenover de beginselen van standaarden.
Lizzard (get on with it)
Technologieën zoals SVG, SMIL en bijvoorbeeld Microformats zijn al jaren beschikbaar en worden nog te weinig toegepast.
Spock (futureproof)
Het uiteindelijke doel is “Open Web Stack”, open source op alle levels.
Flash & custom fonts, het blijft een speciale combinatie. Op zich is een custom font gebruiken niet moeilijk, maar wat als je extended ASCII karakters wil gebruiken?
Bij de uitwerking van een Flash ActionScript 3 project voor Toyota Europe werd ons de vraag gesteld om ondersteuning te bieden voor andere talen, met hun eigen tekenset, zoals o.a. een Cyrillische tekenset. Zo gingen wij op zoek naar de meest efficiënte manier om een custom font te embedden, met ondersteuning voor de meer exotische karakters.
Fonts in de library
Een eerste, logische stap zou zijn om het gewenste font in onze Flash library op te slaan, en daaruit te exporteren.
Met het font in onze library kunnen we nu in de code duiken. We creëren een TextFormat object, waarin we de .name property invullen met de naam van ons font (de naam zoals je die ziet in elke tekst editor). Een goede manier om de naam van het font op te halen is via de Font.enumerateFonts() methode.
var fonts:Array = Font.enumerateFonts(false);
fonts.sortOn("fontName", Array.CASEINSENSITIVE);
var fmt:TextFormat = new TextFormat();
fmt.font = fonts[0].fontName; // Naam van het font als String
fmt.color = 0x4E3E16;
fmt.size = 20;
fmt.bold = false;
Om tekst te tonen hebben we natuurlijk een TextField nodig. Een overzicht van de belangrijkste properties.
var normalField:TextField = new TextField();
normalField.defaultTextFormat = fmt;
normalField.embedFonts = true;
normalField.text = "Custom font\n.text property\n&éèà# Ъ ē Ψ";
Als resultaat krijgen we volgende Flash movie. Het linkse veld is normale tekst, het rechtse html tekst.
Zoals je ziet worden de ‘gewone’ ASCII tekens en accenten getoond, de Cyrillische en Griekse tekens zijn echter in geen van beide gevallen zichtbaar.
[kml_flashembed fversion="9.0.0" movie="/wp-content/uploads/2009/01/as3-fontembedding-swf-01.swf" targetclass="flashmovie" publishmethod="dynamic" width="471" height="140"]
[/kml_flashembed]
Een font embedden in een tekstveld
Als we even terug de Flash IDE induiken, kunnen we een nieuw Flash AS3 bestand aanmaken. In dit bestand creëren we via de IDE een dynamisch tekstveld. In dit veld embedden we ons font via de ‘embed’-knop.
In ons geval embedden we de volgende karakter sets:
- Uppercase [A..Z]
- Lowercase [a..z]
- Numerals [0..9]
- Punctuation [!@#%...]
- Basic Latin
- Latin I
- Latin Extended A
- Greek
- Cyrillic
Als we tekst in dit tekstveld stoppen, zien we dat onze tekst getoond wordt, het font zit dus mee in onze movie.
Het zou natuurlijk nogal omslachtig zijn om per blok tekst een veld manueel op de stage te plaatsen. Een oplossing hiervoor is dat we ons tekstveld in een MovieClip stoppen. We hebben nu dus een MovieClip op onze stage, met daarin een TextField waarin ons font zit.
Deze MovieClip kunnen we nu van onze stage verwijderen, daar die toch nog in de library zit. Als we nu de MovieClip een klasse naam geven (bij de linkage eigenschappen) kunnen we deze exporteren.
Merk op dat ik de Sprite klasse als base class definieer, dit omdat we in deze ‘MovieClip’ geen gebruik maken van de timeline mogelijkheden.
Nu kunnen we ons font binnen onze applicatie gebruiken, mits we deze MovieClip 1x instantieren (zodat het font mee gecompileerd wordt).
new EmbeddedFont(); // Eénmalig instantieren
var field:TextField = new TextField();
field.embedFonts = true;
field.htmlText = "<font face=\"My Font\" size=\"20\" color=\"#4e3e16\">Custom font<br>.htmlText property<br>&éèà# Ъ ē Ψ</font>";
addChild(field);
Dit is echter niet praktisch, als we bijvoorbeeld meerdere SWF bestanden gebruiken zouden we telkens deze MovieClip moeten kopiëren naar elk FLA bestand. En wat dan als we helemaal geen FLA bestanden gebruiken om te compileren (bvb. via het Flex SDK)?
Een tekstveld in een SWC
Hoe kunnen we er nu voor zorgen dat we gemakkelijk aan onze geëxporteerde Sprite kunnen, zodat deze kan geinstantieerd worden? Via een centraal SWC bestand natuurlijk.
Bij de publicatie instellingen van onze FLA kunnen we er voor kiezen om deze Flash movie ook als SWC bestand exporteren.
Dit SWC bestand bevat dus onze Sprite met daarin het tekstveld en kunnen we voortaan gebruiken doorheen onze applicaties.
In ons voorbeeld hebben we de Sprite geëxporteerd als klasse EmbeddedFont. Nu kunnen we in een willekeurige Flash movie deze SWC integreren (via FDT kun je deze bijvoorbeeld aan je ’source folder’ toevoegen). De geëxporteerde klasse kan nu gebruikt worden in ons nieuw project.
Stel dat we in onze Flash applicatie een tekstveld willen, met daarin terug enkele speciale karakters, het enige wat we nu moeten doen is eenmalig een instantie aanmaken van onze geëxporteerde Sprite, zodat de compiler weet dat deze mee in de SWF moet.
Dan kunnen we doorheen alle klasses van de applicatie tekstvelden aanmaken, en ons font gebruiken.
new EmbeddedFont(); // Eénmalig instantieren
var field:TextField = new TextField();
field.embedFonts = true;
field.htmlText = "<font face=\"My Font\" size=\"20\" color=\"#4e3e16\">Custom font<br>.htmlText property<br>&éèà# Ъ ē Ψ</font>";
addChild(field);
Omdat we deze keer gebruik maken van de .htmlText property hoeven we hier geen TextFormat object aan te maken. Wil je gewoon de .text property gebruiken, dan werk je natuurlijk best wel met een TextFormat object.
Let erop dat we terug de naam van het font letterlijk moeten gebruiken, zoals je deze bijvoorbeeld in de Flash IDE ziet.
Links hebben we terug een tekstveld opgevuld via de .text property, links via de .htmlText property.
[kml_flashembed fversion="9.0.0" movie="/wp-content/uploads/2009/01/as3-fontembedding-swf-02.swf" targetclass="flashmovie" publishmethod="dynamic" width="471" height="140"]
[/kml_flashembed]
Meerdere SWF-files
Alles in orde zou je denken, maar wat dan als een applicatie meerdere SWF bestanden bevat?
Links hebben we hier een tekstveld binnen de SWF waarin we onze geëxporteerde EmbeddedFont klasse instantieren, het rechtse tekstveld zit in een SWF die bij runtime ingeladen wordt.
[kml_flashembed fversion="9.0.0" movie="/wp-content/uploads/2009/01/as3-fontembedding-swf-03.swf" targetclass="flashmovie" publishmethod="dynamic" width="471" height="140"]
[/kml_flashembed]
Ons font wordt dus niet getoond doorheen alle SWF bestanden.
Doordat we met een SWC bestand werken waarin ons font vervat zit, kunnen we dit gemakkelijk oplossen. Een gemakkelijke manier is om gewoon binnen elk SWF bestand, onze geëxporteerde klasse één maal te importeren.
In onderstaand voorbeeld hebben we terug een SWF bestand, met links een tekstveld, en rechts een ingeladen SWF bestand met ook een tekstveld. In beide SWF bestanden wordt onze klasse 1x geinstantieerd, en nu worden alle tekens getoond.
[kml_flashembed fversion="9.0.0" movie="/wp-content/uploads/2009/01/as3-fontembedding-swf-04.swf" targetclass="flashmovie" publishmethod="dynamic" width="471" height="140"]
[/kml_flashembed]
Conclusie
Er zijn natuurlijk meerdere manieren om fonts te gebruiken binnen Flash, en elke manier heeft zijn voor- en nadelen. Uit ervaring merken wij echter dat deze manier weinig omslachtig en zeer flexibel is. Ook vooral de ondersteuning van allerhande tekensets naar wens zorgt ervoor dat deze implementatie gemakkelijk werkt.
