Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 93, views: 16.526 •

Drie weken zijn verstreken en zojuist is iteratie #31 de deur uitgegaan. Griep en verkoudheid hebben in deze iteratie flink huisgehouden, met zieke devvers tot gevolg. Toch zijn er ongeveer 154 tickets afgehandeld.

Pricewatch

Aan de Pricewatch zijn diverse features toegevoegd. Zo is het nu mogelijk een product te vergelijken met een product uit een andere categorie. Je kunt nu bijvoorbeeld een telefoon met een tablet vergelijken. Een koelkast met een processor vergelijken kan trouwens ook, mocht je dat willen ;) Verder bevatten sommige tabs bij producten (bijvoorbeeld de tab Review of Advertentie) nu een plusje als er nog geen content voor is, zodat die meteen aangemaakt kan worden.

Direct content toevoegen

Diverse verbeteringen

In de vorige iteratie werd de 'cookiemuur' weer afgebroken, en aan het begin van deze iteratie is de balk naar de bovenkant van de pagina verhuisd en van een duidelijkere inhoud voorzien. De landencheck bij het reageren op de site, die ook in de vorige iteratie werd geïntroduceerd, is wat gebruiksvriendelijker gemaakt, met zowel betere controles op de landcode als duidelijkere meldingen van wat er aan de hand is.

Verder hebben we de zoekmachine van een upgrade naar Lucene 4.1 voorzien en tegelijk weer wat kleine bugjes erin opgelost. Daarnaast hebben we kleine verbeteringen aan de snelheid van de website doorgevoerd. Ook hebben we zowel onze Java- als onze PHP-code nu in Sonar geplaatst, zodat we automatische analyses van de kwaliteit van onze code kunnen uitvoeren. We moeten daarbij overigens nog wel de regeltjes naar onze eigen smaak inrichten. Met de huidige instellingen, over 270.000 regels code, hebben we in ieder geval nog aardig wat problemen op te lossen ;)

Tweakers php-code in Sonar

Cybercrime challenge

Op dinsdag 5 maart is de Cybercrime Challenge van start gegaan. Hiervoor hebben we een mooie advertorialpagina ingericht en voorzien van een livestream van de liveshow Tek Tok Late Night in Den Haag. De video van afgelopen dinsdag is op deze pagina dan ook terug te kijken. Mocht je je eigen hackerskills willen testen: de challenge is nog tot 31 maart te doen.

Responsive website

Iteratie #31 was de eerste waarin we serieus werk hebben gemaakt van een van onze 'strategische doelen', namelijk het ombouwen van Tweakers tot een 'responsive website'. Dit slaat niet op de reactiesnelheid, die is over het algemeen goed; een responsive website past zich aan aan het apparaat waarmee je Tweakers bezoekt. De bedoeling hiervan is vooral dat je met 'elk' apparaat op tweakers.net terecht kunt, en dat je dus niet in het ene geval beter de Tweakers App kunt gebruiken en in het andere geval beter af bent met tweakers.mobi. Dit gezegd hebbende, zullen er in de praktijk altijd wel momenten zijn waarop gespecialiseerde toepassingen beter zijn dan een algemene :)

Dit is een grote uitdaging. Voor nieuwe sites, met een beperkt aantal pagina's en weinig inhoud op zo'n pagina is het al lastig om zoiets goed op te zetten. Bij Tweakers lopen we helemaal tegen allerlei moeilijkheden aan. Hoe detecteer je bijvoorbeeld op een betrouwbare manier welk apparaat wordt gebruikt? Een lijst namen aanleggen is niet praktisch en zodra er een nieuw apparaat komt of een bestaand apparaat een software-update krijgt, kun je de lijst weer bijwerken. Bovendien zegt een naam niet alles; de diverse maten iPads hebben bijvoorbeeld dezelfde 'user agent'. Je kunt ook niet naar de resolutie kijken, want bij een 1080p-resolutie kan het om een 5"-telefoon of een 80"-tv gaan en alle maten schermen daartussenin. Omdat de techniek nog vrij jong is, is er nog geen volledig uitgewerkte standaardmethode waarmee de diverse mobiele en desktopbrowsers een mooie, consistente manier van werken aanbieden.

Andere uitdagingen betreffen de keus wat we wel en wat we niet direct op het scherm willen tonen. Hoe kleiner het gebruikte scherm, hoe minder je aan overbodige informatie wil tonen en hoe minder ruimte je wil verspillen. Maar wat is overbodig en wat is verspilling? De opinie daarover verschilt per bezoeker en per gebruiksdoel. Extra witruimte tussen twee knoppen zorgt er op een touchscreen voor dat je minder snel de verkeerde knop indrukt, maar is onnodig als je met een muis of toetsenbord navigeert.

Kortom, we zijn ermee bezig en gaan er ook in de komende iteraties mee verder. Het is echter nog niet in een stadium aangeland waarin we de wijzigingen op Tweakers.net kunnen loslaten. Je zult dus nog zeker een paar iteraties moeten wachten voordat je er profijt van hebt :)

Android & iOS

Naast een responsive design is er ook wat tijd vrijgemaakt om enkele verbeteringen en fixes aan te brengen in onze mobiele apps. Zo is in de Android-app een vervelende bug opgelost die tot gevolg had dat het inloggen niet altijd lukte. Ook gaf een '&' problemen bij het plaatsen van een reactie. De niet werkende videoplayer is gemaakt en vanaf heden zal de native videoplayer in Android worden gebruikt voor het afspelen van video's. Verder zijn enkele bugs opgelost die de applicatie lieten crashen en worden externe links nu niet meer in de app zelf geopend.

Wat de iPhone-app betreft: deze ondersteunt nu de iPhone 5 en ook iOS 6. Daarnaast zijn er kleine ui-aanpassingen gedaan, is de videoplayer verbeterd en is er een bug geplet bij artikelen met embedded content. Daarnaast is de gerelateerde content van een artikel verbeterd.

De updates voor beide apps worden apart vrijgegeven via de beide appstores. Op dit moment is nog niet bekend wanneer we de apps precies zullen vrijgeven, dus we vragen nog even jullie geduld.

Overige

Natuurlijk zijn er een hoop andere zaken verbeterd. Hieronder de verbeteringen die het noemen waard zijn:

- betere foutmeldingen bij het uploaden van een verkeerd bestand bij Profielfoto;
- de mogelijkheid om gedeelde video's nu direct af te spelen op Facebook;
- zichtbaarheid van het aantal kilometers in Vraag & Aanbod als je niet ingelogd bent;
- eenvoudiger insturen van een nieuwstip via een nieuwe frontpage-link.

Macht aan de gebruiker: part two

In de vorige iteratie zijn we ermee begonnen onze vaste gebruikers meer macht te geven. Er kon via de vorige .plan gestemd worden op vijf features. De feature met de meeste stemmen wordt opgepakt, terwijl die met de minste stemmen voorlopig afvalt. De feature die de meesten van jullie graag willen zien, is een mogelijkheid om de lijst met artikelen op de frontpage te kunnen opdelen in aparte lijsten per contenttype en om een contenttype helemaal uit de lijst weg te laten. Deze feature werken we in de komende iteratie verder uit.

Het verzoek om de opties in de Tweaker CV te actualiseren kreeg de minste stemmen en valt dus af. De overige drie keuzes staan weer in de poll en er zijn twee nieuwe toegevoegd:

  1. links naar Myreact, Active topics en Bookmarks overal op het forum rechts naast de breadcrumb
  2. alternatieve weergave categoriebrowser

Welke feature wil jij in de volgende iteratie zien?

Keuzeoptie voor meer dan 25 resultaten bij zoekopdrachten, bijvoorbeeld 50 en 100
23,0%
Links naar Myreact, Active topics, Bookmarks overal op het forum rechts naast de breadcrumb
22,4%
Bredere forumtopics, gerelateerde producten weer erboven en uitgebreidere user-info in drop-down
21,5%
Alternatieve weergave categoriebrowser
17,4%
Binnen V&A-tabbladen (standaard) in V&A zoeken ipv Pricewatch
15,8%

Aantal stemmen: 1.341. Deelname gesloten op 17-03-2013 13:37. Stemmen is niet meer mogelijk.

Reacties (93)

Reactiefilter:-193093+187+220+30
Het liefst zou ik een update zien voor de Android app qua design... deze loopt nu echt hopeloos achter.
Zoals in de .plan vermeld staat ligt de focus op een responsive design, niet op een update voor onze native apps. Het is voor nu voor ons verstandig om slechts 1 kanaal te hebben dat we moeten bouwen, onderhouden en promoten, in plaats van iets op ieder mogelijk (toekomstig) platform
Ja lijkt me ook verstandig. Nu het mobiele spelersveld zich eindelijk weer een beetje lijkt te verbreden (blackberry, bada, windows phone, firefoxOS, ubuntu phone en sailfish) is het niet erg practisch of gewenst om voor elk platform een aparte app te bouwen die hetzelfde doel dient.
Ik vind de iPhone app een lelijk ding tegenover Android. Ik heb de update nog niet gekeken, maar gebruik nu een iPhone 5. Ik merk dat er tussen de comments veel lege ruimte is, dat bij een artikel openen gelijk een filmpje afgespeeld wordt in een nieuwe tab en nog meer kleine dingen,
Vind de app op mijn note 2 stukken beter.
wat is er dan erg aan? werkt toch goed? ..
Omdat de techniek nog vrij jong is, is er nog geen volledig uitgewerkte standaardmethode waarmee de diverse mobiele en desktopbrowsers een mooie, consistente manier van werken aanbieden.
CSS media queries?
Het is wel een klap werk om het bij zo'n grote site toe te gaan passen, maar de techniek is er zeker al wel en werkt prima.
Prima is een groot woord. Het werkt redelijk. Media Queries zullen dan ook het grootste uitganspunt worden om een devicegrade op te baseren.
Dit eventueel te samen met dingen als Modernizr en andere methodes om verouderde browsers op de been te helpen.

Bij mijn weten houd responsief maken in dat je de website beschikbaar maakt voor elke scherm grootte. Dus pas je ook de website aan aan de grootte van de website.

Ik snap daarom ook niet helemaal waarom het belangrijk is te weten welk apparaat gebruikt wordt. Dan nog, als iemand zich voor doet als ipad terwijl hij een computer is. Dat doet hij waarschijnlijk bewust en hij wilt daarom waarschijnlijk ook de indeling van een ipad op zijn pc zien (of andersom) en waarom zouden we hem dit ontnemen?

http://mobile.smashingmag...etter-responsive-website/

[Reactie gewijzigd door Sephyros op 12 maart 2013 14:45]

Maar dat is hem nou net, schermgrootte is heel wat anders dan resolutie. Op een 5 inch mobieltje met 1080P resolutie wil je alsnog niet teveel dingen in beeld, omdat het veel detail in een kleine vorm oplevert. Terwijl op een 24 inch breedbeeld met HD-resolutie je juist wel weer alle toeters en bellen wil zien. Net als de knopruimte toegespitst op touch of non-touch, dergelijke dingen kan je niet afvangen met media queries alleen.
Toch valt er goed mee om te gaan :) Zie bijvoorbeeld wat Barryvdh in 'plan: Development-round-up - Iteratie #31' zegt
Precies dit. Mediaqueries kunnen naar mijn weten nog niet goed filteren op werkelijke scherm grootte. Misschien is dit al wel mogelijk in de specs, maar het is sowieso nog niet in alle browsers proper geimplementeerd.
Dat is niet helemaal waar. Een 5" inch full HD mobieltje zal in CSS3 media queries niet de HD resolutie doorgeven. Het geeft de software pixels door, niet de hardware pixels.

Als voorbeeld: de iPhone5 heeft 640 hardware pixels in de breedte. Echter, websites worden gerendered op 320 pixels, waarna iOS de sub pixels rendered. Jij als web ontwikkelaar krijgt dus 320 pixels door, wat een veel betere weergave is van de beschikbare ruimte. In gevallen waar een scherm een high PPI heeft waarbij de software resolutie gelijk is aan de hardware resolutie (wat vreemd is, want alles wordt onleesbaar klein), dan nog heb je in CSS3 media queries de mogelijkheid om de pixel density te meten.

Bovenstaande zaken maken bovenstaande problemen een heel stuk kleiner dan gesteld. Daar is nog aan toe te voegen dat je je media queries absoluut niet op apparaten of pixels moet baseren. Je break points zijn het best relatief, gebaseerd op ems of rems. Dat zorgt er voor dat je layout en text proportioneel worden. Hiermee wordt je design veel minder afhankelijk van apparaten of resoluties.

Het is en blijft een uitdaging en een specialisme volop in beweging, maar eerlijk gezegd maak ik me een beetje zorgen over de responsive web design kennis van de tweakers crew. Het artikel en sommige comments suggereren problemen en aanpakken die eigenlijk allang not done zijn en achterhaald. Hopelijk heb ik hierin ongelijk.
Het principe van device indepedent pixels is bij ons bekend en is ook het uitgangspunt voor onze verdeling in diverse device classes, die als uitgangspunt dient om te beoordelen of de layout optimaal functioneert op de verschillende soorten apparaten. Helaas blijken niet alle devices in de standaard browser een correcte resolutie in device independent pixels door te geven.
En meteen daaronder stond al waarom zo iets niet goed gaat werken...
Je kunt ook niet naar de resolutie kijken, want bij een 1080p-resolutie kan het om een 5"-telefoon of een 80"-tv gaan en alle maten schermen daar tussenin.
Als je op een iPhone/Android je viewport width instelt op device-width, werkt dit prima, die geven dan een kleinere resolutie en een hogere pixel density.
Ja en neen. Ik vind dit persoonlijk nu eigenlijk een slecht voorbeeld, omdat je bij een TV met een 10-feet UI zit, waaarbij je net als bij een telefoon een kalere UI wilt, met grote, duidelijke, leesbare elementen.
Los daarvan blijft een responsive UI inderdaad een aartsmoeilijke oefening.
TVs zijn inderdaad een uitdaging, maar het is een beetje een border case en excuus om te stellen dat resolutie niet betrouwbaar is voor responsive design. Als je een responsive web design maakt die schaalt van 320 pixels tot full HD dan ben je al een heel eind, en op 90% van de devices kan dat perfect nu al gedaan worden door de combinatie software resolutie (niet hardware resolutie), de device-pixel-ratio en em-based layouts.

Blijft over sommige border cases zoals de TV. Besef dan dat je website nu op een TV ook niet bruikbaar is, dus slechter ben je niet geworden, maar wel 10 keer beter op alle andere devices.
Keuzeoptie voor meer dan 25 resultaten bij zoekopdrachten, bijvoorbeeld 50 en 100
Gewoon endless scroll :)
Endless scroll ziet er heel gaaf uit en werkt op sommige plekken ook erg goed, alleen is het niet goed in iedere situatie. Organisaties zoals Etsy en Booking.com hebben juist Endless scrolling weggehaald omdat dit de gebruikerservaring ontzettend in de weg zat. Als je bijvoorbeeld vanuit een lijst naar een detailpagina gaat en vervolgens weer terug gaat naar de lijst, dan eindig je altijd bovenaan ipv waar je was gebleven. Dat is verre van een ideale situatie :)
Polletje houden maar: open jij de topics uit zoekresultaten in dezelfde tab of in een nieuwe? Ik denk zelf, dat vooral hier op Tweakers het overgrote deel de topics in een nieuwe tab opent. En dat endless scroll voor velen wel ideaal is. Uiteraard kunnen ze er ook een instelling van maken :)
Voor de gebruikers die resultaten niet in een nieuwe tab openen is de teruggang in de gebruikservaring door endless scroll (en het niet terugkeren naar de resultaten waar je was toen je wegklikte) veel te groot. Je mag er vanuit gaan dat een aanzienlijk deel van de gebruikers sequentieel browst ipv parallel.
Ook hier zijn weer workarounds voor te maken. Kijk maar eens naar http://forrst.com

Als je nieuwe content load door naar onder te scrollen wordt via JS de location hash aangepast, bij page_load wordt deze gelezen en indien nodig geredirect.

Hun hebben er voor gekozen om dit per sectie artikelen te doen maar dit zou je ook per artikel kunnen doen.

Nu vind ik het per sectie doen persoonlijk nog een redelijk slechte manier, je zou hem per artikel op zo een manier kunnen doen:
http://stackoverflow.com/...-that-can-handle-the-back

[Reactie gewijzigd door Schnoop op 12 maart 2013 14:49]

Je wilt niet weten hoeveel keer Tumblr mijn browser liet crashen voordat ik die functie uit heb gezet.
Het vreet gewoon te veel memory en wat is er mis met vorige/volgende knoppen?
En hoe wil je dat doen als je een brakke 3G verbinding heb en de pagina moet daardoor opnieuw worden geladen? Moet je weer helemaal naar beneden scrollen om te komen waar je eerst was. Wat leuk.
Wat betreft de Responsive website sectie, is het niet mogelijk als een gebruiker inlogt zijn Eigen Apparaten kan koppelen met daarbij de weergave van tweakers?

Daarmee haal je het argument van identificatie van het apparaat weg en leg je dat voor vast bezoekers al vast.
Het forceren van een devicegrade op een desbetreffend device zal inderdaad tot de mogelijkheid behoren. Echter proberen we iedere bezoeker een zo goed mogelijke device grade voor te shotelen zodat dit zo min mogelijk nodig is. Media Queries zijn helaas nog niet volwassen genoeg, zo geeft de stock Android browser nog lang niet altijd de juiste resultaten. Dit gaan we dus de komende iteratie verder uitzoeken.
Daarom is het meestal een beter idee om "Mobile First" toe te passen, ofwel je site eerst geschikt maken voor mobile devices (die geen media queries ondersteunen) en met behulp van media queries je site beter maken voor desktops, tablets, etc.

Dit boek is overigens een aanrader als je er meer over wilt lezen:
http://www.amazon.co.uk/I...-Everywhere/dp/0321821688

Ik vind het ook niet zo'n slimme aanpak om te praten in termen van welke apparaten de site komen te gebruiken (iPhone, een Samsung Galaxy S3, etc.). Zo blijf je bezig als je op zo'n manier "responsive design" wilt toepassen. Wat met TV's, of in de toekomst hele andere devices? Je kunt veel beter uitgaan van de ruimte die je hebt en de features die een device heeft (zoals touch, retina support, etc). Met media queries is daar ook al (deels) ondersteuning voor. Toegegeven, nog niet alles kan ermee worden opgelost (responsive images blijft lastig), maar beetje bij beetje wordt het wel opgelost.

[Reactie gewijzigd door Nordlys op 12 maart 2013 14:42]

"Mobile First" is leuk maar we moeten werken met wat we hebben en dat is al een complete site inclusief CSS. Ik begrijp niet waar het idee vandaan komt dat we specifieke devices gaan ondersteunen, dit is namelijk simpelweg niet het geval. We werken ,momenteel enkel, met mediaqueries om de resolutie van het device te bepalen waarna de desbetreffende device grade geladen wordt. Dit is dus niet op basis van een merk telefoon nog USER_AGENT. Kort samengevat komt het er dus op neer dat Mobiel First op dit project helaas niet van toepassing is en we momenteel aan het kijken zijn in hoevere media queries kunnen worden toegepast om de gewenste resultaten op het scherm te krijgen :)

[Reactie gewijzigd door Inspector op 12 maart 2013 14:53]

Maar houdt er dus rekening mee dat door desktop down toe te passen (tegenhanger van mobile up), je Android 2.3.x en eerder, oudere BlackBerry devices, en nog heel wat andere zooi uitsluit. En je bent nogal simpel in oude besluite toe te passen. We hebben besluit X eerder gedaan, dus kunnen we mobile first niet toepassen. Da's natuurlijk flauwekul, je kunt altijd de CSS / bepaalde structuren in je site opnieuw opbouwen met mobile first...

[Reactie gewijzigd door Nordlys op 13 maart 2013 13:05]

Mobile-first is ook de weg die Bootstrap is ingeslagen voor versie 3 (responsive was nog optioneel bij 2). Daar hebben ze overigens ook al een indeling gemaakt voor device grades.

Is http://abouthalf.com/deve...nges-in-android-browsers/ het probleem waar je tegenaan loopt met Android browsers?
Daarvoor heeft men Mobile First verzonnen.

Daarnaast is dit stukje op stack overflow misschien wel een handige:

http://stackoverflow.com/...res-responsive-web-design
Nee, want dan moeten we nog een (praktisch eindeloze) lijst van devices gaan bijhouden. Dat is onbegonnen werk. We proberen het zo goed mogelijk te detecteren. Mochten we het mis hebben, dan kun je middels een device detect zelf een bepaalde weergave kiezen. Mocht het bijvoorbeeld per ongeluk voorkomen dat we op een HiDPI-smartphone de 'tablet'-variant serveren, dan kun je zelf aangeven dat het apparaat dat je gebruikt een smartphone is :)
Je hoeft ook niet de selectie te maken aan de hand van lijsten. Tweakers weten heus wel wat de details van hun apparaat zijn, en kunnen dus prima zelf aangeven hoe ze per apparaat tweakers willen bekijken.
En dat kunnen ze dan ook doen, mochten wij het zelf niet goed kunnen detecteren. Zo slaan we twee vliegen in 1 klap :)
Dat werkt uiteraard alleen voor mensen die de moeite daarvoor willen nemen. En niet voor de vele anderen die dat niet willen :)

Maar ik zou het zelf ook wel handig vinden als we daar wat mee kunnen gaan doen.
Ik doel inderdaad op de mensen die vaak actief zijn op tweakers, en dus al een optie hebben om dit in te stellen.

Dus een setting dat je een resolutie kunt kiezen met daarbij een scherm oppervlak.

[Reactie gewijzigd door pedaalemmer op 12 maart 2013 14:32]

Een responsive website reageert (past zich aan) op de beschikbare ruimte die er is om de site weer te geven. Dit handmatig op te moeten geven is anti-responsive te noemen :P
Mee eens, daarom proberen we dit ook zo goed mogelijk te detecteren. Maar de ervaring leert ons dat Tweakers graag zelf het heft in hand nemen en dus soms de device grade die voor hen bepaalt is willen over-rulen. Die optie zullen we dus ook bieden :) Daarnaast kan ik me voorstellen dat een Full HD tv herkent word als device grade A (de reguliere website) maar dat grade C of zelfs B hier beter voor geschikt is. Hierin wordt de content namalijk groter weergegeven wat handig kan zijn als je ver van de TV af zit. Om dan te kunnen forceren op een andere grade is een mooi extraatje.
Dat is noch een duurzame, noch een efficiŽnte of noch een gebruiksvriendelijke methode.
Stel je voor hoeveel werk het niet is, voor elke (nieuwe) device de weergave te testen? Voor tweakersleden is het koppelen van apparaten misschien maar een ťťnmalige hindernis, maar wat met bezoekers die geen leden zijn of niet ingelogd zijn? En zo zijn er nog meer problemen.

Persoonlijk ben ik geen voorstander van device-driven responsive webdesign. Het is veel toekomstgerichter te werken vanuit een device-agnostic approach. Je bouwt de responsiviteit van de website vanuit de weergave van de content zelf en niet vanuit een specifiek apparaat.

Een mooi voorbeeld van zo een aanpak is de Goldilocks Approach. Maar zoals de Tweakers DevCrew correct stelt is dit geen gemakkelijke aanpak voor een complexe website als Tweakers en daarbij is responsive webdesign nog steeds in zijn kinderschoenen.

[Reactie gewijzigd door c-mattic op 12 maart 2013 14:41]

"Wat de iPhone-app betreft: deze ondersteunt nu de iPhone 5 en ook iOS 6."

Wanneer krijg ik de app te zien op fullscreen op mijn iPhone 5? De zwarte balken zijn echt heel vervelend.
Dat zit dus (eindelijk) in de komende release :)
Volgens mij moet de app eerst worden goedgekeurd door Apple, vervolgens zie je hem als update, met deze veranderingen. (correct my if i got wrong)
Dat klopt helemaal. :) Hij ligt momenteel dan ook bij Apple ter goedkeuring.
Grootste nadeel met Tweakers.net op android is het openen van -1 reacties. Klikken geeft geen indicatie of hij daad werkelijk laadt. Succes met openen als je in de ICE in duitsland zit :/
Niet een van de keuzes, maar wel 1 die ik graag zou willen zien:
Onderscheid tussen snelle beoordelingen (alleen sterren) en uitgebreide. Liefst nog met aanduiding of er een Tweakers beoordeling over is.
Dus bijvoorbeeld door middel van een andere kleur sterren. Dan kan je na een zoekopdracht gelijk zien waar je wat meer over kunt zien.
Ik wil op den duur de simpele reviews (die enkel sterren hebben) gaan uitbreiden met een korte nuancering die gegeven kan worden door de gebruiker. Zo snapt een lezer ook in welke context hij de score moet plaatsen en zorgt het ervoor dat een reviewer toch net ff wat langer nadenkt voordat hij de score plaatst. Zo maken we de simpele reviews ook direct een stuk waardevoller en kunnen we het apart gaan tonen. Ook kunnen we dan (speelt toekomstmuziek af) handige overzichten maken van beoordelingen op criteria incl. een korte toelichting van meerdere gebruikers. Zo heb je als lezer in 1 overzicht een volle bak aan informatie :)
Waarom is er voor gekozen om de transparantie uit de user-avatars te halen? Er zit nu een witte achtergrond achter mijn icoontje in de balk bovenaan de pagina.
Dat is niet bewust gedaan. De markup is iets aangepast om gebruik te maken van onze generieke .thumb class en die heeft toevallig een witte achtergrond ingesteld staan. Deze class werd op andere plekken al gebruikt, dus in feite had je icon overal al altijd een witte achtergrond op het menu na.
En dat blijft zo? Ik vind het niet echt mooi zo'n witte tegel in de verder zwarte balk? Het viel mij ook direct op namelijk.

[Reactie gewijzigd door jip_86 op 13 maart 2013 00:33]

Wat me opvalt is dat jullie responsive design per apparaat willen invoeren, maar dat is tegenwoordig niet meer de gebruikelijke manier. Om Trent Walton (designer van Microsoft.com's huidige responsive homepage) te quoten:
It’s good to plan, design, and test with all sorts of devices in mind, but it’s become standard to let media queried breakpoints be defined by content/layout rather than any specific device. Whenever things don’t fit or hierarchy breaks, add a media query. My favorite example of this is if we set a max-device-width media query at 480px to target an iPhone 4, the iPhone 5 wouldn’t display any of the targeted styles because the screen is larger. Fine-tuning breakpoints to the design rather than the device will make your responsive layout ready for just about any new device the market may throw at it.
Misschien is een fluid grid met breakpoints waar kolommen naar onder klappen een beter idee dan speciale layouts voor vaste breedtes/devices? Dan heb je een lay-out die voor elk willekeurig scherm en resolutie prima werkt.

[Reactie gewijzigd door haampie op 12 maart 2013 14:33]

Nee, het wordt niet per apparaat. We hebben een definitie gemaakt van vier verschillende device grades, afhankelijk van het schermdiagonaal en dpi. Vaste apparaten gaan definiŽren is een eindeloos karwei
Misschien staat het onduidelijk in de .plan maar nee, er wordt niet op device gechecked en ja, de layout wordt fluid en schaalt mee. Echter kunnen we geen fluid grid gebruiken daar we al met een bestaande website zitten. De uitganspunten zijn dus leuk maar niet geschikt voor dit project.
Wat er mis is met deze vorm van stemmen is dat er opties zijn voor de diverse onderdelen van T.net. Dat houd dus in dat als er altijd een grotere groep mensen is die alleen gebruikmaken van de FP dus alleen op die opties zullen stemmen en de rest dus al bij voorbaat geen kans heeft.
Begrijp mij goed, ik stel het op prijs dat we uberhaupt een keuze krijgen maar het zou zinniger zijn om per hoofdonderdeel een keuze te geven.
Ik zou zeggen: Open een topic en maak mensen warm om hier hun stem uit te bregen. In het verleden werden dit soort polls weleens in het Forum gepost waar de kritiek ontstond dat de frontpage gebruikers er amper kwamen en dus de poll ovwegend door Forum gebruikers overspoeld werd. :/ Het is natuurlijk een beetje van het kastje naar de muur gewezen worden. ;)
Daar heb je het forum niet voor nodig. Je kan per onderdeel prima een poll maken en op de frontpage plaatsen. WAAR de poll staat is het probleem niet. Wel hoe de enkele poll is samengesteld.
Wat er mis is met deze vorm van stemmen is dat er opties zijn voor de diverse onderdelen van T.net. Dat houd dus in dat als er altijd een grotere groep mensen is die alleen gebruikmaken van de FP dus alleen op die opties zullen stemmen en de rest dus al bij voorbaat geen kans heeft.
Als een grote groep daar behoefte aan heeft dan ligt de prioriteit voor dat onderdeel inderdaad hoger dan de overige opties zelfs als dat voor een specifiefe groep is. Je trekt de stelling dat de rest bij voorbaat al geen kans meer heeft maar vergeet niet dat de overige twee opties (laatste valt tijdelijk af) volgende maand weer terug komen in de poll. Daarnaast wil ook niet zeggen dat afgevallen opties niet gemaakt worden, sterker nog, ze worden wel degelijk ontwikkeld alleen ligt de prioriteit wat lager.
Dat zal allemaal best maar ondertussen zitten we dus nog steeds met een pricewatch en V&A onderdeel wat vanaf de invoering van T7 minder functioneel, minder intuÔtief en over het algemeen minder goed werkt als beide oude versies. En als ik dan zie aan wat voor kneuzige dingen er soms gewerkt word dan krab ik wel eens achter mijn oren. Dan komt er vervolgens weer een oplossing, de poll, waarvan je weet dat de uitslag op een dusdanige manier behandeld word dat bovenstaande zaken NOG langer gaan duren. Ik hoop dat je dan ook kan begrijpen dat het geduld gaat zakken en de irritatie gaat stijgen.
Maar dat roepen anderen ook over hun irritatiepunten. Om enige zinnige ranking te krijgen doen we het zo. Niet optimaal, maar beter dan alleen maar topics in LD.
Om enige zinnige ranking te krijgen is zoals het nu gebeurt juist niet de manier. Straks krijgen, god help us all, nog een vote over de 'ik henk en knop' . Stel nou dat die, wat waarschijnlijk gaat gebeuren, meer votes krijgt als een wel belangerijke feature, dan kan je jezelf toch niet meer serieus nemen of wel?
Er word een oplossing gezocht die gaat van het ene uiterste naar het andere. Er is ook nog een middenweg als je maar wil.
Er wordt niet een willekeurige greep gedaan uit alle feature-requests. Er wordt gekeken naar welke requests past binnen onze strategie en die verschijnen vervolgens in de poll. De 'I Henk it' bijvoorbeeld is een hartstikke leuke tool, maar ook niet meer dan dat. In die vorm zul je het hoogstwaarschijnlijk dus ook niet gaan zien op de website. :)

Op dit item kan niet meer gereageerd worden.



Populair: Samsung Intel Smartphones Processors Sony Microsoft Games Apple Politiek en recht Smartwatches

© 1998 - 2014 Tweakers.net B.V. Tweakers is onderdeel van De Persgroep en partner van Computable, Autotrack en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013