Development-round-up - Iteratie #59

Na drie weken hebben we in deze iteratie weer een mooi aantal van 103 tickets weg weten te werken en intussen kunnen jullie weer genieten van het resultaat  Hieronder de bloemlezing.

Responsive webdesign

In deze iteratie hebben we onder meer grade B onder handen genomen. Dat betekent dat Tweakers nu ook meeschaalt op apparaten met een effectieve horizontale resolutie tussen de 767 (portrait) en 1000 pixels (landscape), en je ons prima kunt bezoeken. Hierbij moet je eigenlijk denken aan alle gangbare tablets met een resolutie van 1280x800 of 2560x1600 pixels. En mocht je de nieuwe variant toch niets vinden, dan kun je natuurlijk altijd nog een bepaalde grade forceren via de instellingen onder het tandwieltje of via je Voorkeuren.

De grootste aanpassingen voor grade B zijn dat de tracker onder het hamburger-menu verstopt wordt, net als bij grade C en D, en dat de content bij nieuws- en reviewartikelen gecentreerd wordt.

Vanaf deze release blijft ook standaard de header van de site in beeld als je naar beneden scrolt. Mocht je dat niet willen, dan kun je dit simpel uitzetten via je Voorkeuren. Natuurlijk gaan we nu niet op onze lauweren rusten wat rwd betreft, maar blijven we tweaken aan de verschillende versies en zullen we ook de pagina's die we nog niet onder handen hebben genomen stapsgewijs aanpakken.

Bijstippen grafische elementen

Het formulier voor het schrijven van een shopreview was alweer een tijd niet onder handen genomen en wat usability betreft was er nog wel het een en ander te verbeteren. We hebben dan ook het hele blok met 'Aanvullende informatie' weggehaald, omdat we daar in de praktijk helemaal niets mee deden. Ook de tekstinvoervelden bij Verzenden en Aftersales worden nu pas zichtbaar als er daadwerkelijk een beoordeling wordt gegeven op die onderdelen. Daarnaast zijn we de teksten even nagelopen, zodat die nu duidelijker moeten zijn. We denken dat het nu overzichtelijker is geworden voor wie een shopreview wil achterlaten.

De lijstjes met alternatieven in de reviews en BBG's zijn wat opgefrist. Het visuele gedeelte hiervan kon wel een likje verf gebruiken en moet nu weer even meekunnen.

Sinds een tijdje gebruiken we Datawrapper voor het weergeven van grafieken in nieuwsartikelen, reviews en benchmarkresultaten. Het aantal te gebruiken kleuren kon echter enigszins worden beperkt. Daarin hebben we dan ook verandering aangebracht en als kers op de taart is het nieuwe kleurenschema dat we gebruiken beter onderscheidend voor mensen met vormen van kleurenblindheid.

Overige zaken

Natuurlijk zijn er ook talrijke kleinere bugjes en aanpassingen gedaan, zodat Tweakers weer een stukje beter is geworden Een ander belangrijk deel van de tijd is opgegaan aan het refactoren van het reactiesysteem. Aan de werking of weergave zal dit niet veel veranderen, maar de code was ondertussen wel zo oud dat een goede poetsbeurt naar een meer actuele codestijl zeer wenselijk was. Het is echter wel een dusdanig grote klus dat deze wijzigingen nog niet meegenomen zijn met deze release. Zodra dit wel gebeurt, komt dit vanzelfsprekend aan bod in de release.plan.

Als laatste hebben we in deze iteratie de nodige tijd besteed aan het testen van onze code onder php 5.6.2. Hoewel we dit op ons gemak hebben gedaan, gingen we ruim voor de eol-datum van php 5.3 aan de slag. Overigens was php 5.5 toen al uit. Toen we onze code hadden omgebouwd voor de grote wijzigingen uit php 5.4, kwamen we erachter dat er verzuimd was om in de changelog te melden dat de standaardcodering van htmlspecialchars en htmlentities was veranderd van ISO-8859-1 naar UTF-8. Bovendien bleek dat je dat niet via php.ini kon veranderen.

Effectief betekende die wijziging dat alle tekst met tekens met accenten als 'lege string' terugkwam in plaats van netjes te zijn omgezet in tekst met html-entities. Om dat op te lossen hadden we alle aanroepen naar htmlspecialchars en htmlentities moeten voorzien van een parameter voor de door ons gewenste codering.

Gelukkig werd toen ook duidelijk dat het in php 5.6 wel via php.ini instelbaar zou worden en we niet die honderden aanroepen hoefden aan te passen. Uiteindelijk hebben we daarom ook PHP 5.5 overgeslagen en gewacht op de release van 5.6. Het moment van overstappen is echter ondertussen nabij, zodat ook Tweakers binnenkort weer op een actuele versie van php draait.

Reacties (83)

Profiel ziet er op smartphone (iPhone 6) niet responsive uit. Na een vergelijking tussen de HTML van de twee pagina's blijkt dat de profielpagina geen viewport meta tag heeft, terwijl de index deze wel heeft. Misschien dat dit de oorzaak is dat hij op mobiel niet goed schaalt?

Klopt, dat is nog een van de pagina's die nog niet responsive is gemaakt.

Schaalt wel op de desktop, dus volgens mij zou het toevoegen van de meta tag in eerste instantie moeten volstaan.

Herstel: is niet zo. Hij schaalt tot op zekere hoogte.

[Reactie gewijzigd door DiWolff92 op 28 oktober 2014 12:55]

Zo simpel is het helaas niet. De hele MyTnet omgeving hangt nog in het oude framework en is geen onderdeel van Symfony2. In principe staat dit los van RWD ware het niet dat we dit eerst willen migreren zodat het gebruik maakt van de algemene HTML generators en CSS classes. Dit zou het responsive maken enorm vergemakkelijken. Dit staat op de planning maar voor wanneer durf ik niet te zeggen.

Wat wel een keer tijd mag worden...

Het profiel gaat er ook nog wel komen, maar andere pagina's hebben tot nu toe een hogere prioriteit gehad.

Wanneer word het forum aangepakt? Het forum markeert gelezen topics nu lang niet altijd (direct) als zijnde gelezen, er gaat regelmatig flink wat tijd overheen. Aangezien ik een paar keer per dag via Bookmarks kijk, is up to date informatie hier wel relevant.

Technisch gezien heeft het forum geen 'gelezen' functionaliteit. Wij markeren topics als 'nieuw' op basis van je sessietijd. Die wordt automatisch 'gereset' na 15 minuten inactiviteit.

Oke thanks! Dat werkt inderdaad, maar vergt wel weer een extra klik. Wellicht een idee?

Op een forum met de omvang als de onze vergt het bijhouden van wat wel of niet gelezen/gezien is per gebruiker/sessie behoorlijk wat opslag en rekenkracht om dat per view in acht te nemen. Dat is feitelijk de reden dat we daar tot nog toe nog geen moeite voor gedaan hebben.

Dat was waar maar de stand der techniek heeft dat standpunt aardig ingehaald.

phpBB heeft een functie waarmee per gebruiker per topic wordt bijgehouden tot waar een topic is gelezen. Dat werkt bij ons prima met een database met bijna 2 miljoen topics, 90 miljoen posts en 300.000 gebruikers. De tabel om dit bij te houden is erg eenvoudig:

https://wiki.phpbb.com/Table.phpbb_topics_track

en dus ook behoorlijk klein, snel op te joinen, er wordt ook maar een beperkt deel van gebruikt (de actieve topics/gebruikers). Eventueel kan je alles dat ouder is dan b.v. 2 maanden uit die tabel gooien als ruimte een probleem zou zijn. Dat doen wij al een flinke tijd niet meer (meer gedoe dan het oplevert) waardoor die tabel nu 12GB is zonder problemen voor de database.

Wat performance betreft kan het prima, maar ik kan me voorstellen dat het nogal een klus is om dit in te bouwen in de forumsoftware. Zou wel super zijn als deze feature beschikbaar zou komen op GoT. Is iets dat ik best wel mis eigenlijk

't Aantal accounts, topics en posts is eigenlijk niet zo heel belangrijk voor de groei-ontwikkeling van zo'n tabel.

Wat vooral relevant is, is hoeveel mensen er 'nieuwe' topics (voor hen dan) bezoeken.

Maar los daarvan vind ik 12GB nog best veel data om 'alleen hiervoor' te moeten bewaren. Het zou een van onze grootste tabellen worden (en dat is het neem ik aan ook bij jullie).

Ik ben benieuwd naar de performance-impact van zo'n tabel, je hebt met een paar factoren te maken:
- Elke topic-view is een insert/update (of replace) op die tabel
- Elke listing van forumtopics (en ik neem aan ook elke weergave van een topic) doet een join op die tabel

Hoe groter die tabel, hoe langer ze ook beide duren. Dat heeft natuurlijk geen lineaire verhouding (eerder log(n)) maar heeft wel degelijk impact. Het is vooral vervelend als mysql weer es een deadlock er tussendoor gooit of om andere redenen het wat drukker heeft.

Dat levert uitendelijk een tabel op met een hoge schrijf-druk die ook veel gelezen wordt. Echt ideaal is dat niet.
De schrijfdruk kan je nog proberen te verminderen door e.e.a. te queuen, maar dan zit je natuurlijk weer met vertragingen die niet zo handig zijn.

Losse databases (redis ofzo) zijn ook niet echt ideaal omdat je dan weer los die data moet ophalen en het niet gelijk al mee kan joinen.

Al met al is het een interessant idee, maar ben ik niet helemaal overtuigd dat het allemaal niet meer uitmaakt met moderne databases.

Mijn ervaring is dat je tegenwoordig nog steeds met dezelfde aandachtspunten en problemen te maken hebt. De snellere software en hardware wordt weer gecompenseerd door het feit dat de hoeveelheid data ook flink is toegenomen

Ik snap je bezwaren, zou ze zelf ook hebben, maar tot mijn verbazing heeft die extra tabel echt bizar weinig impact op de DB.

Los van de posts tabel is het inderdaad onze grootste tabel, maar het overgrote deel van die tabel staat alleen op de disk niets te doen. Voor het verwijderen van oude data is een full-tablescan nodig en dat levert meer gedoe op dat het aan voordeel oplevert. Daarom gooien we die tabel al jaren niet meer leeg. Op zich is dat vrij onzinnig, de gemiddelde gebruiker hoeft van een topic dat al maanden stil ligt niet te weten tot waar hij/zij dat topic heeft gelezen. De tabel is veel kleiner te houden dus.

Inderdaad een replace bij iedere topicview door een ingelogde gebruiker maar dit op een super simpele tabel op een heel snel te vinden tuple (user_id, topic_id). Daar ligt de gemiddelde DB server niet wakker van zolang je geen 2000 topics per seconde uitserveert.

Maar we kunnen hier natuurlijk eindeloos over filosoferen Het is relatief makkelijk om de database-kant hiervan te testen, zelfs in de productieomgeving. De logica voor het up to date houden van die tabel is vrij triviaal. Zelfde met de join bij het bekijken van topics/topiclijsten. Het wordt pas wat ingewikkelder als je een 'markeer dit forum als gelezen' functie in wil bouwen maar die is voor de DB niet zo interessant.

Maar goed, dan nog. Het is wel weer een project en ik gok dat jullie je al niet vervelen. En als dit mogelijk is op het forum, waarom dan niet in de reacties bij de nieuwsartikelen en bij de artikelen op de frontpage zelf, en, en Hoor ik function creep?

Precies, maar met jullie ervaring hier opgesomd hoeven we ons in ieder geval minder zorgen te maken om de performance.

Het klinkt trouwens ook (qua dataverloop/verwijdertaak) als een ideale kandidaat voor partitioning. Wellicht met de laatste-bezoek-datum als key en dan op maanden werken. Dan is die verwijder-taak weer triviaal geworden.

Nadeel is dat je dan weer niet weet wat het doet voor je join-performance omdat dan ineens alle losse partities meegenomen moeten worden

Als je trouwens een index op die datum zet en dan elke dag bijhoudt (desnoods een paar keer loopt met een 'limit 5000' om de kans op deadlocks te beperken), zou dat geen full table scan nodig moeten hebben

Graag op de nieuwspagina's zou ik bij de reacties graag kunnen zien welke reacties ik wel en nog niet gelezen heb. Zeker als je wat langer wilt mee discussiëren weet je vanaf een bepaald punt gewoon niet meer welke berichten nieuw zijn en welke oud waardoor je sommige reacties meerdere keren leest.

In het forum staat rechtsbovenaan 'Reset sessietijd'. Als je dat aanklikt wordt de sessietijd op 'nu' gezet (d'oh) en zijn all topics als gelezen voor dat moment gemarkeerd.

Tablet view werkt nog niet echt lekker, iets te veel ingezoomd zo lijkt het, en dat doet de gebruikers ervaring niet ten goede. Voor nu dus maar er terug op de desktop layout.

Hoe bedoel je ingezoomd? De lettergroottes en dergelijke zijn niet aangepast in grade B en zouden dus niet moeten verschillen van de desktop variant.

Het valt mij hier ook op (Opera 25). Onder andere titels van de artikelen op de frontpage zijn iets groter en blurry in grade B (desktop op half scherm) ten opzichte van de grade A op volledig scherm.

Edit: font-size verandert van 12px op A naar 13px op B. Dat zal het dan wel zijn.

[Reactie gewijzigd door cpt.skydiver op 28 oktober 2014 14:19]

Hier idem dito op een ipad 2 (non retina )
Weergave nu geforceerd op desktop, zoals het was.

Klopt het dat dit per apparaat verschillend instelbaar is of zit ik nu voor al mijn apparaten (pc/ipad/telefoon) op de desktopweergave?

Klopt het dat dit per apparaat verschillend instelbaar is of zit ik nu voor al mijn apparaten (pc/ipad/telefoon) op de desktopweergave?

Dat is idd per apparaat instelbaar en wel precies om de reden die je zelf al aangeeft.

Top, ik zie bij de voorkeuren het onderscheid tussen de apparaten niet, vandaar de vraag.

iPad retina 3 (landscape) lijkt ook alles erg ingezoomd. Neiging om de hele tijd uit te zoomen maar dat gaat dus niet.

Ziet er weer goed uit! De fixed header vind ik er handig, op deze manier hoef ik niet steeds naar boven te scrollen oid.

php 5.6 al! Dat doen jullie snel, al zal het wel meevalleen met de wijzigingen, gezien jullie dat netjes bijhouden.

Het moment van overstappen is echter ondertussen nabij, zodat ook Tweakers binnenkort weer op een actuele versie van php draait.

Zoals ik 't lees is die overstap nog niet gedaan?

Maar ze geven aan dat het wel snel gaat gebeuren, dus dat vind ik nog steeds snel Inderdaad, mijn reactie doet overkomen of het al zover was. Ik doelde meer op het überhaupt nu al bezig zijn met php 5.6.

Klopt, 5.6.2 draaien we nog niet, maar dat gaat niet lang meer duren. In onze testomgeving is de parsetijd een stuk sneller, maar we moeten nog even goed meten hoeveel sneller precies. Het is iig een leuke bijkomstigheid.

De grootste aanpassingen voor grade B zijn dat de tracker onder het hamburger-menu verstopt wordt (...)

Dat merk ik ja, en om eerlijk te zijn vindt ik dat nogal ergerlijk.
Ik draai 1920x1200 en heb mijn browser in de helft van het scherm staan. Dus... Floep weg! tracker, zonder dat ik een instelling kan doen om hem in beeld te houden.
Kunnen jullie ons de keuze geven om hem toch in beeld te krijgen? Voor mij werkte dat namelijk perfect.

Dat kan door in je voorkeuren op te nemen dat je de weergave vast wil zetten op grade A (optie 'Desktops'), zoals ook in de .plan beschreven staat.

Bij mij blijft de tracker ondanks deze instelling toch verdwijnen als mijn venster <1000 pixels breed is.

Ah ja, dat komt omdat er een stukje is wat nog wel grade A is, maar eigenlijk te smal om de tracker goed te tonen. Dat loopt van 1235px tot 1000px breed (kleiner gaat naar grade B, groter toont de tracker gewoon)

kortom dan werkt responsive design dus tegen in plaats van voor je... en eigenlijk is dat raar, je hebt immers aangegeven (lees: override) dat je geen grade-B wilt maar grade-A dat doe je (neem ik aan) niet om je eigen ego te strelen en voor te wenden dat je een beter scherm hebt..

dit zelfde gebeurd trouwens ook voor mensen die veel zoom gebruiken (zoals ik), je kunt vast zetten wat je wilt maar zonder tempermonky en 3rd-party hacks kun je fluiten naar die tracker ... of je moet zover uitzoomen dat je het zelf niet meer kunt lezen ...

dat zou trouwens heel simpel op te lossen zijn door de verschillende onderdelen van de tracker uit de header te laten poppen zoals een pulldown menu.

[Reactie gewijzigd door i-chat op 28 oktober 2014 13:35]

Dit staat helemaal los van RWD. Dit is een wijziging die doorgevoerd is omdat de tracker niet altijd in beeld paste. Dit leek ons een goede oplossing. We zien nu dat er gebruikers zijn die liever een horizontal scroll gebruiken en de tracker standaard uitgeklapt hebben, ook op resoluties onder de 1235px.

Ego strelen heeft er dus helemaal niets mee te maken. Het was simpelweg een design keuze die niet voor iedereen werkt en daarom terug gaat naar de tekentafel

Heb liever inderdaad een horizontale scroll!

Fijn om te horen dat er naar wordt gekeken. Ik weet niet of dit makkelijk te implementeren is, maar een vinkje dat je de tracker altijd wil zien is dan toch de handigste optie?

Dan kunnen mensen kiezen voor de layout die ze willen + wel of geen tracker in beeld.

Horizontale scrollbalk? Je kan toch ook voor kiezen dat hij links absolute gepositioneerd is en standaard over de content valt. En wanneer je bijvoorbeeld met de muis over het artikel gaat de tracker verdwijnt.

Dit is natuurlijk één van de vele oplossingen..

De tracker klapt bij mij de hele tijd in, en wil niet meer uitgeklapt blijven

Wellicht te maken met rob_erwt in 'plan: Development-round-up - Iteratie #59'? Indien ja, dan is dat iets waar we binnenkort naar gaan kijken gezien de reacties tot nu toe daarover.

[Reactie gewijzigd door rob_erwt op 28 oktober 2014 13:14]

Dat zou heel goed kunnen, ik heb wel ongeveer die resolutie. Wel irritant is dat hij bij elke pagina de animatie toont van het inklappen, en niet simpel ingeklapt danwel uitgeklapt blijft.

Edit: als je hem open klapt, en daarna zelf weer dicht, dan blijft hij wel netjes dicht, en toont hij de animatie niet meer.

[Reactie gewijzigd door EJlol op 28 oktober 2014 13:20]

uuuuhm op mijn mobiel HTC One M7 staat hij nu op grote tablet ingesteld en de site is nu volledig overhoop (alles onder elkaar) EN ik kan nu niet meer op de "weergave opties" knop drukken. Alle text in de header zitten over elkaar heen. In landscape mode kan ik wel weer op weergave opties klikken
screenshot van mijn mobiel
http://imgur.com/P5L1KxO

Tjah, als je grade B forceerd (voor grote schermen) en het vervolgens op een smartphpone probeerd te gebruiken (klein scherm) gaat dat uiteraard niet goed Het is niet voor niets gefocreerd Zet hem op automatsich of op grade D en dan gaat het wel goed.

Heb hem nu op grade A staan en dat werkt prima (wel beetje inzoomen natuurlijk)

De tracker verdwijnt steeds op mijn desktop nu? Eerder was hij altijd zichtbaar, nu kan ik hem zelf zichtbaar maken door op het pijltje naar rechts te drukken, maar als ik van pagina wissel verdwijnt hij weer.

Chrome, 23"monitor, niet fullscreen.

Waarschijnlijk komt dat door rob_erwt in 'plan: Development-round-up - Iteratie #59'

Nog een klein iets:

Als ik nu op je link klik, die naar jou reactie loopt, dan valt het bovenste menu over het begin van je reactie/naam.

Bugs mogen gemeld worden op het forum, dat houd de bugs overzichtelijk en de reacties on topic. Dit is echter bekend en meerdere malen gemeld in. stoute bugs. De header is fixed gepositioneerd en dus geen onderdeel meer van de flow van het DOM. Een anchor link zet je bij de correcte Y positie op de pagina en dat is precies wat hij doet. Momenteel is hier simpelweg geen andere oplossing voor dan met negatieve margins werken en dat is nu niet bepaald een mooie oplossing. Mocht je er dus nog een mooie suggestie voor hebben, horen we die graag

[Reactie gewijzigd door Inspector op 28 oktober 2014 13:46]

50% screen view ziet er een pak beter uit, good job! (1680x1050)

Al gaat er met div positioning hier wat fout (3 img elementen front-pag; CiV Sunset overdrive en 4g race) en is de ease-in voor mij persoonlijk misselijkmakend.

Wat ik altijd vervelend/vreemd vind is het volgende: De lijst met nieuwsitems wordt automatisch bijgewerkt, maar als je dan op een item klikt, het leest en de terugknop van de browser gebruikt (doe ik altijd via een knop op mijn muis) dan zijn die bijgewerkte nieuwsitems verdwenen. Je moet dan weer op 'Tweakers' klikken om de voorpagina opnieuw te laden. Ik gebruik Chrome op W7 64.

De nieuwe items worden opgehaald via AJAX, maar als je browser dat resultaat vervolgens niet cached, dan krijg je inderdaad de "oude" pagina te zien. Daar is niet zoveel aan te doen, behalve niet op back klikken, maar bijv op het Tweakers logo.

Auw, dat vind ik dan weer jammer. Dan doorbreek je de defaultwerking van de browser en dat is volgens mij altijd onwenselijk. Om die reden heb ik ook een hekel aan links die ongevraagd in een nieuw venster openen. Backspace is mijn vriend bij het surfen.