Afstemming
Het is het W3C vooral te doen om de echte nieuwe functionaliteiten zoals HTML5-video en –audio en de uitbreiding van standaard formulier mogelijkheden. Deze onderdelen van HTML5 verrijken de mogelijkheden binnen de browser waarmee er een directe discussie ontstaat op welke wijze deze verrijking exact moet werken.

Het probleem dat het consortium aankaart is dat implementaties op dit moment, een probleem kan geven in toekomstige browser-versies omdat de specificatie hiervan nog niet volledig is afgerond.

Als gevolg van de bekendheid van het W3C is het advies om HTML5 nog niet te implementeren vaak voorbij gekomen op IT-nieuwssites, maar geven onvoldoende houvast voor verschillende betrokkenen die zijdelings te maken (kunnen) krijgen met HTML5, zoals webbouwers en opdrachtgevers, om te bepalen wat dit betekent voor het heden en de (nabije) toekomst.

Concurrent van Flash
HTML5 is op een aantal vlakken een zeer grote concurrent van het platform onafhankelijke Flash aan het worden. Zeker met de opkomst van de iPhone en iPad, waar Flash niet op kan draaien, lijkt de toekomst van HTML5 zeer rooskleurig.

Het enthousiasme waarmee de browsers Firefox, Safari, Chrome en Opera de nieuwe techniek al een behoorlijke tijdje hebben ingebakken in hun software, geven webbouwers nu ook de mogelijkheid om hiermee te experimenteren. Zelfs in de nieuwste versie van Internet Explorer, IE9 dat nu nog in beta is, wordt HTML5 al voor een groot deel ondersteund.

Dat HTML5 de toekomst heeft lijkt hiermee gegarandeerd, en het begint op dit moment al vormen van een echte hype aan te nemen.

Officieel nog niet af
HTML5 is al sinds 2004 in ontwikkeling. Aangezien het W3C hier aanvankelijk geen toekomst in zag, is de ontwikkeling ervan voor een groot deel bewerkstelligt door het WHATWG, een werkgroep met individuele werknemers van Apple, Mozilla en Opera. Microsoft, de grootste browser-fabrikant, doet niet mee met deze werkgroep.

Pas in latere fase heeft het W3C de specificatie van HTML5 weer opgenomen in haar takenpakket. Door de betrokkenheid van de browser-fabrikanten zal het geen verrassing zijn dat de nieuwe functionaliteiten al snel werden opgenomen in Firefox, Safari en Opera. Een belangrijke vraag is dan ook in hoeverre sommige onderdelen uit het HTML5-spectrum nog drastisch zullen worden aangepast.

De kunst van het documenteren
Naast de eerder genoemde functionele toevoeging die HTML5 met zich meebrengt, zijn er ook toevoegingen die betrekking hebben op de syntax en de semantische opbouw van een HTML-document.

In eerdere HTML-specificaties werd veel, misschien wel te veel, rekening gehouden met de uitbreidbaarheid. Daarom zijn regels opgesteld waarin  gespecifeerd moest worden waar een bepaalde HTML-element precies voor diende. Een decennium later blijkt dat een groot deel van deze overhead beter weggelaten kan worden, omdat de uitbreidingen zich op een andere manier aandienen.

Verder bleek HTML onvoldoende mogelijkheden te bieden om aan te geven waar een bepaald deel van een document voor dient. Daarom zijn er een aantal semantische elementen toegevoegd die hier beter inzicht in kunnen geven: <header>, <article>, <nav>, <footer>. Juist deze minder functionele aanpassingen hebben weinig impact op het gedrag van een browser en zullen dus geen problemen opleveren. Ze zijn zelfs voor de oudere browsers (bijvoorbeeld IE6) met een kleine aanpassing geschikt te maken.

Ready or not: stilstand is achteruitgang
Nog altijd de helft van alle internetgebruikers wereldwijd heeft Internet Explorer als voorkeursbrowser. Omdat de implementatie van bepaalde HTML5 onderdelen juist in IE nog niet ver is, zullen websites voorlopig nog een terugvalmechanisme moeten bevatten voor deze groep.

Maar voor die andere helft gebruikers, die nog altijd groeit, is het de moeite waard om te onderzoeken of er meerwaarde gecreëerd kan worden door nieuwe technieken toe te passen.

Concessies doen aan de installbase van nieuwe techieken, of  principiele bezwaren van instanties als het W3C ten opzichte van de praktische impact moeten natuurlijk altijd in overweging worden genomen.

Maar websites zijn er voor de bezoeker. Niet voor het W3C, browser-fabrikanten of websitebouwers/-beheerders.

Verder lezen:

• The W3C and the “HTML5 Isn’t Ready” Backlash – Craig Buckler
• Hold off on deploying HTML5 in websites? – Remy Sharp
• Dive Into HTML5

Hoe kunnen ontwerpen toegankelijker worden gemaakt?

Use case (scenario) modellering kan hier uitkomst bieden omdat alle interactie tussen het systeem en de gebruiker wordt uitgewerkt. Het ontwerp wordt ook toegankelijker en makkelijker te controleren  door  de visuele representaties van uses cases in bijvoorbeeld het context diagram en activity diagrams. De volledigheid van een ontwerp kan o.a. worden gecontroleerd door requirements te koppelen aan Use cases en Use cases aan (prototype) schermen. In de praktijk worden Use cases echter vaak niet uitgewerkt omdat dit in Word en de losse tools arbeidsintensief is. Tevens is het aanbrengen en onderhouden van relaties tussen requirements en Use cases eveneens arbeidsintensief, foutgevoelig en lastig te controleren. Dit is exact de behoefte waar Topteam op inspeelt.

Requirements modelleren in Topteam

Topteam is een client-server applicatie met een Windows interface. Na inloggen toont de applicatie de project tree met o.a. requirements, Use cases, schermen, woordenlijst, diagrammen (zie afbeelding 1). Tevens zijn er speciale doorsnedes o.a. voor het bewerken van requirements, Use cases, issues/RFC’s, Testcases en projecten.

Requirements kunnen worden geïmporteerd vanuit Word of Excel, waarbij ook kenmerken als type (b.v. non functioneel) en prioriteit mee worden genomen. Requirements kunnen ook direct in Topteam worden ingevoerd, waarbij de gebruiker de keuze heeft tussen een Word achtige interface (genummerde lijst met nivo’s) of een lijst/boom interface. Dit is waar de meeste requirements management tools stoppen. Topteam bevat echter ook een uitgebreide ondersteuning voor het verder vertalen van de requirements naar Use cases en daar vervolgens weer schermen aan te koppelen. Op basis van de Use case lijst kunnen één of meerdere Context en Use case diagrammen worden gegenereerd.

Wijzigingen in het Use case diagram, bijvoorbeeld het tekenen van een relatie tussen een Actor en een Use case, worden ook bijgewerkt in de Use cases en vice-versa. De requirements kunnen eenvoudig aan Use cases worden gekoppeld door eenvoudigweg een lijn tussen beiden te trekken in het “Tracebility diagram”. Hierdoor heb je als ontwerper bij het beschrijven van de Use Case de requirements direct bij de hand.

Krachtige functionaliteit rondom Use cases

Het bewerken van Use cases, en met name Use case scenario’s, is waar Topteam in excelleert.  Het uitwerken van de scenario’s gebeurt in een Word-achtige interface die razendsnel werkt en waarbij het systeem begrijpt wat wordt ingevoerd.  Zo worden Actoren, schermen, andere Use cases en begrippen automatisch herkend of kan de gebruiker deze kiezen uit een lijst. Op deze manier wordt ook de traceability links tussen Use cases en requirements, Use cases en schermen vastgelegd.

Kers op de taart is het Activity diagram, eventueel met swimlanes,  dat de tool geheel automatisch genereert op basis van de scenario’s. De gebruiker kan projecten, releases en iteraties definiëren en hier de requirements en Use cases aan koppelen. Hierbij bieden de vrijwel onbegrenste querymogelijkheden van de tool een helpende hand, doordat zowat elke doorsnede door de repository kan worden gemaakt, en alle gevonden items vervolgens in één keer kunnen worden bewerkt (b.v. koppelen aan een release).

Solide versiebeheer en Word ontwerpen genereren

Topteam houdt automatisch van vrijwel alles een versiehistorie bij, waarbij voor iedere wijziging een nieuwe versie wordt aangemaakt. Zo kan je altijd teruggevallen op een oudere versie. En kunnen verschillen tussen versies worden bekeken. Tevens kunnen projectbrede baselines worden aangemaakt.

Topteam kan ontwerpen in een Word document generen door een doorsnede te maken uit de repository.  Standaard worden er maar liefst 60 templates meegeleverd die geheel naar eigen hand aan te passen zijn. Hierbij kan ook gebruik worden gemaakt van de tracebility links, bijvoorbeeld om bij een Use case gerelateerde requirements en schermen te tonen.

Tevens biedt topteam de mogelijkheid het hele ontwerp te exporteren naar Microsoft TFS waardoor de projectmanager en developer direct kan plannen en ontwikkelen op basis van Use cases.

Volgende week deel 2 van de review, met daarin de beperkingen, praktijkervaring en conclusie!

Al tijden wordt er getest volgens de testaanpak van TMap Next. Afgelopen maand is het derde TMap Next certificaat behaald, waardoor alle testers TMap Next gecertificeerd zijn!

Hiermee stopt ons verbeter proces natuurlijk nog niet. Door middel van Test Proces Improvement (TPI Next, zie http://www.tmap.net/Home/TMap/TPINEXT.jsp voor meer informatie) zijn we bezig om onze testafdeling naar een nog hoger niveau te brengen.

Wat is testen?

Testen is het inzicht geven in de kwaliteit van het informatiesysteem. Wij gaan voor Redhotkwaliteit.

Er bestaan verschillende definities over testen en er zijn verschillende testmethodieken gedefinieerd. Zo bestaat er de testaanpak TMap, welke in Nederland de meest toonaangevende en meest gebruikte testaanpak is. De definitie van testen volgens TMap luidt: “Testen is een proces van plannen, voorbereiden, uitvoeren en beoordelen, dat tot doel heeft de kenmerken van een informatiesysteem vast te stellen en het verschil tussen de actuele en de vereiste status aan te tonen.”

Met andere woorden betekent dit:

1)      Inzicht geven in kwaliteit d.m.v.:

• Toetsen: Reviewen documenten, zoals ontwerpdocumentatie
• Testen: Inspecteren van eindproducten

2)      Vroegtijdig fouten signaleren

• Kosten besparen (minder  onderhoudsmeldingen)
• Tijd besparen (tijdens project)

3)      Risico’s in kaart brengen

• Risicovolle onderdelen van de webapplicatie in kaart brengen
• Known issues lijst opleveren

4)      Verwachtingsmanagement

• Communicatie wat er getest wordt
• Duidelijkere communicatie wanneer en vooral wat er af is
• Known issues lijst

Wat is TMap Next?

TMap Next is de vernieuwde TMap testaanpak.

• TMap is gebaseerd op een business driven testmanagement (BDTM) aanpak.
• TMap beschrijft een gestructureerd testproces.
• TMap bevat een complete gereedschapkist.
• TMap is een adaptieve testmethode.

Zie voor meer informatie over TMap op http://www.tmap.net/

Wat doen we zoal?

• Reviewen documenten (= toetsen)
• Voorbereiden (Testplan, Testplanning)
• Afstemming met de klant
• Specificatie (Testscenario’s opstellen)
• Uitvoering (Testen, Bevindingenbeheer, Hertest)
• Afronding (Testrapport, vrijgaveadvies)

Wat kunnen we opleveren?

• Testplan
• Testscenario’s (voor Gebruikers acceptatie Test)
• Testrapport incl. vrijgaveadvies
• Assistentie bij Gebruikers Acceptatie Test
• Bevindingentool FogBugz

Natuurlijk heb ik een maar. Een paar zelfs. Hoe doe je dat dan met schoonmakers? Post-its zijn een vereiste en de kamer hangt samen van Scotch tape en whiteboard marker. Ik kreeg een mooie tweet terug van Pieter die avond:

Dat is natuurlijk wel een probleem. Creatief zijn is één, maar dat is gewoon onpraktisch. Eigenlijk wil je alles wat digitaal kan, digitaal maken. Onder voorwaarde dat het makkelijk benaderbaar is en niet drie mappen diep verstoft op een fileserver staat; dat visual designs en wireframes in een overzicht getoond kunnen worden en een helder gedeeld overzicht met post-its. Pieter verwoordt dat goed in zijn presentatie: “laat me maar weten als je een goede vindt, wij hebben ‘em nog niet gevonden”.

Een andere maar vind ik toch wel de fysieke ruimte. Scrum vereist een eigen scrumroom. Een met prikborden vol schetsen, whiteboards met delen van het TO en een lichte zweetlucht van het lang doorhalen de dag ervoor. Eigenlijk de oude vertrouwde zolderruimte. Toch, in een volwassen bedrijf lijkt me dat lastig te verwezenlijken. Daarbij, als een klant even de rem op een project gooit of dat het qua resources nou even beter uitkomt om een project voor te laten gaan, heb je je scrumroom niet even in de ijskast gezet. Laat niet weg dat het ideaal is voor het team en het project zelf.

Voor de een een langlopende hype, voor de ander een levenswijze. Mits volwassen toegepast en mits je als bedrijf in het diepe kunt en durft te springen kan het best werken. Sterker: ik denk dat project management zelfs inhoudelijk een meerwaarde geeft aan het product met Scrum (kom maar op met reacties..). Redhotminute werkt tot die tijd met het beste van beide werelden. Eerst maar eens een paar discussies voeren over het begrip ‘clean desk policy’..

P.s. De slides van Pieter zijn beschikbaar via Slideshare

Behoeftes en voordelen

Uw bezoekers zijn helaas niet in u geïnteresseerd. Alleen in zichzelf. Hoe kan uw product of dienst hun probleem oplossen of wens vervullen.

Als eerste zult u dus de kernbehoefte van uw ideale klant moeten vaststellen. Wil zij minder zorgen, meer gemak, meer zekerheid, meer geld, meer populariteit of minder twijfel?

Als tweede bepaalt u de belangrijkste voordelen van uw product/dienst voor uw ideale klant. Let op: voordelen zijn niet hetzelfde als specificaties! Het voordeel van een klopboormachine is niet de Press+Lock-snelspanboorhouder of de geïntegreerde stofafzuiging, maar het gemak waarmee je zonder rommel een gat in de muur maakt.

Headlines boven alles

Als u de behoefte en voordelen heeft vastgesteld kunt u gaan schrijven. Veel schrijven. De meeste copywriters beginnen met de headline. Dit zijn de eerste woorden die uw bezoekers lezen. Een goede headline geeft ook richting aan de rest van de tekst.

Een headline heeft maar één doel. Hij moet uitnodigen om door te lezen. De headline is de eerste stap in het AIDA model. Attention, Interest, Desire, Action. De headline trekt aandacht doordat hij de bezoeker emotioneel aanspreekt op zijn behoefte.

Een goed voorbeeld van een persoonlijke en emotionele headline is de headline die David Ogylvy schreef voor Rolls Royce: “at 60 miles an hour the loudest noise in this new Rolls-Royce comes from the electric clock.” (bekijk de originele advertentie).

Het schrijven van een goede headline kost tijd. Het overkomt mij regelmatig dat ik 200 verschillende headlines voor één tekst schrijf.

7 tips voor het schrijven van goede headlines

1. Schrijf vanuit het perpectief van de lezer. Uw lezer is geen specialist zoals u.

3. Schrijf niet voor de wereld, maar voor één ideale klant. Die klant bestaat. En het is uw plicht om hem uw website binnen te trekken.

4. Maak de headline persoonlijk en emotioneel. Lezers willen niet met een bedrijf praten, maar met een persoon die daar werkt.

5. Stel je na elke headline de vragen: So what? en Who cares? Dit voorkomt open deuren en algemene claims die niemand aanspreken.

6. Probeer uw headlines vragend te maken. Ons brein wil niets liever dan vragen beantwoorden.

7. Maak de headline niet te lang. Doe de adem-test om uw headline te testen. Kunt u hem niet in één adem uitspreken, dan is hij te lang.

In een volgende post ga ik dieper in op de andere tekstelementen van uw webpagina’s en email nieuwsbrieven. Er zijn online diverse blogs die helemaal gericht zijn op dit onderwerp. Een van mijn favorieten is www.copyblogger.com

Cheers,

Justin Kniest, Creative Director
Redhotminute.com - sites, stores en apps

PS. Als u dit een interessant artikel vindt, schrijft u zich dan vooral in voor onze nieuwsbrief. Daarin bespreken wij regelmatig de nieuwste ontwikkelingen in website ontwikkeling en online strategie. Lees hier meer over redhotminute en onze nieuwsbrief.

Als Dave in een zaal aankwam en de bruine M&M’s zaten nog in de schaal, wist hij dat de zaaleigenaar het contract niet goed gelezen had. En de ervaring had geleerd dat er dan ook belangrijkere zaken niet geregeld waren. Zoals te weinig stopcontacten voor de apparatuur. Door de M&M clausule kon hij rechtmatig het hele concert afzeggen of een flinke schadevergoeding eisen.

Dat is dan toch weer behoorlijk slim

Jump Dave, jump.

PS. Wil je weten hoe Van Halen ook al weer klinkt? Van Halen – Runnin’ With The Devil