Development-round-up - Iteratie #42

Het developmentteam heeft in de afgelopen drie weken gewerkt aan iteratie 42, waarin 68 tickets werden weggewerkt. Door de afslanking van de afdeling Technology in september was er aanzienlijk minder tijd beschikbaar dan we gewend zijn. De focus lag bij het responsive maken van de Pricewatch en het bouwen van betere overzichtspagina’s voor de productcategorieën. Daarnaast werden er talloze kleine verbeteringen en bugfixes uitgevoerd, werd de iOS-app bijgewerkt en werden er verbeteringen uitgevoerd aan de onlangs vernieuwde Pricewatch Manager waarmee winkels hun prijzen in de Pricewatch kunnen beheren.

Responsive Pricewatch

Op dit moment leggen we de laatste hand aan de open bèta van het responsive design van Tweakers. De responsive lay-out zorgt ervoor dat de website op alle soorten apparaten optimaal tot zijn recht komt, van smartphones tot desktops met grote beeldschermen. De focus ligt in eerste instantie bij smartphones omdat de website al vrij goed werkt op tablets. In iteratie 42 werden de zoekresultaten in de Pricewatch en de productlijsten die getoond worden op categoriepagina’s geoptimaliseerd voor smartphones en tablets. Op kleine beeldschermen worden de filters die normaal gesproken naast de productlijst worden weergegeven, ingeklapt boven de lijst getoond. Een druk op Filters maakt een lijst zichtbaar van de beschikbare filters en die kunnen vervolgens een voor een opengeklapt worden om het desbetreffende filter in te stellen.

Ander werk aan responsive betrof diverse kleine verbeteringen zoals het updaten van de notificatietellers, de weergave van pushmessages en de weergave van de tabs in de productomgeving. We verwachten nog enkele iteraties nodig te hebben voordat de responsive lay-out als publieke bèta beschikbaar zal zijn.

Nieuwe categorieoverzichten

In de huidige categoriepagina’s ontbreken goede overzichten die een indruk geven van de populaire producten in een categorie en de content die we over een categorie aanbieden, zoals reviews, koopadviezen en best buy guides. We hebben een verbeterd ontwerp gemaakt voor de overzichtstabs, dat iteratief opgeleverd gaat worden, beginnend met een pagina waar je veelgebruikte filters, het eventuele koopadvies en de eventuele best buy guide, de populairste producten en de laatste reviews in een categorie kunt raadplegen.

Later willen we aan de filters handmatig samengestelde voorselecties toevoegen die bij laptops bijvoorbeeld de keuze bieden uit subgroepen binnen de categorie zoals ultraportables, mobiele werkstations en gamelaptops. De voorselecties kunnen een combinatie van verschillende filters zijn, bij een ultraportable bijvoorbeeld bepaald door afmetingen en gewicht.

In de toekomst zal vanuit plekken op de site waar de focus breder is dan prijzen naar de overzichtstab gelinkt worden. Vanuit de categoriebrowser op de Pricewatch portal klik je nog steeds door naar de productlijst.

Bijwerken iOS-app

De lichte en platte vormtaal in iOS 7 betekende een radicale verandering in de vormgeving van Apples mobiele besturingssysteem. Apps die niet zijn aangepast voor iOS 7 laten de gebruiker terugkeren naar een tijdperk waarin donkere gradients, schaduwen en zware typografie de norm waren. In een timebox van twee dagen hebben de developers ernaar gestreefd om het uiterlijk van onze iOS-app zoveel mogelijk in overeenstemming met de stijl van iOS 7 te brengen. Het bijwerken van de app was ook nodig om een bug met betrekking tot het inloggen in iOS 7 te verhelpen. Om de app te kunnen compileren met de nieuwe versie van Xcode moest de app op meer plekken aangepast worden. Het oppoetsen van de iOS-app is work in progress en het resultaat wordt nog niet met deze iteratie vrijgegeven.

Meuktracker omgezet naar Symfony

In iteratie 42 werd de Meuktracker omgezet naar het Symfony-framework, zodat de Meuktracker nu dezelfde listings met een facetted search heeft als andere onderdelen van de site. Gelijktijdig werden de meeste pagina's van de Meuktracker responsive gemaakt.

Optimaliseren prestaties videoplayer

De responsiviteit van de videoplayer, die ontwikkeld wordt door StreamOne, werd verbeterd door de afbeeldingen van de skin in te pakken in een zipfile zodat er geen losse requests voor elk plaatje gedaan hoeven te worden. Dit zorgde voor een besparing van het aantal requests met een factor drie en een afname van de laadtijd met veertig tot zestig procent.

Nieuwe browserdetectiemethode

We hebben een eenvoudiger methode ontwikkeld om server-side browsers te detecteren. We maakten hiervoor gebruik van Wurfl, maar die methode is onderhoudsgevoelig en biedt meer mogelijkheden dan we nodig hebben. De browserdetectie wordt gebruikt om vast te stellen of de browser op een desktop of mobiel apparaat draait. Op basis hiervan worden bijvoorbeeld bepaalde advertentieformaten getoond en het aantal items in een lijst aangepast. De oude detectiemethode via Wurfl zorgde er steeds vaker voor dat browsers verkeerd werden herkend, waardoor bijvoorbeeld abusievelijk werd aangenomen dat een browser geen JavaScript ondersteunde met verlies van functionaliteit als gevolg.

Nieuwe frontpage

Het productteam is de afgelopen weken bezig geweest met het maken van ontwerpen voor een verbeterde frontpage die de populairste productcategorieën beter toegankelijk maakt, best buy guides een vaste plek geeft, een aantrekkelijkere vormgeving heeft van de redactionele ankeilers en trending producten een mooiere positie geeft. Binnenkort zullen we de ontwerpen voorleggen aan de community en zullen er usabilitytests uitgevoerd worden.

Nieuwe storageserver

Onlangs hebben we twee Sun ZFS Storage 7120 storage appliances in gebruik genomen die de opslag verzorgen van vm-images, video's en afbeeldingen van zowel de redactie als gebruikers. De machines zijn elk gevuld met 48GB ram en elf 3TB-harde schijven, resulterend in een bruto opslagcapaciteit van 66TB waarvan netto 20TB overblijft. In elk van onze twee datacenters is een 7120 geïnstalleerd. De servers repliceren alle data naar elkaar toe zodat de data toegankelijk blijft bij het omwaaien van een van de datacenters.

Reacties (96)

resulterend in een bruto opslagcapaciteit van 66TB waarvan netto 20TB overblijft.

Dus Tweakers gebruikt 46TB?! Is er ergens een grafiekje wat wat is? (plaatjes, tekst e.d)

Er zijn 2 servers met ieder 33TB aan schijven, welke dezelfde data bevatten. Daarnaast wordt er waarschijnlijk een RAID-vorm toegepast zodat de server door kan draaien als er 1 schijf wegvalt. Zo blijft er 20TB aan capaciteit over.

kweet niet, maar dat zou neerkomen op raid5
dan blijven er 10 disks van 3tb over dus 30tb.

maar als dit is wat ik denk dat het is, dan komt het neer op 4x3tb in raid10 voor vms
en 9x 3tb in raidz2 (raid6) voor data. wat dus 7x3tb = 21tb, pak hier de formule van 1024 / 1000 TB/TiB (ja vergeet mn hoofdletters enzo) en er blijft 20tb over.

4 + 9 = 13, dus dat past sowieso niet in 11

Vziw is het 4x3TB in striped mirror (raid10) en 7x3TB in raidz2. Wat dus netto respectievelijk 2x3TB = 6TB en 5x3TB = 15TB oplevert. Daarnaast is er nog wat reserved space enzo.

Het totaal wordt dan dus ongeveer 20TB.

ja ik reken compleet krom 11 en 13 door elkaar halen .

maar zo komen we er wel. even 2 disks die ik erbij heb bedacht eruit gooien, en de raid10 set erbij optellen.
ik denk dat het niet reserved space is maar echt 1000x1000x1000x1000 vs 1024x1024x1024x1024 (ik heb van mijn 12tb ook maar 11tb bruikbaar door deze stunt van hdd fabriekjes)

Mijn ervaring is het dat alleen Microsoft niet snapt dat kilo 1000 is, en niet 1024. Aangezien er een BSD-variant op de betreffende server draait is dit 'omrekenen' niet van toepassing.

Reserved space is meer omdat je schijven niet geheel partitioneert, maar een klein deel aan het einde leeg laat. Dit doe je om er voor te zorgen dat als je een nieuwe schijf plaats ter vervanging van een defecte, deze zeker genoeg ruimte heeft om de data op kwijt te kunnen. De grootte van een 3TB-schijf kan best wel eens met enkele MB's verschillen naargelang de serie, en je wilt niet het risico lopen dat je nu 'grote' 3TB schijven hebt en een vervangende schijf 'klein' is.

Daarnaast lust uiteraard het filesystem ook nog wat ruimte.

[Reactie gewijzigd door dcm360 op 29 oktober 2013 13:56]

Bedankt voor de info. Ik ga er ff een kop koffie ingooien, dat is zo te zien nodig

Zie dcm360

We gebruiken momenteel in de buurt van de 3TB, waarvan een groot deel in de Video-files en waarbij bovendien door deduplicatie (sommige files staan omdat dat eenvoudiger werkt effectief 2x op disk) blijft daar zo'n 2TB op de disks over.

Daarnaast gaan we ook VM-images hierop zetten. Die zijn nu goed voor 7TB, maar daar gaan (we o.a. tijdens het verhuizen) nog wat in snoeien. En bovendien zou ook daar deduplication nuttig werk moeten verrichten.

Ah, ja VM images tikken aan meestal. Welke virtualisatie techniek gebruiken jullie als ik vragen mag (of een linkje als dat in een ,plan ofzo al ergens staat)? KVM, vmware, iets anders?

(Nu gaat m'n geekybone jeuken )

Daar gebruiken we momenteel KVM voor, dat werkt prima voor ons

Met alle tests die ik gedraaid heb kwam KVM voor mij ook het beste uit de test. Gebruiken jullie virsh of gewoon plain SSH om te verbinden met je instances (ik neem aan dat het Linux/BSD machines zijn ;-))?

Ik gebruik zelf virsh om m'n setup (simpele op het moment, 2 webservers en 1 caching server) te beheren. Werkt érg fijn.

Ik ben wel benieuwd hoe een 'grote jongen' als Tweakers dat doet (geekbone gaat nog meer tintelen nu )

Onze vm servers zijn ook erg simpel, we zetten namelijk alleen vm's op die niet direct door users gebruikt worden op de website. Denk hierbij aan mail-filters, video-transcode, irc-server, development omgevingen, log servers etc. De performance van vm's is om te janken dus dat gaan we niet gebruiken om users te bedienen.

Verder worden de vm's net zo beheerd als de normale servers, dus via ssh/puppet etc, als ik specifiek een vm moet beheren pak ik de vnc console via virt-manager

Mua, ligt eraan hoe je het instelt. Ik heb VM's gezien met een performance waar menig bare metal oplossing een puntje aan kon zuigen. Toegegeven dat was 1 op de 100.

En, ah, via virt-manager/vnc. Dat kan ook inderdaad.

Als een vm een goede performance heeft, dan heeft hij die performance ook op de machine waar die vm op draait en omdat er dan geen extra laag tussen zit is die performance nog beter. Een VM kan nooit beter presteren dan de bare metal waar hij op draait en aangezien er altijd iets van overhead tussen zit zal de performance van de service in die vm dus hoger zijn op de bare metal waar de vm op draait.

Ligt eraan hoe "stevig" je moeder machine is en wat je doet op de kind machine.

Als je een super zware moeder hebt en alleen logging VM's draait bijvoorbeeld, of IRC-servers dan is je performance hit vrij klein geloof ik.

Zoals je zei: bare metal heeft áltijd voordelen.

Klopt, en daarom gooi ik die onbelangrijke services waar de performancehit niet uitmaakt in een vm

Er zijn uiteraard ook voordelen aan vm's, zoals het eenvoudig migreren naar een andere server, hogere uptime, eenvoudig starten/stoppen etc. Maar voor veel machines (webservers om maar iets te noemen) heb ik liever een bare-metal oplossing vanwege de performance.

Het hangt er helemaal van af hoe de applicatie die je draait schaalt op bare-metal en virtueel. Het is bijvoorbeeld al bewezen dat men meer exchange mailboxen kwijt kan op één fysieke machine door virtualisatie. Er wordt dan namelijk een veel betere verdeling gemaakt van de load (meerdere mailboxservers i.p.v. 1 grote mailbox server).

Dit is vaak het geval als 1 bepaalde resource (Network, Disk IO, CPU of MEM) je schaalbaarheid beperkt. Door virtualisatie kun je resources beter mixen (een CPU intensieve VM en een netwerk intensieve VM draaien op één box bijvoorbeeld).

Ja, het kan een oplossing zijn voor bijvoorbeeld de exchange boxen - ik ben totaal geen exchange specialist, dus ik redeneer puur vanuit een linux oogpunt qua services etc - maar je kan die exchange server ook gewoon meerdere keren starten op dezelfde bare-metal machine, bijvoorbeeld door elk naar een ander ip te laten luisteren, op een andere disk te laten schrijven en ervoor te zorgen dat je hem op de juiste cpu's bind en de juiste numa geheugen set geeft.

Nu snap ik wel dat dat met windows wat lastiger gaat en dat je dan beter vm's kan gebruiken, maar dat blijft een extra laag tussen de service en het bare metal.

En het is zeker een oplossing om meer te doen met minder resources, dat ontken ik ook nergens, maar je zal er altijd wat performance voor moeten inleveren

We hebben een eenvoudiger methode ontwikkeld om server-side browsers te detecteren. We maakten hiervoor gebruik van Wurfl, maar die methode is onderhoudsgevoelig en biedt meer mogelijkheden dan we nodig hebben.

Kunnen jullie kort toelichten welke methode jullie nu gebruiken?

We hebben zelf een component geschreven dat feitelijk alleen probeert de browser en het plaform/OS en eventueel bijbehorende versienummers te achterhalen op basis van user agent.
Feitelijk doen we daar maar een paar dingen mee (naast het bijhouden van statistieken); zo voorkomen we bijvoorbeeld dat er flash-advertenties worden geserveerd op iOS of Android en nog een aantal andere dingen. In elk geval zijn dat geen zaken die bij een false positive of negative nadelige consequenties voor de gebruiker hebben.

In ons responsive project maken we verder volledig gebruik van media-queries en clientside feature detection om de website aan te passen aan het gebruikte device

[Reactie gewijzigd door crisp op 29 oktober 2013 12:45]

En dan de domste vraag van allemaal, welk OS draait er op deze server? Gezien er van KVM gebruik gemaakt wordt kan het alleen maar een Linux variant zijn. Gebruiken jullie Ubuntu 12.04 LTS ofzo?

De nieuw geplaatste storage-machines draaien natuurlijk gewoon Sun/Oracle's eigen (applicance-versie van) Solaris. Maar de servers draaien in Ubuntu LTS, dus vooralsnog 12.04.

Bedankt jongens, fijn dat jullie even reageren. Ik ben altijd al een grote fan geweest van OpenSource en zeker van Ubuntu. Het is dan ook fijn te zijn dat er nog mensen hiervan gebruik maken

Thuis gebruik ik ook de gewone Ubuntu LTS 12.04 voor het stabielere werk en als ik echt eens wil knutselen val ik terug op de nieuwere 13.10. Waarvan ik eigenlijk toch moet zeggen dat die er best wel knap uitziet. Misschien niet alle nieuwe features die de mensen verwachten, maar het werkt wel lekker vlot en vloeiend. Alsof het meer gepolijst is door de jaren... Unity is er alleen maar beter op geworden.

[Reactie gewijzigd door GBB1 op 29 oktober 2013 13:52]

Ja op bijna alle servers hier draait Ubuntu 12.04 LTS

hier zit je nogal fout.

smartos is een solaris fork en die hebben kvm vrijwel compleet geport naar smartos.

Maken jullie gebruik van Symphony of van Symfony? Lijkt veel op elkaar maar de eerste is een cms het andere is een bekend framework

Ik heb de typo hersteld. We gebruiken het PHP Framework. Ons CMS hebben we zelf ontwikkeld.

In ons CMS maken we overigens wel weer gebruik van Symfony.

[Reactie gewijzigd door Misha op 29 oktober 2013 12:35]

Het CMS (zover ik weet) is maatwerk en word nu langzaam omgebouwd naar een maatwerk CMS op basis van het Symfony PHP framework.

Correct me if I'm wrong.

Tweakers gebruikt Symfony.

In de nieuwe IOS app, is dan ook eindelijk, maar dan ook echt eindelijk, landscape support ingebakken Tweakers app op mijn ipad zou dan een heel stuk prettiger werken.

Nee, we voegen geen features toe. Landscape-support zit er niet in en zal niet komen, net als een app speciaal voor de iPad

Mag ik vragen wat de redenen zijn om tot dat besluit te komen? Tablets worden toch veelvuldig gebruikt en verschrikkelijk veel mensen gebruiken tablets i.c.m. een hoesje waarbij je dus in landscape werkt.

Omdat we ons gaan focussen op onze website in plaats van native apps. Onze website is prima te gebruiken op een 10" tablet in portrait. Met ons responsive design pakken we direct alles onder de 7". Dan hebben we enkel nog een gat tussen de 7" en de 10" die we ook nog zullen opvullen.

De grote voordelen van deze aanpak is dat we maar 1 contentsilo hebben die we moeten bouwen, onderhouden en promoten, al onze gebruikers altijd op onze allerlaatste versie zitten, je niet expliciet Tweakers hoeft te installeren op je telefoon om onze content fatsoenlijk te nuttigen op je device en je automatisch landscape support hebt.

Helemaal helder

Onlangs hebben we twee Sun ZFS Storage 7120 storage appliances in gebruik genomen die de opslag verzorgen van vm-images, video's en afbeeldingen van zowel de redactie als gebruikers.

Is hier niet meer info of achtergrondinformatie over? Vroegah, toen de drempels nog kuilen waren, werd er uitgebreid verslag gedaan van nieuwe servers. Jammer, dat dat tegenwoordig wordt weggeschoven in een development .plan (hoort daar ook niet thuis lijkt me...) .

Om nu telkens bij de aanschaf van nieuwe hardware een uitgebreid achtergrond artikel te schrijven lijkt me toch ook wat overdreven, zeker daar deze in het verleden de revue al zijn gepasseerd. Vandaar dat het hier de .plan mijn inziens wel gerechtvaardigd is. Daarbij kost het schrijven van zo'n artikel behoorlijk wat tijd en daar deze artikelen doorgaans door het development team zelf worden geschreven heeft dit momenteel minder prioriteit. Toevallig wordt er op dit moment wel gekeken naar de mogelijkheid voor een nieuw artikel (van technische aard). Maar dat zal dan niet over de storage gaan

Hoewel het nieuwe machines zijn, verandert er fundamenteel niet echt iets aan de opstelling zoals hier al beschreven:

reviews: Tweakers' serverpark anno 2013

Het belangrijkste verschil is dat deze machines daadwerkelijk complete replicatie-features en failover-mogelijkheden hebben (en uiteraard dat we er nu 2 identieke hebben), waar dat met onze oude oplossing nog een beetje erbij gehacked was.

Helaas schiet het vermelden van nieuwe serverhardware er tegenwoordig een beetje bij in. Dat komt waarschijnlijk ook omdat we er zelf domweg niet zoveel meer expliciet, hands-on mee bezig zijn.
Het spannende is er na een jaar of 10 wel af, sowieso kopen we alleen nog maar off-the-shelve systemen en het plaatsen van hardware in de colocatie is tegenwoordig ook een kwestie van een uurtje werk en dan weer gauw uit die lawaaiige datacentra terug naar onze bureau's op kantoor

Betekenen al die aanpassingen in de PW dat je eindelijk ook op naam kan sorteren?

Even geprobeerd, maar nu in ieder geval nog niet.

Deze en alle honderden andere verzoeken gaan niet vanzelf. Dus zolang we er geen expliciete moeite voor doen, zal het niet 'eindelijk ook' mogelijk worden doordat we zijdelings gerelateerde of zelfs niet gerelateerde andere zaken aanpakken.

Dus helaas, we hebben nog altijd geen goede manier verzonnen om de ruimte - die af en toe te krap is voor de sorteeropties als ook productnaam er bij komt - te tonen. Althans, op de momenten dat we niet met een van de duizend-en-een andere dingen bezig waren

Je kunt nu in elk geval nog ?orderField=name in je URL meegeven. Als je het echt mist...

Het mag misschien arrogant overkomen maar dat is het zeker niet; wanneer gaan jullie eindelijk eens de Android App mooier maken? die zit nu nog met Froyo/Gingerbread design language...

We hebben geen plannen om dit in de nabije toekomst te doen. We hebben binnenkort een mooie RWD, wat het gebruik op de smartphone vele malen beter maakt. Het zorgt er meteen voor dat al onze functionaliteit voor zover redelijk beschikbaar is ipv een kleine subset. Als je wil, dan kan ik je alvast toegang geven tot de besloten beta. Stuur me daar even een DM voor.

Het punt dat hier gemaakt wordt is dat er twee dagen gedevelopt wordt aan een iOS app, terwijl het marktaandeel van Android al jaren hoger is, al helemaal bij de doelgroep van Tweakers.net. Dit geeft mensen het gevoel dat de iOS app een soort lievelingetje van de crew is, en dat men Android maar niks vindt.

Toen de iOS app uit kwam in juni 2010 kan ik me nog goed herinneren hoe er moord en brand geschreeuwd werd dat er geen Android app was. Rond die tijd was Android al het grootste mobiele platform (klik), en dan nemen we nog niet eens mee dat jullie doelgroep sowieso al meer geneigd is om Android te nemen vanwege de tweakability: binnen jullie userbase was het marktaandeel toentertijd waarschijnlijk nog hoger dan de links suggereren.

Het duurde 9 maanden, dus tot maart 2011, voordat er een Android app werd bekendgemaakt, welke altijd een beetje karig is geweest in vergelijking met de iOS app.

Ik heb recentelijk vaker discussies gezien tussen users en crew over het updaten van de Android app, en altijd werd er gezegd dat er niet meer aan gewerkt werd en dat het responsive design top prioriteit had. Toch zijn er nu 2 dagen besteed, als ik de tekst letterlijk mag nemen zelfs door meerdere developers, om de iOS app weer vlot te krijgen. Mijns inziens is de opmerking van magatsu dan ook zeer begrijpelijk: het lijkt erop dat keer op keer het lievelingetje iOS wordt voorgetrokken (waarom eigenlijk? heeft een groot deel van de crew een iPhone?), terwijl het marketing-technisch een zeer onbegrijpelijke keuze is.

Misschien zie ik iets over het hoofd, maar kunnen jullie die iOS en Android apps niet beter gewoon helemaal uit de markt halen en die dev-uren aan het responsive design besteden? Twee dagen van meerdere devs zijn een hoop uren, daarin kunnen jullie veel gedaan krijgen lijkt me zo. De beta van het responsive design bevalt mij op mijn Windows Phone nu al beter dan de Android app die ik op mijn vorige telefoon gebruikte. Als het responsive design af is kunnen naast de Android en iPhone gebruikers ook de mensen met een BB, Windows Phone of een ander smartphone OS fijn gebruik maken van jullie site. Het lijkt me dat een eerdere release hiervan de voorkeur zou moeten hebben boven een update van een bijna-deprecated iOS app...

Het punt dat hier gemaakt wordt is dat er twee dagen gedevelopt wordt aan een iOS app, terwijl het marktaandeel van Android al jaren hoger is, al helemaal bij de doelgroep van Tweakers.net. Dit geeft mensen het gevoel dat de iOS app een soort lievelingetje van de crew is, en dat men Android maar niks vindt.

Dat het wereldwijd groter is, betekent niet per direct dat het bij Tweakers ook groter is. Zo kan ik ook refereren naar bronnen waaruit blijkt dat Android weliswaar een groter marktaandeel heeft, maar dat iOS vele malen actievere gebruikers zijn en netto meer online zitten. Uiteindelijk maakt het globale plaatje niet uit; het maakt voor ons uit wat het op Tweakers doet. En bij ons gaat het een beetje gelijk op. Als je overigens op de vloer kijkt wat iedereen qua smartphone gebruikt, dan zul je veel vaker Android tegenkomen dan iOS.

Toen de iOS app uit kwam in juni 2010 kan ik me nog goed herinneren hoe er moord en brand geschreeuwd werd dat er geen Android app was. Rond die tijd was Android al het grootste mobiele platform (klik), en dan nemen we nog niet eens mee dat jullie doelgroep sowieso al meer geneigd is om Android te nemen vanwege de tweakability: binnen jullie userbase was het marktaandeel toentertijd waarschijnlijk nog hoger dan de links suggereren.

Het duurde 9 maanden, dus tot maart 2011, voordat er een Android app werd bekendgemaakt, welke altijd een beetje karig is geweest in vergelijking met de iOS app.

Ik zou hier graag dieper op willen reageren, maar in die tijd werkte ik pas een maand bij Tweakers en hield ik mij niet bezig met de apps of de mobiele strategie. Waarom er toen als eerst voor iOS is gekozen ipv Android weet ik niet maar er zal vast een valide reden voor zijn geweest.

Ik heb recentelijk vaker discussies gezien tussen users en crew over het updaten van de Android app, en altijd werd er gezegd dat er niet meer aan gewerkt werd en dat het responsive design top prioriteit had. Toch zijn er nu 2 dagen besteed, als ik de tekst letterlijk mag nemen zelfs door meerdere developers, om de iOS app weer vlot te krijgen. Mijns inziens is de opmerking van magatsu dan ook zeer begrijpelijk: het lijkt erop dat keer op keer het lievelingetje iOS wordt voorgetrokken (waarom eigenlijk? heeft een groot deel van de crew een iPhone?), terwijl het marketing-technisch een zeer onbegrijpelijke keuze is.

Er is nu door 1 developer zeer kort aandacht aan besteed. De reden was simpel: de app was fundamenteel stuk. Ik denk dat de beschrijving in de .plan mensen het verkeerde beeld zet van wat we met de update doen; we repareren het. We redesignen het niet. Natuurlijk komt met iOS 7 automatisch een hoop dingen mee, maar als ik eerlijk ben is het nog steeds een lelijke app. Je kunt echter wel weer gewoon inloggen want dat was compleet stuk. Stel dat in de Android app met de nieuwe Androidversie dat ook stuk zou gaan, dan zou ik dat ook laten repareren. Mocht direct automatisch een stuk Holo-interface meekomen; mooi meegenomen.

Misschien zie ik iets over het hoofd, maar kunnen jullie die iOS en Android apps niet beter gewoon helemaal uit de markt halen en die dev-uren aan het responsive design besteden? Twee dagen van meerdere devs zijn een hoop uren, daarin kunnen jullie veel gedaan krijgen lijkt me zo. De beta van het responsive design bevalt mij op mijn Windows Phone nu al beter dan de Android app die ik op mijn vorige telefoon gebruikte. Als het responsive design af is kunnen naast de Android en iPhone gebruikers ook de mensen met een BB, Windows Phone of een ander smartphone OS kunnen fijn gebruik maken van jullie site. Het lijkt me dat een eerdere release hiervan de voorkeur zou moeten hebben boven een update van een bijna-deprecated iOS app...

Je schakelt niet zomaar tussen een app en een website. We gaan de app waarschijnlijk gewoon op den duur uitfaseren zodra ons responsive design voldoende gerijpt is om voor iedereen aan te zetten. Tot die tijd zullen we hem sowieso in de store houden.

[Reactie gewijzigd door Misha op 29 oktober 2013 21:29]

Dat het wereldwijd groter is, betekent niet per direct dat het bij Tweakers ook groter is. Zo kan ik ook refereren naar bronnen waaruit blijkt dat Android weliswaar een groter marktaandeel heeft, maar dat iOS vele malen actievere gebruikers zijn en netto meer online zitten.

Je hebt een punt dat het marktaandeel van een mobiel OS niet gelijk staat aan de activiteit van zijn gebruikers. Desalniettemin is Android van het begin af aan erg populair geweest op Tweakers, omdat het zich in het begin best wel als het tweakbare open-source OS profileerde. Ik zou erg verbaasd zijn als iOS in 2010 Android heel erg domineerde qua pageviews, om er dan maar een activiteits-gerelateerde benchmark erbij te halen.

Er is nu door 1 developer zeer kort aandacht aan besteed.

Dan is dit wel erg ongelukkig geformuleerd in het artikel: "In een timebox van twee dagen hebben de developers ernaar gestreefd..."

maar als ik eerlijk ben is het nog steeds een lelijke app

Net als dat de Android-app ook niet moeders schoonste is. Dat de bug gefixt wordt begrijp ik, maar dat er hier een daar wat iOS7 look in wordt geplakt zonder consistency lijkt mij tijdverspilling, net als dat het mij een tijdsverspilling lijkt om "een stuk Holo-interface" mee te nemen. Het is niet consistent; dus het voegt niets toe.

Je schakelt niet zomaar tussen een app en een website. We gaan de app waarschijnlijk gewoon op den duur uitfaseren zodra ons responsive design voldoende gerijpt is om voor iedereen aan te zetten. Tot die tijd zullen we hem sowieso in de store houden.

Dat is ook een manier om het te bekijken. Aan de andere kant zijn de mobiele browsers op dit moment al zo goed dat jullie de users beter op de non-responsive site kunnen hebben dan in de app: op de site hebben leveren de users jullie meer inkomsten op(correct me if I'm wrong), daarnaast worden ze niet meer geconfronteerd met een out-dated, inconsistent look van Tweakers, die evt. zelfs een beetje jullie imago zou kunnen schaden.

Wellicht wel eens interessant om de strategie van Tweakers over mobiel / smartphone / tablet gebruik in een .plan post te behandelen. Als non-developer lees ik hier voor het eerst over responsive design en ik kan mij daar nog niet alles bij voorstellen.

Als gebruiker consumeer ik bij voorkeur nieuws wel steeds meer per smartphone en tablet (afhankelijk welke aanwezig is), persoonlijk via Android. De app loopt loopt qua usability sterk achter op die van bijv. Nu.nl.

Direct via Chrome naar Tweakers doe ik momenteel niet. Net even geprobeerd en ik ben gelijk het overzicht kwijt door de sizing van de site. Maar mogelijk is usability niet een belangrijk argument in deze...

Daar gaat ook nog een .plan over geschreven worden.

Als je wil, dan kan ik je alvast toegang geven. Als je dat wil, dan moet je mijn even een DM sturen

Toen de iOS app uit kwam in juni 2010 kan ik me nog goed herinneren hoe er moord en brand geschreeuwd werd dat er geen Android app was. Rond die tijd was Android al het grootste mobiele platform (klik), en dan nemen we nog niet eens mee dat jullie doelgroep sowieso al meer geneigd is om Android te nemen vanwege de tweakability: binnen jullie userbase was het marktaandeel toentertijd waarschijnlijk nog hoger dan de links suggereren.

Die iOS-app werd natuurlijk niet in één dag gebouwd . We zijn eind 2009 begonnen met de ontwikkeling en toen stelde het marktaandeel van Android nog weinig voor. De echte opkomst van Android begon in het voorjaar van 2010 en ergens in 2011 vond het moment plaats waarop we meer visits kregen van Android-devices dan van iPhones.

Als men de keuze maakt om een officiele smartphone-app uit te brengen, moet men er vanaf het begin rekening mee houden dat de smartphone-markt nog zeer snel kan veranderen. Bovendien werd toen al voorspeld dat Android hard zou gaan groeien. Maar goed, ik wil niet de zeurpiet uithangen, en ik weet ook niet of ik het beter had gedaan. Ik wilde alleen even inhaken op Misha's reactie, omdat ik het idee had dat hij niet snapte wat de Android gebruikers hier op Tweakers een beetje irriteerde/frustreerde.

Als men de keuze maakt om een officiele smartphone-app uit te brengen, moet men er vanaf het begin rekening mee houden dat de smartphone-markt nog zeer snel kan veranderen.

Dat hebben we ook gedaan door in 2010 te beginnen met de ontwikkeling van een Android-app.

De reden dat we de iOS app nu aangepakt hebben, is de update naar iOS7: de app werkt gewoon niet onder iOS7. Dat is de reden dat er nu die tijd ingestoken wordt. Overigens was dat met welgeteld 1 devver, namelijk ondergetekende. Ook hier wraakt zich de afslanking van het devteam: de andere iOS devver is helaas geen onderdeel meer van ons team. Overigens houdt ik mijzelf nauwlijks bezig met RWD, dus de tijd die ik aan de app besteed, wordt niet afgetrokken van dat project.

Als het aan ons (ikzelf en de andere devvers) ligt, zouden we inderdaad de apps uit de stores halen en of volledig gaan voor RWD of op zijn minst de apps van de grond af aan opnieuw opbouwen naar de huidige maatstaven. Helaas is die keus niet aan ons...

de app werkt gewoon niet onder iOS7

Goede reden op de app te updaten, al had ik dan alleen gefocust op de bug, en niet aan de looks gesleuteld(zie reactie op Misha).

Overigens houdt ik mijzelf nauwlijks bezig met RWD, dus de tijd die ik aan de app besteed, wordt niet afgetrokken van dat project.

Goed om te weten, het artikel suggereerde iets anders. Ik geef je overigens groot gelijk, ik vind het CSS-gepriegel dat bij responsive web-design vaak komt kijken geen leuk werk

Als het aan ons (ikzelf en de andere devvers) ligt, zouden we inderdaad de apps uit de stores halen en of volledig gaan voor RWD

great mindsdevelopers think alike, I guess .

Het idee is volgens mij dat de site responsive wordt, en daarmee de apps overbodig maakt.

Precies. De app wordt daarmee overbodig. Daarom hebben ze nu ook de iOS App bijgewerkt.

@magatsu Ik erger me ook dood aan die oude android app van tweakers. Heb er al diverse discussies over gevoerd met admins hier maar het blijkt een managementbeslissing te zijn dat er geen moeite wordt gestoken in een app voor gebruikers die de app prefereren over de site.

De iOS-app is opgelapt vanwege bugs in combinatie met iOS 7. Er is geen developmentcapaciteit beschikbaar om een reponsive website tegelijkertijd met Android- en iOS-apps door te ontwikkelen terwijl we ook nog functionaliteit aan de website verbeteren. Het is dus een kwestie van keuzes maken.

Don't get me wrong, ik snap dat er keuzes gemaakt moeten worden. Maar het opvoeren van technische argumenten werkt niet als het overduidelijk een managementkeuze is.

Het probleem is evenmin dev capaciteit. Er is notabene gesnoeit in het aantal devvers. Het gebrek aan capaciteit is een gevolg en geen oorzaak. De oorzaak is de genomen beslissing vanuit het management om het aantal devvers terug te schroeven.

Het is inderdaad een managementkeuze om de developmentcapaciteit terug te schroeven waardoor er automatisch ook geen capaciteit is om de iOS- en Android-apps door te ontwikkelen. Totdat de responsive site voor iedereen toegankelijk is worden de apps nog wel in de lucht gehouden. In dit geval moest de iOS-app opgelapt worden omdat hij niet goed functioneerde onder iOS 7.

Precies mijn zelfde gedacht, daarom dat de iOS versie wel geüpdatet wordt? Achja, we zullen het maar moeten doen met de website zeker .

Die android app is ook gewoon niet meer wat het moet zijn. Geen enkele mogelijkheid tot aanpassingen en dat voor een website dat "tweakers.net" heet .
Crashing bij een refresh op mijn N4... ach, wat maakt het ook uit, zullen wij maar via de website moeten gaan.

[Reactie gewijzigd door magatsu op 29 oktober 2013 13:34]

Je kunt mij ook gewoon een DM sturen of je alvast de responsive website mag gebruiken. Dan heb je alle content tot je beschikking, geen crashende apps etc

Thanks, net even gedaan. Vond het gewoon frustrerend dat de laatste update nog in mei was en er niets nuttig werd toegevoegd. But hey, i'll give it a shot!

Ik vind het net zo frustrerend als jij. Ik heb een groot native app hart, maar voor Tweakers is een RWD uiteindelijk de betere keuze.

Zou het niet aardig zijn als Tweakers.net enkele (REST) API's zou aanbieden (pricewatch, news, forum), en dat er een projectje gestart wordt om met z'n allen een OS Android/iOS variant gemaakt wordt? We zijn toch immers een community van Tweakers/Developers, of niet?

Ik heb dan ook de app weggegooid en een shortcut naar de site (ingelogd en responsive beta aan) ingesteld op mijn Nexus 4. Ik heb geen traan gelaten om de Android-app, dus stuur Misha een DM om ook toegang te krijgen zou ik zeggen

Ik ben zo'n zak die de oude vormgeving van T.net prefereert over de huidige. Daarom heb ik ook wat custom css in de desktopversie. Dan moet ik daar bovenop ook nog beta? Ehm... tweaken is vooral mijn werk. In mijn prive hou ik het graag simpel. Een App is daarom erg welkom. En voor mij part een goede (kale) responsive site waar ik niet apart achteraan hoef. Call me lazy

Ik snap niet echt waarom men zo vaak Apps maakt voor het bekijken van een website. Het is toch veel flexibeler om gewoon een mobiele versie van je website te maken ? Ik installeer niet graag een App voor het bekijken van 1 website !

Exact. En daarom zijn we bezig met een responsive design. En dat is overigens iets heel anders dan een 'mobiele versie'. Een RWD is maar 1 contentsilo, 1 url etc, ipv een apart subdomein voor een mobiele versie.

Ja, dus eigenlijk waar HTML in eerste instantie voor bedoeld was: Content wordt optimaal gerenderd voor het device waarop het wordt getoond ;-)

Overigens zie ik ook pluspunten van een eigen app (voor Android in mijn geval):

• Vindbaar in de Play store
• Je hoeft je niet druk te maken hoe het rendert in tientallen browsers

Er zijn zat plus- en minpunten te verzinnen voor alle mogelijke strategieën. Het gaat echter om wat bij jou past. Iedereen heeft zijn eigen doelstellingen en mogelijke resources. Die moet je goed inzetten.

Ben je nou sarcastisch of niet?

Tweakers is al maanden bezig met het responsive maken van website, wat inhoud dat deze dus wordt geoptimaliseerd voor het device die je gebruikt. Bezoek je met je mobiel, wordt er een mobiele skin gebruikt. Dit gaat de bestaande apps in de toekomst in principe overbodig maken. Ze hebben nu enkel een nodige update doorgevoerd voor de iOS app omdat deze nu sinds iOS7 een bug bevat. Niet omdat ze zo graag de apps willen ontwikkelen.

[Reactie gewijzigd door TimmiX op 29 oktober 2013 12:43]

Bij iedere .plan staan dergelijke reacties. Het is voor velen nog niet helemaal duidelijk wat nou een .mobi en wat een RWD is. Opzich niet vreemd.

Hangt een beetje van de functionaliteit af die je wilt bieden. Kan me zo voorstellen dat sommige zaken makkelijker zijn in een app dan in een mobiele website.

Denk bijvoorbeeld aan het uitlezen van de fysieke locatie van de bezoeker en het aanpassen van de selectie van V&A advertenties. Als je de locatie hebt, kun je advertenties die in de buurt zijn voorrang geven.

Verder kun je in een app bijvoorbeeld direct koppelen naar de telefoon, zodat je een adverteerder kunt bellen. Daarnaast heb je toegang tot notificaties, et cetera.

Kortom, een native app kan best voordelen hebben maar het hangt sterk af van welke functionaliteit je wilt aanbieden.

In zijn algemeenheid waar, maar toch is er meer mogelijk dan menigeen denkt. Lokatie uitlezen in een web browser is en koud kunstje en wordt zeer breed ondersteund. Een persoon bellen kan volgens mij ook door je markup op een bepaalde manier vorm te geven. Notificaties op het web is nog experimenteel, maar in bijv Chrome kan het al.

Deze ontwikkelingen kunnen mij niet snel genoeg gaan. Wat mij betreft hebben we de verkeerde afslag genomen met al deze app stores. We kwamen van een open web, en zijn nu weer deels terug in gesloten tuintjes. Je kunt niet vrijelijk bewegen tussen hardware omdat je semi-vast zit aan je apps. Ook gaan app store eigenaren tussen jou en je klant zitten en plukt lekker mee. Het open model is veel aantrekkelijker.

Uiteraard zijn er specifieke soorten apps waar het lastiger is, althans dat zegt men. In werkelijkheid zijn er steeds minder technische redenen om het onderscheid te maken.

Misschien kunnen jullie ook eens wat doen aan de Facebook/Twitter pagina's. Twitter is op zich wel aardig, maar erg inconsistent. De ene dag 10 updates, andere dagen 2 of 3, het zou fijn zijn ieder nieuwsbericht voorbij te zien komen.
Facebook aan de andere kant, stelt, wat mij betreft, geen zak voor(sorry voor het taalgebruik). Daar is toch ook wel een API voor te vinden die bij ieder nieuwsbericht een update op Facebook aflevert. Soms is het daar dagen stil, dan zijn er een paar updates op een dag en dan weer tijden niets.
Het hoeft van mij nog geen halve alinea nieuws te zijn, een linkje is genoeg, maar voor een techsite in een wereld waar sociale media heerst, is het, wederom wat mij betreft, zwaar onder de maat.

[Reactie gewijzigd door DeTeraarist op 29 oktober 2013 12:28]

Dat heeft vrij weinig met ons devvers te maken. Ik stuur het in ieder geval door naar de juiste afdeling! Ik ben het verder met je eens. Daar mag veel meer gebruik van gemaakt worden.

Ik begrijp dat het nu met de hand wordt gedaan, maar dat kan natuurlijk automatisch. Dat maakt het wel iets voor de devvers toch?

Iemand die automatisch zijn zut doorplaatst op een sociaal platform, waar juist de persoon erachter van belang is, is wat mij betreft sowieso slecht bezig.

Je social media strategie moet iets toevoegen aan je merk, niet een doorgeefluik zijn. Daar heb je, zoals StephanVierkant ook al zegt, RSS trackers en de nieuwsbrief al voor

Ik zou het erg vervelend vinden als alle berichten naar Twitter/Facebook worden gepushed. Daarvoor heb je vele RSS-trackers of anders de Nieuwsbrief.