Verkleinen window laat tweakers naar -C schieten op desktop

[Cyleo]

Als ik mijn browserwindow verklein tot ik gok 400 pixel breed verandert tweakers van A naar C terwijl ik op een desktopclient (chrome op een pc) werk. Ik vermoed dat mensen liever de A variant houden op hun desktop, mogelijk komt dit omdat device detection nog niet helemaal lekker werkt?

[Misha]

Dat is expres gedaan. We bekijken de beschikbare ruimte en passen daar de website op aan. We kijken niet naar welk apparaat je precies hebt en serveren daar vervolgens een aparte versie van Tweakers voor. Daar is dit een 'effect' van. Mocht je uiteindelijk wel echt perse willen dat je altijd A hebt op een bepaalde client, dan kun je dat forceren middels device detect

[JoostBaksteen]

Misha schreef op dinsdag 02 april 2013 @ 16:04:
Mocht je uiteindelijk wel echt perse willen dat je altijd A hebt op een bepaalde client, dan kun je dat forceren middels device detect.

Wat nu dus nog niet werkt, maar wat er wel aan komt.

[Anoniem: 457607]

Slechts mijn mening: het is volstrekt terecht dat in dit geval C getoond wordt. Device detection moet je eigenlijk niet willen. Daarnaast moet je je afvragen wat een desktop user met een browser window van 400 pixels moet.

[Anoniem: 294494]

Frappant detail, bij m'n windows client op mijn werk - IE10 - werd ik omgezet naar C toen ik ver genoeg inzoomde, op m'n Mac Mini (OSX 10.8.3) maakt het echter niet uit hoever ik inzoom (tot max), maar ik blijf op A zitten.

[Anoniem: 457607]

@Gish: Een mogelijke theorie, maar ik heb het nog niet uitgezocht. Het kan zijn (en ik hoop dat ook) dat de breakpoints van dit design niet op pixels maar op ems gebaseerd zijn. Als dat zo is, dan reageren sommige browsers daar verschillend op. Firefox en IE pakken de switch meteen op bij het zoomen van de page, terwijl je bij webkit engines moet zoomen en vervolgens de page refreshen om de nieuwe layout te zien.

[Cyleo]

Anoniem: 457607 schreef op dinsdag 02 april 2013 @ 19:03:
Slechts mijn mening: het is volstrekt terecht dat in dit geval C getoond wordt. Device detection moet je eigenlijk niet willen. Daarnaast moet je je afvragen wat een desktop user met een browser window van 400 pixels moet.

Twee schermen naast elkaar op 1378 x 768 oid. Ik zie het mijzelf ook nog niet direct doen maar ik weet zeker dat het gaat voorkomen. De C versie lijkt wel erg gecrippled als desktop gebruiker, maar dit is niet echt een probleem meer als je straks die detectie kan overrulen, bedankt voor de verduidelijking.

[Anoniem: 294494]

Anoniem: 457607 schreef op dinsdag 02 april 2013 @ 19:43:
@Gish: Een mogelijke theorie, maar ik heb het nog niet uitgezocht. Het kan zijn (en ik hoop dat ook) dat de breakpoints van dit design niet op pixels maar op ems gebaseerd zijn. Als dat zo is, dan reageren sommige browsers daar verschillend op. Firefox en IE pakken de switch meteen op bij het zoomen van de page, terwijl je bij webkit engines moet zoomen en vervolgens de page refreshen om de nieuwe layout te zien.

Je theorie klinkt aannemelijk, maar blijkt niet zo te zijn. Safari blijft hem in A weergeven. Ook Chrome ( Versie 26.0.1410.43) op OSX heeft hetzelfde gedrag als Safari, ook na een refresh blijft de weergave in A. Gelijk Firefox maar even gedownload (versie 20), exact hetzelfde gedrag.

[crisp]

Breakpoints zijn in pixels gedefinieerd, en in feite maakt dat ook niet uit; em gebruik je om elementen mee te laten schalen met je font-size (zogenaamd 'fluid'-design) en bij zoomen is dat niet relevant. Dit is puur afwijkend gedrag van browsers.

[ Voor 5% gewijzigd door crisp op 04-04-2013 00:12 ]

[Anoniem: 294494]

Okay, dus als ik je goed begrijp dan zou het wel moeten werken als ik mijn browserscherm gewoon klein maak? Gelijk even getest, zelfde resultaat als eerder. Of snap ik het nu gewoon niet? Ik ben niet zo bedreven in devtermen vrees ik, ben maar een simpele beheerder

[Anoniem: 457607]

@crisp. Dat is simpelweg onjuist. Ems worden ook gebruikt voor breakpoints, sterker nog, dit is de best practice. Het is nu juist bedoeld voor zoomen. Baseer je breakpoints op pixels en zoom in, het gevolg is dat de bestaande layout opgeblazen wordt, waardoor deze op een gegeven moment niet meer past. Baseer je breakpoints op ems, zoom in, en de layout die nog past wordt voorgeschoteld. Ems maken je responsive design los van harde pixels en maken het niet alleen mogelijk om te zoomen, ook het ondersteunen van grote schermen met een relatief lage resolutie (bijv een TV) wordt hierdoor mogelijk.

[crisp]

Anoniem: 457607 schreef op donderdag 04 april 2013 @ 00:23:
[...]
Baseer je breakpoints op pixels en zoom in, het gevolg is dat de bestaande layout opgeblazen wordt,

Op een desktop is dat iig ook precies wat ik verwacht van een zoom-functie; dan wil ik niet dat ineens de layout veranderd en ik effectief deels terug bij af ben. Ik weet niet of dat op kleinere devices wel wenselijk zou moeten zijn. 'best practice' ben ik het dus zo net nog niet mee eens; RWD is sowieso nogal pionieren wat dat betreft...

Daarbij is het nogal een omslag die je dan technisch gezien moet maken omdat je dat dan eigenlijk in de basis (dus de desktop-variant in ons geval) moet inbouwen, of mobile met clean CSS moet gaan doen.

[ Voor 15% gewijzigd door crisp op 04-04-2013 00:45 ]

[Anoniem: 457607]

@crisp: met "best practice" bedoel ik niet dat het mijn best practice of mening is, ik bedoel dat het de community consensus is dat dit een best practice is. Uiteraard maakt het dat geen wet, maar de pioniers vinden het over het algemeen de betere methode, en daar zit solide logica achter.

Over zoomen: misschien persoonlijk maar ik vind het nu juist ontzettend logisch dat de layout zich aan het zoomniveau aanpast. Responsive web design gaat over de juiste layout, voor de juiste content. Vergeet devices. Als ik op een desktop een pagina 200% inzoom en dan de "tablet" layout voorgeschoteld krijg, dan is dat de ideale layout voor deze content grootte. Je moet dat niet als "terug bij af" zien en ook niet als "tablet" view, het is de juiste layout voor die content situatie, ongeacht je device.

Tot slot: ems als breakpoint is kinderspel als je nu pixels gebruikt. Ik gebruikte namelijk eerst ook pixels. Het enigst wat je hoeft te doen is je pixel breakpoints te delen door je base font size (bijv 16px). Het resultaat is een em waarde, en die gebruik je in je media queries:

@media screen and (min-width: 0em) { @import 'mode_xxs'; }
@media screen and (min-width: 35em) { @import 'mode_xs'; } /* 560/16 */
@media screen and (min-width: 40em) { @import 'mode_s'; } /* 640/16 */
@media screen and (min-width: 48em) { @import 'mode_m'; } /* 768/16 */
@media screen and (min-width: 64em) { @import 'mode_l'; } /* 1024/16 */

En klaar is kees.

[crisp]

Het punt is dan wel dat jij in feite gaat bepalen wat de zoom-functionaliteit precies doet zonder dat de gebruiker daar nog zeggenschap in heeft. M.i. zou zeker op een desktop met voldoende mogelijkheden om genoeg ruimte te creëeren voor een 'full website' de keuze voor een andere/aangepaste layout een expliciete gebruikerskeuze moeten zijn.

Als ik in wil zoomen om bijvoorbeeld een bepaald plaatje wat groter te zien, en vervolgens verdwijnt dat plaatje omdat de layout zich aanpast naar een waar dat plaatje overbodig geacht werd dan ga je in tegen mijn intentie en verwachting zonder me een andere mogelijkheid te geven. Dat mag toch niet de bedoeling zijn.

Maar goed, hier intern pleit ik er nu sowieso voor om 'responsive' ueberhaupt optioneel te houden voor desktop devices. Dan zou het ook geen issue zijn, maar laat je de gebruiker wel weer de keuze.

[ Voor 15% gewijzigd door crisp op 04-04-2013 14:56 ]

[Anoniem: 457607]

Ik denk dat we fundamenteel verschillen van mening over wat zoomen is. Door te zoomen (en dit kan zowel een tekstzoom als een pagezoom zijn) wordt in feite je viewport kleiner (maar niet je browser window...belangrijk verschil) omdat je content in omvang toeneemt. In de redenering die jij volgt stel je in feite dat je viewport bij een zoom nu juist toeneemt, waardoor deze dus groter dan je browser window kan worden.

Dit laatste is niet wat er daadwerkelijk gebeurd. Stel je een browser window voor van 1024 pixels breed, 100% zoom level. De viewport is dan ook 1024 pixels breed. Zoom die page naar 200%. Je window is nog steeds 1024 pixels breed maar je viewport is gehalveerd. Dat is geen mening maar een feit, browsers rapporteren dit daadwerkelijk. Gezien het verschil in viewport kun je dus een andere layout krijgen. In een goed responsive design krijg je dan een betere layout voor die situatie, dus het is geen achteruitgang, het is een feature.

De kunst is het loslaten van denken in pixels en devices. Denk in content en capabilities. Responsive design is geen fix voor mobiles en tablets, het is veel meer dan dat, en door in content en relatieve eenheden te denken dek je de breedst mogelijke lading zonder je over ieder device druk te maken, inclusief devices die nog uitgevonden moeten worden.

Ik begrijp overigens wel je punt van zorg. Er is niet mis met het oneens zijn met elkaar, ik probeer slechts ideeen uit te wisselen. Over dit punt emmer ik graag door omdat het zo'n fundamenteel concept is.

[crisp]

Ik vind dat je dan voorbij gaat aan wat (naar mijn mening) een zoom-functie hoort te zijn (en hoe die in de meeste gevallen ook werkt en gebruikt wordt); het is als het ware een soort vergrootglas waarmee je een bepaald deel van je object beter kan bekijken. Als elke keer een object veranderd wanneer ik een vergrootglas erbij pak dan zou ik redelijk geirriteerd raken

Als ik slechtziend ben, en ik wil inzoomen op een stuk tekst dan moet niet de situatie ontstaan dat eea zich zo aanpast dat de tekst wel prima binnen mijn viewport past, maar uiteindelijk nog te klein is voor mij om goed te kunnen lezen. Een dergelijke feature moet intuitief zijn en blijven en niet stiekum opeens ander gedrag gaan vertonen (want dat gebeurd dan feitelijk wel). Daar waar een layout-change niet intuitief zou zijn moet het aangeboden worden als expliciete keuze; je moet die keuze dan m.i. niet opdringen.

[Anoniem: 457607]

Het idee van een geoptimaliseerde view bij zoomen is dat deze beter is voor de situatie (anders is je design verkeerd), terwijl jij telkens verondersteld dat een layout change ongewenst en een verslechtering is.

Vergeet ook niet dat zoomen niet eens een expliciete keuze van een gebruiker hoeft te zijn. Zoomen is alles groter dan 1 em. Het kan dus ook een TV zijn met een 2em setting. Of een gebruiker met een font size voorkeur. Of een browser op een of ander vaag device wat standaard je pagina inzoomt. Het is ook niet zo dat je ineens tekst van mobile formaat (klein) krijgt bij zo'n switch. Die is namelijk relatief en schaalt mee met het zoom level.

Anyway, het gaat me denk ik niet lukken om je te overtuigen, en dat is prima. We agree to disagree.

(om toch nog even te klieren...zodra je een breed scala aan devices gaat testen acht ik de kans groot dat je nog bijdraait

[ Voor 9% gewijzigd door Anoniem: 457607 op 04-04-2013 15:39 ]

[crisp]

Anoniem: 457607 schreef op donderdag 04 april 2013 @ 15:36:
Het idee van een geoptimaliseerde view bij zoomen is dat deze beter is voor de situatie (anders is je design verkeerd), terwijl jij telkens verondersteld dat een layout change ongewenst en een verslechtering is.

Het gaat in tegen wat ik van een zoom-functie verwacht; that's all. In ieder geval op desktop that is (en ik ben een verstokt desktop gebruiker; voor dingen lezen gaat een tablet nog wel maar een telefoon vind ik al way te klein daarvoor, en browsen op TV zie ik al helemaal niet zo voor me - sowieso is mijn CRT TV onverwoestbaar )

Vergeet ook niet dat zoomen niet eens een expliciete keuze van een gebruiker hoeft te zijn. Zoomen is alles groter dan 1 em. Het kan dus ook een TV zijn met een 2em setting. Of een gebruiker met een font size voorkeur. Of een browser op een of ander vaag device wat standaard je pagina inzoomt. Het is ook niet zo dat je ineens tekst van mobile formaat (klein) krijgt bij zo'n switch. Die is namelijk relatief en schaalt mee met het zoom level.

Anyway, het gaat me denk ik niet lukken om je te overtuigen, en dat is prima. We agree to disagree.

(om toch nog even te klieren...zodra je een breed scala aan devices gaat testen acht ik de kans groot dat je nog bijdraait

Daar zullen we dan een overwogen keuze in moeten maken. Mijn voorstel hier is om 'computers' (groot scherm met hoge dichtheid) toch anders te behandelen dan andere devices (portable, TV etc.)

[Misha]

Interessante discussie. Ik moet wel zeggen dat ik het eens ben met crisp. Als ik iets ingezoomd wil hebben, impliceert dat niet dat ik ook ineens wil dat de content iets anders gepresenteerd wordt.

Als ik kijk naar wat de rest doet, dan wordt ook niet ineens een andere device grade gepakt. Zie bijvoorbeeld:
http://www.smashingmagazine.com/
http://www.currys.co.uk/gbuk/index.html
http://bostonglobe.com/
http://clearleft.com/

Heb je zelf voorbeelden waar dit gedrag plaatsvind zoals jij omschrijft? Ik ben wel benieuwd hoe dat werkt

[Anoniem: 457607]

"Als ik iets ingezoomd wil hebben, impliceert dat niet dat ik ook ineens wil dat de content iets anders gepresenteerd wordt. "

De content wordt *beter* gepresenteerd voor het betreffende zoom level, anders zit er iets fout in je responsive design. Als het namelijk slechter zou worden, dan betekent dat dat je andere layouts ook een achteruitgang zijn en kun je beter bij alleen een desktop layout blijven. Er is namelijk geen verschil tussen 200% zoomen op een groot scherm en een tablet/mobile scherm: beiden dienen de optimale layout te kiezen voor de content grootte.

Ik denk dat teveel gedacht wordt dat dit alleen een gebruikersactie is. Een zoom is alles anders dan 1em. Het device kan ook uit zichzelf zoomen, door een gebruikersvoorkeur, of wat dan ook. Hier wat artikelen over de kracht van em-based responsive designs:

http://blog.cloudfour.com...tional-media-queries-ftw/
http://www.alwaystwisted....t-of-breakpoints-to-start
http://dmolsen.com/2013/0...-breakpoints-tweakpoints/
http://www.vanseodesign.c.../media-query-breakpoints/
http://www.netmagazine.co...kpoints-responsive-design

Motto: responsive design gebaseerd op *content*, niet op pixels of devices. Inmiddels zijn zowat alle high profile web designers die hiermee bezig zijn over op em-based designs.

Het klopt dat je niet veel sites in het wild ziet die dit doen (het 1e artikel laat het wel in screenshots zien). Er zijn ook veel sites die geen mobile-first aanpak hebben, terwijl dat toch echt de beste aanpak is. En er zijn nog veel meer sites die helemaal niet responsive zijn. Dit kan te maken hebben met budget en/of de nieuwheid van dit inzicht. RWD bestaat pas sinds 2010, en pas recent (2012) is em-based als idee opgekomen. De RWD wereld veranderd zeer snel. Wat in het begin logisch was, is nu een worst practice, en dit veranderd in rap tempo.

Voor nu ligt de fundamentele keuze bij jullie: een responsive design gebaseerd op content of op pixels/devices.

De keuze is niet zo zwaar als deze lijkt: switchen hiertussen is kinderspel. Onder de voorwaarde dat buiten de breakpoints units, jullie daadwerkelijke CSS geen pixel waardes bevat, want dat is not done in resposive design (hooguit in uitzonderlijke situaties).

[crisp]

Anoniem: 457607 schreef op donderdag 04 april 2013 @ 16:56:
[...]
De keuze is niet zo zwaar als deze lijkt: switchen hiertussen is kinderspel. Onder de voorwaarde dat buiten de breakpoints units, jullie daadwerkelijke CSS geen pixel waardes bevat, want dat is not done in resposive design (hooguit in uitzonderlijke situaties).

hmm, wie gaat dat vertellen aan onze designer?

[Anoniem: 457607]

Haha, ja daar was ik al bang voor. Erg begrijpelijk gezien het hier om een bestaande site gaat.

Je kunt bij pixels blijven. Het probleem is dan dat je pijn vermenigvuldigd. Het idee van breakpoint-specifieke CSS is dat het uitzonderingen beschrijft. Je hebt dus een vrij grote brei aan default styles die altijd van toepassing zijn. Echter, die worden deels overruled in de breakpoint CSS. Het is dus zaak om die breakpoint CSS klein te houden, je wilt niet 5 kopieen van de hele stijlset onderhouden.

Het gevaar bij gebruik van pixels is dat je wel in die situatie komt, omdat een pixel in de ene viewport niet in verhouding is met een andere viewport. Het gevolg is dus zeer expliciete harde pixel waardes onderhouden op meerdere plekken, en dat voor zeer veel styles.

Beter is het om percentages en/of ems te gebruiken. Die gelden dan over alle viewports, en alleen waar nodig schaaf je bij, als uitzondering.

Terugrekenen van pixels naar percentages of ems voor een individueel geval is eenvoudig, meestal slechts een deelsom. Echter, de totale omvang van zo'n klus kan fors zijn, dus je moet er goed over nadenken. Het is het kiezen tussen 2 soorten pijn: een vrij grote eenmalige pijn of een steeds terugkerende, zichzelf vermenigvuldigende pijn. Hoe groot die pijn is, kan ik niet beoordelen in jullie geval.

[Anoniem: 457607]

Overigens, mijn gezeur over relatieve units moet je zien als een pleidooi voor de "heilige graal" van web design: design volledig gebaseerd op content, en niet op devices of pixels. Je zou het de ideale situatie kunnen noemen.

Ik begrijp heel goed dat er praktische en commerciele afwegingen te maken zijn waardoor je soms een andere afslag neemt. Mijn doel is alleen om food for thought te bieden. Mijns inziens zijn dit namelijk de belangrijkste design decisions om te maken in een responsive design:

- De keuze voor een responsive of een adaptive design, of een mengvorm hiervan
- De keuze tussen pixel based of relatieve units in het design zelf
- De keuze tussen relatieve of absolute breakpoints (waarbij opgemerkt moet worden dat een pixel helemaal niet zo absoluut is als je misschien denkt)
- De daadwerkelijke keuze van breakpoints (waar leg je de snedes, waar precies, en zijn deze design-based of device-based)

Deze beslissingen hebben grote gevolgen voor het project, in tijd, kosten, onderhoudbaarheid, en aller belangrijkst: user experience.

[crisp]

Uiteraard spelen er nog wel meer zaken mee buiten dat je pixelprecisie echt moet gaan loslaten; zo zijn bijvoorbeeld advertenties altijd vaste formaten. En inderdaad; doordat we al een site hebben (en veel legacy met ons meezeulen) is het praktisch onmogelijk om van scratch af aan te beginnen, laat staan mobile-first toe te passen.

Dat is ook de reden dat ik het liefst eigenlijk voornamelijk kijk naar mogelijkheden om met bestaande markup en behaviour zo dicht mogelijk bij het beoogde doel kom. Dus feitelijk eigenlijk door alleen de presentatie-laag (CSS) aan te passen. Het alternatief is inderdaad een nog grotere onderhoudsnachtmerrie.

Ik zie nu al dat bijvoorbeeld de mogelijkheid om te kunnen kiezen voor 'compact' en 'cozy' grotendeels wordt 'vergeten' bij aanpassingen en nieuwe features. Feitelijk moet je straks elke wijziging nog 4x extra testen.

Ik denk inderdaad dat we hier intern nog een keer goed over moeten nadenken en niet rucksightloss deze POC (want dat is het) als uitgangspunt moeten gaan nemen

[JoostBaksteen]

Tot op heden heb ik dit topic voornamelijk geleeched en dat komt vooral omdat ik het moeilijk vind om hier een stelling over in te nemen.

Ik vind namelijk dat jullie beide goede argumenten hebben.

Op het moment dat je inzoomt om bijvoorbeeld een plaatje groter te kunnen zien, of om bepaalde tekst beter te kunnen lezen wil je gewoon dat dat plaatje groter wordt. Om dezelfde reden hebben we dit op mobile juist weer aangezet. Je wilt de gebruiker deze mogelijkheid gewoon niet ontnemen. Op een desktop omgeving vraag je er bij het inzoomen in principe ook niet om dat de content opeens anders weergegeven wordt.

Aan de andere kant kan dit wel een betere user experience opleveren. Op het moment dat je op de bank op wikipedia aan het browsen bent, zoals ze hier als voorbeeld geven, is dat bijna onmogelijk door de veel te kleine tekst. Dan wil je inzoomen om de tekst beter te kunnen lezen. Als je niks 'responsives' aan de layout doet, is er een grote kans dat de content buiten het scherm gaat lopen en dat je de content dus niet meer kan lezen zonder dat je moet gaan scrollen. Dit is momenteel het geval, zowel op tweakers.net als op tweakotine.nl

Als je inzoomt op het artikel wat ik net aanhaalde zie je dat de tekst beter leesbaar wordt en het plaatje ook groter wordt, maar de navigatie blijft ook bereikbaar (!) en ook de rightsidebar/relevancy column blijft zichtbaar, wat duidelijk een design keuze van ze is.

Op het moment dat je hier rekening mee kan houden kan je zowel de tekst als de plaatjes groter maken en de content toch binnen de viewport houden zodat alles zichtbaar blijft.

Ik vind het bij cloudfour toch best goed werken en wil hier toch wel even naar kijken hoe dit bij ons zou werken.

Overigens zijn we het volgens mij allemaal met je eens dat em's de betere weg is. Het is alleen erg lastig met een css vol pixels om dat in 1 keer om te zetten. Dat is praktisch gezien gewoon veel te veel werk. Wel maken we in de responsive css nu gebruik van em's en proberen we dat steeds vaker te gebruiken. Ook gebruiken we procenten waar dit mogelijk en toepasselijk is zodat alles beter schaalt, dus daar zitten we wel op een lijn.

Maar zoals je ook terecht opmerkt zijn er uiteraard praktische en commerciele afwegingen die een rol spelen. In de ideale situatie zou je de hele site 'mobile first' ontwikkelen en de grotere viewports daar 'bovenop' bouwen. Maar aangezien we al een site hebben die voor desktop geoptimaliseerd is gaat dat bij ons niet werken. We kunnen niet zomaar alle styling weggooien en 3 keer zo lang over dit project doen. Daarom is de 'holy grail' zoals je ook begrijpt niet altijd mogelijk, maar dat is nog geen reden om het niet (deels) na te streven en waar mogelijk wel te volgen.

[Anoniem: 457607]

Echt een leuke discussie dit, die de grootste vraagstukken van responsive design in de kern raakt. Een aantal reacties wederom:

- Volledig respect en begrip voor de legacy die hier een grote rol speelt.

- Eens dat je responsive design grotendeels met CSS moet doen. In mijn ervaring kom je bij een complex project daarmee zeker tot 80%, misschien 90%. Ikzelf gebruik javascript voor een aantal dingen: dynamisch showen/hiden van navigatie-opties, voor het laden van hi-res images voor high PPI schermen, voor dynamisch tekst truncaten op basis van de viewport. Server-side is responsive code af te raden. Ik gebruik het alleen om zware componenten die op mobile niet goed werken gewoon niet mee te sturen. In mijn geval is embedded Google maps daar een voorbeeld van, dat werkt voor geen meter op mobile.

- Of je die bestaande CSS gaat converteren naar in ieder geval zo weinig mogelijk pixel values zal denk ik een groot effect hebben op onderhoud. Ik begrijp dat het pijn doet, maar vrees dat het niet doen tot een grotere pijn zal leiden. Als ik het zo lees gaan jullie dit doen binnen de mogelijkheden die er zijn. Of het pijn doet is makkelijk te lezen: als jullie breakpoint-specifieke CSS uit de klauwen loopt, dan is er pijn, vooral toekomstige pijn.

- Over plaatjes zoomen: normaal gesproken zal em-based zoomen gewoon tot een groter plaatje en tekst leiden, alleen dit keer binnen een layout die niet groter wordt dan de browser window zelf. De vrees dat dingen onbereikbaar worden is onterecht: hooguit worden dingen anders bereikbaar, maar zelfs dat niet in de meeste gevallen.

- Over personalisatie-mogelijkheden zoals "cozy". Dit zijn mooie features, vanuit een gebruiker gezien. Maar ze voegen inderdaad een geheel nieuwe dimensie aan complexiteit toe. Ik weet dat tweakers mondig zijn en dit soort features vragen en waarderen, maar een risico is het zeker. Soms is nee zeggen tegen features die slechts weinig gebruikers bedienen het beste, maar makkelijk is dat allerminst.

Al met al is tweakers een prachtige case voor responsive design, een dergelijke grote site "ombouwen" is geen kinderspel, vele sites zitten in hetzelfde schuitje, en het is knap dat jullie het gewoon gaan doen. Nogmaals success!

[Bosmonster]

Leuke discussie idd mbt em-based zoomen. Ik vind het wat ver gaan om te zeggen dat het een "concensus is van pioniers dat dit best practice is". Voor zover ik weet is het een mening van een select gezelschap.

Persoonlijk ben ik het met crisp eens. De zoom-functie is een voorgedefinieerde browser functionaliteit en het is niet de bedoeling dat als een soort responsive toggle te gaan misbruiken. Een gebruiker verwacht simpelweg niet bij pinch zoomen dat de layout verandert. Je wijzigt/breekt de standaardmechanismen en ik zou het zelfs bad practice willen noemen in het meest extreme geval.

edit:
Voor desktop overigens (of niet-touch devices zonder pinch zoom) kan ik er beter mee leven, omdat het daar puur een toegankelijkheidskwestie is.

[ Voor 12% gewijzigd door Bosmonster op 05-04-2013 10:31 ]

[ormagon]

Als het responsive design goed is dan zal men in principe enkel zoomen om bijvoorbeeld een plaatje te willen vergroten. Mensen met slecht zich veranderen hun ppi om zaken zichtbaar te houden. Als ik zoom wil ik absoluut niet ineens dat mijn layout overhoop gaat.

[Anoniem: 457607]

@Bosmonster: Zoomen moet in een bredere context gezien worden dan een gebruiker die inzoomt. Een gebruiker die op de desktop 200% inzoomt heeft dezelfde viewport als een mobile/tablet user. Dat gaat tegen de intuitie van mensen in, maar het is wel zo. De viewport is gelijk, de beschikbare ruimte is gelijk. Als die 200% zoom tot een onwenselijke layout leid, betekent dat dus dat je mobile/tablet views ook niet goed zijn, en dan is je responsive design mislukt.

Ik merk soms de neiging om te stellen dat tablet en mobile views een achteruitgang zijn. Dat hoort niet zo te zijn. Het hoort nu juist een betere view te zijn voor de beschikbare ruimte. Een layout hoort ook niet "overhoop" te gaan, deze hoort beter te zijn voor die content grootte, anders is wederom je responsive design mislukt.

Maar goed, we agree to disagree. Niets mis mee.

[Bosmonster]

Daarom zit er een groot verschil tussen (meer permanent) zoomen op de desktop ivm toegankelijkheid en (het meer situationele) pinch-zoomen op een mobile device. Die dienen verschillende doelen en kun je mijns inziens niet over 1 kam scheren.

Wat de eerste betreft zijn de toegankelijkheidsrichtlijnen wat mij betreft duidelijk (dat de layout moet blijven werken bij grotere tekst en tekst niet onleesbaar moet worden, bijvoorbeeld doordat ie buiten een vlak valt). Dit laatste oplossen met RWD vind ik overigens een zeer interessante theorie

[ Voor 12% gewijzigd door Bosmonster op 05-04-2013 12:46 ]