Development-round-up - Iteratie #31

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.

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

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)

[kikker81]

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.

[jip_86]

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.

[Barryvdh]

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.

[Verwijderd]

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.

[Bauknecht]

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.

[Sephyros]

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 23 juli 2024 04:27]

[MsG]

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.

[Verwijderd]

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.

[Femme]

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.

[Misha]

Toch valt er goed mee om te gaan Zie bijvoorbeeld wat Barryvdh in 'plan: Development-round-up - Iteratie #31' zegt

[markusclaas]

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.

[Inspector]

Prima is een groot woord. Het werkt redelijk. Media Queries zullen dan ook het grootste uitganspunt worden om een devicegrade op te baseren.

[Verwijderd]

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 Verwijderd op 23 juli 2024 04:27]

[Misha]

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

[Inspector]

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.

[Bosmonster]

Keuzeoptie voor meer dan 25 resultaten bij zoekopdrachten, bijvoorbeeld 50 en 100

Gewoon endless scroll

[Misha]

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

[Schnoop]

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 23 juli 2024 04:27]

[DeTeraarist]

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

[Femme]

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.

[rusman]

Daar hebben we tegenwoordig iets moois voor: http://eviltrout.com/2013...scrolling-that-works.html

[RoestVrijStaal]

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.

[- peter -]

Zie ik nu ook ads bij individuele V&A advertenties? Die vielen me eerder niet op, boven de reacties.

[crisp]

Ik denk dat je vraag moet zijn "zie ik nu ads?". Je bent namelijk ex-abonnee en door een foutje in de code heb je tot vandaag nog kunnen profiteren van een bannervrije frontpage. Helaas voor jou is dat foutje nu dus gefixed...

[- peter -]

Haha ok, tijd om weer een abbo dan maar te nemen

[pedaalemmer|IA]

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.

[Inspector]

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.

[Nordlys]

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 23 juli 2024 04:27]

[Inspector]

"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 23 juli 2024 04:27]

[Nordlys]

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 23 juli 2024 04:27]

[Rafe]

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?

[Sephyros]

Daarvoor heeft men Mobile First verzonnen.

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

http://stackoverflow.com/...res-responsive-web-design

[Misha]

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

[MenN]

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.

[Misha]

En dat kunnen ze dan ook doen, mochten wij het zelf niet goed kunnen detecteren. Zo slaan we twee vliegen in 1 klap

[ACM]

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.

[pedaalemmer|IA]

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|IA op 23 juli 2024 04:27]

[Rafe]

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

[Inspector]

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.

[c-mattic]

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 23 juli 2024 04:27]

[Brummetje]

Het liefst zou ik een update zien voor de Android app qua design... deze loopt nu echt hopeloos achter.

[Misha]

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

[markusclaas]

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.

[lifeguard]

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.

[SmokingCrop]

wat is er dan erg aan? werkt toch goed? ..

[TheAshcat]

"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.

[BaZnGaNL]

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)

[Misha]

Dat klopt helemaal. Hij ligt momenteel dan ook bij Apple ter goedkeuring.

[Misha]

Dat zit dus (eindelijk) in de komende release

[Kapiteiniglo]

Wanneer kunnen we eindelijk weer eens een filter met GEEN in de pricewatch gebruiken? Het is bijvoorbeeld nu onmogelijk om alleen m-atx behuizingen te zoeken.. (kon vroeger met het filter GEEN atx).

[Femme]

Je kunt gewoon filteren op micro atx . De toevoegde waarde van een wel/geen filter is beperkt. Het is immers ook mogelijk om alle opties aan te vinken behalve de optie die je wil uitsluiten. Dit werkt prima zolang het aantal opties beperkt is. Als het aantal opties groot is, is het weer minder waarschijnlijk dat je er specifiek één wil uitsluiten.

[ACM]

Hij wil de logische combinatie van (Micro ATX) AND NOT (ATX). Dat bieden we inderdaad al een hele tijd niet meer praktisch aan.

[Reactie gewijzigd door ACM op 23 juli 2024 04:27]

[markusclaas]

Inderdaad.. ik wil wel vaker dit soort dingen filteren maar dat kan niet meer Fix pls!

[zeef]

maak een topic in Lieve Devvers of mail naar [e-mail]

[Verwijderd]

Als ik filter op micro atx dan krijg ik daarbij ook nog steeds resultaten met behuizingen die ook atx kunnen hebben. Dat wil ik dus niet. Alles kleiner als M-atx met M-atx als reslutaat is prima maar dan toch resultaten met groter als M-atx lijkt mij niet de bedoeling.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 04:27]

[Kapiteiniglo]

Wat ciris zegt, dan krijg je ook alle ATX kasten...

[Destralak]

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 daar tussenin.

Je moet niet apparaatnamen gaan detecteren, maar gaan kijken naar media queries, fluid grids, pixel density, responsive scaling en bepaalde browsermogelijkheden (via Modernizr).

Een handig artikel over responsive design: http://www.html5rocks.com/en/mobile/responsivedesign/

[wildewouter]

Zoals al meerdere malen in comments hierboven aangegeven: Wij houden geen lijst bij van apparaten:

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.

Er wordt dus browser window gedetecteerd en bepaald of een device bijvoorbeeld een smartphone of een tablet is. Daarop reageert de stijl van de website (responsive). Hiervoor worden dus al mediaqueries gebruikt.

[Destralak]

Het is duidelijk wat je zegt, maar het artikel insinueert dat jullie je dat nog afvragen. Verder geef je aan dat er nog geen consistente methode is, terwijl dat artikel juist wel voorziet in die behoefte.
Kijk bv naar pixel density (het argument dat je geeft van die TV en tabletresolutie), responsive scaling (bv zodat je het gat tussen media queries kunt opvangen)... enzovoort.

[wildewouter]

Je hebt gelijk dat het misschien wat onduidelijk kan zijn in het artikel. De manieren die jij noemt zijn de manieren waarop wij dit willen gaan doen. Helaas is dit niet helemaal waterdicht. Je kunt door middel van density nog steeds een telefoon voor een tablet aan zien, of andersom. Het zou jammer zijn als je de smartphone layout op een tablet krijgt. Wij proberen nu vooral een goede manier te maken die de meeste coverage heeft voor alle devices (ze dus goed detecteert per device grade).

[Destralak]

In dat geval zou je de eerder genoemende technieken (Modernizr) kunnen combineren met device databases zoals van http://www.scientiamobile.com/

[Verwijderd]

Er gaan steeds meer geluiden op dat ook die device grade approach niet de juiste is. Breakpoints dienen niet op basis van populaire resoluties plaats te vinden. Ze dienen op jullie design plaats te vinden. Stel dat jullie navigatie niet meer past onder de 900 pixels. Dan is dat een breakpoint. Geen device breakpoint maar een design breakpoint. Dus pas je de styles aan op dat punt, ongeacht welk device onder de 900 pixels zit, smartphone of tablet...boeit niet.

En ook die design-based (ipv device-based) breakpoints zijn niet ideaal. Ze zouden op basis van ems moeten plaatsvinden, niet op pixels. Dat maakt ze proportioneel, en nog minder afhankelijk van devices.

[Misha]

Maar dat is dus ook exact wat we aan het doen zijn. We hebben op veel devices gekeken wat het met onze website doet, tevens hebben we onze websites wat zitten schalen en vervolgens gekeken wat er allemaal wegviel/niet meer paste. Op basis daarvan hebben we wat uitgangspunten gedefinieerd and so on

[Verwijderd]

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.

[Inspector]

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.

[Verwijderd]

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.

[Inspector]

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.

[Verwijderd]

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.

[zeef]

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.

[Verwijderd]

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.

[Misha]

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.