IE 6: Checkboxen & Radiobuttons

[DeEindbaas]

Hoi Alle,

In een vorig topic liep ik tegen een puntje op maar dat is mooi opgelost. Ik heb nu alles gereed in elke browser (IE 6, IE 7, IE 8, IE 9, Firefox, Chrome, Safari). Alleen ik blijf met 1 vervelend bugje zitten in IE 6.0.

Ik heb een formulier deze staat in een box. Deze box kan getoggled worden (show / hide) in het begin als de website geladen is ziet alles er perfect uit maar zodra je de box hide en dan weer open gooit dan gaat IE 6.0 opeens raar doen.

Zie:


Ik heb ongeveer alles geprobeerd met floats, displays, position alleen ik kom er niet meer uit. Ik heb ook nog de zoom : 1 geprobeerd maar dit mog blijkbaar ook niet baten...

Ik hoop dat iemand mij kan helpen!

HTML:

code:

<div class="row">
    <label>A checkbox</label>
    <span class="jqTransformCheckboxWrapper"><a href="#" class="jqTransformCheckbox jqTransformChecked"></a><input type="checkbox" checked="" name="ckbox" class="jqTransformHidden"></span> <span>Checkbox on</span>
    <span class="jqTransformCheckboxWrapper"><a href="#" class="jqTransformCheckbox"></a><input type="checkbox" name="ckbox" class="jqTransformHidden"></span> <span>Checkbox off</span>
</div>

CSS:

code:

span.jqTransformCheckboxWrapper{
    margin : 0;
}

span.jqTransformCheckboxWrapper input{
    margin : 0;
    padding : 0;
    width : 15px;
}

a.jqTransformCheckbox {
    background: transparent url(../gfx/form/checkbox.gif) no-repeat center top;
    height: 19px;
    width: 15px;
    display: inline-block;
}

a.jqTransformChecked{ 
    background-position: center bottom;
    height: 19px;
    width: 15px;
}

Oplossing

Ik heb het opgelost door bij de hide knopjes ipv van slideToggle fadeToggle te gebruiken. Dan doet IE 6 niet moeilijk

[ Voor 4% gewijzigd door DeEindbaas op 29-04-2011 17:59 ]

[jw_moonshine]

bedankt voor het posten van de oplossing!

[R4gnax]

Ik zou het geen oplossing noemen. Hoogstens een work-around voor een layout / margin bug in IE6.

De getransformeerde HTML structuur voor de rich checkboxes en radiobuttons laat trouwens behoorlijk te wensen over. Het kan veel korter:

HTML:

<label class="rich-checkbox" for="autogen-00">
  <input id="autogen-00" type="checkbox" />
</label>

Cascading Stylesheet:

.rich-checkbox {
  background: transparent url("../gfx/form/checkbox.gif") no-repeat;
  display: inline-block;
  height: 19px;
  width: 15px;
}
.rich-checkbox-on {
  background-position: center top;
}
.rich-checkbox-off {
  background-position: center bottom;
}
.rich-checkbox input {
  clip: rect(0 0 0 0);
  outline: none;
  position: absolute;
}

Daarna met wat Javascript events op de (nog steeds bereikbare) input de assignment v/d rich-checkbox-on/off classes regelen.

Weet ook vrijwel zeker dat IE6 met deze aanpak geen rare dingen gaat doen, want heb het zelf al op een meertal sites toegepast waar gebruikers lijsten met aanvinkbare opties moesten kunnen in- en uitklappen.

[DeEindbaas]

R4gnax schreef op zaterdag 30 april 2011 @ 15:04:
Ik zou het geen oplossing noemen. Hoogstens een work-around voor een layout / margin bug in IE6.

De getransformeerde HTML structuur voor de rich checkboxes en radiobuttons laat trouwens behoorlijk te wensen over. Het kan veel korter:

HTML:

<label class="rich-checkbox" for="autogen-00">
  <input id="autogen-00" type="checkbox" />
</label>

Cascading Stylesheet:

.rich-checkbox {
  background: transparent url("../gfx/form/checkbox.gif") no-repeat;
  display: inline-block;
  height: 19px;
  width: 15px;
}
.rich-checkbox-on {
  background-position: center top;
}
.rich-checkbox-off {
  background-position: center bottom;
}
.rich-checkbox input {
  clip: rect(0 0 0 0);
  outline: none;
  position: absolute;
}

Daarna met wat Javascript events op de (nog steeds bereikbare) input de assignment v/d rich-checkbox-on/off classes regelen.

Weet ook vrijwel zeker dat IE6 met deze aanpak geen rare dingen gaat doen, want heb het zelf al op een meertal sites toegepast waar gebruikers lijsten met aanvinkbare opties moesten kunnen in- en uitklappen.

Natuurlijk kan het korter ik gebruik alleen een jQuery plugin om formulieren te stylen: http://www.dfc-e.com/meti...a/opensource/jqtransform/

[Bosmonster]

Waarom zou je een jQuery plugin gebruiken (en nog een slechte ook) om een formulier te stylen, als dat ook gewoon met CSS kan.

Daarnaast: Blijf zoveel mogelijk van formulieren af qua CSS.

[Kajel]

Bosmonster schreef op dinsdag 03 mei 2011 @ 15:25:
Daarnaast: Blijf zoveel mogelijk van formulieren af qua CSS.

Deze begrijp ik niet Je mag formulieren niet mooi stijlen?

Wat betreft Topicstart: Waarom IE6 nog ondersteunen? Ik vind het persoonlijk een best practice om gewoon van elke browser de laatste 2 versies te ondersteunen. En dan duidelijk aangeven dat de website bij oudere browsers niet optimaal werkt.

[Flowmo]

Kajel schreef op woensdag 04 mei 2011 @ 12:28:
[...]

Deze begrijp ik niet Je mag formulieren niet mooi stijlen?

Wat betreft Topicstart: Waarom IE6 nog ondersteunen? Ik vind het persoonlijk een best practice om gewoon van elke browser de laatste 2 versies te ondersteunen. En dan duidelijk aangeven dat de website bij oudere browsers niet optimaal werkt.

Formulieren zijn een hel om cross-browser (en zelfs cross-platform) te stijlen. Op text inputs een border en wat padding is niet erg, maar grafische aanpassingen aan o.a. selects, checkboxes en radios gaan vaak op basis van (alleen) CSS hopeloos fout.

Daarnaast ben ik dit issue eerder tegengekomen in IE7- en dat kwam door een position:relative op en van de parent elementen van de verkeerd uitgelijnde inputs. Dit heb ik toen ook met javascript moeten oplossen door de css in te stellen naar position:static en weer terug naar relative. Verre van de mooiste oplossing, maar position:relative kon ik ook niet dumpen.

[Bosmonster]

Kajel schreef op woensdag 04 mei 2011 @ 12:28:
[...]

Deze begrijp ik niet Je mag formulieren niet mooi stijlen?

Het is aan te raden daar idd vanaf te blijven. Daarom is het ook onderdeel van de webrichtlijnen.

Je kunt formulieren daarnaast zelden consistent stylen. Naast xbrowser-issues loop je ook tegen dingen aan zoals het niet kunnen stylen van selectboxes of file inputs. Het gevolg is juist een hele rommelige user-experience, terwijl de standaard OS-rendering vaak juist prima (en wel consistent) is en dat waar de gebruiker aan gewend is.

Custom scripts gaan gebruiken om toch maar geforceerd selectboxes e.d. te kunnen stylen gaat nog een stap verder en mijnsinziens te ver. Vaak lever je dan flink in op standaardfunctionaliteit (zoals toestenbordnavigatie, accessibility-opties, etc).

Uiteindelijk zijn formulieren een noodzakelijk kwaad voor een bezoeker en wil je die niet ook nog lastigvallen met quasi-gestylede en/of halfwerkende formulier-elementen.

[DeEindbaas]

Wat betreft Topicstart: Waarom IE6 nog ondersteunen?

Omdat IE 6.0 nog genoeg gebruikt word door bedrijven.

Verder check ik of alles er goed uitziet en werkt in:
IE 6, IE 7, IE 8, IE 9, Firefox 3.0, Firefox 3.5, Firefox 3.6, Firefox 4.0, Chrome 4, Chrome 5, Safari 4.0, Safari 5.0, Opera

En tot nu toe werkt het in elk boven genoemde browser hetzelfde zoals ik het bedoeld heb. Dus ik zie hiervan het probleem niet?

[R4gnax]

Flowmo schreef op woensdag 04 mei 2011 @ 13:57:
[...]

Daarnaast ben ik dit issue eerder tegengekomen in IE7- en dat kwam door een position:relative op en van de parent elementen van de verkeerd uitgelijnde inputs. Dit heb ik toen ook met javascript moeten oplossen door de css in te stellen naar position:static en weer terug naar relative. Verre van de mooiste oplossing, maar position:relative kon ik ook niet dumpen.

Kwestie van vanaf het element dat problemen geeft omhoog werken en alle parent elementen één voor één layout geven (middels zoom:1) tot je erachter bent welke het probleem geeft.

Wat je met javascript feitelijk gedaan hebt is geforceerd dat er een pagina repaint en reflow plaatsvindt, terwijl dat automatisch al goed zou gaan als je de juiste elementen de speciale layout eigenschap geeft. IE < 8 heeft wat dat betreft een hele domme renderer die je nog wel eens moet 'helpen'.

Bosmonster schreef op woensdag 04 mei 2011 @ 14:15:

Custom scripts gaan gebruiken om toch maar geforceerd selectboxes e.d. te kunnen stylen gaat nog een stap verder en mijnsinziens te ver. Vaak lever je dan flink in op standaardfunctionaliteit (zoals toestenbordnavigatie, accessibility-opties, etc).

Eensch.

Ik moet alleen eerlijk bekennen dat ik er zelf ook schuldig aan ben als iets persé naadloos in een site design moet passen. Mijn scripted selectboxes hebben gelukkig wel een volledige set muis en keyboard interactie en apen voor 99.99% de user interface van en interactie met normale OS dropdown lists succesvol na. Alleen de ARIA ondersteuning moet ik nog wat aan schaven, maar tot die tijd is het onderliggende select element tenminste nog 'accessibly hidden'.

Het was dan ook wel een HELS karwei om voor elkaar te krijgen, wat meteen illustreert waarom je in de meeste gevallen flink op functionaliteit in levert. Je moet voor een echt goede implementatie gewoon met zo ongelooflijk veel zaken rekening houden dat de meeste mensen de moeite niet zullen doen.

En zelfs met een complete rich selectbox implementatie zal ik op belangrijke, grote formulieren (zoals bijvoorbeeld bij e-booking of e-commerce) nog steeds terug vallen op de vertrouwde standaard OS UI widgets, precies omdat ze voor een consument vertrouwd zijn en die consument daarmee een 'veilig' gevoel geven bij zaken als elektronisch aanschaffen van goederen of diensten.

[Spinal]

Dreamwire schreef op donderdag 05 mei 2011 @ 14:10:
[...]
Verder check ik of alles er goed uitziet en werkt in:
IE 6, IE 7, IE 8, IE 9, Firefox 3.0, Firefox 3.5, Firefox 3.6, Firefox 4.0, Chrome 4, Chrome 5, Safari 4.0, Safari 5.0, Opera

Lichtelijk offtopic: Chrome 4 en 5? Je weet dat Chrome inmiddels op versie 11 zit?

[DeEindbaas]

ZanderZ schreef op vrijdag 06 mei 2011 @ 13:37:
[...]

Lichtelijk offtopic: Chrome 4 en 5? Je weet dat Chrome inmiddels op versie 11 zit?

Klopt... maar als dat de wens is

En het verschil ertussen qua HTML / CSS regels is het niet echt anders ofzo

[Spinal]

Klopt, maar juist bij Chrome kun je vanwege de auto-update er min of meer vanuit gaan dat 99% de nieuwste versie gebruikt. Waarom dan testen in Chrome 4/5?

[Martijntj]

ZanderZ schreef op vrijdag 06 mei 2011 @ 17:31:
Klopt, maar juist bij Chrome kun je vanwege de auto-update er min of meer vanuit gaan dat 99% de nieuwste versie gebruikt. Waarom dan testen in Chrome 4/5?

Er staat toch dat dat de wens van de klant is om die te gebruiken, of wat ?

[R4gnax]

Martijntj schreef op vrijdag 06 mei 2011 @ 17:40:
[...]


Er staat toch dat dat de wens van de klant is om die te gebruiken, of wat ?

Het klinkt cru, maar: klanten zijn dom.

Als een echte professional is het dan ook jouw taak om, wanneer dat nodig is, ook je klanten te adviseren dat bepaalde baten niet opwegen tegen de daarmee geassocieerde kosten.

[martijn2008]

Dreamwire schreef op donderdag 05 mei 2011 @ 14:10:
[...]

Omdat IE 6.0 nog genoeg gebruikt word door bedrijven.

Verder check ik of alles er goed uitziet en werkt in:
IE 6, IE 7, IE 8, IE 9, Firefox 3.0, Firefox 3.5, Firefox 3.6, Firefox 4.0, Chrome 4, Chrome 5, Safari 4.0, Safari 5.0, Opera

En tot nu toe werkt het in elk boven genoemde browser hetzelfde zoals ik het bedoeld heb. Dus ik zie hiervan het probleem niet?

IE 6.0 zou ik ook geen tijd meer insteken, alleen in China gebruiken ze die nog veel, ik weet niet of je site ook in het Chinees is? In Nederland gebruiken 2,4% van de gebruikers MSIE6 dat is toch te verwaarlozen? En dan ziet het er misschien net iets anders uit.
bron:http://www.theie6countdown.com

En vind het ook verstandig om je opdrachtgever inderdaad wat beter te adviseren. Het is denk ik een beetje zonde van de tijd, maar als je daardoor meer geld krijgt moet je het zeker doen!! Ik weet niet of het helemaal eerlijk is...

[ Voor 12% gewijzigd door martijn2008 op 07-05-2011 22:16 ]

[CH4OS]

R4gnax schreef op zaterdag 07 mei 2011 @ 17:22:
Als een echte professional is het dan ook jouw taak om, wanneer dat nodig is, ook je klanten te adviseren dat bepaalde baten niet opwegen tegen de daarmee geassocieerde kosten.

Want Chrome 4 en 5 zijn van het pre IE6 tijdperk? Kom op zeg, overdrijven is ook een vak. Chrome 4 en 5 zijn zo oud niet. Dat Chrome zo supersnel op versie 11 zit, zegt imo alleen wat over de marketing machine van Google, maar dat is een andere discussie. "Under the hood" zal Chrome 4 / 5 niet zo heel veel verschillen met 11. Dat de versie van Chrome inmiddels stappen verder is, doet niets onder de wens van de klant. Als service zou de ts dan nog Chrome 10 / 11 ook kunnen testen, maar dan komen we weer bij jouw kosten en baten, omdat de klant er niet naar heeft gevraagd.

[R4gnax]

CptChaos schreef op zaterdag 07 mei 2011 @ 22:30:
[...]
Want Chrome 4 en 5 zijn van het pre IE6 tijdperk? Kom op zeg, overdrijven is ook een vak. Chrome 4 en 5 zijn zo oud niet. Dat Chrome zo supersnel op versie 11 zit, zegt imo alleen wat over de marketing machine van Google, maar dat is een andere discussie. "Under the hood" zal Chrome 4 / 5 niet zo heel veel verschillen met 11. Dat de versie van Chrome inmiddels stappen verder is, doet niets onder de wens van de klant. Als service zou de ts dan nog Chrome 10 / 11 ook kunnen testen, maar dan komen we weer bij jouw kosten en baten, omdat de klant er niet naar heeft gevraagd.

Het ging me meer om de misvatting dat het de wens van de klant is en dus maar moet gebeuren: "U vraagt, wij draaien." In het specifieke geval van Chrome 4 & 5 zal het inderdaad weinig uitmaken.

[Kajel]

Bosmonster schreef op woensdag 04 mei 2011 @ 14:15:
[...]


Het is aan te raden daar idd vanaf te blijven. Daarom is het ook onderdeel van de webrichtlijnen.

Je kunt formulieren daarnaast zelden consistent stylen. Naast xbrowser-issues loop je ook tegen dingen aan zoals het niet kunnen stylen van selectboxes of file inputs. Het gevolg is juist een hele rommelige user-experience, terwijl de standaard OS-rendering vaak juist prima (en wel consistent) is en dat waar de gebruiker aan gewend is.

Custom scripts gaan gebruiken om toch maar geforceerd selectboxes e.d. te kunnen stylen gaat nog een stap verder en mijnsinziens te ver. Vaak lever je dan flink in op standaardfunctionaliteit (zoals toestenbordnavigatie, accessibility-opties, etc).

Uiteindelijk zijn formulieren een noodzakelijk kwaad voor een bezoeker en wil je die niet ook nog lastigvallen met quasi-gestylede en/of halfwerkende formulier-elementen.

Wat een ontzettend steaming pile of shit, no offense Heb jij recentelijk nog wel eens een browser geopend en wat rond gesurft? We zijn ondertussen al weer lang en breed voorbij Web 2.0, en daar was CSS gebruik bij formulieren ed, niet alleen common practice, maar ook gewenst.

Ik kan jouw argumenten ten aanzien van consistentie ook precies andersom gebruiken: Het stijlen van formulieren middels CSS is de enige manier om formulieren en crossbrowser, en zeker cross-OS, hetzelfde uit te laten zien. Een selectbox ziet er bv op Windows echt anders uit dan op Max OS X, of zelfs maar een invoerveld.

En wat dacht je van consistentie binnen je Web applicatie? Dus jij kiest ervoor je formulieren niet te stijlen, waardoor ze volledig uit de toon vallen in het design van de rest van je web app. Consistent hoor...

Al die webrichtlijnen waar jij zo zealously over preekt, weerhouden enorm grote en succesvolle sites er niet van om gewoon hun formulieren te stijlen. En om andere moderne, en soms zelfs experimentele, webtechnieken te gebruiken. Zie twitter.com en facebook.com

Ik word ontzettend moe van mensen die vasthouden aan dat soort regels die alleen in hun hoofd nog actief afgedwongen worden, en daarmee de vooruitgang van het web tegenhouden.

Wat betreft IE6: "enorm veel bedrijven" gebruiken niet IE6. En zelfs als ze dat doen... is dat je doelgroep?
Ik durf te stellen dat de gemiddelde webgebruiker tegenwoordig een bijna desktop-achtige ervaring verwacht. Ze verwachten een mooie, slicke, usable website. Niet een totaal verouderde website, om maar IE6-compatible te zijn...

[Janoz]

Kajel schreef op maandag 09 mei 2011 @ 14:36:
Een selectbox ziet er bv op Windows echt anders uit dan op Max OS X, of zelfs maar een invoerveld.

Dat is precies het punt. je gaat een Windows gebruiker toch geen Mac widgets voorschotelen?

En wat dacht je van consistentie binnen je Web applicatie? Dus jij kiest ervoor je formulieren niet te stijlen, waardoor ze volledig uit de toon vallen in het design van de rest van je web app. Consistent hoor...

Ja, want een scrollbalk in de kleur van de huisstijl maakt de site zoveel mooier [/chargeer]

Wat betreft IE6: "enorm veel bedrijven" gebruiken niet IE6. En zelfs als ze dat doen... is dat je doelgroep?
Ik durf te stellen dat de gemiddelde webgebruiker tegenwoordig een bijna desktop-achtige ervaring verwacht. Ze verwachten een mooie, slicke, usable website. Niet een totaal verouderde website, om maar IE6-compatible te zijn...

Als ze een desktop achtige ervaring verwachten dan zul je juist niet je form elementen compleet moeten verbasteren, maar juist moeten laten lijken op wat voor dat platform gebruikelijk is.

[peddro]

Janoz schreef op maandag 09 mei 2011 @ 14:52:
[...]

Dat is precies het punt. je gaat een Windows gebruiker toch geen Mac widgets voorschotelen?

Daar gaat het toch ook niet om? Je wilt ze beide toch exact hetzelfde voorschotelen?

Janoz schreef op maandag 09 mei 2011 @ 14:52:
[...]

Ja, want een scrollbalk in de kleur van de huisstijl maakt de site zoveel mooier [/chargeer]

Scrollbalken daargelaten van de browser altijd hetzelfde laten (in hoeverre deze in huidige browsers nog aan te passen valt). Maar een interne scrollbalk zou voor mij persoonlijk mooier zijn als het consistent is met de rest van het design.

Janoz schreef op maandag 09 mei 2011 @ 14:52:
[...]

Als ze een desktop achtige ervaring verwachten dan zul je juist niet je form elementen compleet moeten verbasteren, maar juist moeten laten lijken op wat voor dat platform gebruikelijk is.

Met een desktop ervaring wordt niet direct gedoeld dat alles op of Windows of Mac lijkt, maar dat het zo werkt als een programma (door de browser niet te laten refreshen, etc.).

[Bosmonster]

Kajel schreef op maandag 09 mei 2011 @ 14:36:
[...]


Wat een ontzettend steaming pile of shit, no offense Heb jij recentelijk nog wel eens een browser geopend en wat rond gesurft? We zijn ondertussen al weer lang en breed voorbij Web 2.0, en daar was CSS gebruik bij formulieren ed, niet alleen common practice, maar ook gewenst.

Thanks. Maar dat stukje over "gewenst" is dus juist waar ik het niet over eens ben

Ik kan jouw argumenten ten aanzien van consistentie ook precies andersom gebruiken: Het stijlen van formulieren middels CSS is de enige manier om formulieren en crossbrowser, en zeker cross-OS, hetzelfde uit te laten zien. Een selectbox ziet er bv op Windows echt anders uit dan op Max OS X, of zelfs maar een invoerveld.

Consistentie tussen platformen lijkt me compleet irrelevant. Je wilt consistentie binnen je platform. De beste manier om dat te bereiken is door de standaarden van dat platform te hanteren.

En wat dacht je van consistentie binnen je Web applicatie? Dus jij kiest ervoor je formulieren niet te stijlen, waardoor ze volledig uit de toon vallen in het design van de rest van je web app. Consistent hoor...

Dat is alleen belangrijk als een vormgever het hoogste woord heeft. Dat is bij voorkeur niet het geval.

Al die webrichtlijnen waar jij zo zealously over preekt, weerhouden enorm grote en succesvolle sites er niet van om gewoon hun formulieren te stijlen. En om andere moderne, en soms zelfs experimentele, webtechnieken te gebruiken. Zie twitter.com en facebook.com

Ten eerste is het niet zo dat alles wat grote sites doen per definitie goed is. Ten tweede gaat het om formulieren, niet om losse invulboxen zoals bijvoorbeeld een search-box of reactie-box. Hier kun je best nog wel eens afwijken naar eigen (professioneel) inzicht.

Ik word ontzettend moe van mensen die vasthouden aan dat soort regels die alleen in hun hoofd nog actief afgedwongen worden, en daarmee de vooruitgang van het web tegenhouden.

Denken aan je gebruikers en accessibility is juist vooruitgang. Vormgeving of techniek de overhand geven is juist iets van het verleden. Frontend, usability en accessibility is waar de focus tegenwoordig steeds meer ligt in grotere trajecten.

Samengevat: Kwaliteit in dienst van de gebruiker, niet in dienst van de designer.

[Kajel]

Bosmonster schreef op maandag 09 mei 2011 @ 15:05:
Consistentie tussen platformen lijkt me compleet irrelevant. Je wilt consistentie binnen je platform. De beste manier om dat te bereiken is door de standaarden van dat platform te hanteren.

Je moet juist niet denken binnen 1 platform, maar consistentie behouden tussen platformen. Gebruikers willen dat bijvoorbeeld Facebook er overal hetzelfde uitziet.

Dat is alleen belangrijk als een vormgever het hoogste woord heeft. Dat is bij voorkeur niet het geval.

Een vormgever hoeft niet het hoogste woord te hebben, maar in de praktijk draagt een goede vormgever meer bij aan de usability en accessibility dan een gemiddelde (backend)programmeur... En dat zeg ik, als programmeur.

Ten eerste is het niet zo dat alles wat grote sites doen per definitie goed is. Ten tweede gaat het om formulieren, niet om losse invulboxen zoals bijvoorbeeld een search-box of reactie-box. Hier kun je best nog wel eens afwijken naar eigen (professioneel) inzicht.

Niet per definitie, maar je kunt er echt wel vanuit gaan dat een miljoenen-applicatie als Twitter of Facebook tot stand is gekomen met behulp van mensen die per stuk meer ervaring, kennis/know-how hebben dan jij en ik bij elkaar. Er is heel goed onderzocht wat wel en niet werkt qua usability en accessibility en op basis daarvan zijn die applicaties ontworpen en gebouwd.
Het is nogal naief/arrogant te denken dat jij beter weet hoe een goede web app in elkaar zit, dan de makers en bedenkers van bovengenoemde apps.

Denken aan je gebruikers en accessibility is juist vooruitgang. Vormgeving of techniek de overhand geven is juist iets van het verleden. Frontend, usability en accessibility is waar de focus tegenwoordig steeds meer ligt in grotere trajecten.

Samengevat: Kwaliteit in dienst van de gebruiker, niet in dienst van de designer.

Het punt is, dat een goede designer juist ontwerpen aflevert die zo hoog mogelijk scoren op het gebied van usability en accessibility. Bij het bedrijf waar ik werk, gebeurt dat in ieder geval wel, want ik word regelmatig door de designer op mijn vingers getikt als ik iets gemaakt heb, wat wel cool is, maar niet gebruiksvriendelijk genoeg.
Het stijlen van je formulieren, in plaats van ze de sterk verouderde HTML3-achtige scheiss laten zijn, die ze vaak zijn, is juist ontzettend goed voor de Usability.

Ga maar eens naar twitter.com, zonder ingelogd te zijn, en kijk naar de form aldaar. Prachtig, en zeer bruikbaar.

[Bosmonster]

Grappig, want de nieuwe Twitter-site heeft meer kritiek gekregen dan lof Hetzelfde geldt voor Facebook. Die site staat nu ook niet echt te boek als een usability-juweeltje.

Ik ben inderdaad arrogant genoeg om me niet omhoog te hoeven trekken aan fictieve figuren bij grote namen. Ik ben overtuigd genoeg van mijn eigen capaciteiten en kwaliteiten om dat niet nodig te hebben. Derhalve kan ik dat - ze doen het bij Bedrijf X - ook onmogelijk als argumentatie zien.

Maar goed, dat gaat off topic, maar inhoudelijk valt er verder toch weinig meer te bediscussieren vrees ik. We agree to disagree (hoewel dat wel een beetje PVV-geurtje heeft gekregen tegenwoordig ).

[ Voor 15% gewijzigd door Bosmonster op 09-05-2011 15:49 ]

[Janoz]

Kajel schreef op maandag 09 mei 2011 @ 15:19:
Je moet juist niet denken binnen 1 platform, maar consistentie behouden tussen platformen. Gebruikers willen dat bijvoorbeeld Facebook er overal hetzelfde uitziet.

Ik zou dit niet als waarheid willen verkondigen. Het is niet automatisch de ene of de andere.

Een vormgever hoeft niet het hoogste woord te hebben, maar in de praktijk draagt een goede vormgever meer bij aan de usability en accessibility dan een gemiddelde (backend)programmeur... En dat zeg ik, als programmeur.

Gemiddelde designer is net zo brak met interface design als de gemiddelde webprogrameur. Interaction design is een discipline op zichzelf.

Niet per definitie, maar je kunt er echt wel vanuit gaan dat een miljoenen-applicatie als Twitter of Facebook tot stand is gekomen met behulp van mensen die per stuk meer ervaring, kennis/know-how hebben dan jij en ik bij elkaar. Er is heel goed onderzocht wat wel en niet werkt qua usability en accessibility en op basis daarvan zijn die applicaties ontworpen en gebouwd.
Het is nogal naief/arrogant te denken dat jij beter weet hoe een goede web app in elkaar zit, dan de makers en bedenkers van bovengenoemde apps.

Voor Twitter en Facebook zijn juist een voorbeeld van een website/applicatie waarbij de formulieren zo overdreven simpel zijn dat de 'usability' requirements niet boven die van de door bosmonster al aangehaalde searchbox komt. De meeste formulieren zijn niet meer dan een textarea met een submit. Daarnaast zou ik Facebook niet aan willen dragen als voorbeeld van fantastische usability (alhoewel het bij facebook al beduidend beter is dan hyves)

Het punt is, dat een goede designer juist ontwerpen aflevert die zo hoog mogelijk scoren op het gebied van usability en accessibility. Bij het bedrijf waar ik werk, gebeurt dat in ieder geval wel, want ik word regelmatig door de designer op mijn vingers getikt als ik iets gemaakt heb, wat wel cool is, maar niet gebruiksvriendelijk genoeg.
Het stijlen van je formulieren, in plaats van ze de sterk verouderde HTML3-achtige scheiss laten zijn, die ze vaak zijn, is juist ontzettend goed voor de Usability.

Maar wanneer checkboxes zo 'vernieuwd' zijn dat de gebruiker ze niet eens meer herkend? Dan draagt dat toch niet meer bij aan de usability?

[ Voor 3% gewijzigd door Janoz op 09-05-2011 16:00 ]

[Kajel]

Er is een verschil tussen zodanig stijlen dat een gebruiker ze niet meer herkent, en "Je moet formulieren niet CSSen".

[OkkE]

Kajel schreef op dinsdag 10 mei 2011 @ 10:06:
Er is een verschil tussen zodanig stijlen dat een gebruiker ze niet meer herkent, en "Je moet formulieren niet CSSen".

Natuurlijk kan je een <input> en <textarea> binnen je formulier wel een andere border-color geven als je dat beter binnen je design vindt passen. Daar gaat het ook niet om. En we hebben het hier ook niet over de Twitter of Facebook inputs.

Het enige dat er gezegd wordt; pas op met het te veel stijlen van je formulieren (checkbox, radio, dropdown, ...). Het wordt daar door veel minder herkenbaar voor gebruikers en het verkleint het gebruikersgemak (bijv. toetsenbord ondersteuning, screen readers, mobile devices, ...).

En waarom? Zodat je checkbox een ander vinkje heeft? De meeste bezoekers boeit het niks hoe de checkbox er bijvoorbeeld uit ziet, als ze 'm maar snel herkennen en makkelijk kunnen gebruiken. En dat gaat nog altijd het beste met de standaard vorm.