Willen we bewegende user icons ja oder nein?

[Hero of Time]

Verwijderd schreef op maandag 30 januari 2017 @ 20:49:

[...]

Zo zie ik het niet, een proof of concept heeft altijd een goed doel. Ik maak die bijna dagelijks voor alle kleine tot grote functies in applicaties die ik bouw. Zo zie ik vrij snel of iets wel of niet kan werken, daarna pas ik het aan op de doelapplicatie waarna ik het inbouw (of niet; mocht de test falen). Deze kleine PoC-projecten worden netjes allemaal verzameld in één grote SVN-bak zodat ik die later kan hergebruiken.

Hoe zinvol denk je dat het is om een bestand te kunnen selecteren voor uploaden waar je in de poc deze lokaal ergens opslaat, terwijl je hele infra is gebouwd om alles in een database op te slaan? Hoe 'eenvoudig' is het dan om die code te integreren?

Het enige wat je hebt gedaan is iets aantonen wat de devs al wisten. De complexiteit is juist die functionaliteit in de huidige code plaatsen, zorgen dat de overhead minimaal is, performance impact voor de duizenden bezoekers te minimaliseren en de code beheerbaar te houden zonder dat het in de weg zit of bij een update van het platform stuk gaat.

[Verwijderd]

Hero of Time schreef op maandag 30 januari 2017 @ 21:56:
[...]

Hoe zinvol denk je dat het is om een bestand te kunnen selecteren voor uploaden waar je in de poc deze lokaal ergens opslaat, terwijl je hele infra is gebouwd om alles in een database op te slaan? Hoe 'eenvoudig' is het dan om die code te integreren?

De PoC slaat het bestand helemaal niet op, het bestand komt op de server in een tijdelijke map binnen (PHP eigen) mijn script dan leest dit bestand in en zet het om naar een base64 image string welke direct weer teruggegeven wordt aan de zender. Mijn script verbindt niet met een database, maar met een kleine aanpassing had ik dat ook kunnen doen. Dit was echter ook niet het doel van het script: het aantonen van de eenvoud van het controleren of een afbeelding een animated gif is en zo ja er de eerste frame van pakken. Dat is 100% het doel van mij Proof of Concept.

Het enige wat je hebt gedaan is iets aantonen wat de devs al wisten. De complexiteit is juist die functionaliteit in de huidige code plaatsen, zorgen dat de overhead minimaal is, performance impact voor de duizenden bezoekers te minimaliseren en de code beheerbaar te houden zonder dat het in de weg zit of bij een update van het platform stuk gaat.

Nogmaals ik heb géén inzicht in de codebasis van Tweakers.net. Ik heb ook nooit geclaimed dat ik dat wel heb.

[Gomez12]

Verwijderd schreef op maandag 30 januari 2017 @ 22:07:
[...]
Nogmaals ik heb géén inzicht in de codebasis van Tweakers.net. Ik heb ook nooit geclaimed dat ik dat wel heb.

Waarom plaats je dan in hemelsnaam een PoC die totaal niet relevant is en eigenlijk alleen maar voor verwarring kan zorgen.

Helemaal als je de volgende teksten er ook nog eens bij gaat zetten :

Verwijderd schreef op maandag 30 januari 2017 @ 17:52:
[...]
Beide zijn vrij eenvoudig in elk php framework in te bouwen, lijkt mij zo.

In minder dan een uur gemaakt, inclusief het opzetten van een lokale webserver en XDebug voor PHP:

Het is meer trollen op deze manier dan constructief meewerken.

[Verwijderd]

Dat is gewoon hoe lang ik er mee bezig ben geweest. Ik had XDebug nodig omdat ik een paar gegevens wilde controleren (debuggen). Er zit niets aan optimalisatie (etc) in, gezien ik niet bekent ben met de codebasis van Tweakers. Ik had het in de codebasis van mijn Framework / website kunnen doen, maar ook dat zou niet direct een goed beeld geven (mijn website is niet bepaald vergelijkbaar met Tweakers ).

Maar in de basis blijft PHP gewoon PHP. Wanneer je een bestand upload komt deze binnen in de $_FILES global, wordt in de temp-map van de server opgeslagen. Je kan deze bestanden dan met PHP inlezen, manipuleren en verwerken. Hoe dit verder in het Framework van Tweakers gaat, dat weet ik niet. Mijn doel en uitgangspunt was puur php, zonder een extern framework, zelfs zonder het framework wat ik zelf geschreven heb.

Dit is een methode waarin ik ontwikkel, als iets voor mij ongrijpbaar of ingewikkeld is. Dan versimpel ik het. Werkt de simpelere oplossing naar wens dan doe ik de volgende stap. Na die stap bepaal ik van: "Mijn oplossing is goed", "Mijn oplossing voldoet", "Mijn oplossing is verkeerd" en alle drie komen voor. Hierna bepaal ik wat mijn volgende actiepunt is.

Dit is exact wat ik hier gedaan heb. Het dev-team zegt dat het moeilijk te implementeren is, dus geef ik ze een voorbeeld van hoe ik het zou doen. En dan kan je het wel trollen vinden, want dat is makkelijk als je het er niet mee eens bent, maar ik doe het met de beste bedoelingen. Ik weet serieus niet hoe ik hier verder mee moet, dus laat ik het nu maar voor wat het is.

[ACM]

Verwijderd schreef op maandag 30 januari 2017 @ 23:30:
Het dev-team zegt dat het moeilijk te implementeren is, dus geef ik ze een voorbeeld van hoe ik het zou doen.

Lees jij dat in de startpost van Femme? Of elders in dit topic?

Een gif reduceren tot slechts 1 frame is inderdaad niet per se moeilijk. Hoewel ik het met imagick zou doen en niet met een reeks functies waarbij het meer een bijeffect is dat het uiteindelijk 1 frame wordt

Dat is inderdaad het probleem niet. Hetgene wat er daarna mee moet gebeuren zit het hem in.

De gif reduceren tot 1 frame zorgt uiteindelijk voor een deel ontevredenheid waar je zelf ook nog naar verwijst, dus dat vervangt deze klacht door een andere

Maar als we een animated gif moeten opslaan in twee versies en daarvan de juiste versie afhankelijk van de voorkeuren moeten tonen, dan maken we van een eenvoudige usericon-functie ineens een veel complexer geheel. En als we het aan de client-side overlaten, dan 'verspillen' we cpu-cycles bij iedere forumtopic-view voor iets waarna maar zeer weinig mensen de moeite gaan nemen om de 'click-to-play' te activeren.

En dan zit je nog met wat uitzonderingssituaties en side-effects. Wat doe je bijvoorbeeld met png en jpeg? Daar hoef je geen twee versies van te bewaren, maar dat niet doen betekent weer een beetje extra complexiteit
En wat als de eerste frame van de gif geen mooi/compleet beeld bevat? En hoe herken je dat programmatisch?

[ Voor 12% gewijzigd door ACM op 31-01-2017 08:23 ]

[CyBeR]

De simpelste optie is gewoon icons weer limiteren tot 10 KiB. Daar past wel wát animatie in maar dat is meestal niet zo'n probleem.

[Hero of Time]

ACM schreef op dinsdag 31 januari 2017 @ 08:19:
En wat als de eerste frame van de gif geen mooi/compleet beeld bevat? En hoe herken je dat programmatisch?

Dit, precies dit is het grootste probleem. Als je gif begint met een enkele kleur, zeg zwart, en dan netjes fade naar je animatie of als er ergens op ingezoomd wordt, heb je bar weinig aan het eerste frame. Zomaar het eerste frame of frame #x pakken gaat niet zomaar werken.

[Firefly III]

-

[ Voor 100% gewijzigd door Firefly III op 21-10-2019 09:54 . Reden: Leeg ivm privacy ]

[Verwijderd]

ACM schreef op dinsdag 31 januari 2017 @ 08:19:
[...]

Lees jij dat in de startpost van Femme? Of elders in dit topic?

Het kost veel tijd om te implementeren, dus daar ben ik van uitgegaan. Ik denk dat ik het in een enkele werkdag in elk PHP framework ingebouwd kan hebben. Natuurlijk weet ik dat er meer te doen is, maar ik kan me niet indenken dat een dergelijk kleine functie die een dergelijk grote ophef voorkomt een probleem kan zijn?

Een gif reduceren tot slechts 1 frame is inderdaad niet per se moeilijk. Hoewel ik het met imagick zou doen en niet met een reeks functies waarbij het meer een bijeffect is dat het uiteindelijk 1 frame wordt

Helemaal waar, en ik zou ook niets anders van jullie devvers verwachten. Maar ik wist niet dat Tweakers imagick ondersteund - dat had het voor mij makkelijker gemaakt. En zo versterk je alleen al mijn standpunt.

Dat is inderdaad het probleem niet. Hetgene wat er daarna mee moet gebeuren zit het hem in.

De gif reduceren tot 1 frame zorgt uiteindelijk voor een deel ontevredenheid waar je zelf ook nog naar verwijst, dus dat vervangt deze klacht door een andere

Maar als we een animated gif moeten opslaan in twee versies en daarvan de juiste versie afhankelijk van de voorkeuren moeten tonen, dan maken we van een eenvoudige usericon-functie ineens een veel complexer geheel. En als we het aan de client-side overlaten, dan 'verspillen' we cpu-cycles bij iedere forumtopic-view voor iets waarna maar zeer weinig mensen de moeite gaan nemen om de 'click-to-play' te activeren.

En dan zit je nog met wat uitzonderingssituaties en side-effects. Wat doe je bijvoorbeeld met png en jpeg? Daar hoef je geen twee versies van te bewaren, maar dat niet doen betekent weer een beetje extra complexiteit
En wat als de eerste frame van de gif geen mooi/compleet beeld bevat? En hoe herken je dat programmatisch?

Je hoeft alleen de animated gif twee keer op te slaan. De functie controleert namelijk al of een gif animated is. Dit kan je al met javascript doen. (Heel belangrijk, maar daar kom ik zo op terug) Wat je doet is je maakt ruimte voor twee avatars per persoon, een niet animated en een animated. De niet animated avatar is avatar 1. Dus alle png, jpg, bmp, gif, etc met maar 1 frame. Deze toon je standaard. Je maakt echter ook bij de gebruikers een optie om "Geanimeerde user icons tonen" wanneer dezer de waarde 1 heeft toon je avatar 2 indien deze beschikbaar is anders avatar 1.

Je pakt natuurlijk niet random 1 frame uit de animated avatar. Je laat de uploader kiezen. Je controleert namelijk via JS of een avatar animated is en biedt de gebruiker mogelijkheid een statisch alternatief te kiezen. Dit kan dmv een slider die door alle frames loopt of gewoon "upload een statische afbeelding". Deze tweede afbeelding sla je op als avatar 1 en de originele animated avatar als avatar 2.

En je gelooft het niet, maar ik heb eigenlijk al de functie hierboven omschreven in een testversie van mijn eigen website zitten

[ACM]

Verwijderd schreef op dinsdag 31 januari 2017 @ 09:19:
Natuurlijk weet ik dat er meer te doen is, maar ik kan me niet indenken dat een dergelijk kleine functie die een dergelijk grote ophef voorkomt een probleem kan zijn?

Je maakt echter ook bij de gebruikers een optie om "Geanimeerde user icons tonen" wanneer dezer de waarde 1 heeft toon je avatar 2 indien deze beschikbaar is anders avatar 1.

En dus hebben we naast de preference ineens logica introduceren voor het vertonen van avatars, waar dat nu gewoon werk voor Apache is (en ja, dat kan vast ook met een rewrite-rule, maar ook dat is logica die onderhouden moet worden).

Je pakt natuurlijk niet random 1 frame uit de animated avatar. Je laat de uploader kiezen. Je controleert namelijk via JS of een avatar animated is en biedt de gebruiker mogelijkheid een statisch alternatief te kiezen. Dit kan dmv een slider die door alle frames loopt of gewoon "upload een statische afbeelding". Deze tweede afbeelding sla je op als avatar 1 en de originele animated avatar als avatar 2.

Waarmee je het 'uploaden van een plaatje' veranderd in een behoorlijk complexe versie. Zeker als je het combineert met de uitsnede-optie die er nu ook al in zit.

[Femme]

Verwijderd schreef op maandag 30 januari 2017 @ 17:52:
[...]

Dit is dus een leuke paradox. Je wil geen features toevoegen die je later mogelijk moet verwijderen om geen gebruikers boos te maken. dus stel je voor om een oude feature die door vele gebruikers al goed gebruikt wordt te verwijderen?

Zie je waar je de fout in gaat?

De kern is dat we de features willen bouwen die de meeste waarde toevoegen voor de gebruiker. In plaats van functionaliteit om bewegende user icons uit te zetten, kunnen we ook iets anders bouwen. Als we met die andere feature mensen blijer kunnen maken moeten we dat doen.

Uit de resultaten van de poll blijkt wel dat veel gebruikers animated avatars hekelen, maar ook dat het geen meerderheid is. Er zijn net zoveel gebruikers die animated user icons prima vinden. Afschaffen is dus ook niet de juiste keuze.

Bij deze stand denk ik dat we het nog het beste kunnen oplossen moet goed beleid. Het is niet zo dat het de spuigaten uitloopt met overlast door geanimeerde avatars. Het beperken van de bestandsgrootte vind ik op zich ook wel een goede natuurlijke beperking.

[_David_]

Femme schreef op dinsdag 31 januari 2017 @ 13:16:
[...]

Uit de resultaten van de poll blijkt wel dat veel gebruikers animated avatars hekelen, maar ook dat het geen meerderheid is. Er zijn net zoveel gebruikers die animated user icons prima vinden. Afschaffen is dus ook niet de juiste keuze.

De poll is maar 1412x ingevuld, wat niet eens zeker is dat het ook werkelijk 1412 gebruikers zijn aangezien de poll anoniem in te vullen is. Het lijkt mij ook niet dat je puur op basis van deze poll kan bepalen of een groot deel voor of tegen animated gifs is.

Femme schreef op dinsdag 31 januari 2017 @ 13:16:
[...]
Bij deze stand denk ik dat we het nog het beste kunnen oplossen moet goed beleid. Het is niet zo dat het de spuigaten uitloopt met overlast door geanimeerde avatars. Het beperken van de bestandsgrootte vind ik op zich ook wel een goede natuurlijke beperking.

Die max groote is er ook al, "De iconen moeten 60 x60 pixels en maximaal 100 KiB groot zijn."

Dat was trouwens ook eerst lager, maar is opgerekt toen webicons werden afgeschaft (de manier waarmee
je vroeger er voor kon zorgen dat de je de meest animated gifs niet zag was om web icons uit te zetten...)

Waarom niet een placeholder (henk...) gebruiken voor mensen die animated gifs avatars uit willen zetten?

En als dat niet wenselijk is vanwege het introduceren van een nieuwe pref, dan kan je een Trump™ beleid aannemen, voor elke pref die je toevoegt, moeten er twee verwijderd worden.

[ Voor 10% gewijzigd door _David_ op 31-01-2017 15:56 ]

[Glabbeek]

Op GoT kan je de usericons helemaal uitzetten, daarmee zijn de bewegende usericons ook weg. Ik zou al tevreden zijn als op de rest van de site deze setting ook zou werken.

[wimjongil]

Glabbeek schreef op dinsdag 31 januari 2017 @ 16:07:
Op GoT kan je de usericons helemaal uitzetten, daarmee zijn de bewegende usericons ook weg. Ik zou al tevreden zijn als op de rest van de site deze setting ook zou werken.

Wist ik niet! Bedankt, nu kan ik lekker wegblijven uit dit moddertopic. Slechtste topic van 2017, nu al.

[ArnoutV]

quote: Glabbeek

Op GoT kan je de usericons helemaal uitzetten, daarmee zijn de bewegende usericons ook weg. Ik zou al tevreden zijn als op de rest van de site deze setting ook zou werken.

Antwoord van Femme toon ik hetzelfde voorstelde:
quote:

quote: ArnoutV

schreef op donderdag 26 januari 2017 @ 15:32:
Wat ik bijzonder vind is dat je voor het forum van alles kan instellen (Toon usericons, Toon ondertitels, Toon signatures), maar dat dit niet kan voor de reacties op artikelen.
Ik heb nl. Toon usericons uitgevinkt, van mij hoeft dat allemaal niet.
Jammer dat zoiets niet ook voor nieuws reacties kan.

quote: Femme

We hebben tegenwoordig liever minder dan meer voorkeuren. Ze zorgen voor meer complexiteit, extra use cases om rekening mee te houden en verworvenheden waar gebruikers boos over worden als je ze wegneemt

[evilution]

Het ligt er ook een beetje aan hoeveel users zo'n bewegend ding hebben. Je komt ze nu maar soms tegen, althans, ik, en zelden zijn ze echt irritant, dus zal me worst wezen. Maar als een groot deel van de users animated gifs gaan gebruiken ga ik ze rap uitzetten.

[Redneckerz]

Femme schreef op maandag 30 januari 2017 @ 17:16:
[...]
De vraag is echter wat meer waarde toevoegt voor de gebruiker: het bouwen van functionaliteit om te kunnen kiezen tussen statische of mogelijk geanimeerde avatars of een van de honderden andere verbeteringen die in onze backlog wachten op uitvoering.

In dat geval zou ik dan eerst gaan afwegen wat nu belangrijker is: Een sloot verbeteringen, of wat tijd vrij maken om in het menu een ja/nee voor animated avatars aan/uit te maken.

Noem mij daarin gerust blond, maar aangezien al zoveel dingen op de site gebruik maken van eenzelfde systeem (Wellicht template?) is het mij even onduidelijk waarom het voor avatars niet gebruikt kan worden. Ik lees wat info over implementaties, maar is het niet veel simpeler om, als je avatars uitzet, deze te vervangen voor een ''standaard'' plaatje die voor iedereen hetzelfde is?

Hero of Time schreef op maandag 30 januari 2017 @ 20:48:
Precies, want naast de bestandsgrootte, worden ook dimensies gecontroleerd, bijgesneden waar nodig en mogelijk en nog meer afbeeldingmanipulatie. Daar past jouw code niet zomaar tussen.

Het is aardig dat je dit zo neerzet, maar een beetje verspilde tijd omdat het gewoon niet te integreren is in het bestaande platform.

Hero of Time schreef op maandag 30 januari 2017 @ 21:56:
[...]

Hoe zinvol denk je dat het is om een bestand te kunnen selecteren voor uploaden waar je in de poc deze lokaal ergens opslaat, terwijl je hele infra is gebouwd om alles in een database op te slaan? Hoe 'eenvoudig' is het dan om die code te integreren?

Het enige wat je hebt gedaan is iets aantonen wat de devs al wisten. De complexiteit is juist die functionaliteit in de huidige code plaatsen, zorgen dat de overhead minimaal is, performance impact voor de duizenden bezoekers te minimaliseren en de code beheerbaar te houden zonder dat het in de weg zit of bij een update van het platform stuk gaat.

Ik vind dat we Sander in ieder geval wat kudo's moeten geven dat hij hier codevoorbeelden aflevert van een mogelijke implementatie, ipv het negatief te benaderen

_David_ schreef op dinsdag 31 januari 2017 @ 13:45:
Waarom niet een placeholder (henk...) gebruiken voor mensen die animated gifs avatars uit willen zetten?

Ah kijk, iemand die een soortgelijk idee introduceert! - Redneckerz in "Willen we bewegende user icons ja oder nein?"

Het lijkt mij in ieder geval heel leuk als Henk wat prominenter weer wordt op Tweakers - Via het standaardplaatje zou dat mooi bewerkstelligd kunnen worden. En er is vast nog wel een Henk plaatje te vinden in de code die hiervoor gebruikt kan worden

Uiteindelijk ben ik van mening dat een eventuele implementatie simpel van code moet wezen zodat het relatief makkelijk te plaatsen valt tussen bestaande code. Ik denk dan aan een soort ''module'', wellicht Javascript, waarin wat we willen in een soort functie is opgenomen? Een soort ''klik'' systeem waarin deze dingen (en wellicht anderen) simpelweg er tussenin en tussenuit kan schuiven algelang de gemaakte beslissingen.

[Kecin]

Lekker laten bewegen, de afbeelding is al enorm klein en de signatures zijn ook klein. Je kan ook op je profiel de weergave helemaal uitzetten of zelf via je karma wegstijlen .