Algemeen discussietopic over Responsive design

[Misha]

Centraal topic voor algemene discussie. Dit om zo de topics waar bugs in worden gemeld en/of zeer gerichte opmerkingen die uitmonden in wat grotere discussies te scheiden van onnodig blaat

[Hoite]

Het is mij niet helemaal duidelijk of algemene opmerkingen over het design of usability ook onder bugs worden verstaan en derhalve dus welkom zijn om gemeld te worden in dit forum.

Voorbeeld:

Hetgeen mij meteen opvalt is het lage resolutie logo van tweakers in de floatende bovenbalk.
Is zoiets een eigen topic waard of is het verstandiger om een apart topic te maken voor optische "storingen"?

PS. Plaatje is gehost in een hidden folder van het tweakers fotoalbum

[ Voor 14% gewijzigd door Hoite op 05-04-2013 13:57 ]

[Bosmonster]

Hoite schreef op vrijdag 05 april 2013 @ 13:44:

PS. Plaatje is gehost in een hidden folder van het tweakers fotoalbum

Dat betekent dat alleen jij hem kunt zien

Verder lijkt dit me een Retina-ding en daar was al een (gesloten) topic over
(Geen Retina/HiDPI ondersteuning)

[ Voor 8% gewijzigd door Bosmonster op 05-04-2013 13:51 ]

[Hoite]

Bosmonster schreef op vrijdag 05 april 2013 @ 13:50:
[...]


Dat betekent dat alleen jij hem kunt zien

<..>

Das niet zo handig, kan ik m net zo goed weghalen

Vraag blijft, wat te doen met optische "bugs/hikjes/storingen"?

[Misha]

Hoite schreef op vrijdag 05 april 2013 @ 13:44:
Het is mij niet helemaal duidelijk of algemene opmerkingen over het design of usability ook onder bugs worden verstaan en derhalve dus welkom zijn om gemeld te worden in dit forum.

Voorbeeld:

Hetgeen mij meteen opvalt is het lage resolutie logo van tweakers in de floatende bovenbalk.
Is zoiets een eigen topic waard of is het verstandiger om een apart topic te maken voor optische "storingen"?

PS. Plaatje is gehost in een hidden folder van het tweakers fotoalbum

Nee, ik vind opmerkingen over het design en usability geen bugs. Bugs zijn zaken die echt stuk zijn maar wel horen te werken. Daar mogen gewoon topics over gemaakt worden, zoals nu ook al door bijvoorbeeld Fledder is gedaan

[JoostBaksteen]

Ik ben vandaag bezig geweest met het implementeren van de retina images, dit zal naar alle waarschijnlijkheid dinsdag online komen

[ormagon]

Sowieso vind ik het leuk om de ontwikkelingen van Tweakers RWB te volgen, ik probeer de responsive versie zoveel mogelijk te gebruiken om de gebruikservaring zo goed mogelijk te kunnen vergelijken.

Wat me momenteel heel erg opvalt is dat op niveau D de ruimte tussen het nieuwsbericht en de reacties erg groot is, ik kan er in portrait mode meer dan anderhalf scherm mee vullen. Voorbeeld (rode en groene kaders zijn mijn viewport).

[Misha]

Dat ben ik helemaal met je eens. We hebben al bij de volgend/vorige artikelen al expres twee regels weggelaten (normaal staan er 4), maar naar mijn mening is dit nog niet genoeg. In jouw voorbeeld is het overigens nog minder extreem dan wanneer je bijvoorbeeld ook nog 'Prijzen' en 'V&A' er tussen hebt staan. In het absolute ergste geval kan er ook nog eens een gesponsorde link tussen staan, wat het nog verder van elkaar afzet. Dan is wel de Ads Door Google weg, maar is toch nog net iets hoger

Het weglaten van de commerciële elementen (Gesponsorde Link, Prijzen) zal niet lukken. Tevens wordt het lastig om de Onderwerpen weg te laten, want mensen gebruiken dit als ingang voor meer informatie over bijvoorbeeld Samsung. V&A mag wat mij betreft weg, maar dat wil ik eerst goed kunnen onderbouwen met cijfers. Over de social sharing hebben we het al gehad en we gaan kijken of we dat kunnen minimaliseren. Dan proberen we er van twee regels er een te maken.

Alles wat onder 'Reacties' staat heeft een redelijk grote marge, maar zorgt er wel voor dat alles goed klikbaar is. Ik weet niet of we dit makkelijk nog compacter kunnen maken

[ormagon]

Het zinnetje reactiefilter zou misschien weg kunnen op niveau D. Misschien kunnen bijvoorbeeld ook de knoppen van het reactiefilter zo aangepast worden dat het cijfer iets hoger staat in het kader waardoor het aantal dan zichtbare reacties daaronder in de knop passen (kan de hoogte van de knop misschien heel iets hoger), scheelt weer een regel. Je zou ook kunnen kijken of het zinnetje "Platte weergave - Sorteer aflopend - Faq" naast de kop "Reacties" te passen is. Misschien het afkappen met ... van het vorige en volgende onderwerp aan het einde van de eerste regel.

Het zijn wat willekeurige ideeën. Ik kan me voorstellen dat sommigen daarvan de werkbaarheid van niveau D zouden verkleinen, dat is natuurlijk niet de bedoeling, dan liever wat meer scrollen.

[ Voor 24% gewijzigd door ormagon op 05-04-2013 17:45 ]

[Bosmonster]

Voor niveau D kan een simpel skiplinkje naar de reacties ook al helpen misschien? Is wel een beetje een work-around natuurlijk en lost niet echt het probleem op, maar tenzij jullie bereid zijn heel veel weg te laten zie ik ook even geen andere oplossing

[Verwijderd]

Hoe zit het met reclame?

Ik kijk nu op mijn iPhone en krijg geen reclame.
Het lijkt mij dat dit in de uiteindelijke versie dit wel komt.

Maar nu kunnen we dit niet zien testen.
Niet dat het er zo mooi is en we er allemaal achter staan en dat door de reclame alles weer verandert.

Edit/

Daarnaast vindt ik de mobiele weergave helemaal niks.
Weer veel te veel wit. Te weinig informatie op het scherm.
Veel te grote video's bovenaan.

Ik zou hem als het de uiteindelijke versie zou zijn. Meteen op desktop zetten. Dan heb ik ook meteen de traker weer erbij.

[ Voor 34% gewijzigd door Verwijderd op 08-04-2013 12:18 ]

[Misha]

De tracker is een lastig punt maar maken we op den duur toegankelijk via de navigatie.

We denken hierbij zelf aan het volgende: https://www.dropbox.com/s...navigation-v2-tracker.png

De tracker is dan bereikbaar via de algemene navigatie

Wat betreft de 'video's' (wij noemen ze ankeilers); ik zat er zelf aan te denken om de titels voor de ankeilers iets over de images te plaatsen en de witruimte boven de ankeilers zo klein mogelijk te maken. Zo zorgen we ervoor dat er net wat meer headlines op de frontpage terugkomen.

Qua reclame moeten we nog kijken wat we precies gaan doen. De gehele advertentiemarkt draait zowat op Flash, en dat werkt niet bepaald voor smartphones en tablets. Wel kunnen er zaken als tekstlinks en advertorials verschijnen en die zullen verschijnen zodra we de testomgeving gaan koppelen met live data

[Misha]

Bosmonster schreef op maandag 08 april 2013 @ 10:27:
Voor niveau D kan een simpel skiplinkje naar de reacties ook al helpen misschien? Is wel een beetje een work-around natuurlijk en lost niet echt het probleem op, maar tenzij jullie bereid zijn heel veel weg te laten zie ik ook even geen andere oplossing

Ik heb het hier net met crisp over gehad en het leek ons sowieso praktisch om het aantal reacties weer op te nemen in de auteursregel onder de headline (dat wat in het grijs staat bij een nieuwsartikel, waar ook de views staan). Dan heb je bovenaan de pagina alvast een anchor naar de reacties. Vervolgens zouden we kunnen kijken of er onderaan het artikel eventueel ook direct een anchor kan komen naar de reacties. Momenteel is het bij een review al mogelijk om alle gerelateerde meta-informatie over te slaan door bij de inhoudsopgave op 'Reacties' te klikken, maar dan kunnen we ook telkens het onderaan de laatste pagina (over het algemene de conclusie) plaatsen. Dan kun je altijd op iedere (informatieve) pagina op dezelfde wijze doorskippen naar de reacties

[AmbroosV]

Is het geen idee om met Javascript wat te knutselen zodat de navigatiebalk verdwijnt bij het omlaag scrollen en terug zichtbaar is bij omhoog scrollen? Door zo'n fixed element op een pagina te zetten gaat scrollen op Android (zeker op goedkopere toestellen) een heel stuk trager, dit zou dat kunnen oplossen.

[Hooglander1]

Jullie willen op termijn ook over op een responsive design voor het forum. Dan is het in mijn ogen ook belangrijk om het icon beleid daarin mee te nemen. Door sommige animated gifs in de icons gaat mijn browser namelijk aardig over de zeik. Het scrollen gaat dan heel langzaam en de hele responsiveness is dan weg.

Ik gebruik dan Chrome browser @ HTC Sensation XE.

[Misha]

AmbroosV schreef op zaterdag 13 april 2013 @ 14:32:
Is het geen idee om met Javascript wat te knutselen zodat de navigatiebalk verdwijnt bij het omlaag scrollen en terug zichtbaar is bij omhoog scrollen? Door zo'n fixed element op een pagina te zetten gaat scrollen op Android (zeker op goedkopere toestellen) een heel stuk trager, dit zou dat kunnen oplossen.

Dat is een nette oplossing waar we wat later naar kunnen gaan kijken. Op de kleinere devices (een HTC Desire C bijvoorbeeld) zit de navigatie ook soms in de weg. Een dergelijke oplossing zou de uitkomst kunnen bieden. Ik ben alleen wat terughoudend op het extra toevoegen van javascript. Dat wil ik zoveel mogelijk beperken

Hooglander1 schreef op zaterdag 13 april 2013 @ 14:36:
Jullie willen op termijn ook over op een responsive design voor het forum. Dan is het in mijn ogen ook belangrijk om het icon beleid daarin mee te nemen. Door sommige animated gifs in de icons gaat mijn browser namelijk aardig over de zeik. Het scrollen gaat dan heel langzaam en de hele responsiveness is dan weg.

Ik gebruik dan Chrome browser @ HTC Sensation XE.

Ook op een XE? Ik heb dat tot nu toe alleen gemerkt op de echte simpele devices, zoals de bovenstaande Desire C. Imho mogen alle animated gifs sowieso weg. Afleidende bende is het!

[Hooglander1]

Misha schreef op zaterdag 13 april 2013 @ 14:41:
[...]


Dat is een nette oplossing waar we wat later naar kunnen gaan kijken. Op de kleinere devices (een HTC Desire C bijvoorbeeld) zit de navigatie ook soms in de weg. Een dergelijke oplossing zou de uitkomst kunnen bieden. Ik ben alleen wat terughoudend op het extra toevoegen van javascript. Dat wil ik zoveel mogelijk beperken


[...]


Ook op een XE? Ik heb dat tot nu toe alleen gemerkt op de echte simpele devices, zoals de bovenstaande Desire C. Imho mogen alle animated gifs sowieso weg. Afleidende bende is het!

Een 100 kB snel bewegende animated gif wordt nog steeds niet leuk gevonden inderdaad. Soms is de hosting ook nog eens heel traag, waardoor het laden ook nog weer eeuwig duurt. Webicons verbannen zou al heel wat zijn, maar misschien kunnen de icons ook weg op de C en D omgevingen.

[Misha]

Het afschaffen van webicons is sowieso nog een (interne) wens, maar ik wil niet de avatars zelf gaan verbergen. Avatars zijn een enorm goed hulpmiddel om posters te herkennen. Dat zomaar weggooien zou ik erg zonde vinden

[Hooglander1]

Helemaal ideaal zou dan zijn als je een static versie kan laten zien van de animated versie.

[ Voor 6% gewijzigd door Hooglander1 op 13-04-2013 15:39 ]

[Bundin]

Animated icons hebben imo geen plek op mobiele devices. Ze trekken een relatief gezien enorme wissel op de beperktere resources van niet high-end mobiele apparaten. Als het aan mij ligt gaan ze er helemaal uit. Het enige voordeel van usericons is herkenbaarheid en dat kan prima met statische plaatjes.

[ Voor 17% gewijzigd door Bundin op 15-04-2013 17:27 ]

[Misha]

Hooglander1 schreef op zaterdag 13 april 2013 @ 15:38:
Helemaal ideaal zou dan zijn als je een static versie kan laten zien van de animated versie.

Een static van een animated gifje haalt het hele idee van de avatar weg dan kunnen we beter de gehele animated gif dumpen. Dat zal wel wat weerstand hebben van de gebruikers met animated plaatjes. Sowieso hebben we intern nog wat discussie over het wel/niet toestaan van animated gifjes. De een vind het leuk, de ander storend

[ormagon]

Misha schreef op maandag 15 april 2013 @ 18:19:
[...]


Een static van een animated gifje haalt het hele idee van de avatar weg dan kunnen we beter de gehele animated gif dumpen. Dat zal wel wat weerstand hebben van de gebruikers met animated plaatjes. Sowieso hebben we intern nog wat discussie over het wel/niet toestaan van animated gifjes. De een vind het leuk, de ander storend

Ik gok, maar dat kan je uiteraard onderzoeken met bijvoorbeeld een poll, dat het percentage mensen dat een gif onprettig vindt groter is dan het percentage mensen dat er daadwerkelijk een voordeel aan heeft. Vind ze zelf in elk geval nogal 2002. Automatisch een static maken werkt uiteraard niet omdat je niet van tevoren weet welke frame van de gif wel, en welke niet representatief is.

Ik zie ze het liefst verdwijnen. Scheelt resources, onnodige drukte in beeld en bandbreedte.

[filenox]

GIF's zijn helemaal terug hip, kijk eens naar Cinemagram etc

Ik gok, maar dat kan je uiteraard onderzoeken met bijvoorbeeld een poll, dat het percentage mensen dat een gif onprettig vindt groter is dan het percentage mensen dat er daadwerkelijk een voordeel aan heeft.

Voeg dan ook maar de optie 'mij kan het niet veel schelen dus laat ze maar staan' toe

[ormagon]

filenox schreef op maandag 15 april 2013 @ 19:53:
GIF's zijn helemaal terug hip, kijk eens naar Cinemagram etc


[...]


Voeg dan ook maar de optie 'mij kan het niet veel schelen dus laat ze maar staan' toe

Uiteraard!, Ja/Nee is te beperkt. Cinemagram is geestig, en ik bedoel ook niet dat GIF helemaal overbodig is. Enkel als forum avatar lijken ze mij meer in de weg te zitten dan dat ze toevoegen.

[Misha]

Cinemagram is heel vet, maar daarbij is het juist de kunst om kleine elementen te animeren en iets te laten toevoegen aan de foto zelf. De core van een goede 'cinemagram' is een foto, niet een kort filmpje dat zich achter elkaar afspeelt. Dat wordt helaas wel een beetje gedaan

[JoostBaksteen]

Bosmonster schreef op maandag 08 april 2013 @ 10:27:
Voor niveau D kan een simpel skiplinkje naar de reacties ook al helpen misschien? Is wel een beetje een work-around natuurlijk en lost niet echt het probleem op, maar tenzij jullie bereid zijn heel veel weg te laten zie ik ook even geen andere oplossing

In de 'auteur header' van een nieuws/review/video etc artikel hebben we weer een linkje naar de reacties toegevoegd. Je kan nu dus weer in 1 keer van bovenaan door naar de reacties springen .

[alex3305]

Hoe kan ik trouwens makkelijk op mijn desktop testen op de mobiele versie van Tweakotine? Ik zie namelijk wat bugs terug op mijn telefoon, waar ik benieuwd ben of ik ze ook op desktop kan reproduceren.

[Bundin]

De reactiecount is niet herkenbaar als klikbaar/link. Misschien de volgorde omgooien (auteur, datum, views, reacties, feedback) en van reacties een duidelijke link maken net als Feedback dat is? (of schend ik nu tig design docs? )

[ Voor 8% gewijzigd door Bundin op 16-04-2013 15:20 ]

[Misha]

alex3305 schreef op dinsdag 16 april 2013 @ 15:15:
Hoe kan ik trouwens makkelijk op mijn desktop testen op de mobiele versie van Tweakotine? Ik zie namelijk wat bugs terug op mijn telefoon, waar ik benieuwd ben of ik ze ook op desktop kan reproduceren.

Je kunt je browser resizen

Bundin schreef op dinsdag 16 april 2013 @ 15:16:
De reactiecount is niet herkenbaar als klikbaar/link. Misschien de volgorde omgooien (auteur, datum, views, reacties, feedback) en van reacties een duidelijke link maken net als Feedback dat is? (of schend ik nu tig design docs? )

Dat hebben we expres gedaan. Ik vind het nu al eigenlijk een erg drukke zin. Allerlei kleuren versterkt dat alleen maar. Als dat uiteindelijk wel gewenst is, dan zouden we eigenlijk naar een andere oplossing moeten kijken.

[JoostBaksteen]

alex3305 schreef op dinsdag 16 april 2013 @ 15:15:
Hoe kan ik trouwens makkelijk op mijn desktop testen op de mobiele versie van Tweakotine? Ik zie namelijk wat bugs terug op mijn telefoon, waar ik benieuwd ben of ik ze ook op desktop kan reproduceren.

Gewoon je venster smaller maken, dan krijg je als het goed is gewoon de 'responsive' versie zoals je die ook op je telefoon krijgt

[alex3305]

Misha schreef op dinsdag 16 april 2013 @ 15:27:
[...]

Je kunt je browser resizen

That actually worked . Helemaal verbaasd en erg stoer .

[ormagon]

Een apart topic is wat overdreven, maar op niveau C & D zit er een witregel tussen twee zinnen als het gaat om een "verzamelnieuwtje" zoals Downloads en video's. Juist op dit niveau heb je een erg beperkte viewport en is dit wat nutteloos ruimtegebruik.

[Misha]

Klopt, daar moeten we nog een echte elegante oplossing voor verzinnen. Tips zijn welkom

[WoutF]

Geen bug, maar een opmerking. Is het wenselijk om de custom css ook op kleinere viewports in te zetten? Ik heb bijvoorbeeld een custom css die dingen wat compacter maakt als ik via de deskop kijkt, maar op mijn mobiel zorgt dat voor hele rare resultaten.

Op deze manier moeten gebruikers die custom css gebruiken hun aanpassingen ook responsive gaan maken.

[T.Struik]

So far so good,

Ik heb nu een tijdje Het RWD mogen ervaren en veel reacties gevolgd. Daarnaast een aantal bugs gezien die vrijwel allemaal zijn beschreven. Het RWD heb ik geprobeerd op diverse apparaten A, C, D (naar mijn idee dan). Bij de diverse grades staat een volgende beschrijving:

A: (bijvoorbeeld desktops, laptops en de grotere tablets in landscape)
B: (bijvoorbeeld grote tablets in portrait en middelgrote tablets in landscape)
C: (bijvoorbeeld middelgrote tablets in portrait en sommige high-reso telefoons in landscape)
D: (bijvoorbeeld (high & low-reso) smartphones in potrait & landscape)

waarbij B nog niet (geheel) geïmplementeerd is zoals te zien in het ‘Welkom testers’ topic. Tot dusver 3 puntjes:

1. Misschien een beetje pietluttig, maar wat ik mij afvraag is wat zijn nou inches en resoluties die onder de grades vallen? Nu heb ik het RWD uitgeprobeerd met de HTC One X+, HTC One SV, Sony Xperia S, Apple iPad mini en de Samsung Galaxy Note 10.1. Bij de telefoons werkte het RWD prima. Echter bij de tablets kwam ik gewoon op de ‘gewone’ Tweakers site zonder RWD. Toch lijkt mij dat één van de twee tablets onder C zou moeten vallen?

Locatie
Frontpage (maar ook elders)
Omschrijving
Volledige website wordt getoond, geen RWD stijl, ondanks dat ik denk dat minstens één van de twee apparaten onder één van de grades met bijghorende omschrijving past.
Platform
iOS 6.1, Android 4.1
Browser
Safari, Android standaard browser
Type apparaat
Apple iPad mini, Samsung Galaxy Note 10.1

2. Dit zal wellicht al opgevallen zijn en dat het nog niet aangepast is ook wel enigszins logisch, maar de frontpage staat beschreven als onderdeel van het PoC, maar onderaan kun je nog steeds de grades forceren conform het oude (device detect) systeem.

3. Verder geprobeerd eigen reviews (userreviews) te bekijken en te bewerken, wat niet in het PoC zit volgens mij (alleen redactionele reviews). Hier ondervond ik het eerder gemeldde probleem van de niet correct weergegeven tabellen.





Los van deze luttele puntjes werkte het RWD onder devicegrade D, waar de twee HTC’s en de Sony op werkten, erg goed en ben ik naast eerder genoemde punten nauwelijks tegen obstakels aangelopen. Waar ik alleen een kleine twijfel over heb is in hoeverre ‘echte’ Tweakers gebruik gaan maken van het RWD en niet forceren naar de desktopgrade met hun device. Hierdoor vraag ik mij ook af (mogelijk is het eerder gezegd?) wat de doelgroep is van het aanpassen naar het RWD? En wat mij nieuwsgierig maakt is hoeveel bijvoorbeeld door gebruikers gebruik wordt gemaakt van het huidige device detect en het forceren naar andere grades?

Los van deze bijzaken heb ik het RWD tot op heden als erg positief en op zichzelf staand goedwerkend ervaren .

[filenox]

Wie had dat gedacht, de website werkt zelfs redelijk goed op een iPhone 3G (iOS 3.1.3)

[MueR]

WoutF schreef op vrijdag 19 april 2013 @ 13:11:
Geen bug, maar een opmerking. Is het wenselijk om de custom css ook op kleinere viewports in te zetten? Ik heb bijvoorbeeld een custom css die dingen wat compacter maakt als ik via de deskop kijkt, maar op mijn mobiel zorgt dat voor hele rare resultaten.

Op deze manier moeten gebruikers die custom css gebruiken hun aanpassingen ook responsive gaan maken.

Ik zou de customcss niet gebruiken op de lagere grades idd. Dat breekt nogal in sommige gevallen.

[JoostBaksteen]

Om het targeten van custom css wat makkelijker te maken hebben we op de body nu de huidige devicegrade gezet.

Je kan nu dus dmv:

code:

body.gradeD #eenOfAnderElement { 
    [custom css hier voor grade D]
}
body.gradeC { 
    [custom css hier voor grade C]
}
body.gradeB,
body.gradeA {}

Je custom css toepassen.

Wat je al kon doen en wat natuurlijk nog steeds kan, is media queries gebruiken voor speciale targeting.

Als je alleen desktop wilt targeten kan je dit om je custom css heen zetten:

code:

@media only screen and (min-width: 800px) {
   [hier je desktop css]
}

Dan hoef je niet overal .gradeA voor te zetten

[Misha]

Dank voor het uitgebreide topic!

T.Struik schreef op vrijdag 19 april 2013 @ 16:01:

1. Misschien een beetje pietluttig, maar wat ik mij afvraag is wat zijn nou inches en resoluties die onder de grades vallen? Nu heb ik het RWD uitgeprobeerd met de HTC One X+, HTC One SV, Sony Xperia S, Apple iPad mini en de Samsung Galaxy Note 10.1. Bij de telefoons werkte het RWD prima. Echter bij de tablets kwam ik gewoon op de ‘gewone’ Tweakers site zonder RWD. Toch lijkt mij dat één van de twee tablets onder C zou moeten vallen?

Locatie
Frontpage (maar ook elders)
Omschrijving
Volledige website wordt getoond, geen RWD stijl, ondanks dat ik denk dat minstens één van de twee apparaten onder één van de grades met bijghorende omschrijving past.
Platform
iOS 6.1, Android 4.1
Browser
Safari, Android standaard browser
Type apparaat
Apple iPad mini, Samsung Galaxy Note 10.1

Ondanks dat de iPad Mini 7" is, en het naar mijn mening een mooie C moet zijn, vind Apple dat een iPad Mini een gelijkwaardig product is aan de normale iPads en het doet zich dus ook voor als een normale iPad De detectie daar is dus praktisch onmogelijk. De Samsung Galaxy Note 10.1 zou uiteindelijk in portrait op B landen en in landscape op A.

Mbt de iPad Mini: CSS3 media queries hebben een resolution attribute. De iPad Mini heeft een dpi van 163 en de iPad 2 132. Dat zou het al oplossen, ware het niet dat het attribuut niet beschikbaar is Webkit browsers op iOS . Tevens kun je niet terugvallen op device pixel ratio, omdat zowel de iPad 2 en de iPad Mini een waarde van 1 geven. Je zou nog met inches kunnen werken, maar in de CSS3 specificatie zeggen ze dat cm's/inches wellicht niet matchen met de daadwerkelijke fysieke afmeting. Ergo, no go! Ik hoop de grootheden van het web hier nog een oplossing voor gaan verzinnen.

2. Dit zal wellicht al opgevallen zijn en dat het nog niet aangepast is ook wel enigszins logisch, maar de frontpage staat beschreven als onderdeel van het PoC, maar onderaan kun je nog steeds de grades forceren conform het oude (device detect) systeem.

Het onderdeel qua device grade forceren zit dan nog weer _niet_ in de PoC

3. Verder geprobeerd eigen reviews (userreviews) te bekijken en te bewerken, wat niet in het PoC zit volgens mij (alleen redactionele reviews). Hier ondervond ik het eerder gemeldde probleem van de niet correct weergegeven tabellen.

[afbeelding]

[afbeelding]

Deze pagina's zitten ook nog niet in de proof of concept en is nog helemaal niet naar gekeken. Dus het is logisch dat de weergave daar van nog niet optimaal is

Los van deze luttele puntjes werkte het RWD onder devicegrade D, waar de twee HTC’s en de Sony op werkten, erg goed en ben ik naast eerder genoemde punten nauwelijks tegen obstakels aangelopen. Waar ik alleen een kleine twijfel over heb is in hoeverre ‘echte’ Tweakers gebruik gaan maken van het RWD en niet forceren naar de desktopgrade met hun device. Hierdoor vraag ik mij ook af (mogelijk is het eerder gezegd?) wat de doelgroep is van het aanpassen naar het RWD? En wat mij nieuwsgierig maakt is hoeveel bijvoorbeeld door gebruikers gebruik wordt gemaakt van het huidige device detect en het forceren naar andere grades?

Ik weet niet de exacte cijfers over het gebruik van de device detectfunctie, maar ik vind het aannemelijk dat het op dit moment amper tot niet gebruikt wordt. Het zit nu erg verstopt (volgens mij moet je zelfs de url raden ). Maar desalniettemin vind ik wel dat je de gebruiker zelf moet laten bepalen in welke grade hij wil zitten, helemaal als je bepaalde zaken gaat weghalen/anders presenteren. Wat betreft in hoeverre de 'echte tweaker' het gaan gebruiken en niet direct grade A gaan forceren; dat is erg lastig om te zeggen (sowieso verwacht ik zodra we het gaan releasen wel weer flink wat kritiek dat "we het zomaar door de strot heen duwen"). Sowieso hanteert volgens mij iedereen een eigen definitie van de 'echte Tweaker'. Er wordt al wel jaren geschreeuwd om een goede toegankelijkheid van onze content via mobile devices; een RWD biedt hiervoor een mooie oplossing. Dat is ook direct de reden waarom we al zo vroeg een selectie van onze bezoekers hebben aangehaakt en ik wil de groep in de komende weken alsmaar gaan uitbreiden.

Los van deze bijzaken heb ik het RWD tot op heden als erg positief en op zichzelf staand goedwerkend ervaren .

Dat vind ik echt geweldig om te horen!

[Verwijderd]

"Ondanks dat de iPad Mini 7" is, en het naar mijn mening een mooie C moet zijn, vind Apple dat een iPad Mini een gelijkwaardig product is aan de normale iPads en het doet zich dus ook voor als een normale iPad"

Alle iPad modellen, mini of niet, Retina of niet, hebben dan ook dezelfde CSS software pixels. Een iPad mini doet zich niet voor als een gewone iPad, ze hebben gewoon dezelfde pixels gemeenschappelijk, en dat triggert de media query. Een retina iPad heeft 2 keer zoveel breedte aan hardware pixels, maar aangezien iOS dit terugschaalt, blijven het dezelfde software pixels.

Je hebt gelijk dat dit irritant is, en het zou handig zijn als het responden op basis van fysieke grootte mogelijk zou zijn, maar nu is dat nog niet zo. Dat betekent automatisch dat het responden op viewport width een zeer onbetrouwbare manier is om een device categorie te detecteren.

En daarmee kom ik weer terug op mijn pleidooi van een ander draadje: maak een proportioneel design en vergeet devices. Als je design goed is, krijgt het apparaat de layout die het aankan, ongeacht welke dat is. Het is even wennen om dat los te laten.

Overigens is het alternatief niet per se slecht, maar eigenlijk is dat een adaptive design.

[filenox]

Een nieuw topic openen lijkt me wat overbodig dus bij deze: is er een idee wanneer dit wordt gefixed: http://tweakotine.nl/nieuws/list/20130501? Op C en D devices krijg ik een witte pagina

[Misha]

filenox schreef op donderdag 02 mei 2013 @ 13:19:
Een nieuw topic openen lijkt me wat overbodig dus bij deze: is er een idee wanneer dit wordt gefixed: http://tweakotine.nl/nieuws/list/20130501? Op C en D devices krijg ik een witte pagina

Ik krijg hier wel een gewone pagina, maar moet nog wel eerst weer inloggen. Waarschijnlijk vanwege een filmpje dat op de pagina staat. Heb je ook nog een inlogscherm of blijft het gewoon helemaal wit?

[filenox]

Ik krijg dit te zien (zowel op G Nexus als in Chrome op de desktop)



(+ ik ben ingelogd maar als ik uitlog blijft het probleem bestaan)

[ Voor 13% gewijzigd door filenox op 02-05-2013 17:51 ]

[JoostBaksteen]

Hmmm ik heb hetzelfde op mijn nexus 4, ik had het nog niet gezien, maar dit gaan we uiteraard fixen

Vandaag hebben we ook de navigatie aangepast. De menus hebben nu een animatie maar de keerzijde is dat de navigatie nu niet altijd zichtbaar meer is. Het bleek vrijwel onmogelijk te zijn om de combinatie van altijd zichtbare (fixed) navigatie met de animaties op alle devices werkend te krijgen.

Vooral oudere stock android browsers op bv een htc desire s, of een bepaalde experia bleken veel problemen te geven. Daarom hebben we er nu voor gekozen om (iig tijdelijk) de navigatie niet altijd in beeld te houden zodat he op alle devices gewoon goed werkt.

We zijn echter erg benieuwd hoe jullie deze nieuwe navigatie ervaren en horen graag jullie bevindingen.

[JoostBaksteen]

filenox schreef op donderdag 02 mei 2013 @ 13:19:
Een nieuw topic openen lijkt me wat overbodig dus bij deze: is er een idee wanneer dit wordt gefixed: http://tweakotine.nl/nieuws/list/20130501? Op C en D devices krijg ik een witte pagina

Fixed

[WoutF]

Hmm, dat was me inderdaad al opgevallen. Moet zeggen dat ik het heel fijn vond dat ik na het lezen van een lange reactiethread met een tik op de balk weer naar de FP of het menu kon. Dat mis ik nu wel.

[Misha]

Daar hebben we het zelf ook veel over gehad. Aan de ene kant is het erg praktisch om altijd de navigatie bij de hand te hebben. Het liefst heb ik dat ook op A . Aan de andere kant zorgt een fixed header (of iig alle fixed dingen) voor problemen op Android als mensen gaan pinchen om te zoomen. Een fixed item schaalt dan namelijk gewoon mee (en kreeg je een gi-gan-tische header). Dat lijkt mij een bug in de browser en hopelijk fixen ze dat. Tevens is met het wegvallen van de fixed header ook de navigatie op de wat crappiere Android telefoons (de Xperia P bijv) goed geworden. Voorheen was het niet echt mogelijk om te navigeren op dergelijke telefoons. Een leuke plus is dat er nu wat animatie in zit, waardoor het duidelijker is wat er aan het gebeuren is.

Hopelijk zorgen de goden van Android er ook voor dat je net als op iOS met een tap direct naar de bovenkant van de pagina kan gaan. Dat verlaagt het leed al een beetje. Opzich kun je ook met de back-knop van de browser zelf terug naar de frontpage, met als voordeel dat je land ter hoogte van waar je was gebleven. Dat heb je niet als je via de navigatie gaat

[JoostBaksteen]

Ik mis die knop zelf ook, vooral op het forum of bij veel reacties moet je echt heel veel terug scrollen.

In het forum en vooral in lange topics als deze mis ik ook een 'jump to new post' knop. Als ik dit topic open op mijn telefoon moet ik ook erg veel naar beneden scrollen en vervolgens weer naar boven.

Ok, de back knop moet ik vaker gaan gebruiken nu, maar dat is toch niet intuitief ofzo.

[WoutF]

Hoe staat het eigenlijk met de custom scrollbar code? is die al af? Vind het horizontaal scrollen door de ankeilers namelijk nog niet heel lekker gaan.

[Misha]

Aan de custom scrollbar wordt nog steeds gewerkt, het is een lastig iets om helemaal goed te krijgen op alle devices. We zullen nooit voor alle devices alle haperingen er uit krijgen, het moet dan iig op een acceptabel niveau werken. Voor de ankeilers gaat het sowieso nog mogelijk worden om met behulp van knoppen er doorheen te navigeren.

[WoutF]

Het gaat mij niet zozeer om haperingen, het emuleert gewoon niet wat ik gewend ben in dit soort interfaces. Als ik mijn vinger op de tweede ankeiler leg, en dan langzaam naar links veeg, verwacht ik dat de ankeilers meescrollen. Alsof het geheel vastgeplakt zit aan mijn vinger.

Dat gebeurt echter niet. De enige manier hoe ik kan scrollen is door een zwieper te geven, waarna ze met een snelheid gaan scrollen die redelijk random lijkt.

[Misha]

Op alle devices die ik hier heb werkt het gewoon zoals je beschrijft en hoef ik geen flinke zwieper te geven. Op welke test je?

-edit-

Hmmm, na nog meer heen en weer gescroll merk ik dat het niet altijd direct reageert en af en toe verspringt. Vreemd dat ik het 5 minuten geleden niet had

[ Voor 40% gewijzigd door Misha op 31-05-2013 11:51 ]

[WoutF]

Misha schreef op vrijdag 31 mei 2013 @ 11:49:
Op alle devices die ik hier heb werkt het gewoon zoals je beschrijft en hoef ik geen flinke zwieper te geven. Op welke test je?

-edit-

Hmmm, na nog meer heen en weer gescroll merk ik dat het niet altijd direct reageert en af en toe verspringt. Vreemd dat ik het 5 minuten geleden niet had

Nexus 4 met Chrome stable

[JoostBaksteen]

Het is inderdaag nog niet wat je verwacht. Ook als je wel een zwieper geeft gaat het nog niet net zo als het native is. Dit is inderdaad nog een verbeter punt.

Wel zouden ze custom scrollbars het nu functioneel weer moeten doen, maar ik ben het met je eens dat de experience nog verbeterd kan worden, het 'voelt' nog niet helemaal lekker.

[Rafe]

Misha schreef op zaterdag 04 mei 2013 @ 16:51:
Aan de andere kant zorgt een fixed header (of iig alle fixed dingen) voor problemen op Android als mensen gaan pinchen om te zoomen. Een fixed item schaalt dan namelijk gewoon mee (en kreeg je een gi-gan-tische header).

Maar met een responsive design is dat toch praktisch niet meer nodig?

Gewoon nieuwsgierig: wordt de reactiewergave op de FP opgepakt binnen het responsive-project of gaat dat los gebeuren?

[crisp]

JoostBaksteen schreef op vrijdag 31 mei 2013 @ 19:59:
Het is inderdaag nog niet wat je verwacht. Ook als je wel een zwieper geeft gaat het nog niet net zo als het native is. Dit is inderdaad nog een verbeter punt.

Wel zouden ze custom scrollbars het nu functioneel weer moeten doen, maar ik ben het met je eens dat de experience nog verbeterd kan worden, het 'voelt' nog niet helemaal lekker.

De vraag is of het echt wel verbeterd kan worden; volgens mij lopen we simpelweg tegen de limitaties aan van de browserperformance (en dan met name op Android)

Rafe schreef op zaterdag 01 juni 2013 @ 10:29:
[...]
Gewoon nieuwsgierig: wordt de reactiewergave op de FP opgepakt binnen het responsive-project of gaat dat los gebeuren?

Nog 3 nachtjes slapen en je zal het zien

[filenox]

crisp schreef op zaterdag 01 juni 2013 @ 10:33:
[...]

De vraag is of het echt wel verbeterd kan worden; volgens mij lopen we simpelweg tegen de limitaties aan van de browserperformance (en dan met name op Android)


[...]

Nog 3 nachtjes slapen en je zal het zien

Ik geef je 3 minuten

Wat bedoel je trouwens met die browserperformance? Javascript, nee toch?

[crisp]

filenox schreef op zaterdag 01 juni 2013 @ 12:30:
[...]
Wat bedoel je trouwens met die browserperformance? Javascript, nee toch?

Jawel, voornamelijk de snelheid van het afhandelen van touch events in javascript en de snelheid van animaties en transities (waar we voor webkit CSS3 voor gebruiken). Het is echt nog suboptimaal allemaal, vooral onder Android.

[Bundin]

Ik heb niet zoveel issues met de verdwijnende rode balk, back werkt prima en zo vaak wil ik niet terug omhoog. Daarnaast is meer bruikbare scherm real estate altijd goed. Een kleine semi-transparante 'back to top' knop ergens rechtsonderin zou misschien wel handig zijn voor diegenen die dat willen. Mogelijk aan/uit te zetten in opties (standaard uit).

Verder zie ik (in ieder geval op D) liever minder dan meer animaties. Ik heb liever snappy en onmiddellijke verwerking van mijn input zodat ik meteen door kan dan een mooi wegschuivend paneeltje. Er moet soms al genoeg gewacht worden op telefoons

Als laatste zie ik nog steeds graag iets van visuele feedback als ik een van de twee knoppen op de rode balk aanklik. Iets van shadow zodat ie licht verzonken lijkt geeft aan dat nog eens daar klikken/tappen het menu of de tracker weer sluit.

[Misha]

Bundin schreef op zaterdag 01 juni 2013 @ 19:07:
Ik heb niet zoveel issues met de verdwijnende rode balk, back werkt prima en zo vaak wil ik niet terug omhoog. Daarnaast is meer bruikbare scherm real estate altijd goed. Een kleine semi-transparante 'back to top' knop ergens rechtsonderin zou misschien wel handig zijn voor diegenen die dat willen. Mogelijk aan/uit te zetten in opties (standaard uit).

Ik speel nog met het idee voor navigatiehulpmiddelen onderaan de pagina te zetten. Sommige websites bieden nogmaals de complete navigatie aan bij de footer; dat vind ik net wat te ver gaan. Maar een kleine back-to-top zou niet mis zijn, maar die zou ik dan niet willen laten meescrollen. Dat lijkt mij heel erg storend worden..

Verder zie ik (in ieder geval op D) liever minder dan meer animaties. Ik heb liever snappy en onmiddellijke verwerking van mijn input zodat ik meteen door kan dan een mooi wegschuivend paneeltje. Er moet soms al genoeg gewacht worden op telefoons

Dit ben ik met je eens. Imho moet een animatie iets toevoegen aan de ervaring, in plaats van een ervaring zijn op zich. Bij ons menu hebben we een kleine vlugge animatie wat ik zeer welkom vind; gebruikers weten dat de website iets naar rechts is geplaatst zodat het menu getoond kan worden. De gebruiker zal weten waar hij zit.

Voor onze categorieboom op bijvoorbeeld de Pricewatch portal willen we ook een kleine animatie toevoegen om de gebruiker een idee te geven wat er gebeurt. Als we dit niet doen, dan zal dat voor de novice gebruiker alleen maar verwarrend zijn.

Als laatste zie ik nog steeds graag iets van visuele feedback als ik een van de twee knoppen op de rode balk aanklik. Iets van shadow zodat ie licht verzonken lijkt geeft aan dat nog eens daar klikken/tappen het menu of de tracker weer sluit.

Dit staat nog op het lijstje; ik wil de knoppen in onze menu nog wat gaan aanpassen maar het heeft momenteel een lagere prioriteit dan bijvoorbeeld een goed werkend forum

[Bundin]

Misha schreef op donderdag 13 juni 2013 @ 15:57:
[...]


Ik speel nog met het idee voor navigatiehulpmiddelen onderaan de pagina te zetten. Sommige websites bieden nogmaals de complete navigatie aan bij de footer; dat vind ik net wat te ver gaan. Maar een kleine back-to-top zou niet mis zijn, maar die zou ik dan niet willen laten meescrollen. Dat lijkt mij heel erg storend worden..

Het probleem, zeker op telefoon + D, is dat reactiethreads soms tientallen schermen lang zijn. Als je middenin zit en het wel gelooft met de discussie ben je nog nergens met een knop onderaan. Dan zullen de meesten alsnog op Back drukken om er weer uit te komen, dus of het echt een probleem is weet ik niet. Maar een aan/uitzetbare meescrollende kleine transparante (you get the idea) geeft iedereen opties. Is wel weer optie-bloat...

[Misha]

En optie-bloat wil ik juist zoveel mogelijk voorkomen

Wellicht dat we, als we het heel vaak horen, het aantal reacties per pagina moeten laten afnemen. Dat zou het ook al enigzins oplossen

[crisp]

Misha schreef op vrijdag 14 juni 2013 @ 12:48:
En optie-bloat wil ik juist zoveel mogelijk voorkomen

Wellicht dat we, als we het heel vaak horen, het aantal reacties per pagina moeten laten afnemen. Dat zou het ook al enigzins oplossen

'aantal reacties per pagina' bestaat niet op de frontpage, alleen het aantal threads is in te stellen. Feitelijk heb je dus geen controle over het aantal reacties dat getoond wordt.

[filenox]

Is het eigenlijk mogelijk om met de 'back-knop' in Android de afbeeldingsviewer te sluiten?
Dat zou imho veel natuurlijker werken dan met het sluit-knopje rechtsboven

[Misha]

Ik zou niet weten of dat mogelijk zou zijn, maar ik zou dat zelf verwarrend vinden. De image viewer is eigenlijk een pop-up. De backknop sluit geen vensters; het zorgt er alleen voor dat je naar een vorig venster kan gaan. Dat standaard gedrag zou je dan aanpassen

[Hooglander1]

Gaat de sluiting van tweakotine ook leiden naar dat er meer zaken geimplementeerd zijn?

Zoals een prettige Active Topics layout bijvoorbeeld?

Dat weerhoud mij er tot nu toe van om het echt dagelijks te gebruiken eigenlijk.

[Misha]

Nee, we hebben nog amper tot geen aandacht kunnen besteden aan het forum helaas. Dat is wel een van de eerdere zaken die ik weer wil gaan oppikken De eerste schetsen zijn ondertussen al klaar

[WoutF]

Betekent de sluiting van Tweakotine ook dat de updates en fixes alleen met de normale iteratie meekomen? Vond het op Tweakotine wel fijn dat dingen meteen gecommit werden

[filenox]

Nu ik nog kan posten maak ik er maar gebruik van: wat is het praktisch nut van die pijlen op de review-artikelen? Qua functionaliteit voegt het niets toe & qua design ziet het er wat minder strak uit imho.

[Misha]

WoutF schreef op maandag 17 juni 2013 @ 15:41:
Betekent de sluiting van Tweakotine ook dat de updates en fixes alleen met de normale iteratie meekomen? Vond het op Tweakotine wel fijn dat dingen meteen gecommit werden

Yep het is voor development praktischer om het gelijk te laten lopen met .net. We hebben daarnaast nog wel een testomgeving waar we indien nodig wat kunnen showcasen.

filenox schreef op woensdag 19 juni 2013 @ 17:52:
Nu ik nog kan posten maak ik er maar gebruik van: wat is het praktisch nut van die pijlen op de review-artikelen? Qua functionaliteit voegt het niets toe & qua design ziet het er wat minder strak uit imho.

[afbeelding]

Ik ben niet tevreden met het huidige design van de pijlen. Ik denk zelf dat pijlen zoals deze beter passen: https://copy.com/ZwJPnHNaMf310xK2

Het praktische nut is dat devices die stronttraag erg slecht om kunnen gaan met (horizontaal) scrollen. In sommige gevallen wordt het zelfs niet gedetecteerd. De pijlen zorgen ervoor dat zij alsnog naar links/rechts kunnen gaan. Op de testomgeving staat al een andere implementatie klaar waarbij de pijlen enkel getoond worden als je ze ook daadwerkelijk kunt gebruiken. Dit in combinatie met de andere pijlen die ik net stuurde hebben we denk ik een prima oplossing waarbij de pijlen er niet te dik bovenop liggen

[Relief2009]

Misha schreef op maandag 24 juni 2013 @ 10:06:
[...]


Yep het is voor development praktischer om het gelijk te laten lopen met .net. We hebben daarnaast nog wel een testomgeving waar we indien nodig wat kunnen showcasen.


[...]


Ik ben niet tevreden met het huidige design van de pijlen. Ik denk zelf dat pijlen zoals deze beter passen: https://copy.com/ZwJPnHNaMf310xK2

Het praktische nut is dat devices die stronttraag erg slecht om kunnen gaan met (horizontaal) scrollen. In sommige gevallen wordt het zelfs niet gedetecteerd. De pijlen zorgen ervoor dat zij alsnog naar links/rechts kunnen gaan. Op de testomgeving staat al een andere implementatie klaar waarbij de pijlen enkel getoond worden als je ze ook daadwerkelijk kunt gebruiken. Dit in combinatie met de andere pijlen die ik net stuurde hebben we denk ik een prima oplossing waarbij de pijlen er niet te dik bovenop liggen

Is het ook de bedoeling dat je met touch kunt swipen. Het gaat niet bepaald lekker met de Lumia 920. Ik kom vaak onbedoeld in een item. Als het swipen met touch lekker gaat, dan heb je de knoppen totaal niet nodig.

Ook het uit en insliden van het linker en rechtermenu gaat schokkerig op de Lumia 920.

[ Voor 18% gewijzigd door Relief2009 op 25-06-2013 17:32 ]

[Misha]

Nee, dat is een bekende bug die we nog moeten gaan fixen. Ik merkte het op onze eigen testdevices ook

[Barryvdh]

De forum weergave is trouwens ook een beetje irritant nog op mobiel. Ik neem aan dat er nog niks aan gedaan is, maar de tabs bovenin staan nu onder elkaar (2 langs elkaar) en kan ik niet op klikken (My React, Actieve topics etc)

[Misha]

Er is nog helemaal niks gedaan aan het forum, behalve dat JoostBak het even vlug 'bruikbaar' heeft gemaakt in een paar minuten. Ik hoop in de komede iteratie aan de slag te kunnen met een juiste weergave voor de smartphone!

[Barryvdh]

Ja ok, maar de knoppen zijn nu dus niet bruikbaar: http://imgur.com/M45aeuA

[Misha]

Daarom staat het ook tussen aanhalingstekens uiteindelijk wil ik de tabjes in een dropselector hebben zodat ze weinig ruimte innemen maar wel altijd toegankelijk zijn

[AllSeeyinEye]

Over screen real estate, de wel of niet permanent getoonde header. Google Currents heeft hiervoor een hele nette oplossing. Zolang je naar beneden scrollt is de header onzichtbaar. Maar zodra je terug naar boven scrollt, komt de header terug in beeld. De header scrollt dus onzichtbaar mee en de zichtbaarheid wordt getriggerd door een beweging naar boven. Wellicht dat zoiets mogelijk is? Zou ook op de desktop mijns inziens wel prettig zijn, trouwens.

Verder ervaar ik de al genoemde problemen met scrollen doordat de reacties genest zijn. Het beeld schuift constant naar links en rechts om de reacties zichtbaar te krijgen, en dat onderbreekt de scroll up/down bewegingen.

Ik gebruik overigens de standaard browser van een Galaxy SII, Android 4.1.2

[filenox]

AllSeeyinEye schreef op woensdag 17 juli 2013 @ 07:39:
Over screen real estate, de wel of niet permanent getoonde header. Google Currents heeft hiervoor een hele nette oplossing. Zolang je naar beneden scrollt is de header onzichtbaar. Maar zodra je terug naar boven scrollt, komt de header terug in beeld. De header scrollt dus onzichtbaar mee en de zichtbaarheid wordt getriggerd door een beweging naar boven. Wellicht dat zoiets mogelijk is? Zou ook op de desktop mijns inziens wel prettig zijn, trouwens.

Verder ervaar ik de al genoemde problemen met scrollen doordat de reacties genest zijn. Het beeld schuift constant naar links en rechts om de reacties zichtbaar te krijgen, en dat onderbreekt de scroll up/down bewegingen.

Ik gebruik overigens de standaard browser van een Galaxy SII, Android 4.1.2

Bedoel je niet Google Plus ipv Currents?

[AllSeeyinEye]

filenox schreef op donderdag 18 juli 2013 @ 12:09:
[...]


Bedoel je niet Google Plus ipv Currents?

Lol, ik grijp nu 3x in het luchtledige om te kijken of Plus het ook zo doet, voordat ik me bedenk dat mijn telefoon netjes aan de lader ligt. Op het aanrecht. Thuis...

Maar ik bedoel sowieso Currents. Wellicht ook Plus.

[Misha]

AllSeeyinEye schreef op woensdag 17 juli 2013 @ 07:39:
Over screen real estate, de wel of niet permanent getoonde header. Google Currents heeft hiervoor een hele nette oplossing. Zolang je naar beneden scrollt is de header onzichtbaar. Maar zodra je terug naar boven scrollt, komt de header terug in beeld. De header scrollt dus onzichtbaar mee en de zichtbaarheid wordt getriggerd door een beweging naar boven. Wellicht dat zoiets mogelijk is? Zou ook op de desktop mijns inziens wel prettig zijn, trouwens.

Verder ervaar ik de al genoemde problemen met scrollen doordat de reacties genest zijn. Het beeld schuift constant naar links en rechts om de reacties zichtbaar te krijgen, en dat onderbreekt de scroll up/down bewegingen.

Ik gebruik overigens de standaard browser van een Galaxy SII, Android 4.1.2

Google Currents is er enkel in app-vorm toch? Dat is geen web app? Ik weet niet of het tonen van de navigatie enkel wanneer je omhoog scrollt schaalbaar is (dan bedoel ik niet dat hij de juiste width pakt, maar schaalbaarheid als in ondersteuning op allerlei soorten apparaten). Ook voor WP en in de toekomst FF OS etc zou de navigatie altijd makkelijk toegankelijk moeten zijn bijvoorbeeld.

Worden de reacties wel juist geschaald bij je? Eindigt het kader bijvoorbeeld wel gewoon en staat er ergens in de reacties bijvoorbeeld een lang woord of URL?

[Xesxen]

Ik merk dat mijn custom CSS voor de normale site TRD sloopt. Is het mogelijk om custom CSS op TRD uit te zetten?

[Alex]

Heb dat ook... Nu ff zonder Henk .

[JoostBaksteen]

Xesxen schreef op vrijdag 26 juli 2013 @ 13:40:
Ik merk dat mijn custom CSS voor de normale site TRD sloopt. Is het mogelijk om custom CSS op TRD uit te zetten?

Nee, dat kan niet. Wel kan je je custom CSS zo aanpassen dat ze alleen de 'normale' site targetten zodat de rules TRD niet meer beïnvloeden, of juist andersom. Zie mijn post eerder in deze thread hoe je dat kan doen.

[ Voor 0% gewijzigd door crisp op 28-07-2013 23:25 . Reden: linkje gefixed ;) ]

[JohnVanZetten]

Eerste indruk: erg tof gedaan. Geen bug, wel iets wat ik lelijk vindt: bij de gegroepeerde items op de frontpage als meuk-updates en video's, staat het "en X andere X" in een hele losse regel, terwijl het op de desktop wel als 1 regel staat. Ik kan me voorstellen dat het technisch lastig is om het in 1 regel te krijgen, maar voor een consistente ervaring en een overzichtelijke lijst is het wel net zo chique.

Is het ook mogelijk om de menubalk/tracker te laten verschijnen/verbergen als er op een touch-screen van links naar rechts resp. rechts naar links wordt geswyped?

[ Voor 16% gewijzigd door JohnVanZetten op 26-07-2013 15:44 ]

[Misha]

Wat betreft de gebundelde artikelen geef ik je helemaal gelijk. Ik ben daar nog niet tevreden over. Ik heb er al een paar ideeën voor maar ik wacht even op wat andere dingen voordat ik ze uitwerk.

Het swipen hebben we even gehad, maar bracht fors wat problemen met zich mee. Ik zou het nog wel graag zien overigens. We moeten eens een balans opmaken met zaken die we graag willen, wat dat stuk maakt en of we daar mee willen leven.

Tof dat de eerste indruk al goed is en thanks voor de input!

[AllSeeyinEye]

Wat waren de swipe to open menu problemen dan? Want in de huidige opmaak zitten her geen horizontale swipe acties verstopt. Ik kan me voorstellen dat het een probleem opleverde in de oude geneste weergave, zonder een rechter kantlijn die voor alle posts gelijk was.

[crisp]

AllSeeyinEye schreef op vrijdag 26 juli 2013 @ 16:33:
Wat waren de swipe to open menu problemen dan? Want in de huidige opmaak zitten her geen horizontale swipe acties verstopt. Ik kan me voorstellen dat het een probleem opleverde in de oude geneste weergave, zonder een rechter kantlijn die voor alle posts gelijk was.

Het algemene probleem met het afhandelen van dingen als swipe in javascript mbv touch-events is een catch-22:

1) als je naast dergelijke custom behaviour ook dingen als native scrolling en zoom e.d. wil blijven ondersteunen dan kan je de touchstart handler niet de native action laten cancellen.
2) als je de native action niet cancelled zit je met een behoorlijk irritante vertraging voor de eerste aanroep van touchmove na touchstart waardoor de 'swipe' niet bepaald 'responsive' is.
3) als je de native action op touchstart wel cancelled komt het er feitelijk op neer dat je alles zelf moet gaan implementeren, van page-scrolling tot afhandelen van clicks e.d. (zelfs op gewone links)
4) 3) opent weer een pandora's box vol met vage bugs in de tienduizend verschillende webkit varianten die er in het wild zijn, performance problemen op oudere en low-end devices, grote verschillen in de javascript touch-interface tussen bv webkit-based browsers en IE op windows phone etcetera.

ergo: het is niet makkelijk sterker nog; ik vind persoonlijk dat de mobiele browsers op dit punt gewoon nog steeds keihard falen. Deze situatie is nog 10 keer erger dan toen we enkel nog met oude IE's en Netscape opgescheept zaten

[hylke94]

Jammer dat het voor devvers altijd, zo moeilijk wordt gemaakt door allerlei verschillende browsers.
Ik ben zelf ook wel eens met een website bezig (meer voor de hobby/kerk), maar zelfs iets simpels als margin en padding worden in verschillende browsers op verschillende manieren gerenderd. Hierdoor ziet een simpel menubalkje er in de ene browser perfect uit, maar in een andere browser worden de knopjes net iets breder, waardoor het niet meer past en één knopje onder het menu komt te staan...

Met touch heb ik nog geen ervaring, maar ik kan me voorstellen dat dit lastig is. Ten eerste, omdat er (momenteel) drie verschillende os'en beschikbaar zijn voor mobiel. En ten tweede omdat elk os zijn eigen browser(s) heeft.

Succes in ieder geval!

[AllSeeyinEye]

hylke94 schreef op zaterdag 27 juli 2013 @ 16:24:
Ten eerste, omdat er (momenteel) drie verschillende os'en beschikbaar zijn voor mobiel.
Succes in ieder geval!

Android
Windows Phone
Blackberry

Dan heb je de belangrijksten wel gehad, ja
Maar naast Firefox is er dan nog zo'n OS, die met die kiddie looks.....

[paul999]

AllSeeyinEye schreef op zaterdag 27 juli 2013 @ 16:48:
[...]

Android
Windows Phone
Blackberry

Dan heb je de belangrijksten wel gehad, ja
Maar naast Firefox is er dan nog zo'n OS, die met die kiddie looks.....

Noemden ze dat niet ubuntu mobile?

[hylke94]

En dan krijgen we nu ook nog Ubuntu, Firefox en alle custom roms...

En natuurlijk IOS.

[ Voor 21% gewijzigd door hylke94 op 27-07-2013 17:35 ]

[Misha]

De ontwikkeling voor iOS gaat voor mijn gevoel nog wel het meest smooth. Juist al die talloze Androidvarianten zijn voor mijn gevoel degene die veel roet in het eten gooit. Op het ene device met dezelfde versie van Android werkt het prima, op de andere met dezelfde versie werkt het ineens niet. Ontzetten irritant

[Ferry H.]

Hey,

Zojuist ingeschakeld maar ik kan nergens mijn grade vinden, dus mijn vraag: waar kan ik die vinden?
Op de Ipad doet responsieve het niet op mijn mobiel wel.

[ Voor 24% gewijzigd door Ferry H. op 01-08-2013 18:29 ]

[Misha]

Ipads zijn nog buiten de scope van het project

[ Voor 4% gewijzigd door Misha op 05-08-2013 08:45 ]

[Ferry H.]

Ah dat verklaard het Ik heb al aardig wat foutjes/bugs tegen gekomen dus daarover zal ik een topic.maken.

[hylke94]

Morgen weer een nieuwe iteratie toch? Ben benieuwd wat er allemaal gewijzigd is...

[Misha]

Ik zal eens kijken of ik alvast wat screenies kan plaatsen!

[Misha]

Es spieken of dit zo werkt. Aub onder geen beding verspreiden! Als je iets wil tonen aan iemand buiten de testgroep, overleg dan aub eerst even met mij!

Let er ook op dat het nog niet _af_ is er is nog zat werk te verzetten! Vanaf morgen naar een device near you

Filters

Als je gaat zoeken, dan kun je ook filteren. Je kreeg weinig feedback als je iets gepost had. Nu hebben we het zo gedaan dat als je nog niet gefiltert hebt, er bovenin een grijs blokje staat. Zodra je gaat filteren verschijnt er een throbber in. Zodra het klaar is, wordt het een actieve knop en kun je er op klikken. Dan spring je direct naar de resultaten. Normaliter moet je zelf maar op goede hoop van zegen hopen dat het filter klaar is, met deze handige functie hoeft dat niet meer!





Forum index



Weinig spannend aan. Het is nu iets strakker, plus de quick links zijn toegevoegd zodat je vlug naar je Myreact en Bookmarks etc kan gaan

Topic listing



De topic listing is netter uitgelijnd. Noot dat we nog aan de paginering gaan werken.

Topic start



De topic start. Bovenaan zie je het einde van de breadcrumb, zodat je altijd makkelijk een niveau'tje omhoog kan gaan. Rechts bij de quick links is de forum index toegevoegd, zodat je daar ook vlug naar kunt gaan. 'Koppel onderwerp' en 'Reageer' is onder de topic titel komen te vervallen invm ruimtegebrek. We hadden nog even gespeeld om deze ook in een dropdown te zetten, alleen dan werd het wel heel erg dropdown bonanza. Rapporteren, Bookmarken en Postreminders zijn wat mij betreft op deze plek veel belangrijker voor de gebruiker dan bijv. een Onderwerp Koppelen. Over Reageren heb ik lang getwijfeld, maar gezien je ook kan reageren door iemand te quoten of dit onderaan de pagina te doen, is die uiteindelijk toch vervallen. Daarnaast zorgt dit er hopelijk ook voor dat mensen het hele topic lezen ipv vlug een rantpost plaatsen . Bovenin hebben we de onderwerpen die het topic heeft ingeklapt, zodat dit amper verticale ruimte inneemt.

Topic start deel 2



Topic start nogmaals, maar dan iets naar beneden. Als het goed is, is menig grote topic start goed responsive nu. Natuurlijk zijn er edge cases (tabellen met heel veel kolommen). Dat is erg tricky om goed te krijgen.

Onderwerpen uitgeklapt



Als je meer topics over het onderwerp wil vinden, dan kun je bij onderwerpen ze allemaal vinden die over het topic gaan.

Normale post

En nog eentje van een normale post

[AllSeeyinEye]

Ziet er goed uit! (Behalve dan die gekke blauwe balk onderin je browser, maar da's geen onderdeel van Tweakers of GoT )

[hylke94]

Ziet er al veel beter uit op het forum! Kan niet wachten tot morgen