[Feature] Naast custom CSS ook custom scripts

[.oisyn]

Tweakers biedt de optie voor custom css. Ik zou graag ook een optie voor custom scripts zien. Ik browse t.net op uiteenlopende devices, dus gebruik maken van browser extensions om dingen te customizen is wat onhandig. Met support voor custom scripts op tweakers zou de experience op alle browsers effectief hetzelfde zijn.

Ik begrijp dat dit eventueel nadelig inhaakt op advertenties. Mensen zouden advertenties en adblock-detectie makkelijk om zeep kunnen helpen. Als dat een bezwaar is, zou je kunnen overwegen om het een abo- (en crew- ) only feature te maken. Dat zou ook meteen een added bonus voor abonnementen zijn, en men zou scripts uit kunnen wisselen in het abo forum

[Hero of Time]

Er wordt voor custom CSS al gekeken of het iets met de banners doet en die delen worden uitgeschakeld. Lijkt mij dat een zelfde soort intelligentie voor JS ook gedaan kan worden?

Maar wat zou je dan met zo'n custom script willen doen?

[.oisyn]

Hero of Time schreef op donderdag 04 februari 2016 @ 12:07:
Lijkt mij dat een zelfde soort intelligentie voor JS ook gedaan kan worden?

Nee, wetenschappelijk onmogelijk (leesvoer: halting problem). Je kunt niet zien wat een script doet zonder het uit te voeren. Dat gaat niet op voor CSS omdat de regels daarbij heel beperkt zijn, en je selectors die iets met de visibility banners of ancestor elementen doen er gemakkelijk uit kunt filteren.

Maar wat zou je dan met zo'n custom script willen doen?

Is dat relevant?

Maar ik zou bijvoorbeeld het omhoog/omlaag knopje altijd zichtbaar laten zijn, ongeacht de device class. Of quote-to-quickreply opnieuw implementeren (daar had ik ooit een Chrome extension voor). Of misschien wat tools maken die het modereren wat gemakkelijker maken, zoals het verplaatsen van meerdere reacties over meerdere pagina's naar een andere thread. De mogelijkheden zijn eindeloos

Dergelijke scripts zouden hun weg uiteindelijk ook terug kunnen vinden naar t.net zelf, als ze hun nut bewezen hebben. Het is dus eventueel ook voor tweakers interessant, omdat ze daarmee toegang krijgen tot een hele rits aan extra onbetaalde manuren

[.oisyn]

Of een script dat posts zonder plaatjes uit het plaatjestopic filtert

[crisp]

Het integreren van code van een buitenstaander kost doorgaans meer tijd dan het zelf schrijven

Persoonlijk ben ik bang dat het aantal mensen dat dit uiteindelijk kan en gaat gebruiken te klein is om hier vanuit ons moeite in te gaan steken...

[Hero of Time]

.oisyn schreef op donderdag 04 februari 2016 @ 15:35:
Of een script dat posts zonder plaatjes uit het plaatjestopic filtert

Daarvoor heb je een functie in je browser, genaamd 'toon afbeeldingen'.

Het idee is aardig zoals je 'm schetst, maar de nadelen (complexiteit enzo) vind ik persoonlijk te zwaar wegen om het zinvol te maken om te implementeren. Zoals je zegt kan het heel complex en het 'halting' probleem is niet op te lossen. Je zit dus met een groot gat dat je liever niet wilt hebben.

Je zit straks ook nog met https en via JS kan je weer externe elementen laden waardoor je mixed content krijgt. Ook niet erg gewenst.

[.oisyn]

crisp schreef op donderdag 04 februari 2016 @ 16:08:
Persoonlijk ben ik bang dat het aantal mensen dat dit uiteindelijk kan en gaat gebruiken te klein is om hier vanuit ons moeite in te gaan steken...

Ik denk dat je dan het aantal gebruikers beperkt tot developers, maar dat is natuurlijk niet reëel. Ik had destijds al best wel wat gebruikers van mijn chrome extension. Greasemonkey scripts en custom css zie ik ook gedeeld worden. Nu we het er toch over hebben, wat je zegt gaat natuurlijk net zo goed op voor custom css. Hoeveel gebruikers zijn er daarvan?

Hero of Time schreef op donderdag 04 februari 2016 @ 16:08:
Het idee is aardig zoals je 'm schetst, maar de nadelen (complexiteit enzo) vind ik persoonlijk te zwaar wegen om het zinvol te maken om te implementeren.

Er is geen complexiteit. Er is een invoerveld waarin je script kan dumpen, en de pagina laadt dat script. Net zoals bij custom CSS. Verder was ik niet op de hoogte van jouw functie bij triage, waarvan acte.

Zoals je zegt kan het heel complex en het 'halting' probleem is niet op te lossen. Je zit dus met een groot gat dat je liever niet wilt hebben.

Dat is nonsens, het gat is niet groter dan met browser extensions en custom scripts. Iedereen is nu al in controle over wat er gebeurt op zijn eigen PC, en dat staat los van wat er op de servers van t.net gebeurt. Er is geen gat, en er is geen complexiteit, tenzij je met veel moeite het script probeert te analyseren om te kijken wat het gaat doen. Voor niks, want je (t.net) hebt er zelf geen last van.

Je zit straks ook nog met https en via JS kan je weer externe elementen laden waardoor je mixed content krijgt. Ook niet erg gewenst.

Je snapt dat dat alleen het geval is bij degene die er zelf voor kiezen om externe content vanuit hun eigen scripts te laden, right?

[ Voor 51% gewijzigd door .oisyn op 04-02-2016 16:33 ]

[crisp]

Custom CSS hoeven we niet te beperken tot abonnees.

[.oisyn]

Het zou ook een unique selling feature kunnen zijn. Ik kan niet voor anderen oordelen, maar ik zou daar een abo voor afsluiten

[ Voor 43% gewijzigd door .oisyn op 04-02-2016 16:39 ]

[Douweegbertje]

Je hoeft alleen maar een stukje 'script' op te slaan en eruit te gooien onderaan elke pagina. Het is clientside dus in het ergste geval verpest iemand zijn eigen ervaring (net zoals het nu al met CSS kan).

Om heel eerlijk te zijn zie ik alleen maar reacties van mensen die eigenlijk niet snappen wat het nu precies doet en wat hierbij de gevolgen zijn. Iedereen kan al JS e.d. invoegen d.m.v. de console en/of extensies. Derhalve zijn letterlijk al jullie argumenten omtrent 'veiligheid' en dat soort geneuzel niet meer van toepassing.

[Hero of Time]

.oisyn schreef op donderdag 04 februari 2016 @ 16:28:
Nu we het er toch over hebben, wat je zegt gaat natuurlijk net zo goed op voor custom css. Hoeveel gebruikers zijn er daarvan?

Voor Custom CSS heb ik maar een klein stukje, maar ik moet eigenlijk eens alles (of het meerendeel iig) naar Tweakers zetten, ipv via m'n browser dat te doen, het beheer is nu wat onhandig. Er zullen vast meer gebruikers zijn die 't via een add-on oid doen (bij mij is het een functie in de browser zelf ).

[...]

Er is geen complexiteit. Er is een invoerveld waarin je script kan dumpen, en de pagina laadt dat script. Net zoals bij custom CSS. Verder was ik niet op de hoogte van jouw functie bij triage, waarvan acte.

Ik had het niet over de complexiteit van het laten uitvoeren, maar over de complexiteit om het veilig te doen en te zorgen dat er geen dingen worden gedaan die niet gewenst is, zoals het uitschakelen of verbergen van banners. Zoals je zei, die intelligentie is niet zo triviaal als bij CSS.

[...]

Je snapt dat dat alleen het geval is bij degene die er zelf voor kiezen om externe content vanuit hun eigen scripts te laden, right?

Dat weet ik. Nu ik er over nadenk, kan je met custom css eigenlijk externe css inladen? Want dan zou je het heel naar kunnen doen en alle banners op die manier 'slopen' zonder dat de parser dit tegenhoud.

[.oisyn]

Hero of Time schreef op donderdag 04 februari 2016 @ 16:55:
Ik had het niet over de complexiteit van het laten uitvoeren, maar over de complexiteit om het veilig te doen en te zorgen dat er geen dingen worden gedaan die niet gewenst is, zoals het uitschakelen of verbergen van banners. Zoals je zei, die intelligentie is niet zo triviaal als bij CSS.

Ik zeg dat je geen moeite moet doen om die intelligentie toe te voegen, want het slaat nergens op. Je lijkt je er niet van bewust dat ik alle mogelijkheden die custom scripts met zich meebrengen, nu al mogelijk zijn. Iedereen kan een ad blocker installeren. Ook kan iedereen met custom CSS en custom scripts het detecteren van de ad blocker teniet doen.

Dat weet ik. Nu ik er over nadenk, kan je met custom css eigenlijk externe css inladen? Want dan zou je het heel naar kunnen doen en alle banners op die manier 'slopen' zonder dat de parser dit tegenhoud.

Nogmaals, het is nonsens. Ik kan banners ook blocken met een browser extension die custom css levert.

[Douweegbertje]

Hero of Time schreef op donderdag 04 februari 2016 @ 16:55:
[...]

Voor Custom CSS heb ik maar een klein stukje, maar ik moet eigenlijk eens alles (of het meerendeel iig) naar Tweakers zetten, ipv via m'n browser dat te doen, het beheer is nu wat onhandig. Er zullen vast meer gebruikers zijn die 't via een add-on oid doen (bij mij is het een functie in de browser zelf ).


[...]

Ik had het niet over de complexiteit van het laten uitvoeren, maar over de complexiteit om het veilig te doen en te zorgen dat er geen dingen worden gedaan die niet gewenst is, zoals het uitschakelen of verbergen van banners. Zoals je zei, die intelligentie is niet zo triviaal als bij CSS.


[...]

Dat weet ik. Nu ik er over nadenk, kan je met custom css eigenlijk externe css inladen? Want dan zou je het heel naar kunnen doen en alle banners op die manier 'slopen' zonder dat de parser dit tegenhoud.

Nog een keer:

Iedereen kan al JS e.d. invoegen d.m.v. de console en/of extensies. Derhalve zijn letterlijk al jullie argumenten omtrent 'veiligheid' en dat soort geneuzel niet meer van toepassing.

[Hero of Time]

Denken jullie nu werkelijk dat ik dom ben? Weet je, laat ook maar.

[Douweegbertje]

Ja.

[NMe]

Ik zou deze feature ook toejuichen. Ik heb nog best regelmatig op het punt gestaan om een GreaseMonkey-scriptje te schrijven om een klein stukje irritatie weg te werken om het vervolgens maar achterwege te laten omdat het mij te lastig is om dat script vervolgens op al mijn devices te moeten installeren en bij wijzigingen up to date te houden. Voor iets dat in feite niet meer is dat een tekstveldje dat je, indien aanwezig, includet op elke pagina (niet anders dan custom CSS, lijkt me) kan ik me niet voorstellen dat het een grote wijziging is. Rechtentechnisch zou ik het onder dezelfde rechten als custom CSS wegstoppen, zodat je ook daar geen omkijken naar hebt.

[_David_]

Dit lijkt mij een goeie kandidaat voor een abonnee feature (hoef je ook niet bang te zijn dat mensen het gebruiken om de advertenties weg te halen)

Ik heb meerdere scripts op mn desktop draaien voor Tweakers (vooral moderatie gedoe) en het zou ideaal zijn als ik die automatisch kan meenemen naar m'n laptop en mobiel

[NMe]

Ik zou überhaupt niet bang zijn voor (of rekening houden met) mensen die advertenties weghalen. Het is vele keren makkelijker om een adblocker te installeren dan om zo'n script te schrijven.

[ Voor 6% gewijzigd door NMe op 04-02-2016 18:10 ]

[_David_]

NMe schreef op donderdag 04 februari 2016 @ 18:10:
Ik zou überhaupt niet bang zijn voor (of rekening houden met) mensen die advertenties weghalen. Het is vele keren makkelijker om een adblocker te installeren dan om zo'n script te schrijven.

Totdat iemand een tweakblog schrijft met een scriptje die het doet, dan is 1x een scriptje plakken in een tekst veld en dan overal waar je ingelogd bent geen advertenties hebben makkelijker

[NMe]

_David_ schreef op donderdag 04 februari 2016 @ 18:26:
[...]

Totdat iemand een tweakblog schrijft met een scriptje die het doet, dan is 1x een scriptje plakken in een tekst veld en dan overal waar je ingelogd bent geen advertenties hebben makkelijker

En dan heb je banners geblockt op Tweakers maar nergens anders. Het lijkt me bijzonder onwaarschijnlijk dat iemand OK is met banners op de rest van het internet en uitgerekend het milde bannerbeleid op Tweakers tegengaat met een custom script.

[crisp]

Ik ben er iig geen voorstander van om het simpele feit dat het misbruik in de hand werkt (denk bijvoorbeeld aan een grapjas die het gebruikt om automatisch alle posts in een topic een Henk/duim te geven), en wij er dan niet tegen op kunnen treden omdat we het zelf faciliteren...

Daarbij kan een fout of incompatitbiliteit met onze eigen scripts een grotere impact hebben dan een css fout.

[ Voor 16% gewijzigd door crisp op 04-02-2016 18:52 ]

[NMe]

We faciliteren ook dat iemand het handmatig kan doen, dat betekent toch ook niet dat we er niet tegen kunnen optreden? Al snap ik op dat vlak je zorgen wel.

[_David_]

NMe schreef op donderdag 04 februari 2016 @ 18:46:
[...]

En dan heb je banners geblockt op Tweakers maar nergens anders. Het lijkt me bijzonder onwaarschijnlijk dat iemand OK is met banners op de rest van het internet en uitgerekend het milde bannerbeleid op Tweakers tegengaat met een custom script.

Daar heb je zeker gelijk in maar je geeft dan wel als website de optie.

En het is nogal raar dat je een functie van de website kan gebruiken om iets te doen waar je dan vervolgens een melding over krijgt om het niet te doen

[Douweegbertje]

crisp schreef op donderdag 04 februari 2016 @ 18:48:
Ik ben er iig geen voorstander van om het simpele feit dat het misbruik in de hand werkt (denk bijvoorbeeld aan een grapjas die het gebruikt om automatisch alle posts in een topic een Henk/duim te geven), en wij er dan niet tegen op kunnen treden omdat we het zelf faciliteren...

Daarbij kan een fout of incompatitbiliteit met onze eigen scripts een grotere impact hebben dan een css fout.

Ik snap wat je wilt zeggen, alleen klopt heel je redenatie naar mijn mening niet.

Omdat je toevallig een feature hebt, wilt nog niet zeggen dat je een 'malafide' script faciliteert. De regel moet globaal zijn. Hell, ik kan het nu ook middels een script of handmatig, het zou per definitie verboden moeten zijn om misbruik van 'iets' te maken, of het nu op manier x, y of z gebeurt.

Kijk; mocht er nou niet iets bestaan zoals greasemonkey, de console of überhaupt 'clientside injection' dan was ik het 10000% met je eens. Nu zit je met alle respect ouderwets te doen

De enige insteek waaruit nu gedacht wordt is dat wij dingen zouden misbruiken. Dat is geen uitgangspunt voor een discussie om iets voor elkaar te krijgen. Menig tweaker hier die iets van code weet kan jullie leven een hel maken, maar dat zie je toch ook niet gebeuren? Wellicht denk ik dan te positief, maar ik zie absoluut geen probleem.

Even heel kinderachtig; check je eigen motto even: Wij stellen technologie op de proef

Daarbij kan een fout of incompatitbiliteit met onze eigen scripts een grotere impact hebben dan een css fout.

Not really.. userside en clientside.
Echt het is net als een API, wat boeit het wat de end-user doet met je data? Als hun het 'verpesten' dan ligt het probleem toch daar?
Op het moment dat je het hebt over het feit dat eventueel een script er voor kan zorgen dat jullie website down gaat.. dan heb je sowieso al een probleem want dan zou dat op dit moment ook al kunnen.

Leg het mij anders maar goed uit met een concreet voorbeeld als ik het fout heb.

[ Voor 16% gewijzigd door Douweegbertje op 04-02-2016 21:09 ]

[.oisyn]

crisp schreef op donderdag 04 februari 2016 @ 18:48:
Ik ben er iig geen voorstander van om het simpele feit dat het misbruik in de hand werkt (denk bijvoorbeeld aan een grapjas die het gebruikt om automatisch alle posts in een topic een Henk/duim te geven)

En dat kan niet met een greasemonkey script omdat... ?

en wij er dan niet tegen op kunnen treden omdat we het zelf faciliteren...

En je kunt er wel tegenop treden als het een greasemonkey script is omdat... ?

Daarbij kan een fout of incompatitbiliteit met onze eigen scripts een grotere impact hebben dan een css fout.

En dat is anders dan bij een greasemonkey script omdat... ?

Verander "greasemonkey" naar hartelust met iedere andere methode die clientside javascript insert.

[ Voor 6% gewijzigd door .oisyn op 04-02-2016 21:33 ]

[.oisyn]

Hero of Time schreef op donderdag 04 februari 2016 @ 17:24:

Denken jullie nu werkelijk dat ik dom ben? Weet je, laat ook maar.

Wat ik me vooral afvraag is waarom je nu wederom loopt te bitchen over een bepaalde feature die ik suggereer. Is dat je taak hier? Ga jij erover of iets teveel werk is? Trek je altijd alles standaard in twijfel?

[ Voor 17% gewijzigd door .oisyn op 04-02-2016 21:39 ]

[crisp]

Douweegbertje schreef op donderdag 04 februari 2016 @ 21:06:
[...]

Als hun het 'verpesten' dan ligt het probleem toch daar?

Uiteindelijk wel, maar de kans bestaat dat wij dan eerst een bugreport hebben mogen ontvangen en daar tijd aan besteed hebben om er vervolgens achter te komen dat het door een zelfgebakken of gekopieerd userscriptje komt. Dat gebeurt nu al af en toe met custom css...

[Douweegbertje]

En uiteindelijk zijn het

a) de mensen met affiniteit die zelf een script maken en daarbij niet helemaal 'stom' zijn om vervolgens een bugreport te maken als er vervolgens iets kapot gaat.
b) de mensen die van een persoon X het script krijgen die meestal goed getest is en vervolgens zelf ook wel de conclusie kunnen trekken waar het aan ligt.

De drempel ligt sowieso iets hoger bij CSS en als we zo gaan redeneren dan zou je beter CSS eruit kunnen halen en scripts kunnen toevoegen qua 'support gehalte' omdat CSS veel laagdrempeliger is en waar je eventueel meer gezeik mee kan krijgen.

Ligt het overigens aan mij dat je er al bij het begin van het topic een "nee" in je hoofd hebt zitten, en verder niet open voor de suggestie staat? Ik weet dat het heel makkelijk is om negatief te zijn over iets, maar kunnen we even het uitgangspunt veranderen?


Er zijn namelijk zoveel leuke features mogelijk, en daarbij scheelt het uiteindelijk jullie enorm veel tijd aangezien de community zelf met dingen kan komen zonder dat jullie dit hoeven te maken. Eventueel kan je bij een erg succesvolle 'plugin' dit standaard doorvoeren bij iedereen.

• Mensen van de community, en met name de 'coders' willen dit.
• Biedt enorm veel leuke mogelijkheden, voor de gehele community middels gedeelde 'scripts' die users maken
• Mogelijkheden voor extra sales d.m.v. dit abbo-only te maken
• Het scheelt jullie dev werk op de lange termijn. Immers zijn we niet direct voor alles meer afhankelijk
• We zijn Tweakers... (dit punt alleen al..)
• Dit soort dingen heeft zich al jaren bewezen; elk fatsoenlijk CMS / framework heeft mogelijkheden tot plugins / addons. Zo zie ik deze feature ook.
• Er is geen enkel gedegen tegenargument gekomen

Sorry dat ik dit topic semi-hijack van .oisyn maar het is gewoon een enorm goed idee en ik sta er ook achter.

[Ramon]

Douweegbertje schreef op donderdag 04 februari 2016 @ 22:14:
En uiteindelijk zijn het

a) de mensen met affiniteit die zelf een script maken en daarbij niet helemaal 'stom' zijn om vervolgens een bugreport te maken als er vervolgens iets kapot gaat.
b) de mensen die van een persoon X het script krijgen die meestal goed getest is en vervolgens zelf ook wel de conclusie kunnen trekken waar het aan ligt.

De drempel ligt sowieso iets hoger bij CSS en als we zo gaan redeneren dan zou je beter CSS eruit kunnen halen en scripts kunnen toevoegen qua 'support gehalte' omdat CSS veel laagdrempeliger is en waar je eventueel meer gezeik mee kan krijgen.

Ligt het overigens aan mij dat je er al bij het begin van het topic een "nee" in je hoofd hebt zitten, en verder niet open voor de suggestie staat? Ik weet dat het heel makkelijk is om negatief te zijn over iets, maar kunnen we even het uitgangspunt veranderen?


Er zijn namelijk zoveel leuke features mogelijk, en daarbij scheelt het uiteindelijk jullie enorm veel tijd aangezien de community zelf met dingen kan komen zonder dat jullie dit hoeven te maken. Eventueel kan je bij een erg succesvolle 'plugin' dit standaard doorvoeren bij iedereen.

• Mensen van de community, en met name de 'coders' willen dit.
• Biedt enorm veel leuke mogelijkheden, voor de gehele community middels gedeelde 'scripts' die users maken
• Mogelijkheden voor extra sales d.m.v. dit abbo-only te maken
• Het scheelt jullie dev werk op de lange termijn. Immers zijn we niet direct voor alles meer afhankelijk
• We zijn Tweakers... (dit punt alleen al..)
• Dit soort dingen heeft zich al jaren bewezen; elk fatsoenlijk CMS / framework heeft mogelijkheden tot plugins / addons. Zo zie ik deze feature ook.
• Er is geen enkel gedegen tegenargument gekomen

Sorry dat ik dit topic semi-hijack van .oisyn maar het is gewoon een enorm goed idee en ik sta er ook achter.

1) Wat voor leuke features zie je hierdoor komen?
2) Hoeveel mensen zullen zich laten verleiden tot een abo als dit abo-only wordt?
3) Dat een CMS/framework dit biedt, heeft toch niets met een site als t.net te maken?
4) Waarom dan niet gewoon een REST api? Dat geeft nog véél meer mogelijkheden tot leuke "web 2.0 mashups"...

Een geldig tegenargument is gewoon "Het kost tijd en het levert weinig op", dat je dat blijkbaar niet accepteert als argument ligt niet aan crisp.

[ Voor 3% gewijzigd door Ramon op 04-02-2016 22:35 ]

[Douweegbertje]

1; dat zie je grotendeels vanzelf terug. Mensen zijn creatief..
Het voordeel van jquery is dat je o.a. heel het DOM kan aanpassen.

- Indien ik nu een 'ga naar boven' knop wil, dan kan ik dat zo toevoegen.. inclusief dat hij mij 'volgt' op de pagina.
- Geluidje bij een nieuwe post
- Stukjes functionaliteiten aanpassen/verstoppen/verplaatsen per device (en nee dat gaat soms niet alleen met css).
- De look & feel in zijn algemeenheid. Met CSS kun je de basis goed aanpassen, maar je bent nog steeds afhankelijk van de beschikbare elementen.
- Andere editor
- Eigen shortcuts
- Iemand 'taggen' (dit kan een module worden voor iedereen die een script heeft)
- Markeer alles als gelezen-knop
- [FR]onthouden waar je gebleven bent in topic
- Filter voor specifieke scores bij reacties

en zo kan ik wel verder gaan zoeken in het 'Mooie Features' gedeelte, maar dat is allemaal mogelijk met scripts


2; Dat is afhankelijk van wat voor aanbod er is. Ik weet zeker als er veel scripts zijn, dat er zeker een stijging merkbaar moet zijn. Ik wil ook best realistisch zijn dat het aantal niet perse veel zal zijn, vooral in het begin.

3; uh jawel. Internet = internet. Het geeft aan dat mensen dingen willen personaliseren. Vergeet niet dat er soms hier mensen aardig wat uurtjes spenderen. Is het dan zo gek dat ze zelf ook iets willen veranderen? Als je ziet hoeveel feature requests er zijn, die dan ook nog eens mogelijk worden dmv scripts?

Weet je wel niet wat de invloed van 3rd party materiaal is geweest de afgelopen jaren? Hell, zelfs met games zoals Warcraft is door een plugin/addon het befaamde DOTA uitgekomen. Hoe erg moeten plugins/addons zich nog bewijzen?

4; omdat tweakers daar helemaal anaal over doet


En dat argument is alsnog geen goed argument want dat bewijs ik nog maar eens met deze post. Daarbij als het er is, dan hoeven we dit soort discussies in elk onderwerp niet te hebben want dan maak ik het zelf wel.

IMO sla je plank redelijk mis als je vooral als techsite met zo'n grote community van mensen die iets 'kunnen' zo'n feature niet omarmt.

[ Voor 9% gewijzigd door Douweegbertje op 05-02-2016 00:13 ]

[_trickster_]

crisp schreef op donderdag 04 februari 2016 @ 22:00:
[...]

Uiteindelijk wel, maar de kans bestaat dat wij dan eerst een bugreport hebben mogen ontvangen en daar tijd aan besteed hebben om er vervolgens achter te komen dat het door een zelfgebakken of gekopieerd userscriptje komt. Dat gebeurt nu al af en toe met custom css...

Mij lijkt dit ook een mooie Feature en voor bovenstaand probleem is het Volgens Mij juist makkelijker om erachter te komen dat mensen custom CSS of custom javascript draaien omdat het bij jullie bekend is en niet lokaal wordt geïnjecteerd dmv een browser extensie.
Dan zou je bij een bug report van een user gelijk in jullie DB kunnen zien dat er überhaupt custom aanpassingen zijn en dan al dan niet automatisch kunnen melden of ze het eerst willen testen zonder hun custom spul

[NMe]

crisp schreef op donderdag 04 februari 2016 @ 22:00:
[...]

Uiteindelijk wel, maar de kans bestaat dat wij dan eerst een bugreport hebben mogen ontvangen en daar tijd aan besteed hebben om er vervolgens achter te komen dat het door een zelfgebakken of gekopieerd userscriptje komt. Dat gebeurt nu al af en toe met custom css...

offtopic:
Wat daar zou kunnen helpen is als je aan elke pagina op Tweakers een parameter kan meegeven waarmee je aangeeft dat je géén custom CSS wil inladen (en ook geen custom JS als deze feature er ooit zou komen). Je hoeft dan vrijwel geen tijd te besteden aan dat soort bugtopics: als iemand zegt dat een bepaalde pagina er raar uitziet link je gewoon naar dezelfde pagina mét die parameter in de URL en de vraag "werkt het zo wel?"

[F.West98]

Oh +1 voor dit idee!
Ik heb dit volgens mij een paar jaar geleden ook al gevraagd (bij een lijstje voor abo-features volgens mij), lijkt mij erg handig om te hebben!
Heb op het moment op PC bijvoorbeeld een uitklapbaar Forum-menu in de header maar dat werkt dan weer niet op alle andere apparaten. Lijkt mij erg fijn om te hebben!

@abo's: Het zou voor mij iig een extra incentive zijn geweest om een abo te nemen, naast de advertenties natuurlijk.

[.oisyn]

Ramon schreef op donderdag 04 februari 2016 @ 22:34:
Een geldig tegenargument is gewoon "Het kost tijd en het levert weinig op", dat je dat blijkbaar niet accepteert als argument ligt niet aan crisp.

Nogal wiedes dat ik dat niet accepteer. De tijd die het kost is bijna verwaarloosbaar klein, en wat het oplevert zijn potentieel extra abo's, en tevreden mensen die nou eindelijk eens gewoon zelf hun features kunnen implementeren ipv de hele tijd te horen te krijgen dat ergens geen tijd voor is

[crisp]

.oisyn schreef op vrijdag 05 februari 2016 @ 03:25:
[...]

De tijd die het kost is bijna verwaarloosbaar klein [...]

Ah, daar istie weer...

Nee, de tijd is niet verwaarloosbaar klein. Het ontwikkelen van deze feature behelst in ieder geval het volgende:
- uitbreiding voorkeurentabel
- voorkeuren formulier uitbreiden + verwerking en eventuele validatie (mooiste zou een syntax-check zijn)
- verwerken in ons front-end framework waarbij nog nagedacht moet worden waar we de code injecteren:
-- in de <head>?
-- voor de </body>?
-- op domcontentloaded?
- moeten we de code wrappen in een self-invoking function expression om global namespace vervuiling te voorkomen?
- iets maken waarmee wij als devvers snel en makkelijk kunnen zien of iemand deze feature gebruikt
- ervoor zorgen dat bij impersonatie deze feature niet actief is (ivm security-risks)
- wegwerken tech-debt in de geraakte code (die zal er zeker zijn)
- unit tests schrijven
- testing (UAT, eventueel nog een ronde met crew en/of gebruikers)

dan ben je dus al makkelijk een dagje zoet. En vervolgens moet je aan een stuk meer mensen uit gaan leggen waarom sommige dingen toch relatief veel tijd kosten "omdat gebruiker X het met 10 regels javascript kan"...

[ Voor 4% gewijzigd door crisp op 05-02-2016 08:58 ]

[NMe]

crisp schreef op vrijdag 05 februari 2016 @ 08:55:
[...]

Ah, daar istie weer...

Nee, de tijd is niet verwaarloosbaar klein. Het ontwikkelen van deze feature behelst in ieder geval het volgende:
- uitbreiding voorkeurentabel

Een nieuwe voorkeur is niet nodig, alleen een nieuw veld om het script in op te slaan. Het uitbreiden van een tabel met een text-field lijkt me niet eens het benoemen waard.

- voorkeuren formulier uitbreiden + verwerking en eventuele validatie (mooiste zou een syntax-check zijn)

Klinkt als overbodige eye-candy. Dat gebeurt nu met de CSS toch ook niet? Als iemand zijn pagina's verkloot met zijn eigen script is dat z'n eigen verantwoordelijkheid IMO.

- verwerken in ons front-end framework waarbij nog nagedacht moet worden waar we de code injecteren:
-- in de <head>?
-- voor de </body>?
-- op domcontentloaded?

Het lijkt me een redelijke no-brainer om voor dat laatste te kiezen wegens gebruiksgemak achteraf zodat de gebruiker ervan uit kan gaan dat alles ingeladen is.

- moeten we de code wrappen in een self-invoking function expression om global namespace vervuiling te voorkomen?

Ja.

- iets maken waarmee wij als devvers snel en makkelijk kunnen zien of iemand deze feature gebruikt

SELECT * FROM SettingsTable WHERE CustomJS IS NOT NULL

- ervoor zorgen dat bij impersonatie deze feature niet actief is (ivm security-risks)

Dat heb je, neem ik aan, toch ook al voor custom CSS?

dan ben je dus al makkelijk een dagje zoet. En vervolgens moet je aan een stuk meer mensen uit gaan leggen waarom sommige dingen toch relatief veel tijd kosten "omdat gebruiker X het met 10 regels javascript kan"...

Je kan het ook omdraaien. "Wij gaan Y niet bouwen maar gebruiker X heeft het met 10 regels javascript gedaan op een manier die voor jou misschien acceptabel is, misschien kun je dat overnemen." Je zal er enerzijds ongetwijfeld meer werk aan overhouden maar anderzijds houdt de community zichzelf vast aardig in stand met een leuke scriptverzameling om veel terugkomende problemen op semi-acceptabele manier lokaal op te lossen, net zoals dat nu met het CSS-topic gaat.

Ik ga er met liefde in mee dat een feature als deze misschien wat meer werk kost dan op het eerste gezicht lijkt, maar een deel van wat je hierboven noemt lijkt me heel makkelijk kort te sluiten. Dat je nog steeds kwijt bent voor ontwikkelen en testen is nogal wiedes maar verder is dit typisch zo'n feature die zelfs in zijn meest basale vorm al veel verschil zou kunnen maken.

Dit even los van de wenselijkheidsvraag, want zoals gezegd begrijp ik je bezwaren op dat vlak wel.

[crisp]

Je gaat wel,weer erg kort door de bocht NMe. Als we op de door jou geschetste manier zouden ontwikkelen dan hadden we waarschijnlijk nog veel meer tech-debt

Een database wijziging moet gedocumenteerd worden voor de release en (tijdelijk) opgenomen worden in de automatische updatescripts voor onze testomgevingen. En dat we sommige zaken al hebben voor custom CSS wil niet zeggen dat je dat dan alleen maar hoeft te copy/pasten. Dat is niet DRY.

Ook wil ik niet bij elke bugmelding de database in moeten duiken om te zien of iemand custom scripts heeft draaien.

En je gaat volledig voorbij aan het tech-debt verhaal. Dat is namelijk een serieuze issue, en derhalve moeten we dat wel meenemen bij wijzigingen die we doen aan oude(re) code.

[NMe]

Daar ga ik niet aan voorbij, ik ga er niet tegenin omdat ik begrijp dat dat een punt is.

En ja, DRY... Ik weet het niet, met een stukje copy/pastewerk zou je deze feature veel makkelijker implementeren. Dat het sec niet helemaal netjes is en je bijvoorbeeld liever een CustomResource hebt met een (mime?) type en een vrij tekstveld waarvan je er een of meer aan een gebruiker kan koppelen ben ik ook wel met je eens omdat je dan zowel CSS en JS in die tabel kwijt kan, maar de kans dat je die uitbreidbaarheid ooit nodig gaat hebben is nihil. Soms mag een beetje pragmatiek IMO best tijdens het developen.

[Douweegbertje]

De helft van de meuk had je al kunnen maken in de tijd die je hebt genomen in de reacties waarbij je uitlegt om het niet te doen.

Maar goed, prima dat je er goed over nadenkt en alles netjes wilt doen. Aan de andere kant jammer dat je dat als pure argument gebruikt om iets niet te doen. Soms moet je voor leuke features minder leuk werk doen. Ik ga me niet eens inhoudelijk bemoeien over de implementatie, ik weet niet hoe dat bij jullie er allemaal uitziet. Het enige wat ik kan vertellen is dat zelfs als je alle ins&outs hebt verzameld, dat dit geen major project is.

[matroosoft]

Het merendeel van degenen die dit willen zijn mod of admin. Deze feature zou natuurlijk een mooi bedankje zijn voor hun werk..

..En tegelijkertijd mooi meegenomen zijn voor mij natuurlijk.

Maar even serieus, mij lijkt het een mooie feature. Of het het werk waard is laat ik aan de devvers, maar als het toegevoegd wordt weet ik zeker dat het veel gebruikt gaat worden.

[ Voor 32% gewijzigd door matroosoft op 16-02-2016 14:24 ]

[azerty]

Ik zou deze feature ook wel graag geïmplementeerd willen zien

[ Voor 14% gewijzigd door azerty op 26-02-2016 09:59 ]

[Rutix]

Ik zou dit ook graag zien . Heb de discussie gevolgd en ik haat vaak +1 maar in dit geval wel ik mijn steun wel even laten blijken

[Zeror]

Aangezien het vooral om uiterlijk of weergave gaat waar die scripts voor gebruikt zullen worden, zou ik eerder een soort van drag&drop interface willen zien, maar wel alleen voor abo's.

Tevens de mogelijkheid om aan blokken bepaalde condities mee te geven om ze aan de hand daarvan te tonen of niet. Bijvoorbeeld: Post heeft geen plaatjes = verbergen, video is niet onderwerp games = verbergen, Ik wil geen poll op de frontpage = verbergen, etc....