Development-round-up - Iteratie #58

Ook bij deze iteratie bieden we jullie een update van de technische ontwikkelingen en keuzes bij Tweakers. In de afgelopen weken is hard gewerkt om externe feedback over onze seo te verwerken, ons responsive framework uit te breiden naar grade B, ofwel tablets, en bug fixes door te voeren.

Seo-optimalisaties

Regelmatig laat Tweakers door een externe partij onderzoek doen naar de search engine optimization. De feedback die hieruit voortkomt, is deels in deze iteratie verwerkt en toont zich in een aantal toevoegingen. Zo zijn er merkcategoriepagina's en merkoverzichtspagina's toegevoegd, en zijn er enkele teksten en links aangepast. Hiermee hopen we nog relevantere informatie te kunnen tonen in de diverse zoekmachines.

Responsive

Ondertussen biedt Tweakers al geruime tijd de functionaliteit van responsive design. Dit was echter nog gelimiteerd tot smartphones en kleine tablets, intern ook bekend als 'grade C & D'. In deze iteratie hebben we de eerste stappen gezet voor het gebruik op grote tablets, ofwel grade B. Hiervoor worden in de volgende iteratie de laatste aanpassingen doorgevoerd, voordat het met die release beschikbaar komt. De tabletversie lijkt erg op zijn desktopbroer, maar de weergave van content op apparaten met beperkte schermruimte zou net wat beter geoptimaliseerd moeten zijn.

Een voorproefje van de frontpage en een review, beide geoptimaliseerd voor tablets

Gebruik van externe user-iconen uitgefaseerd

Het gebruik van avatars op Tweakers is nog altijd omstreden. Zo was er de mogelijkheid een avatar te laden vanaf een externe locatie of er een te uploaden. Vanaf nu is het laden van externe gebruikersiconen niet langer mogelijk. Gebruikers die een extern gebruikersicoon hadden ingesteld hebben een dm ontvangen om dit lokaal te uploaden. Later zouden we dit proces graag eens op de schop nemen en een mooie server-side-scaling en -cropping inbouwen, maar dat is nog even toekomstmuziek.

Afscheid mobile apps

We hebben al eerder aangekondigd te stoppen met onze mobiele apps en vandaag komt er echt een einde aan. De api waarop deze apps leunden, is in deze iteratie uit de codebase verwijderd. De apps waren al jaren lastig te onderhouden door onderbezetting van het developmentteam en de geringe kennis van de diverse sdk's. Er is dan ook besloten onze developmentkracht volledig in te zetten om Tweakers als website mooier, sneller en beter te maken. Voor rouwberichten, verdere toelichting bij het uitfaseren van de apps en de eventuele vervolgstappen kun je in dit dedicated topic op GoT terecht.

Overige aanpassingen

Na al dit geweld zijn er ook nog kleinere, maar minstens zo belangrijke wijzigingen doorgevoerd. Zo zijn de levertijdiconen in de Pricewatch uitgebreid voor webshops die ook in het weekend leveren, wordt bij de reacties nu direct vermeld op wie je reageert, is het contrast van kleuren in onze datawrappergrafieken aangepast en kun je nu bij het aanmaken van een shopreview ook met je toetsenbord door de drop-down-lijst van shops navigeren. Daarnaast zijn er natuurlijk de nodige bugs gefikst en features besproken, zoals ook te zien is in de desbetreffende topics.

Ten slotte zijn we ook dit jaar weer genomineerd voor de titel 'Website van het jaar' in de drie welbekende categorieën: Nieuws en Informatie, Communities en Vergelijking.

Reacties (103)

Vanaf nu is het laden van externe gebruikersiconen niet langer mogelijk. Gebruikers die een extern gebruikersicoon hadden ingesteld hebben een dm ontvangen om dit lokaal te uploaden. Later zouden we dit proces graag eens op de schop nemen en een mooie server-side-scaling en -cropping inbouwen, maar dat is nog even toekomstmuziek.

Prima, maar kan dan wel die waardeloze limiet van 10kB uit 1990* wat worden verhoogd? Ik snap best dat externe avatars hun issue hebben, maar er zijn zat mensen met geanimeerde avatars en die passen lang niet altijd in 10kB. En zeg nou zelf, dat is toch ook niet meer van deze tijd?

Als alternatief zou je links naar je fotoalbum eventueel kunnen blijven toestaan.

* beeldspraak

[Reactie gewijzigd door .oisyn op 7 oktober 2014 14:39]

Voor één los icon lijkt het inderdaad een beetje krap Bij 100 reacties onder elkaar heb je het echter dan wel al in de worst-case over 1MB aan data-download puur voor de user icons... (in de praktijk zal het natuurlijk ook weer niet zo hard lopen)

[Reactie gewijzigd door ACM op 7 oktober 2014 14:42]

De tijd dat 1MB veel was, is onderhand echt wel voorbij hoor

Volgens mij rekenen de meeste mobiele bezoekers nog altijd met datalimieten van groottes in tientallen en honderden MB's per maand... Ironisch gezien is het de laatste paar jaar juist meer relevant geworden omdat de datalimieten weer wat strenger werden en toch het mobiele verkeer steeg

En bovendien hebben we het (heel bot gezegd) alsnog over 1MB voor een paar 60x60-plaatjes die bedoeld zijn om enig herkenning te geven aan de gebruikers...

Overigens gaan we nog wel kijken of de grens nog iets omhoog kan. Maar verwacht niet dat we het naar 100KB zetten.

[Reactie gewijzigd door ACM op 7 oktober 2014 14:45]

Overigens gaan we nog wel kijken of de grens nog iets omhoog kan. Maar verwacht niet dat we het naar 100KB zetten.

Zorg er dan in ieder geval voor dat de grens op een veelvoud van 4 KB ligt (of misschien alvast 8 KB voor in de toekomst).

Dat is namelijk de standaard clustergrootte van het NTFS bestandssysteem (en ook het maximale gemiddelde op ext bestandssystemen voor zover ik weet).

Ik heb al eens eerder zitten rommelen met een avatar en dan denk je dus netjes precies onder die 10 KB te zitten ware het echter niet dat de "size on disk" altijd groter uitvalt (namelijk 12 KB). En dat accepteert Tweakers niet bij het uploaden.

Op een (standaard geformatteerd) NTFS systeem zit je nu dus sowieso op een maximale bestandsgrootte van 8 KB.

De grens is blijkbaar al in overleg met onze community-manager verhoogd. Maar los daarvan snap ik je punt niet zo. We kijken op onze server niet naar de grootte die een file bij jou op disk is, maar naar wat er uiteindelijk geupload is. Als je dus een file van maximaal 10240 bytes uploadde, dan werd dat gewoon geaccepteerd. Dat die file vervolgens op disk 12KB (of bij ZFS zelfs iets van 128KB) kost is daarbij irrelevant voor de controle

De grens is blijkbaar al in overleg met onze community-manager verhoogd.

Ik zie het ja. Nu alleen nog de totale opslag naar 2400 KB dan, heh-heh.

Als je dus een file van maximaal 10240 bytes uploadde, dan werd dat gewoon geaccepteerd.

Het bestand dat ik probeerde te uploaden is 9,72 KB (9955 bytes) volgens Windows 7. Ik kreeg toch echt de melding dat het bestand te groot was.

Bij een iets lelijkere versie van 8,91 KB hetzelfde verhaal. Bij een nog lelijkere versie van 8,1 KB wederom hetzelfde verhaal.

Pas bij een versie van 7,96 KB werd de upload geaccepteerd. Dit deed mij vermoeden dat de "size on disk" stiekem de oorzaak was.

Ik vraag me toch af waar het probleem dan zat.
Het enige dat ik nu even gauw kan verzinnen (en me echt heel slecht kan voorstellen) is dat de implementatie van de XMLHttpRequest-functies (of wat daar dan ook voor gebruikt wordt) per engine verschillend is en dat die van FireFox de slack space op de schijf ook doodleuk meestuurt als data.

Helaas heb ik het niet getest met een andere browser dus dat is pure speculatie.

Maar goed. Gezien de vertienvoudiging van de limiet maakt het nu dus eigenlijk ook niet zoveel meer uit. Tenzij je een halve speelfilm in een gifje wilt proppen natuurlijk.

Het zou mooi zijn om de optie te hebben geen usericons te zien (bij mobiel)

Dat lijkt me ook voor de desktop versie een mooie setting eigenlijk. Ik scroll en lees wat comments, en de user icons interesseren me eigenlijk helemaal niets.

Kijk dat is nou fijn, veel mobile abbo's hebben 500 mb data limieten, dan gaat een beetje GoT bladeren onderweg toch hard als elke pagina al tig mb aan gifjes heeft. Goed dat hier aan gedacht is.

True! Daar heb je gelijk in!

Dus voor mobiel moet de rest maar een crippled versie van Tweakers krijgen? Jammer, maar sinds versie 7 is Tweakers.net harder aan het afgleiden dan ooit tevoren! Werkelijk alleen Tweakers presenteert het weglaten van geliefde functies als nieuwe ontwikkeling. Jammer, jammer, jammer.

Ik moet het echt nog een keer zeggen, het is jammer dat de mobiele apps afgeschreven zijn. Dubbele ontwikkeling een probleem? Maak de API openbaar, de community heeft kennis genoeg om een goede app te maken!

[Reactie gewijzigd door 90710 op 7 oktober 2014 15:55]

Ik snap de moderatie even niet.. Zijn post is O.T. Is de "negatieve" toon richting Tweakers al genoeg om dit te down-modden? Freedom of speech mensen...

Daar hik ik een beetje tegenaan. We snoepen we flink van de databundel van sommige users. Maar an zich heb ik geen probleem met een limiet van 20kB.

Wauw! 20 kB! Daar kan ik wel een hele gif van 3 frames in plaatsen! Wooo!

Wat een kul-argument. Verzin dan iets anders om mensen met een databundel tegemoet te komen (m.got.tweakers.net die alleen statics van 10kB laat zien), want dan zit ik daar met m'n glasvezelverbinding. Dan kunnen er prima icons van 100kB worden gedownload.

Serieus, sta op z'n minst het fotoalbum toe, want dat heeft altijd prima gewerkt.

De icons worden nu verboden onder het mom van 'onveilige sites', maar als argument wordt 'databundels!' gebruikt.

[Reactie gewijzigd door krvabo op 7 oktober 2014 15:00]

We gaan echt niet voor alleen de iconen een mobiele site introduceren Het idee van een losse mobiele site hebben we juist geprobeerd overbodig te maken met responsive.

Dit zijn trouwens de redenen voor ons geweest om de webiconen te verwijderen:
- Het werd al niet getoond buiten het forum (dus bij je reactie hierzo al weer niet)
- Ze gaven regelmatig http-auth popups, lange laadtijden, ssl-warnings, e.e.a.

Het fotoalbum daarvoor inzetten was effectief gewoon een webicon gebruiken en dus min of meer een 'hack' waarbij je uiteindelijk toch via servers van Tweakers ging.

Andere nadelen aan de webicons - maar niet direct de reden om ze te verwijderen - was het feit dat we geen idee hadden hoe groot de files waren en welke afmetingen de plaatjes hadden. Zelfs als je ze allemaal downloadt kan je dat niet controleren omdat je geen garantie hebt dat e.e.a. elke keer dezelfde data geeft.
Het kwam zo nu en dan voor dat bezoekers een file van 1MB linkten of een file die effectief een complete 404-pagina probeerde in te laden. Met name voor onze huidige grote groep mobiele bezoekers die nog echt per MB betalen hebben dat soort dingen natuurlijk relatief veel impact.

Ons fotoalbum gebruiken lost eigenlijk alleen het 2e punt op. Het eerste punt en uiteindelijk ook de bijkomende nadelen worden er niet mee opgelost.

Ik heb geen problemen met avatars en het data verbruik ervan. Maar kunnen jullie niet een tumbnail (dus niet bewegend) van <10kB tonen voor alleen grade D in responsive design. Dat heb je de grootste groep te pakken van mobiele gebruikers. Ik weet niet of het technisch kan en/of veel vraagt van het systeem. Maar misschien heb je in die trant iedereen een beetje blij gemaakt (het tonen van hogere avatar size voor grade B & C).

Het is op zich een mooi idee. Maar het grootste probleem met dit soort ideeen is dat we dat bij de (serverside) gegenereerde html al moeten aanleveren.
De normale situatie bij de diverse grades is dat we exact dezelfde html (en dus exact dezelfde image-urls) genereren voor iedere grade en dat het puur bij je browser ligt hoe dat dan getoond wordt.

De (potentieel te) grote plaatjes zijn tegen die tijd dus al door je browser gedownload zijn
Sterker nog, daarna zou in theorie dan nog besloten kunnen worden om andere plaatjes te laden en dus nog meer binnengehaald worden

Is wel op te lossen door ze als achtergrondafbeelding in 2 containers op te nemen en via mediaqueries de zichtbaarheid te bepalen. Achtergrondafbeeldingen worden niet ingeladen als de container onzichtbaar is.

Tot we bredere support hebben voor srcset en picture element blijft het wel beetje behelpen.

Onveilige sites, databundels, icoons met cookies, icoons achter een loginscherm, grote icoons, te zware icoons etc. Het zijn allemaal valide argumenten.

Nou, laat users dan het T.net-album gebruiken en de meeste vallen al weg...
Te groot, mwahja, kan ik nog inkomen, maar leg daarin dan wel een beperking op. 50kb, ook vanaf T.net-album en 99,9% is weer blij toch...

Dan kunnen we beter de limiet verhogen naar 50kb; het fotoalbum gebruiken zou betekenen dat we weer dubbele iconen krijgen (fotoalbum en intern) met de bijbhorende code en complexe onderhoud (klachten over een usericon bijvoorbeeld; welke van de twee die zichtbaar kunnen zijn? etc).

Ahaa you are the master
Naja imho is dit een 'radicale' keuze voor de tig Gif-gebruikers.
Ik heb m'n gifje van 58kb naar 34kb verkleind, maar minder lukt niet, dus in mijn geval zou ik dan al geholpen zijn. 10kb is alleen statisch..

Waarom is het T.net-foto-album dan een externe host, ben nogal een n00b.
Maar als je mensen hun avatar laat hosten via dat album is er toch geen Google-geblaat?

Je kunt gewoon de mobiele gebruikers standaard (aan te passen in instellingen) het 10KB icoon laten zien en de andere gebruikers de grotere icoons. Zo werkte het voorheen ook voor mensen die geen zin hadden in een hoog dataverbruik.

Back to the stone age it is.

Hoeveel zou je willen?

Nou ja, mijn plaatje is 69kB, dus 69kB

Maar ik zat meer te denken aan de oude normen. 100kB was een beetje het maximum wat betreft external avatar. Dat werdt niet geautomatiseerd geenforced maar dat was wel de afspraak.

100kB lijkt me daarom best netjes. Dan kan iedereen in ieder geval zijn oude plaatje naar de servers van t.net uploaden, en hebben we geen last meer van het probleem waarvoor het linken van externe plaatjes is uitgezet.

Mijn oude icoon is 102kb

Meer dan 25kb is echt onzinnig. Sloop je alle snelheidsoptomalisatie er uit. Wat een optie zou zijn is het eerste frame van een gif apart op te slaan als still. Dan optioneel altijd de still versie laten tonen. Topidee nu al

Het is nu 100kB.

Laten we zeggen 1 frame 1 is 10KB, we willen video's van 3 uur uploaden. @24FPS is dat 108.000 KB = 108 MB

serieus: iets van 100-200KB zou genoeg moeten zijn.

So? Dat had je voorheen toch ook?

Als dat serieus een probleem voor je is, misschien moet je dan geen 100 posts per pagina weergeven. Bovendien zal het maar 1x gebeuren, want daarna is de boel gecached. En ook in dat opzicht is de nieuwe situatie beter dan de vorige, want toen had je de mogelijkheid tot uncached dynamische icons.

Dat maakt natuurlijk niet uit. Het gaat erom dat de balans plaatje / post erg uit balans is. Of je dat nou over 1 pagina of meerdere verspreid verandert daar niet veel aan (behalve dat je in het tweede geval nog net iets meer overhead hebt...)
Maar als ik een tijdje zit te lezen en daar 100 posts lees en dan 10 MB van mijn data heb opgesnoept alleen maar aan niet zo belangrijke plaatjes, word ik daar niet heel erg gelukkig van.

Dan zet je avatars uit (ja dat kan). Maar ik moet de eerste topic nog tegenkomen waar 100 verschillende mensen hebben gereageerd met ieder een 100kB plaatje. Men is nu vooral spijkers op laag water aan het zoeken lijkt het wel.

[Reactie gewijzigd door .oisyn op 7 oktober 2014 15:02]

Helemaal mee eens, ik zou het ook graag op de schop gooien en er een mooie uitgebreide anno 2014 upload mogelijkheid van maken. Helaas valt dit onder het project van de upgrade van mytnet waarvan ik nog niet weet wanneer dit uberhaupt op de roadmap komt ...

Dat dat allemaal werk kost is geen reden om nu de limiet, wat zo goed als géén werk kost, te verhogen naar een moderne hoeveelheid

1] Ik heb ooit, jaaaaren geleden gewerkt bij zo'n SEO boer, en het valt me op dat de 2 meest genoemde SEO optimatlisaties niet in tweakers zitten, title tagjes op alle links, alt tagjes op alle plaatjes, als jullie dit doen zal google (en bing etc) de boel een stuk beter indexeren

2] Ik ben misschien heel saai of lomp ofzo, maar kunnen 'we' ook een regel maken dat mensen geen (danwel onmogelijke) rating icoontjes als avatar mogen gebruiken? dat stoort me een beetje.

3] Top beslissing om de app te laten voor wat het is, en te focussen op een goed schaalbare mobiele website, wil ik wel even de vermelding maken dat een mobiele detectie aan de hand van user agent een stuk mooier is dan dat je met max-device-width switchd tussen stylesheets, reden is dat je dan vanaf een mobiel device ook echt een desktop versie van de site kan opvragen, en dat word dan niet teniet gedaan door de max-device-width settings.

En als laatste, al een paar development round up iteraties genoemd, ik snap dat het iets kleins is, maar het springt best wel in het oog, het icoontje helemaal rechts boven op de site (als je bent ingelogd) dat tandwieltje, het is bij mij op al mn devices een onscherp icoontje, je kan duidelijk pixeltjes uit zien steken aan de bovenkant, dat moet makkelijk gefixd kunnen worden

En dat was m'n gepiep weer, verder alles top en mooi etc, ga vooral zo door, iedere iteratie word het geheel net weer dat beetje beter.

We gaan normaliter SEO-tips alleen verwerken als we verwachten dat het de usability niet benadeelt of als het uberhaupt haalbaar is om dat te automatiseren.
Want met de hand dingen proberen te doen vereist dan op zijn minst al dat we ineens een CMS-functie toevoegen voor die specifieke plek, en dat is in de praktijk naast technisch soms veel werk ook organisatorisch gewoon geen doen (want je wil liefst _al_ je producten, nieuwsberichten, reviews, etc dan meenemen bij zoiets, ipv slechts een paar).

Title-attributen op links doen we alleen als de tekst die we in de anchor zelf zetten niet hetzelfde is en dan bij voorkeur alsnog alleen als het voor de gebruiker die er overheen wil hoveren wat toevoegt.

Bij alt-attributen aan plaatjes toevoegen doen we iets soortgelijks. We voegen niet automatisch een alt toe, om 'iets' te hebben of als dat effectief betekent dat een link die er pal naast/onder staat qua tekst herhaald wordt. Want in die gevallen had het waarschijnlijk weinig nut voor de eventuele persoon die wel echt de alt-attributen nodig heeft ivm slechtziendheid.

Bij afbeeldingen die we embedden in artikelen wordt dan weer wel automatisch een alt en title gegenereerd.

Overigens zullen we ook zat plekken hebben waar niet bewust voor het een of het ander is gekozen, dus bovenstaande geldt alleen voor die plaatsen waar we bewust hebben gekozen

Ah oke dat verklaart een hoop, dank voor het inzicht!

3] Switchen op UserAgent is heel erg bewerkelijk en foutgevoelig. Daarom doen wij het met CSS, maar als je op het tandwieltje klikt, dan kun je wel een desktop versie forceren als je dat graag wil.

Dat is imo een nettere oplossing dan de gebruiker te forceren allerlei vreemde dingen te doen.

Oh oke. In mijn ervaring werkt het echter heerlijk, via dit script: http://mobiledetect.net/
Maar zo te horen is het een weloverwogen beslissing geweest, dus laat mijn mening dat niet teniet doen

Inderdaad, ga zo door.

Klein puntje;
Kunnen de links in de Tracker niet gelinkt aan de post?
Het is erg irritant als je in de Tracker ziet dat er een nieuwe reactie is op een artikel dat je volgt en als je dat aanklikt je begint bij de eerste post......niet bij die nieuwe reactie en dus weer bv alle 300 posts door zou moeten lezen (wat je vaak niet doet).
En is het niet mogelijk een cookie te maken dat weet waar je een topic/post verlaten hebt, zodat je bij terugkeer terechtkomt bij de eerste nieuwe, door jou ongelezen, reactie?
Al is dat misschien wat moeilijker gezien de posts niet chronologisch staan maar door elkaar per thread/reactie.
En misschien kan er een lay-out bijkomen die de reacties op reacties achter elkaar weergeeft ipv onder elkaar. Het overzicht is soms wat weg en staan directe reacties een bladzijde verder omdat er een (geheel off-topic) discussie tussen is gekomen waardoor posts plotseling als ontzettend domme reacties worden ervaren gezien het antwoord daarvoor al tig keer tussen geplaatst is achteraf.

[Reactie gewijzigd door Teijgetje op 7 oktober 2014 16:26]

Dan is het wel heeel wat jaren geleden Title attributen op gewone links worden al sinds 2005 (http://www.searchenginejo...itle-attribute-correctly/) genegeerd. En nog steeds doet Google er amper wat mee

Mijn avatar hebben ze keurig geupload naar mijn profiel. Alleen jammer dat zij zo wazig is geworden. Kan dat worden veranderd, of dat ik haar zelf kan verbeteren en dan daarna weer kan uploaden?

Wij hebben 'm niet voor je geupload hoor... Dat heb je wellicht zelf al ooit een keer gedaan.
Maar ja, je kan net zo makkelijk een andere uploaden of vernieuwde versie van je huidige uploaden in je profiel.

Oh okee. Ik dacht dat je dit niet meer zelf mocht doen, vandaar mijn vraag.
Maar waarom is ze dan zo wazig geworden? Ik denk dat jullie haar verkeind hebben?
Hoe het ook zij, zal eens kijken of ik haar scherper kan krijgen of dat ik even een nieuwe juiste en dan minder dan 10 kb kan uploaden.

Bedankt voor het antwoorden, zowel CLB als ACM.

Ja Femke, je kun via je profiel gewoon weer zelf een avatar uploaden, mits die <10kb is!

Wordt bij het weekend ook al de zondags dienst van Coolblue verwerkt?

Daar is het o.a. voor bedoeld ja. Of het ondertussen al in de backend is ingesteld weet ik niet maar dat zou niet lang meer op zich mogen laten wachten

De vormen waarbij je tegen reguliere verzendkosten ook producten op zaterdag of zondag verstuurd worden (dus op zondag en maandag aankomen). En Coolblue is inderdaad een van de voorbeelden waar dat voor geldt

Zo zijn de levertijdiconen in de Pricewatch uitgebreid voor webshops die ook in het weekend leveren, wordt bij de reacties nu direct vermeld op wie je reageert, is het contrast van kleuren in onze datawrappergrafieken aangepast en kun je nu bij het aanmaken van een shopreview ook met je toetsenbord door de drop-down-lijst van shops navigeren.

Hulde, maar naast deze leuke upgrade klopt er van de levertijden over het algemeen maar bar weinig. Dit heb ik al meerdere keren bij jullie gemeld, maar er wordt niets mee gedaan!

Winkels als Saturn zetten doodleuk overal levertijd binnen 24 uur bij, om klanten te winnen waarschijnlijk, terwijl de levering doodleuk weken op zich laat wachten. Dit is misleiding, en heeft mij al meerdere malen hoofdpijn bezorgd. Ik acht de levertijden op Tweakers (uit slechte ervaringen) dan ook volledig onbetrouwbaar, terwijl de rest van de site nagenoeg perfect werkt en informatief gezien tot in de puntjes klopt.

Ik ben vast niet de enige die dit heeft meegemaakt, dit lijkt me een goed punt voor Tweakers om aan te pakken in de nabije toekomst.

Volgens mij komen de levertijden niet van Tweakers zelf uit, maar van de webshops. Wat een probleem geeft voor Tweakers om daar wat aan te kunnen doen.

Als je verschillen ziet op wat de webshop zelf op zijn site plaatst... dan horen we het graag, want dan klopt ons deel gewoon niet of staat hun feed verkeerd bij ons ingesteld. Als zij op hun eigen site ook 24h beloven, dan kunnen wij op dat vlak weinig anders dan hetzelfde aanhouden.

Als een webshop zijn eigen beloofde levertijd niet nakomt, dan is dat een mooie aanleiding voor een negatieve shopreview toch?
Als ze het structureel en expres verkeerd (aka misleiding ipv gewoon fout ingeschat) doen zou het voor ons een reden kunnen zijn om ze uit de pricewatch te weren, maar dan moet het wel duidelijk om meer dan incidentele situaties gaan (ik heb geen idee hoevaak Saturn het verkeerd en goed doet, en dat is voor deze discussie ook niet echt relevant).

Het komt overeen met wat ze op de site hebben staan, alleen klopt dit simpelweg nooit. Dit is al zo sinds 2011 en ze hebben hier zelfs op TV aandacht aan besteed, ik meen bij Tros radar. Er zijn werkelijk duizenden mensen die hierover geklaagd hebben... Op Tweakers staan ook al heel veel slechte reviews, en eigenlijk op elke andere review site ook.

Maargoed deze discussie is daarvoor niet relevant inderdaad. Deze discussie is echter wel de juiste plek om aan te geven dat het klakkeloos overnemen van de levertijden, verzorgd door de site van de webshops zelf, misschien niet de juiste manier is. Als de betrouwbaarheid te wensen overlaat, vloeit de negatieve ervaring van de webshop door in de ervaring van Tweakers. Hier ging men immers op zoek naar een product, en de gekozen webshop op basis van de informatie gegeven door Tweakers, was incorrect. Men ervaart Tweakers in zekere zin dus ook negatief.

Ik heb door de jaren heen al tientallen producten via Tweakers besteld, maar ik heb wel op de harde manier moeten leren dat ook Tweakers niet betrouwbaar is m.b.t. levertijden. Dat vind ik erg zonde...

Nog wat kleine feedback omtrent de responsive site op Safari (iPhone5). Het stoort me dat iedere keer wanneer ik de site open (staat gepinned), ik eerst de cookie bar moet wegklikken en daarna die irritante melding dat je de site kunt pinnen (ja dat weet ik, dat had ik namelijk al gedaan). Ieder bezoek is dus 2 popups wegklikken.

Besef dat wanneer ik dit op mobiel doe, ik meestal ergens op de dag onderweg ben en een paar secondes of een paar minuutjes heb om even snel iets te lezen. Des te irritanter dat je dan zo geblokkeerd wordt in het simpelweg lezen van een lijstje nieuws.

Verwijder je alle cookies bij het sluiten? In principe zou die melding niet terug moeten komen zodra je hem gesloten hebt. Dit wordt zowel in je sessie als een cookie opgeslagen.

Ik verwijder niets aan cookies, het probleem zit hem in de interactie. Als je een site gepinned hebt, dan zul je niet safari openen en op zoek gaan naar het bestaande tab blad. Nee, je tikt op de pinned site, welke dus een nieuwe tab in safari opent, waardoor je telkens dezelfde routine moet uitvoeren.

Dat begrijp ik maar zelfs als je hem pinned en hij in een nieuw tabblad opend of zelfs in een eigen nieuw venster zou hij d.m.v. een cookie toch echt die popups niet mogen tonen. Ik zal eens kijken of ik dit kan reproduceren. Kun je me van de volgende gegevens voorzien? Model Iphone, OS versie en Browser versie.

Sure, iPhone5, iOS 8.

Ik probeer het net te reproduceren, maar nu lukt het me niet meer. Niet als ik de site vanuit de pin open, op home druk, en dit dan nog een keer doe. Ik krijg dan de popups niet opnieuw. Ik heb dit wel vele keren meegemaakt maar dan zit er meer tijd tussen. Ik twijfel nu of het aan mij ligt of niet.

Jammer dat de app 'verdwijnt', maar ik moet zeggen dat de site zeer goed werkt in Safari op m'n iPhone 5 dus ik heb hier dan ook geen klachten over! Ik ben overigens erg benieuwd wat de SEO optimalizaties zullen gaan opleveren wat betreft bezoekersaantallen en wellicht het doen afnemen van het bouncepercentage (Bezoekers die slechts één pagina bekijken en direct de site sluiten omdat ze niet gevonden hebben waar ze op zochten). Maar dat zal waarschijnlijk pas na enkele weken valide te meten zijn.

En verder: keep up the good work! Vooral de Pricewatch blijft een pareltje, ik gebruik hem dagelijks moet ik zeggen en de vele filter opties maken het zoeken zeer prettig

Fantastisch nieuws juist dat de app verdwijnt! Ik zag er de toegevoegde waarde niet van in, zo'n app kan ik ook niet op al mijn hardware draaien. Ik hoop alleen maar dat meer bedrijven de apps vaarwel zeggen, en dat de gebruikservaring op zoveel mogelijk platforms gewoon hetzelfde wordt (!)

Niet helemaal hetzelfde aangezien er twee smaken zijn (op z'n minst). Er is namelijk ook een een 'clean' versie beschikbaar van T.net voor smartphones via .mobi: http://www.tweakers.mobi/ . Dat werkt al een stuk lekkerder dan de 'normale' mobiele website van Tweakers (die is net iets te druk en wijkt daardoor behoorlijk af van de schone app interface).

Tja, dan zou ik zeggen: schoon die mobiele website op. Maar een app, daar zie ik gewoon het nut niet van in.

Wat ik mis in de responsive versie ten opzichte van de app, zijn de thumbnails naast de nieuwsberichten. Ik vind die dingen superhandig om in een oogopslag te scannen welk bericht interessant is voor mij. Adobe-icoontje? Hee, lezen! Zijn de thumbnails echt verdwenen in de responsive versie, of is er een instelling voor?

MIsschien kun je beter het nieuws archief gebruiken, die bied precies wat jij wil: http://tweakers.net/nieuws/zoeken/?keyword=

Dat is een aardige tip. Ik zet in elk geval een bookmark naar die url op mijn mobiele desktop.

Spijtig van de user icons. Daar gaan alle mooie icons van verschillende users.

Ja, de herkenbaarheid van een heleboel users is om zeep geholpen met deze 1990-waardige maatregel ben ik bang.

Die hebben een DM gehad, dus het zal ze wel opvallen.

Het gaat me er ook niet om dat users niet weten dat hun icon niet meer werkt. Het gaat me er om dat hun (vaak op meerdere fora) herkenbare icon niet meer KAN werken ivm 10kB limiet. Waarom denk je dat zoveel users hun icon extern (of in hun foto-album) hadden staan? In de jaren '90 was een 10kB limiet logisch ivm bandbreedt van veel internetgebruikers. Maar naar mijn mening is die limiet absoluut niet van deze tijd.

En nee, ik ben er heus niet voor dat mensen een speelfilm van een kwartier als icon gebruiken, ik zie het nut van een limiet wel in. Alleen is de huidige limiet wel erg... gelimiteerd.

Die limiet was gebaseerd op het feit dat elk statisch plaatje van 60x60 met 3-bit kleur wel onder de 10KB te krijgen is. Daar is verder niet echt rekening gehouden met animated gifjes. Voor die laatste categorie hebben we de limiet nu opgeschroeft naar 70KB

Hulde!

Note: Het is ondertussen al 100kb http://gathering.tweakers...message/43015777#43015777

Ik weet nog niet of ik hem terugplaats op dit moment. Eens een nachtje over slapen

Nu nog de animated gif user icons verbieden. Die dingen zijn zo vreselijk storend!

Mee eens. En daarna ook de klachten verbieden

100% mee eens, hoe eerder ze uitgebannen zijn, hoe beter.