Do's en Don't's bij het maken van websites?

[hamsteg]

Voor mijn werk struin ik regelmatig pagina's af naar informatie. Privé host ik een paar sites en ik vroeg me eigenlijk af wat maakt nu een goede zakelijke website? Vanuit mijn werk kom ik de meest gekke dingen tegen dat je denk "daar zou ik nooit willen kopen". Soms moet je een tijd wachten op een animatie, dan ben ik al weer weg ...

Het gaat dus om een zakelijke pagina, wat maakt die tot een succes. Je baas vraagt om even een bedrijf te bekijken en jij struint naar de pagina ... wat zijn afknappers, wat zijn goede dingen? Met name bij de kleinere hobby sites kom je de meest leerzame dingen tegen.

Don't's:

• Start pagina's alleen geschikt voor IE ...
• Alleen een flash animatie als intro pagina ... (helemaal als er geen skip mogelijkheid is)
• Start pagina beginnen met taal keuze (gewoon aan de hand van IP land bepalen en dan duidelijk zichtbaar de mogelijkheid tot taalveranderen, voorkeur met flaggetjes zodat je geen text hoeft te gebruiken)
• een .nl domein alleen in het Engels
• muziekjes
• Veel animaties in buttons en cursor volg dingtjes.
• Felle achtergrondkleuren.

Do's:

• Eerste pagina alleen maar vertellen wat het doel van het bedrijf is, welke producten er gemaakt worden, functionele foto erbij. De eerste 10 seconden zijn bepalend voor verder kijken of afknappen. Niet beginnen met geschiedenisles (=profiel).
• Duidelijke maar zakelijke menu mogelijkheden (knoppen of lijsten, waar je voorkeur naar uit).
• IE, Firefox en Opera getest.
• tweetalig (zie ook don't, .nl alleen engels)
• letter grootte aanpasbaar
• minimale pagina's: Home, Profiel, Product en Contact.
• contact pagina met alle gevens die voor een klant en leverancier van belang kan zijn (bankgegevens/KvK/email) en een plattegrond met locatie aangegeven.

[mithras]

• een .nl domein alleen in het Engels

Daar zou ik toch op in willen gaan. Een .nl domeinnaam duidt aan dat het bedrijf in Nederland is gevestigd, of het betreft een Nederlands filiaal / dochteronderneming. Wat het laatste betreft geef ik je gelijk, omdat er waarschijnlijk ook een (Engelstalige) .com, .net, .org oid site bestaat, waar informatie van het bedrijf in het Engels getoond wordt.
Maar wat betreft een Nederlands bedrijf dat alleen in Nederland gevestigd is: nee, die site mag denk ik best in het Engels zijn. Als dat bedrijf veel buitenlandse klanten heeft, met veel buitenlandse bedrijven contacten onderhoudt, is een Engelstalige site zeker zo logisch. En de .nl tld geeft dan aan dat het bedrijf in Nederland is gevestigd.

• minimale pagina's: Home, Profiel, Product en Contact.

Wat dat betreft ligt het meer aan het bedrijf. 'Home' en 'Contact' zijn wel benodigde pagina's, maar verder lijkt me niet dat 'Product' er bij moet zitten. Denk bijvoorbeeld aan Shell, die veel met (fossiele) brandstoffen bezig is, maar ook met onderzoek. Of de ANWB, die diensten levert die niet altijd als producten te benoemen zijn.

Voor een site moet het denk ik vooral belangrijk zijn dat er niet teveel informatie te vinden is. Omdat (eigenlijk iedereen weet dat) er niet teveel informatie op een pagina moet staan, wordt het dan verdeeld over meerdere pagina's. De pagina's moeten wel weer te vinden zijn, dus wordt de navigatiestructuur weer onoverzichtelijk. Bied precies voldoende informatie aan om mensen uit te nodigen.
Omdat je met persoonlijk gerichte informatie makkelijker klanten naar je toe kan trekken en sneller "vaste klanten" maakt, moet de site (subtiel) uitnodigen tot het contact zoeken met een medewerker. Mensen (en brochures) kunnen zo gerichtere, klantspecifieke informatie verschaffen.

[ Voor 47% gewijzigd door mithras op 03-07-2006 15:59 ]

[André]

Do's: zoekmachinevriendelijk

[RobIII]

Do's:

• Semantisch correcte pagina's
• Friendly URL's waar mogelijk (/aboutus in plaats van content.php?id=2)
• Meta descriptions en keywords
• Favicon / robots.txt
• Doctype gebruiken dat geschikt is voor de inhoud
• Gevalideerde HTML en CSS waar mogelijk
• Gebruik van ALT attributen
• Gebruik van P3P
• Userinput altijd server-side valideren
• Gebruik van Flash (en in sommige gevallen JS) zoveel mogelijk vermijden
• Letten op accessibility voor mensen met een (visuele) handicap etc.
• Pas .gif/.jpg/.png toe waar ze voor bedoeld zijn. Ik zie vaak jpg's die gif's hadden moeten zijn IMHO
• Privacy statements / Algemene voorwaarden en dat soort dingen
• Wachtwoorden niet "clear" opslaan, maar als MD5 hash ofzo (mocht je gehacked worden dan liggen de wachtwoorden van je klanten niet op straat, die ze waarschijnlijk op andere sites ook gebruiken)
• Gebruik POST / GET waar het voor bedoeld is (zie ik vaak verkeerd gebruikt worden)
• Vriendelijke (en intelligente (waar mogelijk)) 404's
• Een passende <title>
• Vermijd frames e.d.
• Sitemaps waar mogelijk
• ...

Dit zijn er zo een stuk of wat uit m'n blote bol zo 1 2 3 die je nog niet had. Zijn er nog zat....

[ Voor 45% gewijzigd door RobIII op 03-07-2006 16:06 ]

[AtleX]

Do's: standards based code, en dan niet alleen validerend maar ook semantisch correct. Hierbij komt eigenlijk automatisch support van andere browsers dan IE.

[hamsteg]

Meningsverschil Niet mee eens. Het is natuurlijk wel een beetje subjectief maar het gaat om de verwachting die een gebruiker heeft. Een website is een reclame middel. Een .nl domein is in mijn ogen bedoeld voor de nederlandse markt, niet alleen oorsprong maar ook doelgebied. De folders die je in de brievenbus vindt zijn toch ook nederlands? Dat het WWW het voordeel heeft dat iedereen er bij kan betekent toch niet dat je daarom een .nl omzet naar alleen engels? Dat de engelse taal eventueel als alternatief wordt aangeboden, snap ik helemaal, ben daar voorstander van maar alleen engels? Koop dan een .com

Was gisteren op zoek naar een metaalbedrijfje, 25 man, klantenkring 99% nederlands, de website compleet in het engels. De meeste van zijn klanten spreken waarschijnlijk niet eens fatsoenlijk engels. Dan mis je toch de klantenbinding die zo'n website kan bieden?

[mulder]

Don't:
Alleen een vlaggetje ipv text ivmb Textbrowsers

[RobIII]

Overigens vraag ik me af waarom je een engelse topictitel gebruikt als je en/nl zo belangrijk vindt
(Niet dat ik het niet (gedeeltelijk) met je eens ben, daar niet van)

Overigens heb ik niets meer van je gehoord

[ Voor 32% gewijzigd door RobIII op 03-07-2006 16:09 ]

[sanderb]

wat versta je onder een zakelijke site?
Voor een commercieel bedrijf is een website niet alleen een communicatiemiddel of winkel, maar ook een reclamefolder. Het ligt volledig aan de dienst of het product wat aangeboden wordt wat de vorm van de website zou moeten zijn.

De gemiddelde klant zal het worst wezen of een site technisch goed in elkaar zit.
Dat een site door een zoekmachine goed gevonden moet worden is natuurlijk voordelig voor het bedrijf, dus een do, net als dat de site er in zoveel mogelijk browsers goed uitziet.

Wat ik echter veel belangrijker vind, is dat de gebruiker het doel waarmee hij naar de website komt zo snel mogelijk bereikt.

Je kunt een site hebben die volledig aan alle technische do's and dont's voldoet, maar die niet aan de verwachtingen van de potentiele klant voldoet.

[geez]

Don Facundo schreef op maandag 03 juli 2006 @ 16:05:
Don't:
Alleen een vlaggetje ipv text ivmb Textbrowsers

ALT meegeven.

[Verwijderd]

Gebruik maken van printer geschikte css.

[RobIII]

Verwijderd schreef op maandag 03 juli 2006 @ 16:16:
Gebruik maken van printer geschikte css.

Je bedoelt neem ik aan een media="print" attribuut voor een stylesheet? De meeste CSS is geschikt om te printen /sarcasm

[ Voor 25% gewijzigd door RobIII op 03-07-2006 16:19 ]

[Verwijderd]

RobIII schreef op maandag 03 juli 2006 @ 16:17:
[...]

Je bedoelt neem ik aan een media="print" attribuut voor een stylesheet?

Bedoel dat idd, er is een groot verschil tussen papier en scherm.

[Tim Schuhmacher]

hamsteggot schreef op maandag 03 juli 2006 @ 15:39:

• tweetalig

Hangt gewoon van je doelgroep af

[ Voor 3% gewijzigd door Tim Schuhmacher op 03-07-2006 16:36 ]

[hamsteg]

@Don, daarvoor gebruik je ALT
@Tim, aangezien het internet toch als voertaal engels heeft zou ik voor een .nl site met twee talen werken.
@sanderb, 100% mee eens deze (technische) do's zijn een hulpmiddel, het belang van de klant is het belangrijkste. Maar een paar handvaten voor een startende designer zijn wel makkelijk

[Verwijderd]

Onder toegankelijkheid verstaan we ook:

• Correct taalgebruik (spelling, hoofdlettergebruik, spatiegebruik, grammatica, leestekens)
• Taalgebruik richten op de doelgroep, gebruik geen woorden waar de doelgroep niet mee bekend is.

Verder is het vrij simpel: als je een website meertalig maakt, bestaat de doelgroep waarschijnlijk niet alleen uit Nederlanders. Je zult dan al snel aan een .eu of .com gaan denken.
Verder heeft RobIII een aantal goede punten, alhoewel er een aantal totaal irrelevant zijn voor kleine websites.

[ Voor 2% gewijzigd door Verwijderd op 04-07-2006 17:44 . Reden: en dan zelf een spelfout maken... ]

[hamsteg]

Mee eens, de punten van RobIII zijn zeker belangrijk. Zeer belangrijk zelfs. Ik liep er een beetje aan voorbij maar dat komt omdat ik verwacht van een "web-designer" dat een aantal van deze items vanzelfsprekend is. Alleen ik mag niets als vanzelfsprekend aannemen dus goed opgemerkt Cheatah en dus ook RobIII.

[RobIII]

Nja... ik riep ook maar wat Zo zijn er IMHO nog -tig (belangrijke, minder belangrijke en zo-goed-als-niet-er-toe-doende) punten, maar die zijn volgens mij ook prima te vinden in de meeste webdev boeken en op dat ding dat internet heet
Ik zie eerlijk gezegd het nut van dit topic niet zo goed. Het is erg afhankelijk van wat je wil bereiken, wat je doelgroep is, wat je kunnen is, hoeveel tijd (=geld) je er in wil steken enzovoorts. Een 'algemene checklist' is zo niet erg makkelijk samen te stellen (of je moet een lijst willen met vierduizend items )

[ Voor 49% gewijzigd door RobIII op 03-07-2006 19:47 ]

[Wwwillem]

Don't:

• Java buttons met zo'n ronde gradient

[hamsteg]

Waarom dit topic? Ik ben technisch in staat prachtige sites te maken, browser compatible en foutloos volgens de standaard (de basis voor een website). Maar stel dat dit allemaal correct is, waarom blijft je bij een website hangen? Een aantal elementen is natuurlijk strikt persoonlijk, de een houdt van konijntjes en zal bij een menu met konijntjes langer blijven kijken als een ander die daar niet van houdt. Ik heb met name in de prive sfeer bijzonder leuke sites gezien met toeters en bellen, maar als ik om info zoek ben ik daar niet in ge"nteresseerd. SanderB heeft natuurlijk een goed niet technisch punt, je doelgroep is essenti"el uitgangspunt. Afstemmen op de ontvanger heet dat zo sjiek.

Toch zijn er wel een aantal generiek belangrijke items die mee spelen ... mijnpostbank.nl is al twee jaar de beste site in zijn soort, de zakelijke belastingdienst zou wel beter kunnen, tweakers.net vind ik een goede layout hebben. Ik probeer te achterhalen wat de x-factor is. Goede boeken op dit punt bestaan niet, de meesten duiken in CSS verhalen of de puur technische aspecten. Was er maar een boek met lange checklisten (en onderbouwing) dan kon je keuzes maken.

Er zijn wel 100-den check-listen met de top 10, 20 en 100 maar vaak met technische dingen als DOC type, META's, goed gebruik van titels etc. Een goede SDE regelt dit allemaal voor je, W3C checkt dit voor je dus ... Eigenlijk gaat het niet specifiek om web-pagina's maar meer over hoe je naar iets kijkt. Met interesse heb ik het 'F'-lezen van een website bekeken en heb daar eea van opgestoken. Zijn er nog meer van dit soort handige handvaten?

[Verwijderd]

hamsteggot schreef op maandag 03 juli 2006 @ 20:53:
Ik probeer te achterhalen wat de x-factor is.

Kan je lang naar zoeken, daarom heet het ook de x-factor.
Het is allemaal het onderbuik-gevoel van een goede designer icm het gebruiken van de laatste correcte technieken van een goede programmeur.
Jammer dat nou net dat onderbuik-gevoel zich niet laat omzetten in een afstreeplijstje en het werk van de programmeur nu weer wel.

[hamsteg]

Maar toch zijn er wel handvaten zoals het 'F' patroon lezen. Er zijn er vast nog wel een paar in die categorie.

[Pyrus]

Don Facundo schreef op maandag 03 juli 2006 @ 16:05:
Don't:
Alleen een vlaggetje ipv text ivmb Textbrowsers

Don't
Alleen een vlaggetje: een vlag staat voor een land, niet voor een taal. Neem bijvoorbeeld China: drie talen ,als ik het me goed herinner, met dezelfde vlag.
Navigatie rechts of beneden zetten, de ad hoc standaard is boven of links.

[Verwijderd]

hamsteggot schreef op maandag 03 juli 2006 @ 21:24:
Maar toch zijn er wel handvaten zoals het 'F' patroon lezen. Er zijn er vast nog wel een paar in die categorie.

Handvaten zat, bergen ia-sites en guidelines, nielsen, w3-zut en noem maar op,
die ontbrekende factor is niet te vangen in een rijtje (gelukkig).

[sanderb]

hamsteggot schreef op maandag 03 juli 2006 @ 21:24:
Maar toch zijn er wel handvaten zoals het 'F' patroon lezen. Er zijn er vast nog wel een paar in die categorie.

Ik vond dat onderzoek van Nielsen een mooi voorbeeld van een kip-ei verhaal.
Hoewel ik absoluut vertrouwen heb in de resultaten van dat onderzoek, kun je wat mij betrefd niet met zekerheid zeggen dat gebruikers in een F patroon willen lezen. Volgens mij is dat gewoon aangeleerd gedrag. Zoals iemand hierboven al zegt, een menu bevind zich links of boven op een pagina. Dat is al heel erg lang zo, en ik denk zelfs dat een Japanner of Arabier die veel op internationale sites zit dit gedrag zal vertonen, ook al is voor die persoon een ander gedrag natuurlijker vanuit zijn cultuur.

Toont dat onderzoek nu aan dat mensen in een F willen lezen, of toont dat onderzoek aan dat mensen goed opgelet hebben, en door hebben dat al sinds jaar en dag de belangrijkste informatie daar neergezet wordt? Als we begonnen waren met een menu/navigatie aan de rechterkant en dat volgehouden zouden hebben, zou je nu een ander patroon zien...

Hoe intuitief je een interface ook wil maken, aangeleerd gedrag gebaseerd op jarenlange ervaring is zeker zo sterk als intuitie. Nog een voorbeeld? Denk maar eens aan een stuur in een auto. Een kleuter snapt al hoe het werkt, maar eigenlijk is het totaal niet intuitief. Dat het toch werkt, en waarschijnlijk zelfs de beste oplossing is, is het gevolg van 100 jaar ervaring.

[GoT]

RIA ?

[Expander]

WAI?

[RobIII]

Expander schreef op maandag 03 juli 2006 @ 22:25:
WAI?

YA WAI

Effe serieus: Zo'n "F" patroon is natuurlijk allemaal heel leuk en aardig, maar het zijn (soms!) de sites die juist de "durf" hebben om zo'n gangbaar patroon te breken die een aantrekkingskracht (of X-factor, wat jij wil) hebben.
Als alles in "regeltjes" of voor mijn part "handvaten" aangereikt werd zagen alle sites er goed uit. Ik zeg dat je aan 't treasure hunten bent, maar de meeste treasures zijn al gejat of je zult er zelf 1 moeten begraven

m.a.w. stoei eens wat met navigatie, design, layout, techniek... AJAX (overhyped als de pest maar goed) is zo'n idee dat een paar jaar geleden nog niemand echt had kunnen bedenken (jaja...kom maar op met je bewijs dat het uit 1824 stamt , je weet wat ik bedoel) en milliondollarhomepage is een ander voorbeeld. Twee heel verschillende dingen, maar allebei geniaal in hun categorie IMHO. Juist als je de platgetreden graspaadjes verlaat en je diep in het woud stort zul je kans maken om een schat te vinden. Doe eens gek, leef je uit en verzin iets wat niemand nog heeft gedaan of bedacht. Dan zit je met je x-factor geheid geramd (tenzij je en websait bouwt over kantklossen ofzo natuurlijk )

[ Voor 17% gewijzigd door RobIII op 03-07-2006 22:37 ]

[André]

Een website geeft een gevoel, en er kunnen 2 totaal verschillende website zijn die je exact hetzelfde gevoel geven. Er is daarom geen goede guideline over hoe je het beste een website maakt. Er zijn wel een paar handvaten en regels die je moet hanteren.

Een goede website maken is daarom ook echt een vak apart en vereist een nauwe samenwerking tussen de designer en front-end webdeveloper. Beide horen veel ervaring en gevoel te hebben op het gebied van usability in het algemeen om tot een goed resultaat te komen.

En ja: er zijn ook wel n00bs die toevallig een site met een goede x-factor maken, maar over het algemeen is het echt vakwerk.

Ik werk veel met mensen die voor een groot deel hun brood op de plank krijgen door hun website. Daarbij is het ontzettend belangrijk dat je vakwerk aflevert en niet iets doet wat achteraf heel fout zou blijken. Dit is iets wat je gaandeweg leert en waar je gevoel voor ontwikkelt. Aan de hand van deze kennis kun je ook rustig een don't gebruiken op een positieve attractieve manier.

[D4V3]

Zorg dat de site er altijd hetzelfde uitziet in elke browser (d.m.v. goede code en semantisch web),
Zorg dat de site er aantrekkelijk uitziet, mooi maar niet te druk, het gaat om de content niet om de dingen er om heen. Probeer de 10 hoofdregels van een goed ontwerp zo veel mogelijk toe te passen (zie hieronder) en maak de navigatie helder en overzichtelijk.

De 10 vuistregels van een goed ontwerp (Usabilty):

Zichtbaarheid van de status van het systeem (of de applicatie)
Het systeem moet altijd informatie verstrekken aan de gebruikers over wat er aan de hand is, binnen een redelijk tijdsbestek.

Het systeem moet lijken op de werkelijkheid
Het systeem moet de taal van de gebruikers spreken, met logische begrippen en woorden, geen technische taal. Volg conventies uit de werkelijkheid, in een logische volgorde en structuur.

Gebruikersvrijheid en -controle
Gebruikers maken fouten bij het kiezen van de juiste functies. Geef ze een duidelijke uitweg als ze in een ongewilde situatie terecht komen, zonder al te veel complexe dialoog. Ondersteun Undo en redo.

Consistentie en standaarden
Gebruikers moeten zich niet hoeven afvragen of woorden, situaties, functies of acties wel altijd hetzelfde betekenen. Gebruik platform conventies en afspraken zoals: het licht in Windows komt altijd van linksboven.

Voorkom fouten (error prevention)
Voorkomen van fouten is altijd nog beter dan fouten verklaren, hoe goed die verklaring op zich ook is.

Herkenning is beter dan herinnering
Maak objecten en acties zichtbaar. De gebruikers zouden informatie van de ene dialoog niet moeten hoeven onthouden om de andere dialoog te kunnen begrijpen. Instructies voor het gebruik van het systeem moeten direct zichtbaar of anders eenvoudig te vinden zijn.

Flexibiliteit en gebruikersefficiëntie
Zowel beginners als experts moeten makkelijk met het systeem kunnen werken, Sta gebruikers dus toe het systeem en de functies naar eigen wens aan te passen, eventueel met behulp van versnellende functies zoals shortcuts

Flexibiliteit en gebruikersefficiëntie
Zowel beginners als experts moeten makkelijk met het systeem kunnen werken, Sta gebruikers dus toe het systeem en de functies naar eigen wens aan te passen, eventueel met behulp van versnellende functies zoals shortcuts

Esthetisch en minimalistisch design
Dialogen dienen slechts informatie te bevatten die relevant en vaak nodig is.

Help gebruikers fouten te herkennen, te diagnosticeren en te herstellen
Foutberichten moeten in normale taal geformuleerd zijn, dus geen codes. Ze dienen de fout duidelijk te omschrijven en een eventuele constructieve oplossing moet vermeld worden.


Deze regels zijn overigens toe te passen op bijna alle (software) ontwerpen en dus naast een website ook voor bijvoorbeeld een nieuwe applicatie in java.

Je zou ook de GUIDE methode kunnen toepassen op een bestaand of nieuw ontwerp, voor meer info hierover kan je beter een keer een Usability boek kopen van de nooit saaie (kuch) Jacob Nielssen.

[ Voor 5% gewijzigd door D4V3 op 04-07-2006 00:22 ]

[Verwijderd]

D4V3 schreef op dinsdag 04 juli 2006 @ 00:18:
Zorg dat de site er altijd hetzelfde uitziet in elke browser (d.m.v. goede code en semantisch web),

Onzin. Zorg dat je website er fatsoenlijk uitziet. Dat hoeft echt niet exact hetzelfde te zijn in elke browser. Dat dat wel handiger is, is iets anders.

Probeer de 10 hoofdregels van een goed ontwerp zo veel mogelijk toe te passen (zie hieronder) en maak de navigatie helder en overzichtelijk.

...

Deze regels zijn overigens toe te passen op bijna alle (software) ontwerpen en dus naast een website ook voor bijvoorbeeld een nieuwe applicatie in java.

Plaats dan gewoon een linkje naar het document waar je het uit hebt gehaald. Wel zo netjes, een bronvermelding.

Je zou ook de GUIDE methode kunnen toepassen op een bestaand of nieuw ontwerp, voor meer info hierover kan je beter een keer een Usability boek kopen van de nooit saaie (kuch) Jacob Nielssen.

Ik denk dat je maar weer beter kunt gaan gamen. Denk niet dat je van enige meerwaarde bent voor dit forum als je zulke onzin verkondigt. Je post is echt een beetje gelul in de ruimte.

[hamsteg]

@Cheatah, ik vind het jammer dat je mensen zo in de hoek zet ... terecht de opmerking over de link, misschien was het opsommen van de titels voldoende geweest. Je plaatst jezelf hierdoor een beetje boven mensen met wat minder ervaring terwijl wij juist van elkaar moeten leren. Niet iedereen heeft hetzelfde instapniveau (misschien heb jij in het verleden van anderen geleerd, geef die kennis dan netjes door).

RIA, heeft niets met de x-factor te maken. Het is een ontwikkelproces dat zich met kernwoorden als: eenvoud, open interfaces en snel aan te passen bedient. Het gaat uit van een goede architectuur en werkt met de nieuwere technieken als XML en AJAX (geen nieuwe techniek , wel een nieuw naampje).

WAI, yep heb ik al een poosje links laten liggen maar de toolset is heel handig. Heb gisteravond nog even gekeken en vond een aantal toch wel zeer handig (color wheel). Die moet ik in de gaten blijven houden.

Het onderzoek van Nielsen, is zeker manipulatief ... klopt. Toch is het voor de startende developer een belangrijke ondergrond waarom je je eerste websites met een menu boven of links moet beginnen.

De echte x-factor verwacht ik ook niet te vinden, dat is iets dat voor een specifieke website ineens ontstaat, verschillende vactoren komen dan ineens bij elkaar. Toch als wij naar idols kijken weten we uit de voorrondes de mensen er wel uit te pikken die hoogst waarschijnlijk doorgaan naar de volgende ronde. Er zijn dus wel handvaten ... alleen de echte toppers die hebben in dat scala weer wat unieks, stappen net weer af van gebaande paden (en soms ook niet en komen hele brave meisjes ook heel ver ... of misschien is braaf tegenwoordig wel uniek ...). Voorlopig ben ik al blij als ik door de voorrondes kom .

[Michali]

D4V3 schreef op dinsdag 04 juli 2006 @ 00:18:
Zorg dat de site er altijd hetzelfde uitziet in elke browser (d.m.v. goede code en semantisch web),

Dat heeft echt niets met semantische code te maken. Dat kun je net zo goed bereiken met totale bagger code. Maar het is natuurlijk wel een goed streven. Verder zijn je punten wel van belang.

@Cheatah: Ik ben het ook wel eens dat je hem niet zo hoeft weg te jagen. Hij probeert zijn kennis te delen, en als hij er naast zit kun je hem daar natuurlijk op wijzen. Soms is het goed bepaalde punten naar boven te halen, zonder zeker te weten of het wel correct is. Als je daar dan op gewezen wordt leer je, en anderen, daar weer van. Dat vind ik zelf altijd wel een goede strategie voor posten.

[RM-rf]

Een voor mij heel belangrijke 'don't' is:

• versimplificeer het ontwerpproces van een communicatie- of toepassingsmedium niet tot een dom en eenvoudig lijstje.

Voor je het weet gaan mensen zo'n eenvoudig 'do' of 'don't puntje als heilig ervaren, en hechten er meer waarde aan dan aan hun eigen 'common sense'....
Opdrachtgevers die dan opeens gaan zeggen: "onze site moet gemaakt worden voor 800x600 en dan maar openen in een vaste popup van die grootte", "Er mag geen gebruik worden gemaakt van javascript en flash, want plugins zijn slecht", "alles moet in DIVs want tabellen en/of frames zijn slecht".

Soms compleet tegengestelde eisen, gebaseerd op wat ze denken dat de 'kenmerken' van goed design zouden zijn, die vooral in eenvoudig te begrijpen hap-klare brokken verpakt zijn... maar veelal allerminst logisch werken en vooral de aandacht afleiden van een belangrijke issue en dat is dat een ontwerp-proces een individueel proces is waar aandacht voor details belangrijk zijn, flexibel zijn en je concenteren op de gebruikseisen...

Het bepalen van de functionaliteit (wàt moet een website communiceren; is dat enkel een 'visitekaartje'? moet het een 'atmosfeer' overbrengen? wordt de gebruiker aangespoord een actie te ondernemen? Welke informatie zoekt de gebruiker en voor welke doeleinden?)

[OkkE]

Over de taalkeuze, zoals Pyrus al aangeeft; geen vlaggetjes gebruiken. Een tijdje geleden stond hier nog een leuk artikel over taalkeuze op Naar Voren; een kleine quote:

Vlaggen?
Die vlaggen zijn hoe dan ook problematisch. Ze voegen misschien kleur toe aan de site, maar ze zijn daarmee vooral leuk voor luie webwerkers. Haal landen en talen niet door elkaar. Wat doe je met België? Wat met Groot-Brittannië en de VS? Geen vlaggen dus – niet op een intropagina, en ook niet elders in de navigatie.

Verder zijn de meeste punten al wel gemeld. Zolang je website gewoon duidelijk is, aansluit bij de doelgroep, etc...

[Verwijderd]

Ik denk dat je maar weer beter kunt gaan gamen. Denk niet dat je van enige meerwaarde bent voor dit forum als je zulke onzin verkondigt. Je post is echt een beetje gelul in de ruimte.

Ook al ben ik het in die post eens dat het niet zo handig was om het in een DIV te doen... Maar toch wil ik het wel eens weten..

Ik gebruik echt al heeeel lang tabellen in webpagina's, en waarom krijgen die lieve tabelletjes telkens stront over zich heen omdat DIV's "beter" zijn? Waarom zijn ze beter? Wat is het verschil, ik heb op google gezocht, dit forum, maar waarom zweren sommige mensen bij DIV's en andere mensen bij tabellen? Misschien omdat DIV's later geintroduceerd zijn (?) en het daarom 1337 is om die dingen te gebruiken ofzo?

Ikzelf gebruik ze echter gewoon allebei, wanneer het me het makkelijkst uitkomt... Ze werken toch allebei netjes crossbrowser...

[Joshua]

Do's
- Be Original

orginaliteit is denk ik ook erg belangrijk, ook al luid te spreekwoord "beter goed geript dan slecht bedacht" oid.

Ik zelf bekijk liever een site die erg orgineel is, dan een rip-off.

[Verwijderd]

Verwijderd schreef op dinsdag 04 juli 2006 @ 12:13:
[...]


Ook al ben ik het in die post eens dat het niet zo handig was om het in een DIV te doen... Maar toch wil ik het wel eens weten..
...

Dan gaat dit hele topic zwaar offtopic lopen als we hier verder op ingaan , maar zoek maar eens op semantiek. Dan gaat een hele wereld voor je open (hopelijk).

[ Voor 16% gewijzigd door Verwijderd op 04-07-2006 12:18 ]

[Verwijderd]

Verwijderd schreef op dinsdag 04 juli 2006 @ 12:13:
[...]


Ook al ben ik het in die post eens dat het niet zo handig was om het in een DIV te doen... Maar toch wil ik het wel eens weten..

Ik gebruik echt al heeeel lang tabellen in webpagina's, en waarom krijgen die lieve tabelletjes telkens stront over zich heen omdat DIV's "beter" zijn? Waarom zijn ze beter? Wat is het verschil, ik heb op google gezocht, dit forum, maar waarom zweren sommige mensen bij DIV's en andere mensen bij tabellen? Misschien omdat DIV's later geintroduceerd zijn (?) en het daarom 1337 is om die dingen te gebruiken ofzo?

Ikzelf gebruik ze echter gewoon allebei, wanneer het me het makkelijkst uitkomt... Ze werken toch allebei netjes crossbrowser...

of je nou heel je website uit tables, divs of em's opbouwt (misschien moet ik dat eens doen, is wel een illustratief voorbeeld), het is allemaal even slecht. Gebruik gewoon het juiste element voor het juiste doel.

[Rhapsody]

Allemaal leuk dat geouwehoer over semantiek e.d. Het belangrijkste is dat je site werkt in de meest bekende browsers (alle is helaas onmogelijk)
Wat ik bedoel is dat je nog zo'n geweldig stuk code kunt hebben met allerlei semantisch correcte constructies, als IE er een zooitje van maakt heb je daar niets aan. Alhoewel ik IE nog steeds de meest prettige browser vind om mee te werken kan ik niet ontkennen dat deze browser de standaarden maar half geimplementeerd heeft. Dan kun je met allerlei creatieve hacks ervoor zorgen dat je site toch overal goed te zien is, maar dan geef ik toch de voorkeur aan een minder semantische oplossing.

Je bezoeker kijkt niet naar de code, je bezoeker kijkt naar het resultaat. (over het algemeen gezien dus)


ff voor de duidelijkheid: het streven is natuurlijk wel om zo net mogelijke code te produceren.

[ Voor 7% gewijzigd door Rhapsody op 04-07-2006 12:38 ]

[RM-rf]

Rhapsody schreef op dinsdag 04 juli 2006 @ 12:30:

Allemaal leuk dat geouwehoer over semantiek e.d. Het belangrijkste is dat je site werkt in de meest bekende browsers (alle is helaas onmogelijk)

waarom is 'alle' niet mogelijk?

Aandacht besteden aan semantisch correcte code heeft wel degelijk nut voor de toepasbaarheid van de website, het oplossen van fouten, en ervoor zorgen dat deze browsercompatible is en blijft ...
Domweg omdat semantisch correct opgezette code veel handiger werkt....
de structuur kent een zeer overzichtelijke logica....

Als je het met een auto vergelijkt een goed ontwerp van de motor zal ook zorgen vor een betere auto... sneller om te maken, beter te optimaliseren en onderhouden... de bestuurder zal misschien niet zien wat er onderd e motorkap afspeelt, maar als daarachter veel logica zit, en bv de aandrijvingsriem niet toegepast wordt om ook de remkoeling te geleiden... merkt ook hij het verschil ...
Je ziet telkens eweer dat mensen met problemen komen, hun site niet geschikt krijgen voor verschillende browsers... deels omdat ze verzanden in compleet onoverzichtelijke code ... en deels omdat ze bv de verkeerde tags en structuren voor doeleinden gebruiken die er niet voor geschikt is (een TABLE is allerminst geschikt voor positionering en pixelprecieze uitlijning... voor zulke visuele trucjes wil je juist niet dat dat stuk HTML als TABLE gerenderd en geformateerd wordt)..

En nee, zelfs msie gaat zich niet beter gedragen door incorecte oplossingen en jouw idee dat semantische code-opzet betekent dat je 'hacks' gaat gebruiken is nu jist geheel fout... 'hacks' moet je ten allen tijde proberen te vermijden, maar een slechte en onlogische code-opzet gebruiken omdat dat 'makkelijker' zou zijn in msie is nu juist eigenlijk de allerlaagste 'hack'.
(en volgens mij moet je de twee deingen 'ik hou niet van gestructureerde logische code' en 'ik heb veel crossbrowser compatibility' probelemen' eens samenvoergen en je conclusie trekken: volgens mij hangt dat sterk samen)

[ Voor 17% gewijzigd door RM-rf op 04-07-2006 12:44 ]

[Verwijderd]

RM-rf schreef op dinsdag 04 juli 2006 @ 12:41:
[...]en deels omdat ze bv de verkeerde tags en structuren voor doeleinden gebruiken die er niet voor geschikt is (een TABLE is allerminst geschikt voor positionering en pixelprecieze uitlijning... voor zulke visuele trucjes wil je juist niet dat dat stuk HTML als TABLE gerenderd en geformateerd wordt)..

Waaat ? Waarom dat nou weer niet? Ik zal je even een voorbeeld laten zien, mag jij raden waarmee dat gedaan is en mag je ook raden wie het gemaakt heeft..

Sterker nog, mag je ook raden in welke browsers dit allemaal werkt Juist.. alle

Kijk hier: http://www.oblivionsource.com/gulst_show.wmv (heb ik 4-5 maanden terug ooit gemaakt)

Maar ik bedoel... dit werkt zo ontzettend goed, het is met tables gemaakt, het werkt in Opera, FireFox, IE6 & 7, wat wil een mens nog meer? Div's? Hier hoeft het dus niet...


Ik heb ook niet gebruik gemaakt van hacks of rare oplossing, om dingen zoals PNG een alpha layer mee te geven, heb ik gewoon gebruik gemaakt van de stylesheet oplossingen die IE wel heeft en andere browsers niet. Vergt iets meer code, maar dan heb je ook wat Het is strict gemaakt volgens de XHTML standaard

[ Voor 15% gewijzigd door Verwijderd op 04-07-2006 12:50 ]

[disjfa]

Verwijderd schreef op dinsdag 04 juli 2006 @ 12:48:
[...]
Sterker nog, mag je ook raden in welke browsers dit allemaal werkt Juist.. alle

En als jij dat handig vind moet jij je sites zeker zo maken. Maar dat is een compleet andere discussie dan die in dit topic.

[RM-rf]

Verwijderd schreef op dinsdag 04 juli 2006 @ 12:48:


Maar ik bedoel... dit werkt zo ontzettend goed, het is met tables gemaakt, het werkt in Opera, FireFox, IE6 & 7, wat wil een mens nog meer? Div's? Hier hoeft het dus niet...

Het is al fout als je gaat denken in tags die zouden 'mogen' of niet....
Alsof er 'absoluut foute' of 'absoluut goede' tags bestaan
gebruik tags gewoon voor de content waarvoor ze bedoeld zijn, en bovenal, laat je visuele layout niet door tags, maar door CSS creeeren, enkel biedt in de manier van renderen HTML daar een bepaald voorbeeld voor...

Over het renderen van Tabellen:
Een browser zal een TABLE renderen zoals het een TABLE hoort te renderen en dat is als een samenhangende vorm van gegevens die 'on-the-fly' gerenderd wordt, tijdens het laden...
een TABLE bestaat uit onderling samenhangende table-cellen die onderverdeeld zijn in de rijen en kolommen.... iedere aanpassing aan één cel heeft direkt invloed op de andere cellen in dezelfde rij en/of kolom...
als je wat van geheugengebruik van een computer weeet dis het aanpassen van een TD een stuk belastender voor het werkgeheugen dan een aanpassing van een DIV

wat betreft dat filmpje ... je gaat me niet vertellen dat die verschuivende blokken behoren tot één TABLE ....
Als de achterliggende code helemaal bestaat uit TABLE-tags en de verschillende blokken dan TD's zijn heb je je enorme problemen op de hals gehaald en is het heel knap als je dat werkend hebt gekregen en ook nog crossbrowser ... sjappeu... maar dat is eenzelfde prestatie als een vliegtuig bouwen uit luciferhoutjes en elastiekjes... de prestatie ligt er dan vooral in dat je jezelf enorm veel onnodig werk op de hals haalt.

Als het qua code eigenlijk gaat om een heleboel losstaande TABLE's, ofwel genest ofwel los van elkaar gepositioneerd ... tja, dan gebruik je deze tags zelf op een andere manier en benut je niet de essentie van de TABLE tag, en dat is het werken in TR's, TD's en TH's alswel evt.. caption, TBODY e.d.... het gebruik van een samenhangende structuur binnen die tag.

Verwijderd schreef op dinsdag 04 juli 2006 @ 12:48:

Het is strict gemaakt volgens de XHTML standaard

nee, het 'valideert' misschien ... maar als je de standaard van HTML zelf leest wordt er beschreven waarvoor bepaalde tags bedoeld zijn en wat je ermee dient te doen...
als jij je daar niet aanhoud maar op basis van je eigen ideeen code-soup genereert, loop je een groot risico dat je én veel tijd kwijtbent bij het bouwen ... en vervolgens een verder onderhoud van die code onmogelijk is omdat een andere ontwikkelaar diep moet duiken in ondoorzichtelijke codesoup van jou .. of als je het zelf doet, je vast na 6 maanden niet meer weet hoe je code precies is opgezet als dat niet snel te zien is door overzichtelijke code

[ Voor 30% gewijzigd door RM-rf op 04-07-2006 13:04 ]

[Verwijderd]

naast technisch correct en het gebruik van de juiste elementen, moet een site eruit knallen op een of andere manier.

de bezoeker moet een indruk krijgen, en dat is erg moeilijk te creeeren, vaak is dan overdone, te vrolijk, te saai, te flitsend.

vaak is een site het verlengstuk van de huisstijl, maar ook moet de site niet verouderen, het moet meegaan met de hededaagse stijl van websites, maar ook weer niet teveel veranderen dit vinden klanten niet leuk.

kortom er komt zoveel meer kijken dan alleen goede techniek, leuk uiterlijk en do`s en dont`s. je kan het best een X-factor noemen wat sommige sites hebben

[Verwijderd]

Hoe kun jij mijn code zien? Wordt dat ook al ge-embedded in een filmpje?

En natuurlijk is niet alles 1 tabel, al die venstertjes die je kunt verplaatsen zijn losstaande tabellen. En nee, mijn code is geen code-soup

Ik heb dit gemaakt door middel van Javascript en heel goed gebruik te maken van de mogelijkheden van de DOM functionaliteit. Ik heb hierbij echter geen DIV's gebruikt en wilde duidelijk maken dat ook Tabellen gebruikt kunnen worden voor positionering en pixelprecieze uitlijning...

Oh.. en in javascript bestaat ook nog zoiets als comments, ik hoop dat jij wel weet hoe je die moet gebruiken en je kunt dan wel degelijk na 6 maanden precies begrijpen hoe en waarom je iets zo hebt gedaan

[ Voor 18% gewijzigd door Verwijderd op 04-07-2006 13:11 ]

[Verwijderd]

One TR a day keeps the mods away

[ Voor 85% gewijzigd door BtM909 op 04-07-2006 14:13 ]

[mulder]

Don't voor toegankelijke websites:
Javascript

[disjfa]

Don Facundo schreef op dinsdag 04 juli 2006 @ 13:16:
Don't voor toegankelijke websites:
Javascript

Waarom? Je kan perfecte sites hebben die gebruik maken van javascript als je dat hebt en niet als de browser die niet heeft. Javascript gebruiken als meerwaarde is niet minder dan logisch.

[Verwijderd]

Don Facundo schreef op dinsdag 04 juli 2006 @ 13:16:
Don't voor toegankelijke websites:
Javascript

Klopt inderdaad, ben ik het mee eens Probleem is dat zoekmachines er helemaal niks meer van snappen... Maar ik had wel ergens in berichten gelezen op t.net dat Google er wel mee bezig was om ondersteuning daarvoor in te bouwen...

[mulder]

disjfa schreef op dinsdag 04 juli 2006 @ 13:18:
[...]

Waarom? Je kan perfecte sites hebben die gebruik maken van javascript als je dat hebt en niet als de browser die niet heeft. Javascript gebruiken als meerwaarde is niet minder dan logisch.

Het is extra ja, je zult dan altijd een javascriptloze versie 'moeten' hebben. Allemaal leuk die toeters & bellen maar het kan altijd zonder

[ Voor 3% gewijzigd door mulder op 04-07-2006 13:27 ]

[disjfa]

Don Facundo schreef op dinsdag 04 juli 2006 @ 13:27:
[...]
Het is extra ja, je zult dan altijd een javascriptloze versie 'moeten' hebben. Allemaal leuk die toeters & bellen maar het kan altijd zonder

Het ligt zoals meerdere al gezegd hebben geheel aan de opdracht die je hebt. Je hoeft nooit wat

[mulder]

disjfa schreef op dinsdag 04 juli 2006 @ 13:29:
[...]

Het ligt zoals meerdere al gezegd hebben geheel aan de opdracht die je hebt. Je hoeft nooit wat

Daarom zeg ik zet ik er ook 'toegankelijk websites' bij en plaats ik 'moeten' tussen 'quotes'. Je houd door geen javascript te gebruiken je website (navigatie, flow) eenvoudiger en je websites is toegankelijker voor bv je PDA (mediacenter etc etc)

[ Voor 6% gewijzigd door mulder op 04-07-2006 13:36 ]

[chem]

Rhapsody schreef op dinsdag 04 juli 2006 @ 12:30:
Je bezoeker kijkt niet naar de code, je bezoeker kijkt naar het resultaat. (over het algemeen gezien dus)

Jaaa lekker kortzichtig weer.

Wel eens gehoord van bv het opzoeken van informatie via lynx? Of mensen met een visuele handicap?

Of behoren gehandicapte mensen wat jou betreft maar tot een vervelende groep mensen die niet in je 90 percentiel valt?

En vind je de toekomst mbt semantisch web ook maar vervelend?

[André]

Verwijderd schreef op dinsdag 04 juli 2006 @ 13:19:
[...]


Klopt inderdaad, ben ik het mee eens Probleem is dat zoekmachines er helemaal niks meer van snappen... Maar ik had wel ergens in berichten gelezen op t.net dat Google er wel mee bezig was om ondersteuning daarvoor in te bouwen...

Het ligt er maar helemaal aan hoe je je javascript implementeerd. Als het als 'extra functionaliteit biedend' script online staat is er niets aan de hand, als je site er van afhankelijk is heb je een probleem.

[Michali]

@Bluetje: Ik heb inmiddels wel redelijk wat ervaring met bouwen van sites. Ik heb een tijd met tabellen gewerkt, en het overstappen naar de andere manier van werken was af en toe moeizaam. Achteraf zie ik in dat tabellen helemaal niet geschikt zijn om je layout in te maken. Het snelste is om je content zo gestructureerd mogelijk neer te zetten en daarna puur met CSS je layout te fixen. Het is dan wel af en toe vereist om een extra container element hier en daar te plaatsen, maar veel is het niet nodig.

Ik kan je wel aan raden je er toch eens wat meer in te verdiepen, want het scheelt je echt veel tijd. Vooral als je uitbreidingen binnen het ontwerp krijgt. Met tabellen ben je dan vaak genoodzaakt om een heel stuk te hercoden, terwijl je met goede structuren hoef je vaak alleen iets toe te voegen aan je HTML, en dan je CSS aan te passen. Vooral die dingen ga je ook goed merken. Ik ben iig erg blij dat ik niet meer met tabellen werk, wat het is echt enorm omslachtig, terwijl het een stuk simpeler (en logischer) kan.

[BtM909]

Eerlijk gezegd snap ik het nut niet van dit topic. RM-rf riep het al

versimplificeer het ontwerpproces van een communicatie- of toepassingsmedium niet tot een dom en eenvoudig lijstje.

Belangrijkste mijn inziens is je doelgroep en het doel van je website. Ik heb genoeg websites gezien die wellicht niet visueel aantrekkelijk zijn (understatement), maar wel degelijk succesvol.

Ik zie hier dan bij een aantal, voornamelijk topicstarter, allerlei do's and don'ts die in 1998 al bekend waren en het valt me op dat de meeste mensen voornamelijk vanuit een technisch oogpunt naar een siteontwerp kijken.

[ Voor 23% gewijzigd door BtM909 op 04-07-2006 14:19 ]

[Verwijderd]

Voor mij is het Do's/Don't sterk afhankelijk van de vraag van mijn klant.
Is het een privé site dan wil ik er gerust een gastenboekje onder plaatsen, een webwinkel gaat me daarvoor weer te ver. Is het een zakelijke site dan onderzoek ik eerst het bedrijf, de bedrijfscultuur, de opmaak van hun documenten en zeker niet onbelangrijk hoe het bedrijf er financiëel bij staat. Natuurlijk moet het doel van de site altijd vooraf bekend zijn en wil ik graag weten of "wij" het onderhoud blijven uitvoeren of dat mijn klant dit in eigen beheer gaat doen.

Hoe dan ook: Do's en Don'ts zijn steeds verschillend, afhankelijk van de wensen van de klant.
Een van mijn klanten wenste bijvoorbeeld een site die grafisch met veelal velle kleuren (rood/oranje/geel) op een zware ondergrond voorkwamen. Het betrof hier welliswaar een "kinky" site maar tevens volgens het lijstje van mahsteggot een ZAKELIJKE site.

[Rhapsody]

chem schreef op dinsdag 04 juli 2006 @ 13:46:
[...]

Jaaa lekker kortzichtig weer.

Wel eens gehoord van bv het opzoeken van informatie via lynx? Of mensen met een visuele handicap?

Of behoren gehandicapte mensen wat jou betreft maar tot een vervelende groep mensen die niet in je 90 percentiel valt?

En vind je de toekomst mbt semantisch web ook maar vervelend?

Ipv mijn reactie als kortzichtig te beoordelen, lees de eerste zin van mijn bericht nog eens.

[Verwijderd]

Rhapsody schreef op dinsdag 04 juli 2006 @ 16:01:

Ipv mijn reactie als kortzichtig te beoordelen, lees de eerste zin van mijn bericht nog eens.

Nog een keer gelezen, mening ongewijzigd. Wat is "werken"? Een Flash-site waar je prima doorheen kunt klikken werkt niet altijd zo goed als het lijkt. Het kan een ramp zijn om met een zoekmachine de site te vinden. Het kan behoorlijk vervelend zijn als mensen niet fatsoenlijk kunnen bookmarken. En zo kunnen er behoorlijk wat dingen mankeren aan een website die er op zich in elke grafische browser goed uitziet. Een punt als "je site moet goed werken" is volgens mij een beetje te vaag.

[hamsteg]

BtM909 schreef op dinsdag 04 juli 2006 @ 14:17:Ik zie hier dan bij een aantal, voornamelijk topicstarter, allerlei do's and don'ts die in 1998 al bekend waren en het valt me op dat de meeste mensen voornamelijk vanuit een technisch oogpunt naar een siteontwerp kijken.

Die lijstjes waren ook wel eerder bekend in de applicatie wereld van voor 1998 ;-) Zie ook mijn posting van 03 juli 2006 20:53; Ik had gehoopt op nieuwe inzichten maar ... . zo te zien zijn die er niet. De technische start was bewust om een open ingang te geven maar is een verkeerde keuze gebleken. We zitten ze debatteren over punten en komma's, vlaggetjes ... dingen die voor 90% door tooling gecontroleerd kan worden.

Geen aha erlebnis, geen kleintje x-factor. Helaas wel weer een beetje bekvechten dus van mij mag het topic dicht.

[moozzuzz]

BtM909 schreef op dinsdag 04 juli 2006 @ 14:17:
Eerlijk gezegd snap ik het nut niet van dit topic.

De TS is op zoek naar de [niet-technische] basis van een goede site. Het waarom is een site goed? Dat de gegeven antwoorden vnl technisch van aard (en dus offtopic) zijn, is een ander verhaal. Persoonlijk vind ik het zeker een leuk onderwerp.

(persoonlijk idee in het kort)

• frames = don't
• "frontpage [express]-look" = don't,
• java-applet-menu/toepassing = don't

• DO : kleuren: algemeen: licht/pastel, volgens logo-kleurenpallet of alvast daarbij passend. Wat ook veel verteld werd (2jaar geleden) was dat de combi blauw-wit een zakelijke look heeft.
• DO: maximale breedte = 750pix, dit is vnl aangenaam op een 1024scherm. HighRes-schermen zijn nog relatief zeldzaam, ook in de industrie!
• DO : contactpag: snailmail/tel/fax + emailform + [kaartje+wegbeschrijving]. Niets is irritanter dan op een website de contact-gegevens niet volledig terug te vinden. Een kaartje met locatie kan evt. ook apart en ligt uiteraard meer afhankelijk van bizznizz.
• DO : taal: standaard native language + keuze engels. Uiteraard ook afh. van doelpubliek.
• DO : wees zeer kort, het www is een bron van kernwoorden. Bij lange pagina's (te vermijden) steeds een korte inhoud (max 2 kleine paragrafen). Onderaan evt. link naar datasheet of meer specs. Toon dat uw kosten-efficient bedrijf ook in staat is om efficient haar producten/bedrijf te presenteren.
• DO : uniformiteit doorheen uw website. 1 lettertype, 1 <input>/<textarea>/...-style
• DO : eenvoud siert (geen exotische lettertypes, ...). Wijk wel af van de IE/FF standaard-opmaak (vb: Times lettertype, blauw/paars/rode links, ...)
• DO : Correcte inhoud (spelling, productinformatie)

Dat is het eerste waar ik aan denk (en probeer toe te passen).

[Garyu]

Do's: "gewone gebruikers" vragen om even je site te checken en je feedback te geven. Die feedback is namelijk tien keer zo belangrijk als de feedback van de gemiddelde tweaker. Die vinden je producten toch wel, dus daar hoef je je minder zorgen om te maken . De gemiddelde huisvrouw interesseert het geen *** of je vriendelijke URLs gebruikt, maar wel of ze kan vinden wat ze zoekt. Daar hebben ze mooie tests voor uitgevonden, maar de meest eenvoudige is wel om je eigen moeder te vragen om informatie XY te vinden op je homepage. ZONDER jouw hulp! Het enige wat jij doet is toekijken wat er allemaal mis gaat .

Succes met je home-made gratis usability test. Als ik het moet komen doen moet je er flink voor lappen .

[RM-rf]

moozzuzz schreef op dinsdag 04 juli 2006 @ 18:05:
[...]

De TS is op zoek naar de [niet-technische] basis van een goede site. Het waarom is een site goed? Dat de gegeven antwoorden vnl technisch van aard (en dus offtopic) zijn, is een ander verhaal. Persoonlijk vind ik het zeker een leuk onderwerp.

(persoonlijk idee in het kort)

• frames = don't
• "frontpage [express]-look" = don't,
• java-applet-menu/toepassing = don't

• DO : kleuren: algemeen: licht/pastel, volgens logo-kleurenpallet of alvast daarbij passend. Wat ook veel verteld werd (2jaar geleden) was dat de combi blauw-wit een zakelijke look heeft.
• DO: maximale breedte = 750pix, dit is vnl aangenaam op een 1024scherm. HighRes-schermen zijn nog relatief zeldzaam, ook in de industrie!
• DO : contactpag: snailmail/tel/fax + emailform + [kaartje+wegbeschrijving]. Niets is irritanter dan op een website de contact-gegevens niet volledig terug te vinden. Een kaartje met locatie kan evt. ook apart en ligt uiteraard meer afhankelijk van bizznizz.
• DO : taal: standaard native language + keuze engels. Uiteraard ook afh. van doelpubliek.
• DO : wees zeer kort, het www is een bron van kernwoorden. Bij lange pagina's (te vermijden) steeds een korte inhoud (max 2 kleine paragrafen). Onderaan evt. link naar datasheet of meer specs. Toon dat uw kosten-efficient bedrijf ook in staat is om efficient haar producten/bedrijf te presenteren.
• DO : uniformiteit doorheen uw website. 1 lettertype, 1 <input>/<textarea>/...-style
• DO : eenvoud siert (geen exotische lettertypes, ...). Wijk wel af van de IE/FF standaard-opmaak (vb: Times lettertype, blauw/paars/rode links, ...)
• DO : Correcte inhoud (spelling, productinformatie)

Dat is het eerste waar ik aan denk (en probeer toe te passen).

Om eerlijk te zijn ... als ikd at lijstje zie, zie ik voornamelijk dingen die een goed ontwerper voor jullie vaststeld...

Bv over de vraag of men frames wilt gebruiken, dat kan ofwel een structurele reden hebben (de data heeft een bepaalde opzet, bv zeer diepe menu's of de verdeling in meerder 'werkschermen'; het laden van content 'on the fly binnen een pagina, dmv een Iframe)
Daar heeftd e ontwikelaar de beslissing over te nemen ... wil de klant die beslissing nemen, moet hij eerst de consequenties van die keuzes goed weten in te schatten en hoe 'goed' de consultant en account-managers ook zijn in het communiceren van zulke technische zaken ( ) ook hen lukt het niet de klant in korte tijd genoeg kennis te geven om het oordeel van een technicus die hierin reeele ervaring heeft te kunnen 'overrullen'..

Ook klanten die gaan 'bepalen' welke kleurkeuze er gekozen moet worden, geven me de kriebels...
sjees, als je een designer inhuurt dien je dat vanuit een vertrouwen te doen... Natuurlijk kun je dan een bestaande huisstijl voorleggen, maar geef de ontwerper in godsnaam het krediet dat deze dat kan uitzoeken...
Of desnoods huur daarvoor een extra externe ontwerper in (als de ontwikkelaar eerder een informaticus is, met weinig design-feeling)...

Datzelfde geld ook voor lettertypes, gadverdamme: van die klanten die aankomen met "ik wil een website in verdana want dat vind ik een mooi lettertype"..

wat teksten betreft ... ja dat klopt, qua tekststructuur... maar ook daarin lijk je erop toe te sturen dat iemand dus die teksten zelf gaat schrijven in het bedrijf ... dat is al vaak een bekende fout... dat dat een simpele secretesse wordt toevertrouwd (ondanks dat enkele daarin dan weer heel erg goed zijn, maar dat is vaak bij de kleinere bedrijfjes beter geregeld... het valt me wel op dat hoe kleiner een bedrijfje, des te beter gekwalificeerd de secretaresse is, en des te sterker in de communicatie)..
je zou zulke mensen soms willen toeschreeuwen toch gewoon een professionele tekstschrijver/ster in te huren, die dat voor hen regelt

bewering als zouden bepaalde kleurcombinaties beter zijn of minder zijn zeer twijfelachtig... veel verder dan dat roze-zwart-geel met groene letters niet zo goed is voor een zakelijke site kom je echt niet... Een goed design heeft gewoon veel meer detail-inzicht nodig.

Wile en ondernemer gewoonweg geen externen inschakelen en de 'doe-het-zelf-methide aanhangen ...d an moet ik juist zeggen dat frontpage en vooral met standaard Frontpage templates werken waarschijnlijk de simpelste en eenvoudgste en vooral tijdsbesparende oplossing is..
die mogelijk een net aanvaardbaar resultaat oplevert...

[ Voor 5% gewijzigd door RM-rf op 04-07-2006 18:28 ]

[hamsteg]

Garyu schreef op dinsdag 04 juli 2006 @ 18:15:
Succes met je home-made gratis usability test. Als ik het moet komen doen moet je er flink voor lappen .

Oh, dan kan ik de aap dus de deur uit doen? Hij vreet me de oren van het hoofd

Alle gekheid in de boom, dat is zeker een goede test maar waarom wil die aap juist met mijn website spelen? Hoe krijg ik hem gevangen als 'ie voorbij googled? Als de aap mijn doelgroep is zal ik dus bananen moeten gebruiken op de website, zijn taal moeten spreken (en ik bedoel niet de technische taal die spreek ik vloeiend maar zijn woordkeuzes). Apen lezen niet veel dus een paar regels per pagina zijn voldoende, niet te veel uitstapjes want ze hebben maar een beperkt geheugen. Kleurstelling geel van de banaan of juist groen van het oerwoud? Een behoorlijk stukje inleving, een paar dagen emmen zoo etc.

Dat zijn de vragen ... feitelijk is een website niet meer als een richting communicatie ... interactief maar een kant op. Toch mijn communicatieboeken weer eens van stal halen? Alleen die doen niets met het visuale presentatie aspect van een website. Misschien zijn onze huidige website wel helemaal fout ... oeps ik had bijna een revolutionair idee maar het is weg

[ Voor 69% gewijzigd door hamsteg op 04-07-2006 19:42 ]

[Joep]

Do's:
Ervoor zorgen dat de breedte van de website zich aanpast aan de resolutie van het beeldscherm van de bezoeker. Als er bijvoorbeeld een bezoeker is die een resolutie gebruikt van 800*600 is het handig als de breedte van de website 780 pixels is, zodat er onderaan de pagina geen irritant scroll-geval voor in de breedte ontstaat. En als een bezoeker een resolutie heeft van 1920*1280 o.i.d. is het ook (vaak bij zeer-veel-tekst-bevattende websites) fijn dat de breedte niet blijft steken op 1280 pixels, waardoor maar de helft van je beeldscherm gevuld is met tekst. Er zijn echter mensen die een resolutie van 1920*1280 gebruiken, maar hun browser niet maximaliseren en liever 800*600 gebruiken, zodat er ook nog plaats is op hun beeldscherm voor andere schermen.

Don't's:
Plaats aub op websites met bijvoorbeeld leesverslagen, gratis romans of andere grote tekstbestanden geen animated banners, pop-up's. Als het maar niet beweegt. Hierdoor wordt je erg afgeleid bij het lezen van de tekst.

[getfirefoxnow]

Regels in het algemeen en voor SEO in het bijzonder:
- Zorg voor veel passende content op jouw website
- Gebruik zo min mogelijk frames
- Zorg dat bij metatag description alle relevante info vermeld staat
- Gebruik alt tekst bij images
- altijd standaard html tags gebruiken zoals H1, H2, strong, e.d. / webstandards toepassen voor xhtml/css volgens w3c
- Passende domeinnaam gebruiken
- Gewenste keywords in de title zetten
- Gebruik zo min mogelijk javascript
- Update de content regelmatig

[OkkE]

Joep Stoffels schreef op woensdag 05 juli 2006 @ 12:17:
Do's:
Ervoor zorgen dat de breedte van de website zich aanpast aan de resolutie van het beeldscherm van de bezoeker. [...]

Niet helemaal mee eens. Ik zou het omschrijven als; zorg voor een goede vlakverdeling. Persoonlijk heb ik een hekel aan websites waarbij de tekst-vlakken oneindig meeschalen met de grootte van de browser. Vooral de max-width van tekst-vlakken moet IMO niet te groot zijn.

Ik heb er geen probleem mee dat er veel wit (of welke kleur dan ook) naast de 'website' komt als ik 1600x1200 draai. Wat ik wél erg leuk vind, is als er extratjes in die 'overgebleve ruimte' staan.

[Tyrian]

DO: Zorg dat de site ook goed navigeerbaar is voor mensen die JavaScript uit hebben gezet (I.v.m. security)

[Michali]

Tyrian schreef op woensdag 05 juli 2006 @ 12:41:
DO: Zorg dat de site ook goed navigeerbaar is voor mensen die JavaScript uit hebben gezet (I.v.m. security)

Eerst gewoon een puur HTML menu neerzetten, en daarna mbv. JS zelf er een JS driven menu van maken. Zo weet je zeker dat iedereen er goed toegang tot heeft.

[Verwijderd]

Do: Plezier hebben en lekker je gang gaan tijdens het knutselen
Don't: Aankomen met die eeuwige geitenwollen lijstjes

[Verwijderd]

Joep Stoffels schreef op woensdag 05 juli 2006 @ 12:17:
Do's:
Ervoor zorgen dat de breedte van de website zich aanpast aan de resolutie van het beeldscherm van de bezoeker. Als er bijvoorbeeld een bezoeker is die een resolutie gebruikt van 800*600 is het handig als de breedte van de website 780 pixels is, zodat er onderaan de pagina geen irritant scroll-geval voor in de breedte ontstaat. En als een bezoeker een resolutie heeft van 1920*1280 o.i.d. is het ook (vaak bij zeer-veel-tekst-bevattende websites) fijn dat de breedte niet blijft steken op 1280 pixels, waardoor maar de helft van je beeldscherm gevuld is met tekst. Er zijn echter mensen die een resolutie van 1920*1280 gebruiken, maar hun browser niet maximaliseren en liever 800*600 gebruiken, zodat er ook nog plaats is op hun beeldscherm voor andere schermen.

En daarmee is het dus een DON'T geworden. Regels met tekst van een halve meter lang lezen niet zo lekker. Pas ook nooit de website aan aan de grootte van het beeldscherm, hooguit aan de grootte van het venster.
Wat mij betreft hoef je helemaal niet zoveel rekening te houden met mensen die op een hoge resolutie fullscreen browsen. Die bekijken dan maar een hoop leegte.

[RSD1982]

ter aanvulling een don't

arial, of times new roman gebruiken op je website laat staan comic sans

[RobIII]

Hoewel we het waarschijnlijk allemaal eens zijn met comic sans zie ik niet in waarom je geen arial of times zou kunnen of mogen gebruiken. En het is niet zo dat er dan nog heel veel over blijft... Zolang het in het design past zie ik niet in wat er mis mee zou zijn.

[Blaise]

Comic Sans kan ook prima op bepaalde websites, hangt ervan af hoe het is toegepast.

[XWB]

Handig voor wat zoekmachine's betreft met een site die bv drie kolommen heeft: "allow the center column to appear first in the source"

http://alistapart.com/articles/holygrail

[OkkE]

Hacku schreef op donderdag 06 juli 2006 @ 00:14:
Handig voor wat zoekmachine's betreft met een site die bv drie kolommen heeft: "allow the center column to appear first in the source"

http://alistapart.com/articles/holygrail

En dan gelijk nog een handig linkje; http://blog.html.it/layoutgala/

[Zoefff]

RSD1982 schreef op woensdag 05 juli 2006 @ 20:11:
ter aanvulling een don't

arial, of times new roman gebruiken op je website laat staan comic sans

En kijk voor de grap eens welk lettertype hier wordt gebruikt?

Het hangt helemaal van de website af. Ik vind het gebruik van Arial 13px persoonlijk erg prettig, neutraal lettertype wat prettig leest, ook bij grote lappen tekst. Voor vrij formele websites gebruik ik het zelf dan ook graag

[RM-rf]

RSD1982 schreef op woensdag 05 juli 2006 @ 20:11:
ter aanvulling een don't

arial, of times new roman gebruiken op je website laat staan comic sans

• De kleur groen gebruiken op een website is natuurlijk ook compleet fout, je kunt geen goede website bouwen als je de kleur groen gebruikt, die kleur is een absolute 'don't' ...

• Verder, een goede website heeft een juist percentage 'e's' op een pagina... van alle letters op de pagina moet ongeveer 9 tot 14% een 'e' zijn, is dat niet zo, is je website fout en moet je aanpassen.
Bij Websites voor een japans of chinees publiek vergt dat nog wel eens de toepassing van 'hacks' maar dat moet dan maar ...

• En afbeeldingen die je hebt bewerkt in een andere editor, moet je altijd eventjes openen in Photoshop/Imageready en dan opnieuw bewaren... gewoon omdat dat de beste tools zijn en dus alle afbeeldingen daarmee gesaved moeten worden.

[Verwijderd]

RM-rf schreef op donderdag 06 juli 2006 @ 12:54:
[...]

• De kleur groen gebruiken op een website is natuurlijk ook compleet fout, je kunt geen goede website bouwen als je de kleur groen gebruikt, die kleur is een absolute 'don't' ...

• Verder, een goede website heeft een juist percentage 'e's' op een pagina... van alle letters op de pagina moet ongeveer 9 tot 14% een 'e' zijn, is dat niet zo, is je website fout en moet je aanpassen.
Bij Websites voor een japans of chinees publiek vergt dat nog wel eens de toepassing van 'hacks' maar dat moet dan maar ...

• En afbeeldingen die je hebt bewerkt in een andere editor, moet je altijd eventjes openen in Photoshop/Imageready en dan opnieuw bewaren... gewoon omdat dat de beste tools zijn en dus alle afbeeldingen daarmee gesaved moeten worden.

Vergeet niet het allerbelangrijkste:
• Haal alle overbodige spaties en newlines weg uit je html. Dit zijn nl. echte bandbreedte killers, dus je bespaart heul veul als je die weghaalt.

[ Voor 4% gewijzigd door Verwijderd op 06-07-2006 13:01 ]

[hamsteg]

:1,$/./s//

[ Voor 24% gewijzigd door hamsteg op 06-07-2006 13:30 ]

[André]

Verwijderd schreef op donderdag 06 juli 2006 @ 13:00:
[...]

Vergeet niet het allerbelangrijkste:
• Haal alle overbodige spaties en newlines weg uit je html. Dit zijn nl. echte bandbreedte killers, dus je bespaart heul veul als je die weghaalt.

Gewoon http compressie ala gzip gebruiken

[RobIII]

André schreef op donderdag 06 juli 2006 @ 13:53:
[...]

Gewoon http compressie ala gzip gebruiken

Nog beter: Serveer gewoon helemaal geen content, kost het je ook geen bandbreedte. En als je je domein ook nog opzegt hoef je daar ook niet meer voor te betalen

Goed, genoeg geflauwekuld lijkt me zo

[moozzuzz]

RM-rf schreef op dinsdag 04 juli 2006 @ 18:26:
Om eerlijk te zijn ... als ikd at lijstje zie, zie ik voornamelijk dingen die een goed ontwerper voor jullie vaststeld...

De vraag is toch niet gelimiteerd tot ideeën voor niet-ontwerpers?

[getfirefoxnow]

RM-rf schreef op donderdag 06 juli 2006 @ 12:54:
[...]

• De kleur groen gebruiken op een website is natuurlijk ook compleet fout, je kunt geen goede website bouwen als je de kleur groen gebruikt, die kleur is een absolute 'don't' ...

Overmatig gebruik van PTT groen is erg lelijk inderdaad. Je ziet bij een bedrijf als KPN met groen als hoofdkleur in de huisstijl dat ze er beperkt mee omgaan op hun site.

Maar groen kan mits subtiel gebruikt erg mooi zijn zoals op deze site te zien is. En soms ontkom je er als designer ook niet aan groen te gebruiken als de klant perse wil dat je de huisstijl toepast zoals bij KPN.

[Guru Evi]

RobIII schreef op donderdag 06 juli 2006 @ 13:56:
[...]

Nog beter: Serveer gewoon helemaal geen content, kost het je ook geen bandbreedte. En als je je domein ook nog opzegt hoef je daar ook niet meer voor te betalen

Goed, genoeg geflauwekuld lijkt me zo

Je moet wel soms eens denken aan wij 56k-ers die niets beter kunnen krijgen Als je dan zo'n pagina krijgt met allemaal flash-banner menu's dan zit je wel even te wachten. En elke bit telt. 8kb meer aan spaties en returns duurt 2s langer om binnen te halen. Ook compressie van je beeldjes is wel lief.

[Verwijderd]

RM-rf schreef op donderdag 06 juli 2006 @ 12:54:
[...]

• De kleur groen gebruiken op een website is natuurlijk ook compleet fout, je kunt geen goede website bouwen als je de kleur groen gebruikt, die kleur is een absolute 'don't' ...

• Verder, een goede website heeft een juist percentage 'e's' op een pagina... van alle letters op de pagina moet ongeveer 9 tot 14% een 'e' zijn, is dat niet zo, is je website fout en moet je aanpassen.
Bij Websites voor een japans of chinees publiek vergt dat nog wel eens de toepassing van 'hacks' maar dat moet dan maar ...

• En afbeeldingen die je hebt bewerkt in een andere editor, moet je altijd eventjes openen in Photoshop/Imageready en dan opnieuw bewaren... gewoon omdat dat de beste tools zijn en dus alle afbeeldingen daarmee gesaved moeten worden.

• Vergeet ook niet dat je linksonder altijd een onzichtbare pixel moet plaatsen, omdat anders je ontwerp helemaal in elkaar donderd als je ergens op klikt.

[BalusC]

Hacku schreef op donderdag 06 juli 2006 @ 00:14:
Handig voor wat zoekmachine's betreft met een site die bv drie kolommen heeft: "allow the center column to appear first in the source"

http://alistapart.com/articles/holygrail

Maakt dit echt zoveel uit voor de zoekmachines?

[Boelie-Boelie]

BalusC schreef op donderdag 06 juli 2006 @ 20:54:
Maakt dit echt zoveel uit voor de zoekmachines?

Het maakt denk ik vooral uit voor mensen zonder visuele browsers, die anders eerst een hele lap navigatie-items door moeten voordat ze bij de content komen.

[XWB]

BalusC schreef op donderdag 06 juli 2006 @ 20:54:
[...]

Maakt dit echt zoveel uit voor de zoekmachines?

Wat ik vernomen heb is dat zoekmachines een pagina vaak maar tot een bepaald aantal bytes "lezen", daardoor is het beter om de content eerst te hebben en de mindere belangrijke zaken zoals menu's en navigatie pas daarna in de code te hebben.

De voorbeelden van http://blog.html.it/layoutgala/ hebben de content ook eerst staan.

[ Voor 12% gewijzigd door XWB op 06-07-2006 22:17 ]

[André]

BalusC schreef op donderdag 06 juli 2006 @ 20:54:
[...]

Maakt dit echt zoveel uit voor de zoekmachines?

Nee. Zoekmachines kunnen heel goed 'bekijken' wat content is en wat een menu. Of de content nu onderaan of bovenaan staat is irrelevant. Zoekmachine algoritme's zijn hier meer dan goed in, mits je de semantiek goed voor elkaar hebt. Bij zogenaamde tag-soep sites is het wel handig je content bovenaan te hebben zodat Google bij gebrek aan semantiek daar iets meer waarde aan geeft.

[Verwijderd]

Gebruik ook altijd de revisit-after metatag ... dan kom je zeker wel heel hoog in Google terug

[BalusC]

André schreef op donderdag 06 juli 2006 @ 22:31:
[...]

Nee. Zoekmachines kunnen heel goed 'bekijken' wat content is en wat een menu. Of de content nu onderaan of bovenaan staat is irrelevant. Zoekmachine algoritme's zijn hier meer dan goed in, mits je de semantiek goed voor elkaar hebt. Bij zogenaamde tag-soep sites is het wel handig je content bovenaan te hebben zodat Google bij gebrek aan semantiek daar iets meer waarde aan geeft.

Ah gelukkig, ik keek al hoogst vreemd op

[André]

Verwijderd schreef op donderdag 06 juli 2006 @ 22:39:
Gebruik ook altijd de revisit-after metatag ... dan kom je zeker wel heel hoog in Google terug

Heerlijk is die

Maar toch, omdat ik hem zo vaak tegenkwam bij klanten heb ik er maar een stukje over geschreven zodat ze vaak binnen enkele dagen de tag verwijderd hadden.

[eghie]

Ik zie hier vaak tips voorbij komen, met dat de site op maximum breedte op 750px moet worden ontwikkeld, of op die resolutie.

Ik probeer alles gewoon relatief te houden. Breedtes en hoogtes in percentages. Tekst in relatieve grote. Als je op die manier de site voor elkaar kunt krijgen dan werkt hij op vele resoluties wel goed. Dat werkt toch veel fijner?

[Zeror]

Do's:
- Schoon programmeren zodat de broncode netjes is
- Simpel kleuren profiel. Niet teveel verschillende kleuren mits de doelgroep daar niet voor bedoeld is.

Don't:
- teveel nutteloze java/flash/javascript etc.. op je site. (bijv. mooie klok met wijzers of achtergrondkleur faders oid.)
- Website programmeren met Frontpage, dreamweaver oid. Je krijgt teveel loze code dan.

[XWB]

dreamweaver

Tenzij je dreamweaver in code view gebruikt

[Zeror]

Als je dan toch alleen maar code view gebruikt kan net zo goed overstappen naar een gratis variant like Crimson Editor.

[Pascal Saul]

Wat een apart topic is dit.

Toch ben ik van mening de de perfecte website niet bestaat net zoals de perfect vrouw (90-60-90 toch?).

Hoe je het ook went of keert het is puur persoonlijk, smaken verschillen nu eenmaal.

Er komen best wat dingen tevoorschijn in dit topic die handig zijn maar misschien toch weer overbodig.

In principe is een sitemap ook overbodig. De structuur behoort zo goed te zijn dat deze niet nodig zou moeten zijn. Toch denken anderen weer van wel en dat is met alles in dit topic genoemd.

Zolang jij (en eventuele klant) maar tevreden bent met het resultaat

[ILUsion]

Garyu schreef op dinsdag 04 juli 2006 @ 18:15:
Do's: "gewone gebruikers" vragen om even je site te checken en je feedback te geven. Die feedback is namelijk tien keer zo belangrijk als de feedback van de gemiddelde tweaker. Die vinden je producten toch wel, dus daar hoef je je minder zorgen om te maken . De gemiddelde huisvrouw interesseert het geen *** of je vriendelijke URLs gebruikt, maar wel of ze kan vinden wat ze zoekt. Daar hebben ze mooie tests voor uitgevonden, maar de meest eenvoudige is wel om je eigen moeder te vragen om informatie XY te vinden op je homepage. ZONDER jouw hulp! Het enige wat jij doet is toekijken wat er allemaal mis gaat .

Succes met je home-made gratis usability test. Als ik het moet komen doen moet je er flink voor lappen .

Vriendelijke URL's lijkt me juist wel een van de dingen die vrij belangrijk zijn, omdat je niet mag vergeten zoiets in een magazine bijvoorbeeld beter staat. Microsoft zet ook niet "surf naar www.microsoft.com/~12ajan...p?id=11529a2245&lng=1034" maar eerder iets als "surf naar security.microsoft.nl" in hun advertenties. Een duidelijke URL is zeer belangrijk bij het doorgeven van links, daarbij mogen get-parameters, met mate en als die enige verbale betekenis hebben (index.php?page=contact bijvoorbeeld, al is het nog mooier om contact.php dan te gebruiken). Dat is voor pagina's die direct toegankelijk moeten zijn, dat in een websurvey de pagina's geen mooie naam hebben, lijkt me geen probleem.

Verder wel een heel simpele maar bruikbare tip, al zijn sommige sites zo ingewikkeld dat ze zelfs voor tweakers niet altijd even duidelijk zijn waar je bepaalde informatie moet zoeken ( www.vub.ac.be is op het eerste zicht een vrij propere en toegankelijke site, maar de eerder back-end sites (inlogpagina's voor studenten, professoren,...) zijn heel rommelig, ouderwetse opmaak, inconsistent). Daar vind ik, Tweaker zijnde, mijn weg helemaal niet in terug hoor.

Tja, zowat de standaard dingetjes, voor mij is je hele site in Flash maken één grote don't. Voor een promotiesite of een muzieksite wil ik het nog wel aanvaarden, maar een zakelijke site nooit of te nimmer volledig in Flash. Ook rustige kleuren kiezen, steeds (dezelfde) CSS gebruiken voor je opmaak, inderdaad van de standaardopmaak wegblijven zonder het al te bont te maken. Geen simpele kleurvlakken gebruiken, dat komt wat ouderwets over, maar heel lichte accentjes leggen in grote vlakken (kijk bijvoorbeeld naar hoe Slashdot gevorderd is de laatste weken, dan zie je het wel). Geen al te fancy menu's maken, gewoon zo minimalistisch mogelijk blijven (omdat dat in de meeste browsers werkt). Ahja, op je pagina's ajax gebruiken waar dat handig is, al dat wachten doet tegenwoordig zo ouderwets aan.

Een .nl enkel in het Engels vind ik ook niet het toppunt van een professioneel bedrijf, je moet je publiek kunnen inschatten, maar als je een .nl neemt, wilt dat vaak ook zeggen dat Nederland je doelpubliek is (anders had je beter een .com/.net/.org genomen). En keuze met vlaggetjes heb ik niets op tegen (als Belg zijnde, waar de vlag voor twee(of zelfs drie) talen zou kunnen staan én de vlag die niet gebruikt wordt om het Nederlands aan te duiden). Wat je voor de duidelijkheid met die vlaggetjes kan doen, is bijvoorbeeld voor het Engels een rechthoekige knop en de ene helft (tot aan de diagonaal van de rechthoek) daarvan de Amerikaanse en de andere helft de Britse vlag. Voor Het Nederlands hetzelfde: de Nederlandse en Belgische vlag delen. Maar dat is enkel nodig als je een site hebt die internationaal groot is. En gewoon de talen in een kleine combobox of iets dergelijks is al even proper, uiteindelijk