Update 31-3-2008: Naast esthetische slordigheden zat er ook een wat groter probleem in de (na 5 revisies) opgeleverde HTML. In de artikeltemplate zat elke paragraaf in zijn eigen div, waardoor het implenteren van een CMS (WordPress in dit geval) niet echt lekker gedaan kon worden. Een kwestie van niet meedenken door de ontwikkelaars, maar wel snel en zonder morren opgelost. Dus ziehier de nieuwe artikel template.
Jaja, het redesign begint nu echt op gang te komen. Met hulp van wat offshoring geweld omdat Joost het te druk heeft, hij doet nog wel gewoon de WordPress implementatie, geen zorgen! 🙂 De XHTML is inmdidels gemaakt door PSD2HTML.com, een partij die gespecialiseerd is in het omzetten van website ontwerp in valide HTML. In ons geval werd dat natuurlijk XHTML 1.0 strict, om zo toegankelijk mogelijk te zijn.
Voor deze drie templates heb ik $635 betaald. Dat is voor een offshoring partij best duur, maar de kwaliteit vind ik erg goed. Bovendien had ik best een stevig eisenpakket. Om te beginnen strict HTML markup die compleet schaalbaar is (in em’s uitgedrukt). Dat betekent dat als je de tekstgrootte aanpast in je browser, de hele website “groter” wordt, inclusief alle plaatjes die onderdeel zijn van het design.
Verder moest de site tussen 800 en 1280 pixels breedte “liquid” zijn. Dat betekent dat hij op een monitor met 800px breedte (1,74% van Usarchy bezoekers) nog geheel binnen het beeld valt. Maar dat ie op een monitor met 1680px of 1920px breedte (10%) vast blijft staan op 1280px, zodat de tekstregels niet te lang worden om nog lekker leesbaar te zijn. Ik geef toe: dit is overdreven te noemen, ik had het ook gewoon vast kunnen laten zetten op 1024px. Maar omdat dit een usability weblog is, vind ik het leuk om het als case te laten zien. Dat het design daardoor iets minder mooi uitkomt neem ik voor lief.
Hier kun je de templates bekijken (openen in nieuw venster): homepage, artikelpagina, kennisbank homepage. Uiteraard is feedback nog steeds welkom, al beloof ik niet dat er nog veel aangepast gaat worden. Op een gegeven moment moet je toch verder, he 🙂
Hieronder zie je trouwens de resoluties van Usarchy bezoekers in 2008:
Het Usarchy Redesign volgens het boekje bestond in het begin uit de volgende stappen. Ik heb ze even gelinked naar de artikelen met updates die ik erover heb geschreven, zodat je het proces een beetje kunt volgen.
- Wie gaan het doen? Vormgever en Developer gezocht!
- Waarom komt er een redesign, wat is het doel?
- Wat is de doelgroep, wie zijn de persona’s?
- Enquêete: Wat wil die doelgroep eigenlijk?
- Uitslag enquête en samenvatting in functionele specificaties nieuw design
- Interactie ontwerp: wireframes van de templates
- Feedback gebruikers op interactie ontwerp
- Definitief interactie ontwerp
- Vormgeving templates
- Feedback gebruikers op vormgeving
- Definitieve vormgeving
- Ontwikkeling HTML & implementatie WordPress
- Acceptatietest met gebruikers en opdrachtgever
- Lancering nieuwe Usarchy!
Op naar de volgende stap dus, iedereen even juichen voor Joost!
“al beloof ik niet dat er nog veel aangepast gaat worden” – laat maar dan 😉
LikeLike
Haha, je kunt het toch proberen! Ik beloof alleen niks 😉 Ik heb nog geen akkoord gegeven aan psd2html du als er nog iets slecht is dan kan dat wel.
LikeLike
Ik verbaas me altijd over de snelheid en netheid van coderen van PSD2HTML. Helemaal af. Lang leve de koers van de Amerikaanse roepie trouwens. Dat werkt nu even in het voordeel.
Trouwens, de site templates zijn vaak sneller en netter dan de specifieke e-mail templates.
groet,
Wouter
LikeLike
* Veel div’jes
* Veel ‘s
* Veel loze img’s voor icoontjes; waarom niet gewoon background images?
* Waarom [img src=”images/lang-box.gif” alt=”” class=”bg” /] – weten dat iets een b(ack)g(round) is, maar toch niet CSS daarvoor gebruiken?
* Waarom geen dl’etjes gebruiken voor Kennisbank updates en Vacatures en stages?
* Waarom [div class=”heading”][strong]Vacatures en stages[/strong][/div] en niet een hx?
* Waarom iso-8859-1 en niet utf-8 meteen in de templates?
* Waarom IE hacks ook in all.css?
* Waarom opent http://www.usarchy.com/etc/redesign-xhtml/index.html#klassiekers niet meteen de juiste tab?
* Waarom _alle_ div’jes doorlopen in http://www.usarchy.com/etc/redesign-xhtml/js/tabs.js?
* …
LikeLike
Of anders gezegd inderdaad: helemaal af. En dat voor maar ‚Ǩ 400,- 🙂
LikeLike
Nu nog een iPhone variant en Ruben is straks helemaal het mannetje.
LikeLike
In HTML ziet het er toch een stuk beter uit dan op een screenshot, complimenten. Maar om toch ergens kritiek op te hebben; ik vind het reactie veld (textarea) onderaan een blogitem erg klein.
Ik heb zelf trouwens ook erg goede ervaringen met het uitbesteden van front-end development naar India. En vind eigenlijk de prijs wel meevallen.
LikeLike
Ziet er keurig uit. Voor dat soort bedragen krijg je het zelf niet voor elkaar.
Ruben: Hoe wordt de betalingsafhandeling geregeld? Betaal je per creditcard?
LikeLike
Ziet er goed uit!
Een paar zaken die het misschien nog net even beter kunnen maken:
– “direct naar content”-linkje
– kopjes bij navigatie en eventueel een tekstuele indicatie m.b.t. welke knoppen geselecteerd zijn (hoeft allemaal niet zichtbaar te zijn, maar wel toegankelijk voor bv. screenreaders)
– Je hebt erg veel zaken in je site zitten die van Microformats voorzien zouden kunnen worden: bv. beoordelingen, je CV (neem ik aan), contactinfo, copyrightinfo, tags, etc.
– taalindicatie op document
– default values van inputvelden d.m.v. i.p.v. het value-attribuut
Maar nogmaals: het ziet er al goed uit!
En waarom eigenlijk (“natuurlijk”) XHTML en niet HTML?
LikeLike
Laatste item moet dus zijn:
– default values van inputvelden d.m.v. <label> i.p.v. het value-attribuut
LikeLike
Hey Ruben, ziet er best netjes uit.
De gekozen manier om je tabbladen “sliding door” te maken is op een… erhmm.. bijzondere manier uitgevoerd. Volgens mij waren ook de divjes in de aanbieding in India, er zijn namelijk wel erg veel nested divs voor een realtief simpele website.
Maar al met al mag je voor dat bedrag niet teveel gaan klagen.
LikeLike
Ow sorry, vergeet ik nog te juichen voor JOOST.
Kom op Joost, je kan het… yihaaaaaaaaa 🙂
LikeLike
Gefeliciteerd, voelt altijd goed om ook zelf buitenlandse werknemers te hebben 🙂
Wel een beetje tragisch dat mijn schermresolutie als laatste eindigt. Ik zal proberen vaker langs te komen. Ik vind de site er erg goed uit zien, prima van deze tijd, en niet topzwaar door design.
Verder vind ik het liquide zijn een beetje “wennen” ik ben gewend aan een stevige portie wit-ruimte aan beide kanten van de inhoud van een webpagina, en zie nu dat ik mn browser breeder moet maken om dat effect weer ter bereiken. Verder snap ik niet waarom het commentvakje zo smal is, het is toch ook bedoeld om een beetje een preview te zijn van hoe je tekst er uit komt te zien (en de ruimte is er)
Ben benieuwd naar de volgende update 🙂
LikeLike
Ik vind de kwaliteit van de HTML goed voor dat bedrag. Het kan natuurlijk altijd beter maar je kan nu eenmaal niet alles verwachten voor dat geld.
Punten die ik tegenkwam zijn de volgende, maar het zijn kleine punten die je niet kan verwschten voor dat bedrag denk ik.
++ 01 Homepage
Als ik de homepage bekijk dan zie ik dit:
[h1] Usarchy redesign: de vorm krijgt vorm
[h2] Artikelen
Terwijl artikelen niet onder Usarchy redesign: de vorm krijgt vorm valt. Is een klein dingetje maar wel zo netjes als dat gewoon klopt. Maar ook dat kan je eigenlijk niet verwachten voor dat bedrag. Begrijp wel dat ze het zo hebben opgelost en het is ook een eeuwige discussie die je daarover kan voeren.
++ 02 Divveritus / iconen
Verder inderdaad erg veel div’jes gebruikt en zoals krijn zegt hadden ze best wat iconen in de stylesheet mogen dumpen.
++ Liquid layout
Liquid layouts zijn leuk maar wat je wel vaak krijgt is dat teksten langer worden dan 10/12 woorden op 1 regel waardoor het lezen ervan niet echt prettig is.
Verder gewoon top, gelukkig blijft er altijd wat op of aan te merken, maar dat hou je altijd bij ieder project. Gelukkig kan het altijd beter anders zou het ook niet meer leuk zijn.
LikeLike
Ziet er goed uit Ruben! Toegegeven; ik heb 0,0 verstand van XHTML, maar van usability design des te meer. Maar vanzelfsprekend zit dat wel goed bij jou. 😉
Mag ik je eens een brutale vraag stellen? Wat is je totale budget eigenlijk voor dit project en klopt je begroting tot dusver nog?
LikeLike
Zodra je Analytics implementeert, helpt je dat toch weer aan een fout. Hetzelfde geldt voor veel banners. Of zijn daar oplossingen voor?
LikeLike
Voor 400 euro is dat heel degelijk omgezet naar xhtml! Zeker met die eisen is dat niet zo geweldig duur hoor… Eerder goedkoop zou ik zelfs durven zeggen (als je telt dat de gangbare prijs per uur in bijvoorbeeld Belgi?´ toch wel begint bij 45 euro).
Knappe site geworden trouwens! Het enige waar ik een beetje schrik voor heb is de breedte van de artikels… Lijkt me zo net op het randje tussen te breed en *net goed* :). Maar het gaat er volgens mij allemaal wel heel mooi en bruikbaar uitzien ;-). Met de findability zit het volgens mij ook wel allemaal snor… Maar dat is nog afwachten op de WordPress integratie natuurlijk. Go go Joost ;-). Knap!
LikeLike
Je hebt een erg goede koop, het schalen van de pagina gaat erg mooi en goed. Heel mooi!
Natuurlijk kunnen we wat dingetjes anders doen, de punten die Krijn, Sander en Ischa noemen zijn er een paar. Maar dat kun je verwachten als een bedrijf claimt het binnen acht uur te kunnen leveren, dan worden er beslissingen genomen ten koste van wat elegantere oplossingen.
Zelf vind ik het script wat voor de tabjes gebruikt is erg matig. Als je JavaScript uit hebt staan werkt het niet, iets wat op te lossen is door alles te laten zien in het begin. Met JavaScript pas je wat simpele CSS toe om de overbodige dingen tijdelijk te verbergen. Mochten die mensen in India er geen hout van snappen, dan wil ik mijn bijdrage wel leveren door voor jou een net, toegankelijk script te schrijven hiervoor (die ook nog wat sneller is, want zoals Krijn al zei doorloopt het script de hele pagina, terwijl maar een specifiek onderdeel deze functionaliteit behoeft).
@ Willem. Analytics heeft nette code, dus die kun je er zonder problemen plaatsen. Banners kun je wat aanpassen (de validator geeft aan wat er fout is, zodat je dat aan kunt passen). Beste oplossing is gewoon geen banners plaatsen natuurlijk 😛
LikeLike
Iedereen: begrijp me niet verkeerd, ik ben voor dit geld, in deze tijd, en met deze projectmanagement zeker tevreden 🙂 Gasten zijn heel correct, snel en punctueel.
Krijn: True, estetisch is de code niet top. Punt van de divjes was het enige dat mij ook meteen opviel, niet echt netjes inderdaad. Die heading van de blokjes ga ik zeker aanpassen en de javascript ook (kostte nog speciaal 35$ extra!).
Ik denk dat zelfs jij de HTML van Eduhub vrij behoorlijk kan waarderen, daar vind ik (near) perfectie wel belangrijk 🙂 I’ll keep you posted, waardeer je feedback zeker.
Paul: Yeah betaling per creditcard, vooraf.
Sjors: commentvakje wordt een stuk groter en zelf grotermaakbaar en met wysiwyg buttontjes, zat niet in hun briefing.
Ischa: H1/H2 structuur wordt hetzelfde als nu 🙂
Jeroen: Ik heb er niet echt een budget voor, al was het origineel 500eur zoals je in het eerste artikel kunt lezen. Maar daar gaan we dus al dik overheen, en dat vind ik geen probleem, als het maar leuk en leerzaam blijft 🙂
Arjan: you’ve got yourself a job 😉 Ik neem nog wel effe contact met je op als Joost aan de slag is.
Over de max resolutie: Misschien is de tekst kolom inderdaad aan de brede kant, je komt nu op ±15 woorden per regel. Hoor graag van de mensen met grotere monitoren wat ze van de leesbaarheid vinden.
Verder kom ik er net achter dat het content gedeelte een behoorlijke ******zooi is, qua markup. Voor de sidebar is dat geen ramp, maar het contentstuk valt helemaal uit elkaar als je er gewoon een artikel inzet. Elke alinea zit in een div, dat kan natuurlijk absoluut niet want dan zullen we de wordpress editor moeten aanpassen ofzo?
Daar zal ik nog wel even over moeten gaan zeiken, alleen ben ik daar wel wat laat mee, dushopen dat het nog geregeld wordt.
Meedenken doen ze uiteraard niet, dat is part of de offshoring game ben ik bang 🙂
LikeLike
Ok?©, roep me maar als de HTML definitief is 😉
Over het artikel/HTML gebeuren, dat ziet er inderdaad erg slecht uit. Ook is bij de ul een class meegegeven ‘bulletlist’ (erg redundant natuurlijk). Ik zou eens kritisch overal naar kijken en de belangrijkste dingen aan ze doorgeven. (Zo zie je maar weer, het mag wel valideren maar dan is de code niet per definitie goed.)
LikeLike
Hmm, bekende namen hier ineens 😉
Wat betreft die tabjes, die werken volgens mij wel als JavaScript niet ondersteund wordt. Echter staat er niks in het eerste en laatste tabje, behalve de naam van de betreffende tab en de tabs linken via een interne link naar de content van de bewuste tab.
LikeLike
Toch niet Sander zonder linkje h?®? 😉
Ruben: welke HTML bedoel je, wat betreft Eduhub?
LikeLike
@ Sander. Ja, ze worden inderdaad wel getoond (valt niet zo op nu, maar je kan ze zien). Toch denk ik dat op een bepaalde manier de tabjes er dan niet zouden moeten staan (en dus met JavaScript moeten worden aangemaakt).
De meest elegante oplossing in mijn opinie:
* Er staat eerst een div. Daarin zitten genest de tabs als div. In de tabbladen zit een header met de titel van dat tabblad. Met CSS is dit mooi vorm te geven zodat mensen zonder JavaScript toch blij zijn.
* JavaScript haalt vervolgens de tekst uit de headers en genereert daarvan de klikbare tabs. Deze tabs worden boven de tabbladen geplaatst. De overbodige informatie (non-actieve tabs) wordt van het zicht onttrokken.
LikeLike
@Arjan: Da’s inderdaad netter, maar het is nu in ieder geval wel toegankelijk en dat is volgens mij het allerbelangrijkste. Ook zijn de tabjes niet zomaar loze links (href=”#”).
LikeLike
Uhm, je weet dat IE6 geen min-weight en max-weight ondersteund? M.a.w. IE6 gebruikers zijn screwed, en (helaas) moet je daar tegenwoordig nog altijd meer rekening mee houden dan met verschillende resoluties.
LikeLike
@ Boris. Dat wordt afgevangen door de speciale IE6 stylesheet die een CSS expression gebruikt voor de max-width (vreemd genoeg niet de min-width, zie ik).
LikeLike
@Arjan: een ‘spacertje’ zorgt wellicht voor de min-width.
LikeLike
Halleee, ik zie nu dat een van mijn ijzersterke quotes vereeuwigd is in het ontwerp. Nu vind ik ‘m natuurlijk nog mooier 😉
LikeLike
Ik zie in je planning dat jouw laatste stap voor het lanceren ‘De acceptatietest’ is. Maar moet er geen stap tussen? Wat ga je doen met de resultaten van die test? Niets dus..(?) Dan kan je hem net zo goed niet doen 😉
LikeLike
Michel: scherp 🙂 Het zal meer een soort lange beta fase zijn verwacht ik, tijdens het development zal ik een subdomein aanmaken waar we allemaal live kunnen zie hoe het gaat, feedback wordt dus meteen verwerkt.
LikeLike
Om nog even op Sanders vraag terug te komen. Waarom heb je dit laten doen Ruben? Ik heb er even op gezocht, maar xhtml is netter.. Maar nu graag jouw verhaal 🙂
LikeLike
@Lodewijk: HTML kan net zo net zijn als XHTML. ‘Slordiger’ kan inderdaad ook, maar dat is een keuze. HTML eist geen minder nette code.
LikeLike
Lodewijk, ik snap je vraag niet helemaal, zou je hem kunnen rephrasen? 🙂
LikeLike
Ruben, mijn oorspronkelijke vraag, waar Lodewijk volgens mij naar verwees, was: ‘En waarom eigenlijk (‚Äùnatuurlijk‚Äù) XHTML en niet HTML?’
LikeLike
Juist 🙂
LikeLike
Ik blijf me storen aan de 4 groene blokken op de homepage. Deze zijn nergens op gelijnd en passen niet in het stramien.
LikeLike
Even iets heel anders:
Wat is de beste manier om de rechter kolom in de code te zetten? Het is mogelijk om deze in de code vóór of ná de hoofdcontent te zetten, afhankelijk van hoe je het doet met divjes en css. In Rubens ontwerp voor zijn nieuwe Usarchy staat de rechter kolom vóór de hoofdcontent.
Ruben, vind jij dit geen probleem? Hoe zit dit met SEO? En met mensen die met schermlezers je site lezen (slechtzienden)?
Wat is de voorkeur voor iedereen? Is het beter om het zo te implementeren dat je in de code eerst de hoofdcontent krijgt en daarna de onderdelen die in de rechterbalk te zien zijn, of juist andersom?
Ik was hierover aan het nadenken met een project waarbij de rechterkolom ook wel eens weg kan blijven. Die ruimte dan opvullen met de linker-kolom is goed mogelijk als je het op de manier van Ruben doet (vandaar dat zo de variabele breedte mogelijk is). Om dit mogelijk te maken is het dan volgens mij noodzakelijk om de inhoud van de rechterkolom vóór de hoofdcontent in de code te plaatsen (met float:right).
Maar wat nou als ik het liefst de rechterkolom ná de hoofdcontent in de code zet? Is er hier ook een oplossing voor? Is het verstandig om dit te willen? Of maakt het allemaal niet zoveel uit?
LikeLike
Sander: zie de discussie op het Fronteers blog over dit punt.
LikeLike