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 , , 127 reacties, 143.170 views •

De engine in de toekomst

Onze site, code en engine kunnen altijd beter. De belangrijkste toepassing die nog niet gerealiseerd was bij de release van Tweakers 7, was de integratie van het forum. We willen namelijk dezelfde techniek gaan gebruiken om lijstjes forumtopics te kunnen presenteren, bijvoorbeeld als tab binnen een merkpagina. Die toont dan alle forumtopics die gekoppeld zijn aan het merk Kingston of producten van dat merk. Bovendien moet de zoektechniek die we voor veel andere onderdelen van de site hebben geïntroduceerd ook voor het forum gebruikt gaan worden. Omdat het hier gaat over tientallen gigabytes aan informatie, hebben we dit niet gelijk geprobeerd te integreren.

Dbadmin disk-grootte voor Topics en Messages

Op deze manier konden we eerst de basisideeën van de techniek goed in de praktijk testen. Bovendien zou het integreren van die functionaliteit onze overstapdatum weer weken of zelfs maanden uitgesteld hebben. Het is natuurlijk jammer voor degenen die al heel lang wachten op een betere zoekmachine in het forum, maar hij is eindelijk in ontwikkeling. Op het moment van schrijven is er zelfs al een goed werkende opzet, die we nu verder uitwerken :)

Forumtab van TPlink voor Tweakers 7

Daarnaast is het de bedoeling dat je de forumtopics ook bij de algemene zoekresultaten gaat vinden. Ook dit is geen triviale uitbreiding; dus ga er maar vanuit dat we de nieuwe forumzoekmachine eerst in gebruik nemen en dat we de geïntegreerde zoekfunctie pas in een latere iteratie uitbreiden.

Verder zullen we natuurlijk nog kijken naar andere onderdelen van de site die hier nog niet in opgenomen zijn en daar wel baat bij hebben. Momenteel vallen onder andere de Meuktracker, onze banensectie en wat andere kleinere delen nog (deels) buiten de boot. Ook die stonden eerder wel op het programma, maar zijn uiteindelijk uitgesteld om het Tweakers 7-project een gezonde einddatum te kunnen geven.


Reacties (127)

Reactiefilter:-11270122+195+220+30
Moderatie-faq Wijzig weergave
Er was me al een paar dagen geleden iets opgevallen aan de pricewatch. Zag er zeer overzichtelijker uit en er waren meer producten. Prima gedaan, zou ik zeggen, want pricewatch was hiervoor erg bar slecht.
uhhh... deze engine staat al een jaar of wat online voor de pricewatch en is nu 'slechts' uitgebreid naar de rest van de site. 8)7
Hoe zou dit hebben uitgepakt met C++ ipv java. En gebruik van linux piping (stdin / stdout) in plaats van http?
Je bent 2 keer zo lang met de integratie bezig en wint er niks aan.
Waarom zou je daar twee keer zo lang over doen?
Interesant (voor mij) om is wat meer te weten over de techniek achter tweakers.net. Ook zullen er hopelijk wat mensen de omzet nu beter begrijpen. Artikel was voor mij wat te technisch (geen enkele java kennis hiero!) maar zoals aangehaald is het wel is leuk om te zien hoe het er achter de schermen aan toe gaat, voor mij als normale gebruiker.

Hopelijk zullen mensen nu ook wat beter begrijpen wat de beweegredenen waren voor t.net. Dat scheelt vaak veel in kritiek en commentaar.

En nu we het er toch over hebben, wanneer gaat al dat wit weg? :+

Edit:spelfoutje

[Reactie gewijzigd door Postius op 16 november 2012 14:07]

Ik stoor me totaal niet aan het wit. Het ziet er juist fris uit.
Ik stoor me er dus wel aan, hoop dat ze hier snel iets aan gaan doen....
Er is toch al een nieuwe slider voor de side-bars van de site en een "padding" slider om meer text / cm^2 op je beeld te krijgen?

Persoonlijk zou ik nog wel meer tekst in beeld willen, nu is ongeveer 1/3 van het scherm in gebruik bij mij, dat mag best 1/2e worden. Ook het grijs is nu op z'n donkerst nog nťt niet donker genoeg.

Wel typisch trouwens, ik klik op een link over T.nets backend, en ik krijg tot 2x toe:

Ooops
Er ging iets mis met het ophalen van deze pagina, probeer het zo nog een keer. (503 Service Unavailable 42065847)
:+
Ok, ik heb die optie net pas gevindt, wist nog niet dat die optie er was, bedankt voor de tip :)
Zou het niet mogelijk zijn dat je bij de pricewatch een bestellijst kan ingeven

(bv voor camer'a een specifieke lens + een specifieke body, en nog wat accesoires
of vr computers een behuizing + geheugen + moederbord + ...)

en dat de pricewatch de goedkoopste leverancier vindt voor het volledige lijstje, want nu moet je het soms bij tien firma's bestellen.

"t is maar een idee...
Dit is al mogelijk, je kunt een wensenlijst opstellen en daar kiezen bij hoeveel leveranciers je wilt bestellen.

OT: zeker interessant om dit te lezen, lijkt me prettig als het forum geintegreerd wordt in de zoekresultaten.
@ wimdezoveelste.
Om jou gerust te stellen, dat wit gaat voorlopig niet weg.
Als ik naar T7 kijk, heb ik het idee dat het een beetje voor portable devices is gemaakt/geoptimaliseerd.
Pak maar een TFT panel en zet er geen data op maar wel CCFL (verlichting) dan zul je zien dat je scherm wit is.
Toch wel slim bekeken, houdt je accu het misschien wel tien minuten langer vol...

[Reactie gewijzigd door Murdy op 16 november 2012 22:57]

Een deel van je comentaar slaat natuurlijk nergens op.

Wanneer er software matig verkeerde keuzes gemaakt worden (zoals bv bij de nieuwe tNet waar nog niks aan gedaan is) dan moet je niet de techniek de schuld geven. Er zijn (gezien alle reacties) fouten gemaakt.

Daarbij vind ik deze artiekelen zeker interessant en ik hoop dat er meer van dit soort artiekelen komen. Daarvoor leest de "oude" tweaker toch tweakers.
Dat kan je al aanpassen hoor, rechts boven in twee de icon
Zelfs op z'n donkerst is de site nog te wit. Het doet gewoon pijn aan je ogen.
Volgens mij wordt er bedoeld dat er behalve een klein veld bovenin de website wat van licht naar donker (en andersom) kan worden veranderd, de hoeveelheid wit tussen de nieuwsberichten op de frontpage, in de nieuwsberichten zelf en de comments het wit niet aan te passen is van licht naar donker.
Voor de mensen die Java-twijfels hebben en uit de PHP-hoek komen, misschien is het interessant om eens te kijken naar SpringSource Grails, onder de motorkap wordt Spring MVC en Hibernate gebruikt, is Jetty als servlet-engine geintegreerd en aan de achterkant kun je in puur Java/Groovy ontwikkelen. Dit maakt de overstap naar de Java/Spring/Hibernate-taal erg interessant voor mensen die nieuwsgierig zijn, maar denken dat het allemaal 'eng' is in Java. Grails bewijst het tegendeel. Zie www.grails.org. In combinatie met de InteliJ IDE is dit erg productief.

[Reactie gewijzigd door Tjeerd op 16 november 2012 16:29]

Hibernate is leuk maar een erg zwaar systeem. Backends wil je zo veel mogelijk clean houden.
Onzin. Als je het goed configureert is Hibernate echt niet zwaar hoor.
- Afhankelijkheid
- Ondersteuning
- 1+N
- Minder controle op collections
- enz

Om een pakket te implementeren zeker op schalen zoals hier op Tweakers.net zal ik wel 10x nadenken om zo'n pakket te implementeren.
Het probleem en verhaal dat Hibernate slecht zou presteren is maar deels waar, het is wel belangrijk om een goed genormaliseerd datamodel te hebben. Verder kun je kiezen om alles over te laten aan Hibernate of om queries zelf te schrijven. Je kunt daar zelf een balans in zoeken. Momenteel zit ik bij een bedrijf waar alles lowlevel in JDBC en insertqueries gebeurt en handmatig verbindingen worden opgebouwd en gesloten. Dat werkt prima, maar het kost zoveel extra tijd en verhoogt de kans op transactieproblemen, verbindingen die niet goed worden afgesloten enzovoorts. Lazy (geen relaties van records ophalen) en eager fetching (wel kinderen/gerelateerde records ophalen) is wel iets om mee uit te kijken bij Hibernate omdat het nogal gulzig data kan gaan ophalen. Daarbij het feit dat een taal als Grails dynamic finders heeft, zodat je data ophaalt dmv User.getByName(...), zonder dat je een regel SQL hoeft te schrijven. Resultaat is dat het gemiddelde bedrijf heel snel wat op poten heeft gezet.

@ACM: JdbcTemplate is een prima stuk techniek uit Spring om mee te werken idd, als je geen Hibernate (ORM) wil gebruiken.

[Reactie gewijzigd door Tjeerd op 17 november 2012 09:37]

Er zijn uiteraard allerlei mates van ingewikkeldheid. Omdat wij SQL zelf al hadden afgeschreven voor dit project (in de tijd dat we de SQL nog vanuit php uitvoerden) werden de benodigde queries ineens vrij simpel. Maar wel een vrij belangrijke eis werd dat objecten efficient in geheugen moesten kunnen blijven.

Hoedanook, uiteindelijk gebruiken wij Spring's (Simple)JdbcTemplate's om het gros van de Pooling- en JDBC-overhead voor ons af te handelen, maar schrijven we wel zelf de paar SQL-statements en de bijbehorende RowMappers. Dat gaat dan in de orde van 1 a 2 queries per objecttype, vaak alleen een "fetch all"-equivalent om bij het opstarten het geheugen te vullen, soms een "get all modified since"-statement en verder nog een "get by id"-query om de vernieuwde data op te halen.
Dat kan vast ook in Hibernate, maar zodra je van CRUD alleen maar de R nodig hebt is het uiteindelijk misschien wel minder werk om domweg zelf je queries te schrijven dan om via Hibernate alle mappings te moeten regelen :P
Bovendien was MySQL 5.1 in die tijd net uit, wat betekent dat we nog op 5.0 draaiden en die stond niet bekend om zijn performance met complexe queries en queries met subqueries
Waarom dan niet een DB-platform gebruiken dat daar wel goed mee om kan gaan?
Waarom dan niet een DB-platform gebruiken dat daar wel goed mee om kan gaan?
De andere genoemde redenen gelden voor andere databases net zo lijkt me: erg veel data met erg veel condities met SQL bij elkaar harken is gewoon niet zo efficiŽnt.

(los daarvan zijn er natuurlijk nog steeds wel goede redenen te bedenken om een andere database te gebruiken)
De andere genoemde redenen gelden voor andere databases net zo lijkt me: erg veel data met erg veel condities met SQL bij elkaar harken is gewoon niet zo efficiŽnt.
Daarom is er ook een markt voor een speciaal soort database dat specialiseert in de zogenaamde faceted search.

Endeca (nu aangekocht door Oracle) is er zo een. Veel van de sites die wij afleveren binnen de reisbranche draaien hun zoeksysteem daar op en dat zijn zeker geen kleine databases.
Ik denk omdat je anders dan de hele site kan verbouwen voor zoiets, omdat een groot deel van Tweakers op MySQL draait. Niet een geweldige goede oplossing.

[Reactie gewijzigd door AW_Bos op 16 november 2012 14:19]

Volgens mij inderdaad door de history, het is ooit begonnen met PHP en dan ga je inderdaad niet een volledige website opnieuw opbouwen. Zeker niet een site van deze omvang.
Als ze toendertijd ANSI-SQL in de PHP laag gebruikte en dus geen DBMS specifieke SQL-instructies, zou hier eenvoudig een abstractielaag tussen kunnen worden gezet.

In het geval dat ze SQL-instructies van MySQL hadden gebruikt, zullen andere DBMS'n met dezelfde doelgroep ook deze functionaliteit beschikbaar hebben gehad. Een voorbeeld is de SQL instructie "TOP" van Microsoft Sql Server en "LIMIT" van MySQL:
dba.stackexchange.com/questions/1115/top-x-of-sql-server-in-mysql-analog

Om dit te voorkomen kon bijvoorbeeld Hibernate worden gebruikt:
http://en.wikipedia.org/wiki/Hibernate_(Java)
Dat probleem heb je alleen als je geen abstractielaag tussen de data access en de DBMS (MySql in dit geval) hebt geplaatst. Ik mag hopen dat ze in hun Java-engine niet SQL (nog nog erger: MySQL specifieke instructies) gebruiken om tegen MySql te praten. Dat is toch niet echt een net design...
Zodra je een beetje geavanceerde SQL-features wilt gebruiken (denk aan dingen als recursieve queries) zul je zelfs met een abstractielaag toch snel op database-specifieke SQL uitkomen.

Dat kun je wel een lelijk ontwerp vinden, maar in omgevingen waar performance (en/of andere eigenschappen die je met database-specifieke SQL beter kunt behalen dan zonder) belangrijk is kan het toch een goede keus zijn dat te gebruiken.
Wat recursive queries betreft, dit kan MySQL juist niet dus dit is eigenlijk een gek voorbeeld, maar ik snap wat je bedoelt :)

Wat ik in mijn post als reactie aan BlackHawkDesign al aangeef, ook al gebruik je DBMS specifieke SQL-instructies of features, dan kan een abstractielaag als Hibernate hier alsnog bij helpen.
Zolang je geen dynamische queries (lees: opbouwen vanuit code) gebruikt, kun je deze prima wegmoffelen achter een stored procedure. Daardoor heb je geen specifieke (My)SQL code in je back-end staan, waardoor je net even wat losser tegen je database implementatie aan leunt. Het wordt er ook iets wat sneller op doordat niet telkens de query hoeft te worden overgebracht naar de database server.
Met ACM. Daarbij komt nog dat SPs vanuit het oogpunt van versiebeheer en deployen/rollbacken van functionaliteit een hell zijn. Ik heb ze in een grijs verleden weleens gebruikt (lees: misbruikt), maar ben daar keihard van teruggekomen.
Hoezo is versiebeheer een hell? Uiteindelijk is het gewoon plain text en dat kun je prima in versiebeheer zetten.

rollback is ook prima te doen, mits je een database gebruikt die transactional DDL ondersteunt. Dan kun je namelijk ook je verificatie tests binnen de transactie (dus deployment) opnemen en afhankelijk van de resultaten een commit of rollback uitvoeren.

MySQL kent deze opties niet, maar in PostgreSQL (of bv. Oracle) is het geen enkel probleem.

Wij doen niet anders en beheren hier een database van een paar TB met ongeveer een miljoen unieke bezoekers per dag, ~800 transacties per seconde, goed voor ~20.000 (eenvoudige en zeer complexe) queries per seconde. High performance is hier het allerbelangrijkste, dat is ook de reden dat we voor stored procedures hebben gekozen: logica hťťl dicht op data zodat er zo min mogelijk data uitgewisseld hoeft te worden. En dat werkt, gemiddelde tijd per transactie (die dus meerdere queries bevat) is minder dan 10ms, ondanks dat we ~200 concurrent users van data moeten voorzien. Stored procedures kunnen dus prima werken.
Onze code en toepassing van MySQL is van voor dat ze stored procedures ondersteunden... we hebben daarbij domweg teveel code om zomaar even over te stappen op een compleet andere manier van werken.
Dat zou uiteraard gradueel kunnen, maar ik ben niet echt een fan van het in de database opslaan van functionaliteit (wat SP's effectief zijn), die scheiding bijt je altijd wel ergens weer (het niet scheiden natuurlijk ook).
Waarom maken jullie niet (delen) hiervan open source/community based? Ik denk dat er erg veel tweakers zijn die, in ruil voor een mooie badge naast hun naam, graag hun steentje bijdragen aan een beter Tweakers
Ook dit is een van die vragen die we vaker terugzien :)

Het OS maken van (delen van) de software van Tweakers is een ingewikkelde situatie met erg veel afwegingen om te maken. Er zijn tenslotte allerlei commerciele belangen naast de belangen van de community.
Daarnaast vereist het ook nog een aanzienlijke inspanning van het bedrijf en dan vooral de developers eracher.

Commercieel gezien werkt OS natuurlijk vooral als het niet (het deel van) de software is waar je je geld door verdient, danwel als je software je niet op voorsprong zet ten op zichte van de concurrentie.
Vanuit het perspectief van een website: de gegevens achter je website moeten - bij voorkeur samen met de bezoekers/community - zo'n unieke formule opleveren, dat niemand met dezelfde software jouw positie noemenswaardig in gevaar kan brengen. Bijvoorbeeld door een directe concurrent van je te worden of als bestaande concurrent het product te verbeteren.

Hoewel er allerlei stukken software binnen tweakers geschreven zijn die daaraan voldoen, denk ik dat we juist met de pricewatch toch wel moeten oppassen... Voorbeeld van delen die daar beter op aansluiten zijn bijvoorbeeld forumsoftware en een reactiesysteem. Dat zie je dan ook op het internet, Reddit en Slashdot zijn gebaseerd op open source websitesoftware. Maar ik denk niet dat er veel concurrenten zullen zijn ontstaan door simpelweg dezelfde software ergens anders op te starten. En reeds bestaande concurrenten hebben doorgaans al vergelijkbare software in gebruik of bezoekers die het niet erg vinden dat het wat anders werkt.

Maar naast commerciele belangen zijn er ook nog andere dingen om mee op te passen. Zodra je commiters toelaat moet je sowieso alle commits die binnenkomen nakijken. In een perfecte wereld zou natuurlijk elke commit aan je eigen kwaliteitsstandaarden voldoen, maar in werkelijkheid valt dat waarschijnlijk tegen. Sowieso loop je een risico dat een externe committer bij zijn commit helemaal niet stil gestaan heeft bij gevolgen elders in de code.
Denk aan een wijziging in css waarbij ineens op een ander deel van de site een tabel ineens heel lelijk wordt.
Verder verwacht ik dat een OS-traject alleen succesvol wordt als we ook daadwerkelijk tijd hebben om de commits te verwerken in de productie-site. Als we er geen tijd voor hebben of alleen maar commits binnen krijgen waar we niet op zitten te wachten - en dus afwijzen - zullen de committers snel geirriteerd raken.
Dat betekent in ieder geval dat de commits relatief eenvoudig voor de committer en bezoekers zichtbaar moeten worden. Deze Engine is nou niet bepaald een zichtbaar deel. Sterker nog, om er uberhaupt wat mee te kunnen heb je zowel een goed gevulde database als een zinvolle frontend nodig...
Van alle bugs die gemeld worden zit dan ook het merendeel juist niet in deze code, hooguit in er tegenaan liggende php-code voor de verwerking van resultaten. Maar vaak nog wat laagjes/stapjes ervandaan.

Kortom: ik denk niet dat met name dit project in ons belang is (commercieel gezien) om aan de wereld vrij te geven. Verder heeft dit deel zodanige afhankelijkheden dat we veel moeite moeten steken in een testfrontend danwel (delen van) onze huidige frontend ook vrij moeten geven en vooral dat we ook een forse testdataset moeten gaan aanbieden.

Daarnaast durf ik persoonlijk in ieder geval niet te garanderen dat we de tijd hebben (of van ons management mogen maken) om naar commits te kijken, vragen te beantwoorden, bugfixes te testen en naar de nieuw geintroduceerde bugs te zoeken... Het is natuurlijk maar sterk de vraag of die tijd opweegt tegen domweg zelf met de code bezig zijn :P

[Reactie gewijzigd door ACM op 18 november 2012 11:57]

Waarom nog steeds Apache, alles wijst tegenwoordig naar Nginx vooral als je goed wilt cachen en zeker voor grote websites.

Ik moet zeggen dat wij voor een Applicatie ook Java gebruiken qua server-side kant en dat gaat uitstekend. Voor mij is Java iig geen rare keuze.
In onze ervaring is de combinatie van Apache + PHP nog altijd aanzienlijk krachtiger dan Nginx + "allerlei lijmwerk" + php. En bovendien... het caching-deel (en dus de statische resources) hebben we al helemaal uitbesteedt aan Varnish, dus uiteindelijk blijven alleen de pure php-requests over voor de webservers.
In onze benchmarks was Apache daar zelfs sneller mee dan Nginx.
Verder scheelt het in gebruik houden van Apache dat we onze jarenlange ervaring en op maat gemaakte configuraties niet hoeven te herschrijven naar Nginx zonder dat het echt noemenswaardige voordelen heeft.

Kortom: Apache is gewoon behoorlijk stabiel en erg flexibel zonder door allerlei hoepels te hoeven springen om met PHP te mogen werken. Dat laatste is iets dat (tot voor kort?) met Nginx zeker nog wel het geval was/is.
Goede argumenten!
Leuk om te lezen hoe jullie tot een architectuur plaatje gekomen zijn.

Zelf het afgelopen jaar een framework ontworpen en gebouwd op basis van cassandra en elastic search en herken zeker wel een aantal van de limitaties die m.b.t. genoemde producten genoemd worden. Eerst gebruikten we solr maar daar worden de queries trager als er gelijktijdig ook een index wordt geupdate. Elastic search heeft hier minder last van.

Hebben jullie i.p.v. activemq (Waarom niet RabbitMQ ;) ) ook overwogen om Hazelcast of Terracotta te gebruiken om cached objecten over de verschillend jvms te delen?
't Informeren gebeurt vanuit PHP naar Java, dus een puur-java oplossing voor synchronisatie is niet heel zinvol dan :)

Op zich is iets als Terracotta wel interessant zodra het buiten de reikwijdte van 1 machine gaat, maar de totale actieve dataset waarmee gewerkt wordt zit onder rond de 3GB. Dus dan zijn inspanningen voor een "extra grote VM" wat overbodig :)
't Informeren gebeurt vanuit PHP naar Java,
Misschien een stomme vraag, maar waarom op termijn dan ook niet voor de web layer Java gebruiken?

Je hebt het nagenoeg identieke JSP (html markup met fragmenten code ertussen), of heel goede meer high-level frameworks zoals bijvoorbeeld JSF (JavaServer Faces).
Er zijn diverse redenen voor op te noemen, ik zie het in ieder geval niet gebeuren. Denk aan:
- Het is enorm veel werk, we komen in de buurt van de 400k regels php-code...
- We hebben nog steeds meer php-kennis in huis dan java (en zeker dan jsp en de frameworks voor de presentatielaag)
- Het biedt weinig meerwaarde, het brengt eventueel die back- en frontend dichter bij elkaar, maar een scheiding in dergelijke verantwoordelijkheden is alsnog geen gek idee.

En dat dus verder nog afgezien van eventuele voorkeuren voor het ene of het andere platform en/of nadelen vs voordelen die met het platform samenhangen.

Dus kortweg: het biedt in mijn ogen domweg te weinig voordelen ten op zichte van de inspanning en kosten die ervoor zijn vereist. Alle voordelen zullen bijna automatisch in het niet vallen tegen het nadeel van een rewrite van de complete code-base naar java/jsp...

[Reactie gewijzigd door ACM op 17 november 2012 10:51]

Ik snap de nadelen en dan met name de hoeveelheid werk die natuurlijk aanzienlijk is. Het lijkt me ook niet realistisch om in 1 klap de hele frontend/weblayer te gaan herschrijven, maar stukje voor stukje is er een hoop mogelijk.

Qua de kennis moet je natuurlijk ook niet vergeten dat je nu een hele back-end in Java hebt, dus dat de kennis van Java steeds verder zal toenemen.
een scheiding in dergelijke verantwoordelijkheden is alsnog geen gek idee.
Het klinkt ook als een goed idee, maar bedenk wel dat ook bij het gebruik van dezelfde taal deze scheiding te realiseren is. De voordelen van een gemeenschappelijk taal is wel dat het uitwisselen van programmeurs tussen beide lagen makkelijker maakt, en dat het ook code re-use (bedenkt models/entities die je nu op 2 plekken defineert waarschijnlijk) makkelijker maakt.

Nu hoeft zeker niet altijd een applicatie volledig op 1 platform te draaien. Als er echt redenen zijn dat 1 onderdeel in een andere taal is omdat die taal beter is voor dat onderdeel, dan is het natuurlijk een goede keuze.

Echter, PHP is niet noodzakelijkerwijs 'beter'. Het is alleen een toevallige (legacy) situatie.

Persoonlijk heb ik bij een aantal projecten ook deze setup gezien, en het veroorzaakte toch problemen en spanningen. Misschien dat het bij jullie wel goed gaat, maar just my 2 cents ;)
Ze moeten bouwen wat ze willen als de gebruiker maar tevreden is over het resultaat. En hoewel de storm is gaan liggen heb ik nog niemand gehoord in mijn omgeving die tevreden is over de nieuwe site incl pricewatch.

De site zelf is dramatisch om te zien op een desktop pc en is puur gemaakt voor op een tablet of telefoon, helaas na een maand nog geen echte verbetering op dat punt gezien. Bij de pricewatch moet je tegenwoordig helemaal terug naar de hoofdpagina van pricewatch als je binnen een catogorie naar een andere wil.

Custom je site aanpassen vind ik geen optie, de hoofdsite moet al normaal bruikbaar zijn.

Wat gelukkig wel blijft zijn de vele relevante nieuwsitems maar helaas zie ik hier ook steeds meer een verschuiving naar zaken die weinig tot niets met it te maken hebben bv de witgoed afdeling in pricewatch, en de soms advertentieachtige artikelen zoals steeds vaker lijkt voor te komen vooral bij Apple en Samsung.
Wij zijn er in de T7 versie van de Pricewatch van uit gegaan dat een goede zoekfunctie een veel snellere en efficientere manier is om bij een product te komen is dan door een categorieboom klikken. Op elk punt in de Pricewatch kun je via de search direct naar een ander product of een andere categorie springen zonder via de homepage te gaan. Zo'n categorieboom is aardig als de structuur niet zo complex is maar het bleek af en toe behoorlijk lastig om obscure categorieŽn ergens kwijt te kunnen. Bovendien waren ook in die situatie veel productcategorieŽn niet direct vanaf de homepage toegankelijk: zo moest je maar net weten dat 'beamers & projectoren' als subcategorie was weggestopt onder 'overige randapparatuur' - en dat was uit de oude Pricewatch home op geen enkele manier af te leiden.

In de praktijk blijkt echter dat flink wat mensen zo gewend zijn aan het browsen door die boom - mede door de beroerde search in de oude site - dat het gebruiken van de search niet bij ze opkomt, of het bladeren op zich al prima beviel.

Wil je perse via een categorie bladeren dan is de huidige category browser in combinatie met het ontbreken van een echte breadcrumb inderdaad niet bepaald handig. De behoefte daaraan hebben we onderschat. We zijn aan het kijken of we een goede oplossing kunnen vinden om een categorieview terug te brengen. Probleem daarbij is dat de hoeveelheid categorieŽn nogal groot is (Pricewatch Unsorted geeft een aardige indicatie: http://tweakers.net/pricewatch/unsorted/) dus je krijgt een enorme lijst waarbij een groot deel standaard buiten beeld staat.
quote: Wij zijn er in de T7 versie van de Pricewatch van uit gegaan...

Hmm, je weet toch wel dat elke aanname het begin van alle ellende is... ;)

Persoonlijk vind ik het (nog) geen verbetering, ik geeft het nog even de tijd.
Is er ergens de optie om de oude layout terug te zetten dat zou ik erg fijn vinden.
En dat is dus precies het probleem: wanneer je met je muis aan het klikken bent, wil je niet even via je toetsenbord een categorie in het zoekvenster intoesten. Je wilt gewoon met je muis klikken.

Volgens mij is hier dus echt niet over nagedacht.....
dus omdat jij "te lui"ben om je toetsenbord te gebruiken moet tweakers dat maar mee nemen in hun idee over hoe ze een pricewatch beter kunnen laten werken? we kunnen misschien ook gewoon vaker de poging proberen te nemen om onze gewenning een beetje aan de kant te gooien ipv alleen maar alles af te kraken.
Blij te horen dat er aan de breadcrums gewerkt wordt deze vind ik erg waardevol in de PW.
Gisteren zocht ik naar monitoren, staan die onder "Computers" of onder "Beeld en geluid"? De zoekfunctie werkt inderdaad heel makkelijk. Maar wat je als gebruiker niet verwacht is dat je daarmee ook naar categorieŽn kunt zoeken, daar kwam ik net pas achter. Je zou dit kunnen voorkomen door de hele zoekboom niet te tonen.
Ik vind de nieuwe Pricewatch anders niet fijner werken.

Sorteren op criteria werkt alleen maar als je via het hoofd Pricewatch menu begint.

Begin je via de homepage, en zoek je dan via de "universal content bar", dan kom ik wel uit bij Dominator geheugen, maar op die pagina kan ik dan niet meer sorteren op criteria als "grootte", modules etc.

Wordt dit nog eens aangepakt?
Er missen inderdaad nog aardig wat criteria en soms zelfs product groepen (terwijl die producten wel in de pricewatch staan).

Hoop dat hier inderdaad nog verandering in gaat komen :)
Ik bedenk me dit nu pas trouwens: je klacht over "de nieuwe pricewatch" is onterecht. Het gedrag dat je beschrijft is namelijk niets anders dan met tweakers 6 al het geval was.

Toen kon je ook alleen maar op specificaties van producten filteren en sorteren als je via de categorie naar een lijstje producten was gegaan. Maar niet als je via de zoekbox bovenaan de pricewatch-portal ging.

De algemene zoekomgeving wordt ook aardig complex als we zouden proberen de specificaties van producten er tussen te stoppen. Wat doe je als er producten uit twee verschillende categorieen staan? Stel je zoekt op "sony" (en ja, mensen doen dat), verwacht je dan dat alle specificaties van Sony-producten bij elkaar staan of juist alleen degenen die gedeeld worden door alle producten. Waarbij in dat geval waarschijnlijk dus geen specificatiefilters overblijven... Hooguit iets als garantie.
Met jouw "dominator"-zoekopdracht gebeurt zelfs al zoiets, er staan naast geheugenmodules tenslotte ook een processorkoeler, een ventilator, drie games en iets uit de overclocking-categorie tussen...

Ik geloof dat er wel plannen zijn om dit beter te onderzoeken. Maar hoewel het een eenvoudig probleem is om te beschrijven ("er staan geen specificatiefilters") is het een vrij lastig probleem om op te lossen :)
Je zult in je klacht onderscheid moeten maken tussen de onderliggende techniek en de uiteindelijke inzet en presentatie ervan. Die laatste zijn waar je klachten over lijken te gaan (en alle andere die hier genoemd worden) terwijl dit artikel over de eerste gaat :)
Wat heb ik aan een uitstekende techniek als er minder mee kan dan vroeger met andere techniek?

Leuk hoor die productgroepen, maar echt handig? Nee.
Voor gebruikers is natuurlijk de presentatie en bruikbaarheid veel belangrijker, maar als dat dan ook nog eens gehinderd zou worden door beperkingen in de onderliggende techniek... dan wordt het alleen maar nog erger.
Het voordeel van een krachtige ondergrond hebben is dat we relatief eenvoudig aan de "buitenkant" kunnen sleutelen, zonder alles wat daar onder zit weer aan te moeten passen.

We zijn echt niet met de release van "tweakers 7" gestopt met bijschaven. Maar net als dat "tweakers 6" heel veel bijgeschaafd is in de loop de jaren, zal dat ook met 7 gebeuren. 't Feit dat we ondertussen alweer iets van 500 "tickets" opgelost hebben sinds de lancering onderschrijft dat alleen maar.

Sterker nog, ik ga er van uit dat als er een "tweakers 8" komt dat daar weer het hele bijschaaf-proces van voorafaan begint. En dat is niet omdat we er niks van leren, maar omdat de projecten van dusdanige grootte zijn dat zelfs uitvoerig testen lang niet alle verkeerde interpretaties van bezoekersgedrag en -voorkeuren zal vinden. En daarnaast worden er uiteraard ook altijd wel bugs gemaakt (niet dat we dat expres doen... maarja :/ )

Op dit item kan niet meer gereageerd worden.



LG G4 Battlefield Hardline Samsung Galaxy S6 Edge Microsoft Windows 10 Samsung Galaxy S6 HTC One (M9) Grand Theft Auto V Apple iPad Air 2

© 1998 - 2015 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True