[Feat] Gele balk zou ook edits moeten inladen

[PrisonerOfPain]

De gele balk die laat zien dat er nieuwe reacties beschikbaar zijn om in te laden zou ook aan moeten geven welke reacties ge-edit zijn (door ze te highlighten) en de ge-edite reactie opnieuw moeten laden.

[TheNephilim]

Dat zou een leuke feature zijn. Heb nog al eens regelmatig dat ik iemand quote om dan pas te zien dat ze hun reactie aangepast of aangevuld hebben.

Aan de andere kant is dit denk ik vooral nuttig bij slow-chat topic. Maar wie weet!

[MueR]

[bug] ajax refresh refreshed geen edits

[PrisonerOfPain]

MueR schreef op woensdag 21 augustus 2013 @ 10:28:
[bug] ajax refresh refreshed geen edits

Is een beetje jammer, de feature is nu een beetje half-broken.

[Anoniem: 296939]

In crisp in "[bug] ajax refresh refreshed geen edits" staat te lezen dat dit "by design" is. Waarom precies? In welke situatie zou je oude berichten willen inladen als er al een nieuwe versie van beschikbaar is?

[crisp]

Dat heb ik al meerdere malen uitgelegd. Technisch gezien is het een kwestie van eenvoud: als je kijkt of er nieuwe berichten zijn dan heb je feitelijk al alle data voorhanden om die berichten ook meteen mee te sturen, dus dat doen we dan ook. Op die manier is er geen additionele request meer nodig als de gebruiker klikt op de melding en staan de nieuwe berichten er ook meteen.

Als we rekening moeten gaan houden met wijzigingen van berichten dan zouden we dat feitelijk ook moeten gaan doen voor berichten die al zichtbaar zijn. Dat zou het hele systeem dan een stuk complexer maken en performancetechnisch ook een heel stuk zwaarder. De vraag is dan of de toegevoegde waarde groot genoeg is, en dat is het m.i. simpelweg niet.

[GlowMouse]

crisp schreef op woensdag 21 augustus 2013 @ 11:11:
Dat zou het hele systeem dan een stuk complexer maken en performancetechnisch ook een heel stuk zwaarder.

Dat valt wel mee als je in een extra tabel bijhoudt welke posts in welke topics gewijzigd zijn.

[crisp]

GlowMouse schreef op woensdag 21 augustus 2013 @ 11:21:
[...]

Dat valt wel mee als je in een extra tabel bijhoudt welke posts in welke topics gewijzigd zijn.

Ook dat heeft een performance impact, alleen op een andere plek

Uiteraard zijn er altijd wel manieren om performance te verbeteren, maar dat voegt dan meestal weer complexiteit toe wat de kosten/baten afweging weinig veranderd.

[PrisonerOfPain]

crisp schreef op woensdag 21 augustus 2013 @ 11:11:
De vraag is dan of de toegevoegde waarde groot genoeg is, en dat is het m.i. simpelweg niet.

En toch is het iets waar ik vrijwel dagelijks tegenaan loop - en ik verwacht dat ik niet de enige ben. Lijkt me dat het wellicht de moeite is om het op te nemen in de volgende Development-round-up poll?

crisp schreef op woensdag 21 augustus 2013 @ 11:36:
Ook dat heeft een performance impact, alleen op een andere plek

Een plek waar het waarschijnlijk minder impact heeft.

[Anoniem: 19894]

Als je voor elke poep- en scheet edit de gele balk gaat gebruiken, blijf je aan de gang, zeker in snelle topics.

[GlowMouse]

crisp schreef op woensdag 21 augustus 2013 @ 11:36:
[...]

Ook dat heeft een performance impact, alleen op een andere plek

Elke feature heeft een performance impact, en ook deze heeft een impact die je nooit gaat meten omdat hij zo klein is.

De huidige auto-updates zijn onbruikbaar omdat je niet de meest recente versie van de pagina op je scherm hebt. Belangrijke edits zie je niet totdat je op F5 drukt. Dat neemt het hele voordeel weg.

Complexiteit: ja je moet een extra query draaien bij elke nieuwe of gewijzigde post en je moet een cron draaien die de tabel af en toe opschoont, maar dat weegt niet op tegen de extra usability.

[Anoniem: 19894]

En dan heb je ook nog lieden die een edit op een edit doen

En als de TS eens zijn topic update? Lachen, kan een aardige chaos worden..

[PrisonerOfPain]

Anoniem: 19894 schreef op woensdag 21 augustus 2013 @ 11:51:
En dan heb je ook nog lieden die een edit op een edit doen

En als de TS eens zijn topic update? Lachen, kan een aardige chaos worden..

Ik snap je punt niet helemaal, het is wel degelijk een nuttige feature (niet alleen in slowchat topics btw) en er zijn al meerdere mensen geweest die het nodig vonden er een feature request voor in te dienen.

[Anoniem: 19894]

PrisonerOfPain schreef op woensdag 21 augustus 2013 @ 11:54:
[...]


Ik snap je punt niet helemaal, het is wel degelijk een nuttige feature...

Laat ik het anders zeggen: In diverse topics is die notificatie al niet bij te benen, laat staan als je de edits ook nog meeneemt.

[GlowMouse]

Anoniem: 19894 schreef op woensdag 21 augustus 2013 @ 11:57:
[...]


Laat ik het anders zeggen: In diverse topics is die notificatie al niet bij te benen, laat staan als je de edits ook nog meeneemt.

Jij klikt dus elke keer op de gele balk zodra hij verschijnt. Dan zou je een andere feature request in moeten dienen: laat die updates direct zien, en toon de gele balk alleen als je een berichtje aan het typen bent.

[PrisonerOfPain]

Anoniem: 19894 schreef op woensdag 21 augustus 2013 @ 11:57:
[...]


Laat ik het anders zeggen: In diverse topics is die notificatie al niet bij te benen, laat staan als je de edits ook nog meeneemt.

Dus moeten we het maar helemaal niet doen?

[Hero of Time]

Dan zou je een andere feature request in moeten dienen: laat die updates direct zien, en toon de gele balk alleen als je een berichtje aan het typen bent.

Nee, met dat laatste zie je dus niet waar je was gebleven met lezen. Dan moet er weer wat tussen het laatste bericht van de pagina toen je 'm opende en de nieuwe berichten.

Waar ik aan denk wanneer je de edits wel graag wilt zien is in topics die je open houd, maar niet elke minuut in kijkt. Stel je laat dit topic open staan en je kijkt 2 uur later pas weer, dan mis je alle edits en krijg je een scheef beeld als iemand een quote plaatst met een edit erin die je nog niet ziet. Dan moet je eerst de pagina verversen voordat je ziet wat er bedoelt wordt.

Het gebeurt regelmatig dat mensen een topic open houden om te volgen, maar eens in de x tijd bekijken. Dan is het wel prettig om bij het laten zien van de berichten de laatste versie te hebben. Is het daarom mogelijk om de berichten die achter de gele balk schuil gaan te updaten na een bepaalde tijd in geval er een edit is geweest van een van de posts? Bijvoorbeeld na een half uur sinds de gele balk dat er dan bij de eerst volgende AJAX refresh de voorgaande berichten worden bijgewerkt.

[Anoniem: 296939]

Hero of Time schreef op woensdag 21 augustus 2013 @ 12:15:
[...]

Nee, met dat laatste zie je dus niet waar je was gebleven met lezen. Dan moet er weer wat tussen het laatste bericht van de pagina toen je 'm opende en de nieuwe berichten.

Waar ik aan denk wanneer je de edits wel graag wilt zien is in topics die je open houd, maar niet elke minuut in kijkt. Stel je laat dit topic open staan en je kijkt 2 uur later pas weer, dan mis je alle edits en krijg je een scheef beeld als iemand een quote plaatst met een edit erin die je nog niet ziet. Dan moet je eerst de pagina verversen voordat je ziet wat er bedoelt wordt.

Het gebeurt regelmatig dat mensen een topic open houden om te volgen, maar eens in de x tijd bekijken. Dan is het wel prettig om bij het laten zien van de berichten de laatste versie te hebben. Is het daarom mogelijk om de berichten die achter de gele balk schuil gaan te updaten na een bepaalde tijd in geval er een edit is geweest van een van de posts? Bijvoorbeeld na een half uur sinds de gele balk dat er dan bij de eerst volgende AJAX refresh de voorgaande berichten worden bijgewerkt.

Dit. Ik heb een stuk of 3 topics die de hele dag open staan maar ik lees ze maar eens om de X tijd in plaats bij elke nieuwe post.

[Anoniem: 19894]

Hero of Time schreef op woensdag 21 augustus 2013 @ 12:15:
[...]

... Bijvoorbeeld na een half uur sinds de gele balk dat er dan bij de eerst volgende AJAX refresh de voorgaande berichten worden bijgewerkt.

Dus in dit geval, alles onder dat half uur krijgt dan geen bijwerking? Dat is dan weer niet consequent.

[Hero of Time]

Anoniem: 19894 schreef op woensdag 21 augustus 2013 @ 12:20:
[...]


Dus in dit geval, alles onder dat half uur krijgt dan geen bijwerking? Dat is dan weer niet consequent.

Nee, na een half uur komt er een refresh van de al gecachte berichten, ongeacht of die nou 25 of 5 minuten geleden is gemaakt. Maar 5 minuten na de refresh dan weer niet. Dus na 45 minuten heb je een gedeelte wat met edit zichtbaar is en een gedeelte zonder.

[Hipska]

Ook ik (en vast genoeg anderen) heb stuk of 3 topics open staan en kijk dan in de titel van de tab of er nieuwe berichten zijn en dan laad ik die in dmv de gele balk. Soms zie ik dan replies met een quote erin van een voorgaande reply met een stuk tekst welke ik nog niet gezien had. Op dat moment moet ik dan alsnog de pagina refreshen en schiet die gele balk zijn doel voorbij.

In mijn optiek zijn er 2 opties.

1. Gele balk meld en laad ook edits in.
2. Gele balk zorgt voor page refresh on click

[Hero of Time]

Een page refresh wil je ook niet altijd hebben. Als je op /last zit en er zijn meer nieuwe berichten dat je per pagina weergeeft, mis je er een paar.

[Hipska]

Dan is er maar 1 optie meer over

[pedorus]

crisp schreef op woensdag 21 augustus 2013 @ 11:36:
Uiteraard zijn er altijd wel manieren om performance te verbeteren, maar dat voegt dan meestal weer complexiteit toe wat de kosten/baten afweging weinig veranderd.

Op zich is dit een mooie gelegenheid om ervaring met iets als socket.io op te doen. Dan nemen de technologische baten gelijk toe

[crisp]

pedorus schreef op woensdag 21 augustus 2013 @ 20:42:
[...]

Op zich is dit een mooie gelegenheid om ervaring met iets als socket.io op te doen. Dan nemen de technologische baten gelijk toe

An sich is de polling en het aantal requests dat we moeten afhandelen daarvoor niet echt een probleem

[pedorus]

Wat is er nou mooier dan dat je een oplossing hebt voordat er een probleem is?

Het scheelt ook weer in de updatesnelheid en bandbreedte bijvoorbeeld, en met een apart servertje kun je de data in memory houden en hoef je ook geen extra tabel te onderhouden. "Performancetechnisch" is het de ideale oplossing, en anders valt dat argument weg.

[GlowMouse]

crisp schreef op woensdag 21 augustus 2013 @ 21:34:
[...]

An sich is de polling en het aantal requests dat we moeten afhandelen daarvoor niet echt een probleem

Dan kan de polling frequency ook wel omhoog. Nu druk je af en toe op F5 omdat je gewoon niet weet hoe oud de pagina is waarnaar je kijkt.

[8088]

Hipska schreef op woensdag 21 augustus 2013 @ 14:11:
Dan is er maar 1 optie meer over

Verwijder de edit-knop

[hylke94]

crisp schreef op woensdag 21 augustus 2013 @ 21:34:
[...]

An sich is de polling en het aantal requests dat we moeten afhandelen daarvoor niet echt een probleem

Dan valt het toch in ieder geval te proberen...

[crisp]

sure, een compleet nieuwe technology-stack opbouwen kost toch geen tijd...

[PrisonerOfPain]

Dit kan toch prima via de bestaande infrastructuur? Kwa technologie weten jullie prima wat er moet gebeuren - en hoe. Er zijn genoeg manieren om dit binnen de bestaande infrastructuur te doen. En ik verwacht ook dat iedere tweaker hier wel een mening over zou kunnen vormen maar dat is een discussie voor een andere keer. Persoonlijk zou ik hiervoor de bestaande message queue en/of key-value store voor gebruiken.

Waar het mij in deze feature-request vooral om gaat (en dat is ook de reden dat ik 'm uberhaupt indiende) is dat dit het enige ding is waaraan ik me regelmatig stoor op het forum. En het is ook eigenlijk het enige wat ik gefixed zou willen zien worden.

[pedorus]

Doet Tweakers nog niet aan 20% innovatietijd voor leuke projecten?

PrisonerOfPain schreef op woensdag 21 augustus 2013 @ 22:47:
Persoonlijk zou ik hiervoor de bestaande message queue en/of key-value store voor gebruiken.

Over welke bestaande infrastructuur heb je het hier? Of doel je op mysql/java? In mijn geval zou ik Kafka->java/socket.io->javascript gebruiken, maar ik weet vrij zeker dat dit nog niet bij Tweakers draait. In principe zou 1 node.js servertje genoeg moeten zijn, en in het ergste geval doen notificaties het even niet. En mysql/polling blijven gebruiken is in het geval van Tweakers natuurlijk het simpelst.

edit:
ActiveMQ staat er al wel inderdaad: reviews: Tweakers 7: waarom een eigen Java-back-end?

[ Voor 13% gewijzigd door pedorus op 22-08-2013 11:12 ]

[Anoniem: 19894]

Ik zie nog steeds niet de meerwaarde van edits in die balk erin. Alleen maar irritaties.

[pedorus]

Anoniem: 19894 schreef op woensdag 21 augustus 2013 @ 23:31:
Ik zie nog steeds niet de meerwaarde van edits in die balk erin. Alleen maar irritaties.

offtopic:
Kan ik me in jouw geval voorstellen... http://gathering.tweakers...ind/poster/19894/messages Hoewel de Edit-functie van zeg Skype chat ook erg handig is wat mij betreft.

[F.West98]

Kan je niet gewoon enkel de edits inladen op de nog niet weergegeven berichten? Enkel back-end anders. Lijkt mij controle op laatste ophaal-datum en kijken of de geladen posts changes hebben?
Die datum wordt volgens mij al meegegeven om te kijken OF er nieuwe posts zijn. Kan die ook worden gebruikt om te kijken of er in de geladen posts (onder de knop) edits zijn...

[PrisonerOfPain]

pedorus schreef op woensdag 21 augustus 2013 @ 23:09:

Over welke bestaande infrastructuur heb je het hier? Of doel je op mysql/java? In mijn geval zou ik Kafka->java/socket.io->javascript gebruiken, maar ik weet vrij zeker dat dit nog niet bij Tweakers draait.

offtopic:
Er staan memcached en ActiveMQ servers

Anoniem: 19894 schreef op woensdag 21 augustus 2013 @ 23:31:
Ik zie nog steeds niet de meerwaarde van edits in die balk erin. Alleen maar irritaties.

Wellicht inderdaad als je alleen maar in slowchat topics post, maar daarin word sowieso niet veel geedit. De topics waar het mij om gaat zijn de langzamere tech topics die ik open laat staan in een tabje om ze te volgen.

[Intru]

Dit zou een erg mooie feature zijn, en het gebrek ervan is momenteel 1 van de weinige dingen waar ik me aan erger in het forum. Het levert vooral verwarring op bij quotes (zoals eerder al gemeld), maar het gebeurt ook regelmatig dat een edit meer relevante informatie bevat dan de originele post.
Daardoor zit je alsnog regelmatig te F5'en in de tabbladen die je open hebt staan.

[Gamebuster]

Ik heb er nog nooit echt last van ondervonden, maar aan de andere kant: hoe "moeilijk" is het om een timestamp mee te sturen bij renderen van de pagina en bij de AJAX request voor changes de timestamp weer mee te sturen en alle wijzigen na die timestamp (incl. nieuwe posts) terug te sturen? Los van de timestamp meesturen en het renderen van de gewijzigde posts met $("#postbyid").replaceWith(...) lijkt het me een simpele aanpassing van de query.

Magoed, dit neemt natuurlijk weer nieuw elende mee, zoals eventuele javascript/flash widgets in de post die dan ook "gereset" worden. Denk aan een post met een youtube video erin die na wijzigen opeens "reset"

[ Voor 87% gewijzigd door Gamebuster op 27-08-2013 12:50 ]

[Anoniem: 296939]

Gamebuster schreef op dinsdag 27 augustus 2013 @ 12:47:
Ik heb er nog nooit echt last van ondervonden, maar aan de andere kant: hoe "moeilijk" is het om een timestamp mee te sturen bij renderen van de pagina en bij de AJAX request voor changes de timestamp weer mee te sturen en alle wijzigen na die timestamp (incl. nieuwe posts) terug te sturen? Los van de timestamp meesturen en het renderen van de gewijzigde posts met $("#postbyid").replaceWith(...) lijkt het me een simpele aanpassing van de query.

Magoed, dit neemt natuurlijk weer nieuw elende mee, zoals eventuele javascript/flash widgets in de post die dan ook "gereset" worden. Denk aan een post met een youtube video erin die na wijzigen opeens "reset"

Ik denk dat dat laatste scenario niet zo heel vaak voorkomt.