Call-for-features voor de forumsoftware

[Spider.007]

Wij hebben wat tijd ingepland om React 1.9.5 te gaan afmaken. Naast een aantal zaken die we zelf al hebben verzameld [vooral qua performance] zijn we geïnteresseerd naar zaken waarvan jullie denken dat ze nog in React thuishoren. Denk hierbij aan features met betrekking tot DM's en dergelijk. Het gaat hier dus niet om templatezaken maar echt om functionele features.

Heb je nog ideeën in je achterhoofd; of stonden er nog feature-requests open; post ze dan in dit topic en we gaan kijken wat we nog in kunnen bouwen. Dit uiteraard zonder garantie op implementatie

---

chem schreef op woensdag 31 januari 2007 @ 13:20:
Even een reply tot zover van wat we overwegen (wat er niet bijstaat is al afgevallen )

• RSS feed voor DM zal vrijwel zeker komen
• Gebruikers die je wel/niet mogen DM'en: misschien dat we dit doen zoals NME voorstelt; aan de hand van je buddy list (met een voorkeur uiteraard)
• Discussies ongelezen markeren gaan we bekijken
• Extra text/uitleg bij bookmarks kunnen we bekijken
• PM management voor verwijderen, uitschrijven etc. gaan we onder de loep nemen
• Het wissen van PH items vind ik discutabel, ik vind het zelf onzinnig. Het kost ook weer flink wat GUI tools om de verstopte items weer wel te zien etc. We'll see
• DM wijzigen tot hij gelezen is

---

Zaken zoals web2.0-stijl posten, extra profielvelden etc. vallen buiten dit topic, want dat kan t.net zelf oppaken; we zoeken hier vooral naar features voor react zelf.

[ Voor 45% gewijzigd door Spider.007 op 02-02-2007 11:08 ]

[AW_Bos]

Hmz...
• /disussion_block_user voor DM, dat ik bepaalde users die me 'stalken' via DM kan weigeren (ook voor profielberichten hoewel dat op GoT uit staat ).
• Afmeld systeem voor DM's (denk eens aan die rage met die Groeps DM bij introducering van 194)
• RSS feeds voor DM's

[ Voor 13% gewijzigd door AW_Bos op 31-01-2007 11:50 . Reden: enkelfout, meervoud... :+ ]

[Osiris]

Zoals ik eerder in een topic al aangekaart had (maar dat was onder de veronderstelling dat ik slechts één, praktisch onmogelijk iets wilde op slot gegaan) een mogelijkheid om in je profiel aan te geven dat je een PGP/GPG-key hebt.

Meest simpele oplossing zou een soort "vinkje" zijn met een bool in de DB ja/nee een key en dat dat vinkje dan ook achter/onder het e-mail-adres van de user komt te staan. T.net-server-served keys is beetje overdreven, dus wellicht dat 't mogelijk is om een linkje te maken naar een keyserver. Bijvoorbeeld inc pulldown in de profiel-edit-pagina waarbij je kunt selecteren uit de meest voorkomende keyservers.

Dit is overigens niet zozeer DM-gericht, maar een profiel-feature. Of valt dat ook onder templates? If so, trashen maar

[ Voor 9% gewijzigd door Osiris op 31-01-2007 11:26 ]

[André]

Als ik met de Quick Reply iets submit zou dat direct aan de pagina toegevoegd moeten worden zonder dat de hele pagina opnieuw moet laden. Het opslaan kan dan gebeuren middels xmlHTTP.

[moto-moi]

• read status bij dm's kunnen aanpassen zoals ik dat in thunderbird e.d. gewend ben
• eigen sortering HG's
• bookmarks beter kunnen beschrijven door er bijv. 255 tekens aan tekst bij te zetten i.p.v. alleen maar de topictitel aan kunnen passen
• echt 255 tekens ruimte hebben in de sigs, i.p.v. 255 voor een in html-geparsede versie
• Toffe interface + bijbehorende groepen voor het verwijderen van PM's

[ Voor 24% gewijzigd door moto-moi op 31-01-2007 11:59 ]

[BtM909]

André schreef op woensdag 31 januari 2007 @ 11:33:
Als ik met de Quick Reply iets submit zou dat direct aan de pagina toegevoegd moeten worden zonder dat de hele pagina opnieuw moet laden. Het opslaan kan dan gebeuren middels xmlHTTP.

Is dat een react feature of zou dat template issues moeten zijn. Wil nl. wel meer dingen web2.0

[GeniusDex]

Een manier om in topics precies te markeren tot welke post je het topic gelezen hebt zodat je dat zelf niet meer helemaal op hoeft te zoeken (bijvoorbeeld iets van een linkje "eerste ongelezen post bekijken")

[DarthPlastic]

@hierboven: Da's ook een hele goede idd, om een extra linkje te hebben per topic in MyReact, waarmee je naar je laatste post in dat topic springt.

Het kunnen editten van DM-berichten. Vaak maak je een klein typfoutje waardoor je de DM opnieuw kan posten.
Ook het achteraf kunnen toevoegen en verwijderen van gebruikers in een DM-topic is wel handig.

[ Voor 26% gewijzigd door DarthPlastic op 31-01-2007 11:54 ]

[Outerspace]

Een overzichtje in de AT waar je in welk topic al hebt gepost. Dus dat het mapje een soort ander kleurtje zou krijgen

[NMe]

Een optie waarin je alle DM's weigert, behalve als ze gestuurd zijn door je buddy's. Is die lijst ook nog eens ergens nuttig voor.

[BtM909]

DarthPlastic schreef op woensdag 31 januari 2007 @ 11:53:
@hierboven: Da's ook een hele goede idd, om een extra linkje te hebben per topic in MyReact, waarmee je naar je laatste post in dat topic springt.

Dat bestaat nu toch al

Het kunnen editten van DM-berichten. Vaak maak je een klein typfoutje waardoor je de DM opnieuw kan posten.

Hoe zie je dat dan in de uitwerking? Ik heb je DM al gelezen en dan ga jij nog ineens dingen wijzigen?

Ook het achteraf kunnen toevoegen en verwijderen van gebruikers in een DM-topic is wel handig.

Hoe zie je dat dan in de uitwerking? Ik heb je DM gelezen en dan is hij ineens weg?

[Morax]

GeniusDex schreef op woensdag 31 januari 2007 @ 11:53:
Een manier om in topics precies te markeren tot welke post je het topic gelezen hebt zodat je dat zelf niet meer helemaal op hoeft te zoeken (bijvoorbeeld iets van een linkje "eerste ongelezen post bekijken")

Is daar het mapje voor het topic () niet voor?

[SinergyX]

• Username search in topics ondersteunen voor mensen met 2 woorden/aparte tekens.
(dit topic bv Ariën Clay - vind hij niets, en ja op userID werkt het wel).

[Zeror]

Ik vind deze wel een leuke

Rakkerzero schreef in [feat]Mogelijkheid om startpost weer te geven...:

Ik zie eigenlijk wel nut voor een optie om startpost in een ingeklapt modus bovenaan te pagina te weergeven.

bv:

code:

                                                         knopje voor uitklappen
[--naam TS. ----|-----------------------------------------------------------[ V ]
[--naam user----|-----------------------------------------------------[ knopjes ]
                  tekst van eerste bericht dat normaal boven aan 
                  de pagina staat
[--naam user----|-----------------------------------------------------[ knopjes ]
                  tekst van tweede bericht dat normaal boven aan 
                  de pagina staat
[--naam user----|-----------------------------------------------------[ knopjes ]
etc....

Neemt nauwelijks ruimte in beslag, behoud het overzicht in de topics en je kan snel de TS inzien voor extra informatie.

[ Voor 75% gewijzigd door Zeror op 31-01-2007 12:11 ]

[mOrPhie]

In het DM-overzicht niet alleen de starter, maar ook de eerst geaddresseerde zien. Soms ben ik lang aan het zoeken naar een DM die ik verstuurd had.

[Zeror]

Ohja nog iets:
Het zou wel handig zijn om de startpagina van DM op de map 'prive' te zetten ipv de map 'berichten' die daarboven staat. Scheelt weer een klik voor de meeste users

@ hahn hieronder:

Dat is ook nog iets ja, waar ik me soms wel aan erger.

[ Voor 27% gewijzigd door Zeror op 31-01-2007 12:14 ]

[Hahn]

Wat ik wel fijn zou vinden is om topics uit je post history te kunnen verwijderen/verbergen. Soms post ik één keer in een (groot) topic, maar om nou vervolgens 3 maanden lang dat topic bovenaan in m'n post history terug te vinden hoeft van mij ook weer niet.

[GeniusDex]

Morax schreef op woensdag 31 januari 2007 @ 12:03:
[...]


Is daar het mapje voor het topic ([afbeelding]) niet voor?

Verrek, dat was me nog nooit opgevallen (ik klik niet zo vaak op rare plaatsen)

[SinergyX]

Dat is een erg goeie Hahn

[Garyu]

Foutmeldingen zo weergeven dat een gemiddelde gebruiker er wat mee aan kan.

Een voorbeeldje:

Er is iets fout gegaan. Probeer het later nog eens, of ga terug.

De gebruiker heeft geen toegang tot categorie 6
(interne identificatie: category::get_categorydata::category_not_allowed)

Dit is niet echt het prototype melding dat je de gemiddelde gebruiker wilt voorschotelen.
0) De eerste opmerking is compleet overbodig, de tweede en derde zeggen eigenlijk niets.
1) wat is categorie 6?
2) waarom heeft de gebruiker daar geen toegang tot?
3) de interne identificatie zegt niets méér dan de melding die schijnbaar wel voor de gebruiker bedoeld is
4) wie is "de gebruiker" (ben ik dat?)

Lijkt me vooral makkelijk aan te passen, en de boel weer wat gebruiksvriendelijker te maken .

[sjaak]

As seen on another forum.

Met een verschillende kleur de posts aangeven van een topicstarter. Ik scroll me helemaal rot als ik wil weten wie ook alweer de topicstarter was, en wanneer ie weer heeft gepost.

[Cloud]

Hahn schreef op woensdag 31 januari 2007 @ 12:14:
Wat ik wel fijn zou vinden is om topics uit je post history te kunnen verwijderen/verbergen. Soms post ik één keer in een (groot) topic, maar om nou vervolgens 3 maanden lang dat topic bovenaan in m'n post history terug te vinden hoeft van mij ook weer niet.

Hier zijn al vaak topics over geweest maar die werden toen helaas gesloten Maar deze functie vind ik ook super handig! Dus als de devvers het nu wel zouden kunnen maken zou geweldig zijn

Als ik een keer reageer in een lol topic van de HK hoeft ie inderdaad niet voor de rest van de topic lifetime bovenaan te staan nee

[Morax]

sjaak schreef op woensdag 31 januari 2007 @ 12:16:
As seen on another forum.

Met een verschillende kleur de posts aangeven van een topicstarter. Ik scroll me helemaal rot als ik wil weten wie ook alweer de topicstarter was, en wanneer ie weer heeft gepost.

Zie het pijltje voor de naam
Topicstarter:
Niet-topicstarter:

[Hoedje]

Ik zou graag willen zien dat je DM's kunt editten bijv. tot 5 min na het versturen. Daarnaast zou ik graag een RSS feed willen van myreact. Tot slot zie ik die functie van Hahn ook wel zitten, dat je dus topics uit Myreact kunt halen en als we dan toch bezig zijn, dan is toevoegen ook wel fijn. Neem bijv. het levertijdentopic in Apple talk, dat wil je niet een paar jaar in je myreact hebben staan, terwijl die steeds maar verder groeit. Topics in A61 worden ook meestal erg lang, maar dat vind ik juist wel weer prettig .

Het inklappen van startposts zie ik echt niet zitten, ze worden nu al nauwelijk gelezen.

[ Voor 23% gewijzigd door Hoedje op 31-01-2007 12:21 ]

[moto-moi]

sjaak schreef op woensdag 31 januari 2007 @ 12:16:
As seen on another forum.

Met een verschillende kleur de posts aangeven van een topicstarter. Ik scroll me helemaal rot als ik wil weten wie ook alweer de topicstarter was, en wanneer ie weer heeft gepost.

Dat is een template functie, en zit er al in, kijk maar eens naar vs

[Zeror]

Hoedje schreef op woensdag 31 januari 2007 @ 12:20:
... en als we dan toch bezig zijn, dan is toevoegen ook wel fijn.

Gewoon in reageren dan, he
en anders post-reminder gebruiken.

[ Voor 7% gewijzigd door Zeror op 31-01-2007 12:22 ]

[Rone]

moto-moi schreef op woensdag 31 januari 2007 @ 12:21:
[...]

Dat is een template functie, en zit er al in, kijk maar eens naar [afbeelding] vs [afbeelding]

Of vs

Maar goed, ook ik zou me wel kunnen vinden in een functie zoals omschreven in Hahn's post.

[ Voor 12% gewijzigd door Rone op 31-01-2007 12:25 ]

[DieterVDW]

Morax schreef op woensdag 31 januari 2007 @ 12:19:
[...]


Zie het pijltje voor de naam
Topicstarter: [afbeelding]
Niet-topicstarter: [afbeelding]

Daar moet je toch al erg goed voor kijken hoor ...
Ik zou dat ook wel erg handig vinden als posts van de TS beter aangeduid zijn!

Bestaat er trouwens ergens een overzicht van al die finesses van React?
Dat met dat klikken-op-mapje om naar ongelezen posts te gaan bvb wist ik ook niet, terwijl ik wel wist dat het op de 1 of andere manier moest kunnen...

[Cloud]

Dit vraagt over een dagje ofzo (als er flink wat ideën binnen zijn) om een poll denk ik. Want ik zie al meerdere stemmen opkomen voor dezelfde functies (zoals Hahn's post history voorstel)

Misschien ideetje?

[CodeCaster]

Het toevoegen danwel verwijderen van topics uit je post history lijkt me zwaar voor de database. Quasi-SQL hoe het mij nu lijkt te gaan:

SQL:

Select topics.title, topics.msgcount, enz from topics left join posts on posts.topicID = topics.topicID where posts.creatorID = $userID

En wil je topics kunnen uitsluiten danwel toevoegen moet er een nieuwe join of een subquery gemaakt worden. Dit lijkt me, zeker voor een zo vaak opgevraagde pagina (in mijn geval dan) nogal zwaar voor de database.

[CLB]

Hahn schreef op woensdag 31 januari 2007 @ 12:14:
Wat ik wel fijn zou vinden is om topics uit je post history te kunnen verwijderen/verbergen. Soms post ik één keer in een (groot) topic, maar om nou vervolgens 3 maanden lang dat topic bovenaan in m'n post history terug te vinden hoeft van mij ook weer niet.

Hoppa dat is mijn grootste call-for-feature idd!
Leuk en aardig allemaal die topics over mobieltjes waar ik 8 maanden geleden wat postte!
Maar om die dag en nacht bovenaan m'n 'post history' te zien

[Wortelsoep]

Ik weet dat er al eens eerder requests voor zijn gekomen maar hoe dat nou is afgelopen heb ik niet meegemaakt:
Automatisch check images doen, eventueel in combinatie met een "check images niet" knop. En/of per forum apart instellen of hij automatisch de images checkt.

Oh ja, en verbergen uit je post history zou echt relaxed zijn.

[ Voor 10% gewijzigd door Wortelsoep op 31-01-2007 12:30 ]

[Cloud]

CodeCaster schreef op woensdag 31 januari 2007 @ 12:27:
Het toevoegen danwel verwijderen van topics uit je post history lijkt me zwaar voor de database. Quasi-SQL hoe het mij nu lijkt te gaan:

SQL:

Select topics.title, topics.msgcount, enz from topics left join posts on posts.topicID = topics.topicID where posts.creatorID = $userID

En wil je topics kunnen uitsluiten danwel toevoegen moet er een nieuwe join of een subquery gemaakt worden. Dit lijkt me, zeker voor een zo vaak opgevraagde pagina (in mijn geval dan) nogal zwaar voor de database.

Dat was inderdaad ook een van de redenen waardoor requests hiervoor eerder altijd stuk liepen. Maargoed misschien dat iemand van het dev team wat meer informatie daarover kan geven. Want zoals we zien is het wel een veel gevraagde functie

edit:
@ hieronder, ik krijg nooit DM's

[ Voor 3% gewijzigd door Cloud op 31-01-2007 12:40 ]

[Rone]

Misschien nog een idee: de mogelijkheid om DM's te markeren als ongelezen.

Het komt wel eens voor dat ik bijvoorbeeld een gestelde vraag op het moment van lezen niet kan beantwoorden omdat ik daar geen tijd voor heb. Het zou in die situatie handig zijn als ik de betreffende DM zou kunnen markeren als ongelezen, zodat ik de volgende keer dat ik inlog nogmaals het gele balkje bovenin te zien krijg, die daar ook blijft totdat ik de DM weer lees.

[ Voor 3% gewijzigd door Rone op 31-01-2007 12:42 ]

[Spider.007]

wolkje schreef op woensdag 31 januari 2007 @ 12:26:
Dit vraagt over een dagje ofzo (als er flink wat ideën binnen zijn) om een poll denk ik. Want ik zie al meerdere stemmen opkomen voor dezelfde functies (zoals Hahn's post history voorstel)

Misschien ideetje?

Nope; wij beslissen gewoon wat er gaat gebeuren; daar hebben jullie niet veel over te zeggen Veel makkelijker toch

[NMe]

Hoedje schreef op woensdag 31 januari 2007 @ 12:20:
Ik zou graag willen zien dat je DM's kunt editten bijv. tot 5 min na het versturen.

Waarom niet gewoon tot ze gelezen zijn?

Het inklappen van startposts zie ik echt niet zitten, ze worden nu al nauwelijk gelezen.

Het gaat erom dat op andere pagina's dan die waarop de startpost sowieso al te zien was óók de startpost opgenomen wordt, als ik het goed begrijp. En in die feature zie ik wel degelijk wat potentiëel, lijkt me erg handig.

wolkje schreef op woensdag 31 januari 2007 @ 12:26:
Dit vraagt over een dagje ofzo (als er flink wat ideën binnen zijn) om een poll denk ik. Want ik zie al meerdere stemmen opkomen voor dezelfde functies (zoals Hahn's post history voorstel)

Misschien ideetje?

Je denkt dat er straks uit dit topic één feature uitgezocht wordt die geïmplementeerd wordt en klaar?

[Erkens]

Mogelijkheid om DM "topics" (van dezelfde user) te mergen, aangezien sommige mensen een nieuwe maken ipv een reply wat erg onhandig is. Nu kan je wel gaan werken met extra folders enzo, maar het blijft behelpen

[chem]

Even een reply tot zover van wat we overwegen (wat er niet bijstaat is al afgevallen )

• RSS feed voor DM zal vrijwel zeker komen
• Gebruikers die je wel/niet mogen DM'en: misschien dat we dit doen zoals NME voorstelt; aan de hand van je buddy list (met een voorkeur uiteraard)
• Discussies ongelezen markeren gaan we bekijken
• Extra text/uitleg bij bookmarks kunnen we bekijken
• PM management voor verwijderen, uitschrijven etc. gaan we onder de loep nemen
• Het wissen van PH items vind ik discutabel, ik vind het zelf onzinnig. Het kost ook weer flink wat GUI tools om de verstopte items weer wel te zien etc. We'll see
• DM wijzigen tot hij gelezen is

---

Zaken zoals web2.0-stijl posten, extra profielvelden etc. vallen buiten dit topic, want dat kan t.net zelf oppaken; we zoeken hier vooral naar features voor react zelf.

[SinergyX]

Niet de fix voor de search?

[CLB]

@ Chem: Kun je maybe 2 lijstje maken? Wat misschien doorgaat en wat is afgevallen?

Dit bijvoorbeeld:

Hahn schreef op woensdag 31 januari 2007 @ 12:14:
Wat ik wel fijn zou vinden is om topics uit je post history te kunnen verwijderen/verbergen. Soms post ik één keer in een (groot) topic, maar om nou vervolgens 3 maanden lang dat topic bovenaan in m'n post history terug te vinden hoeft van mij ook weer niet.

Uhm valt dat af, wordt dat anders benoemd en er wordt er wel naar gekeken... Ik begrijp 'm niet

EDIT: O das dit

chem schreef op woensdag 31 januari 2007 @ 13:20:
• Het wissen van PH items vind ik discutabel, ik vind het zelf onzinnig. Het kost ook weer flink wat GUI tools om de verstopte items weer wel te zien etc. We'll see

[ Voor 20% gewijzigd door CLB op 31-01-2007 13:27 ]

[chem]

SinergyX; uhhh nee, waarschijnlijk niet in de volgende versie.
CLB: nee, er is geen maybe lijstje; twijfel staat al in het lijstje. En de posthistory/find verhaal staat erin; ik noem het de PH

[Cloud]

Spider.007 schreef op woensdag 31 januari 2007 @ 13:06:
Nope; wij beslissen gewoon wat er gaat gebeuren; daar hebben jullie niet veel over te zeggen Veel makkelijker toch

Ik bedoelde het meer in de trant van: 'zo weten jullie wat het meest gevraagd is' Geen dwang whatsoever.

-NMe- schreef op woensdag 31 januari 2007 @ 13:08:
[...]
Je denkt dat er straks uit dit topic één feature uitgezocht wordt die geïmplementeerd wordt en klaar?

Zie boven

[CLB]

ja PH = PostHistorie, ik had 'm pas later door! Naja we will see! Alvast bedankt

[Zeror]

-NMe- schreef op woensdag 31 januari 2007 @ 13:08:
Het gaat erom dat op andere pagina's dan die waarop de startpost sowieso al te zien was óók de startpost opgenomen wordt, als ik het goed begrijp. En in die feature zie ik wel degelijk wat potentiëel, lijkt me erg handig.

Ja mij dus ook. maar dan wel in een ingeklapt modus. Sommige topicstarts hebben immers lappen tekst erin staan en dan zou het vervelend zijn als je eerst helemaal naar beneden moet scrollen.

@ Chem,
Deze feature hebben jullie niet opgenomen, zie ik. Wat is de reden daarvoor?
Ben ik eigenlijk wel benieuwd naar.

[crisp]

Rakkerzero schreef op woensdag 31 januari 2007 @ 13:46:
[...]

Ja mij dus ook. maar dan wel in een ingeklapt modus. Sommige topicstarts hebben immers lappen tekst erin staan en dan zou het vervelend zijn als je eerst helemaal naar beneden moet scrollen.

@ Chem,
Deze feature hebben jullie niet opgenomen, zie ik. Wat is de reden daarvoor?
Ben ik eigenlijk wel benieuwd naar.

In principe kunnen wij dat zelf in de templates regelen, daar is dus geen wijziging in React voor noodzakelijk

[Zeror]

crisp schreef op woensdag 31 januari 2007 @ 13:56:
[...]

In principe kunnen wij dat zelf in de templates regelen, daar is dus geen wijziging in React voor noodzakelijk

Ah ok. dus het was eigenlijk een template-vraag ipv feature-vraag.

Maar dan nog de vraag of jullie er uberhaupt iets mee gaan/willen doen

[eghie]

[quote]André schreef op woensdag 31 januari 2007 @ 11:33:
Als ik met de Quick Reply iets submit zou dat direct aan de pagina toegevoegd moeten worden zonder dat de hele pagina opnieuw moet laden. Het opslaan kan dan gebeuren middels xmlHTTP.
[/quote]
Net zoals André ook al zegt, de quickreply met XMLHttpRequest erin rammen. Dit gaat GoT volgens mij ook vies veel dataverkeer schelen. Aangezien het hele topics herladen gewoon minder vaak gebeurd.

Ook lijkt het me handig, bij gebruik van quickreply de quote knopjes de quote toevoegen via javascript aan je quickreply. Ik gebruik die quickreply namelijk heel vaak en moet dat gewoon een pagina herladen, omdat ik iemand wil quoten. Deze 2 features gecombineerd scheelt denk ik een hoop dataverkeer.

[quote]chem schreef op woensdag 31 januari 2007 @ 13:20:
...

---

Zaken zoals web2.0-stijl posten, extra profielvelden etc. vallen buiten dit topic, want dat kan t.net zelf oppaken; we zoeken hier vooral naar features voor react zelf.
[/quote]
Met die web2.0-stijl posten bedoel je zeker ook het bovenstaande mee, of niet? Dit valt toch gewoon onder React? Aangezien het React is die uitmaakt of je xmlHTTPRequest gebruikt of niet.

Ah man, moet eens lezen. Dit is ook gewoon een template feature.

[ Voor 3% gewijzigd door eghie op 31-01-2007 14:01 . Reden: verkeerd gelezen ]

[NMe]

crisp schreef op woensdag 31 januari 2007 @ 13:56:
[...]

In principe kunnen wij dat zelf in de templates regelen, daar is dus geen wijziging in React voor noodzakelijk

Dus.....jij gaat het oppakken?

[Osiris]

-NMe- schreef op woensdag 31 januari 2007 @ 13:08:
[...]

Waarom niet gewoon tot ze gelezen zijn?

"Privacy"-issue? Dan kun je namelijk exact zien of iemand de DM wel of niet gelezen heeft Bij PM's kan ik me d'r nog wat bij voorstellen, maar bij DM's? Als ik een DM wil 'negeren' terwijl ik hem wel gelezen heb, dan hoeft de verstuurder niet te weten of ik em wel of niet gelezen heb...

[NMe]

Osiris schreef op woensdag 31 januari 2007 @ 14:01:
[...]

"Privacy"-issue? Dan kun je namelijk exact zien of iemand de DM wel of niet gelezen heeft Bij PM's kan ik me d'r nog wat bij voorstellen, maar bij DM's? Als ik een DM wil 'negeren' terwijl ik hem wel gelezen heb, dan hoeft de verstuurder niet te weten of ik em wel of niet gelezen heb...

Och, zo'n issue lijkt me dat niet. En anders gewoon een extra pref, zal crisp leuk vinden.

[chem]

xmlhttp-based reageren is nog vrij lastig. wat als je op pagina 4 van de 6 op reply drukt? wat als er een reply tussendoor komt? hoe doe je dat met paginering?

in base-strict hebben we het wel voor elkaar om xmlhttp-based je bericht te wijzigen; alleen de gui moet nog 'ff' afgerond worden

Maar goed, we hadden het over functionele wijzigingen. Anders splits ik het web2.0-verhaal wel af

[silverstorm]

• RSS feed voor list_discussions
• DM handmatig terug naar ongelezen zetten
• Meerdere DMs tegelijkertijd kunnen verplaatsen
• Handmatige sessiereset

[P_de_B]

silverstorm schreef op woensdag 31 januari 2007 @ 14:32:

• Handmatige sessiereset

http://gathering.tweakers.net/forum/reset

[chem]

silverstorm schreef op Wednesday 31 January 2007 @ 14:32:

• RSS feed voor list_discussions
• DM handmatig terug naar ongelezen zetten
• Meerdere DMs tegelijkertijd kunnen verplaatsen
• Handmatige sessiereset

lees gerust het topic?

[crisp]

-NMe- schreef op woensdag 31 januari 2007 @ 14:01:
[...]

Dus.....jij gaat het oppakken?

Ik schuif het iig niet gelijk van tafel; het lijkt mij ook een leuke feature namelijk
Nu nog tijd vinden

[Erkens]

Osiris schreef op woensdag 31 januari 2007 @ 14:01:
"Privacy"-issue? Dan kun je namelijk exact zien of iemand de DM wel of niet gelezen heeft Bij PM's kan ik me d'r nog wat bij voorstellen, maar bij DM's? Als ik een DM wil 'negeren' terwijl ik hem wel gelezen heb, dan hoeft de verstuurder niet te weten of ik em wel of niet gelezen heb...

Waarom niet de DM als ongelezen markeren zodra de verstuurder hem heeft ge-edit?

[Rone]

Erkens schreef op woensdag 31 januari 2007 @ 14:44:
[...]

Waarom niet de DM als ongelezen markeren zodra de verstuurder hem heeft ge-edit?

Hij bedoelt dat de verstuurder kan zien of de ontvanger de DM heeft gelezen. Als de verstuurder het bericht na verzenden kan editten heeft de ontvanger hem nog niet gelezen, anders wel. Goed punt overigens.

[JHS]

[feat][admin] Direct door naar User Details .

[Erkens]

r00n schreef op woensdag 31 januari 2007 @ 15:03:
Hij bedoelt dat de verstuurder kan zien of de ontvanger de DM heeft gelezen. Als de verstuurder het bericht na verzenden kan editten heeft de ontvanger hem nog niet gelezen, anders wel. Goed punt overigens.

ehm, ja dat was het "probleem" toch, vandaar mijn "oplossing", dus altijd editen toestaan

[AtleX]

Ik heb maar 1 wens eigenlijk: Nette HTTP statuscodes, zoals een 403 als ik op een link klik naar een topic dat ik niet mag lezen, of een 404 bij een topic dat niet bestaat. Ik weet niet of dat dat via de template of via React geregeld moet worden, maar ik gok React.

[edit]
En nog een tweede eigenlijk: [FEAT] DM's kunnen quoten. Maar ik kan me niet voorstellen dat deze functionaliteit niet in React zit dus het zal wel een template-ding zijn.

[ Voor 49% gewijzigd door AtleX op 31-01-2007 15:28 ]

[Saturnus]

Users met een topic reeks de mogelijkheid geven hun eigen topic te closen.
Zelf heb ik bijv. sinds kort de TS van het A64/Opteron OC Topic, nu moet ik een DM sturen (of de mod ziet het zelf) en dan pas kan het topic dicht, dit is soms nadat anderen weer een bericht hebben gepost terwijl een volgende deel al begonnen is.

[CodeCaster]

Saturnus schreef op woensdag 31 januari 2007 @ 15:26:
Users met een topic reeks de mogelijkheid geven hun eigen topic te closen.
Zelf heb ik bijv. sinds kort de TS van het A64/Opteron OC Topic, nu moet ik een DM sturen (of de mod ziet het zelf) en dan pas kan het topic dicht, dit is soms nadat anderen weer een bericht hebben gepost terwijl een volgende deel al begonnen is.

En hoe moet de forumsoftware "ruiken" dat dit een topic uit een reeks is, en dat er een nieuw deel is? Zet gewoon een TR met "hij kan dicht" en het sluit vanzelf.

[Saturnus]

Per user (die dat wil) aanvragen, DM'etje ofzo...
En qua topic herkenning zelf iets maken dat als de ene Deel 1 is, een script herkent dat de opvolger Deel 2 is en dan rechten toekennen.

[ Voor 58% gewijzigd door Saturnus op 31-01-2007 15:32 ]

[SinergyX]

De rechten om een topic te sluiten moet imo bij de Mods blijven. Een TR of DM is al genoeg om je oude topic te laten sluiten. Daarbij heb ik maar erg weinig 'reeks' topics gezien waar ze verder gingen posten toen er een link naar het nieuwe topic werd geplaats.

[CLB]

Iets van 'aantal views' per topic ofzo lijkt me wel leuk!
Niet het aantal 'posts' dus maar het aantal 'views'

Zoiets als op FTD ofzo, kun je bv. zien dat je al 2000 views hebt en 30 berichtjes! Zoiets lijkt me

[BtM909]

Saturnus schreef op woensdag 31 januari 2007 @ 15:26:
Users met een topic reeks de mogelijkheid geven hun eigen topic te closen.
Zelf heb ik bijv. sinds kort de TS van het A64/Opteron OC Topic, nu moet ik een DM sturen (of de mod ziet het zelf) en dan pas kan het topic dicht, dit is soms nadat anderen weer een bericht hebben gepost terwijl een volgende deel al begonnen is.

Maar dan krijg je dat het topic topicstarter niet zint en dus op slot gooit

[SinergyX]

CLB schreef op woensdag 31 januari 2007 @ 15:40:
Iets van 'aantal views' per topic ofzo lijkt me wel leuk!
Niet het aantal 'posts' dus maar het aantal 'views'

Zoiets als op FTD ofzo, kun je bv. zien dat je al 2000 views hebt en 30 berichtjes! Zoiets lijkt me

Stats-geil?
Geeft alleen maar onnodige iritatie, als iemand hulp nodig heeft en ziet dat er al (bv) 1000 views zijn, maar nog geen replies. Gaat meteen weer posten dat er nooit iemand helpt etc etc.

[moto-moi]

CLB schreef op woensdag 31 januari 2007 @ 15:40:
Iets van 'aantal views' per topic ofzo lijkt me wel leuk!
Niet het aantal 'posts' dus maar het aantal 'views'
Zoiets als op FTD ofzo, kun je bv. zien dat je al 2000 views hebt en 30 berichtjes! Zoiets lijkt me

Dat zit er al in, maar we zien weinig nut in het meer dan 700.000 updates per dag extra op de db loslaten alleen maar omdat iemand een tellertje ziet ophogen

[CLB]

SinergyX schreef op woensdag 31 januari 2007 @ 15:43:
[...]
Stats-geil?
Geeft alleen maar onnodige iritatie, als iemand hulp nodig heeft en ziet dat er al (bv) 1000 views zijn, maar nog geen replies. Gaat meteen weer posten dat er nooit iemand helpt etc etc.

moto-moi schreef op woensdag 31 januari 2007 @ 15:44:
[...]
Dat zit er al in, maar we zien weinig nut in het meer dan 700.000 updates per dag extra op de db loslaten alleen maar omdat iemand een tellertje ziet ophogen

It was just something I thougt about Stats-geil ben ik wel ja
Wanneer komen die 'aantal posts'-lists weer van elk subforum!?

[ Voor 38% gewijzigd door CLB op 31-01-2007 15:46 ]

[Saturnus]

BtM909 schreef op woensdag 31 januari 2007 @ 15:41:
[...]

Maar dan krijg je dat het topic topicstarter niet zint en dus op slot gooit

Ik denk dat er weinig misbruik gemaakt gaat worden, en er zijn ook niet super veel topics op GoT die steeds een volgende deel krijgen.
En als je dan van die functie gebruik zou willen maken moet dat per topic reeks aangevraagd worden en je gaat natuurlijk akkoord met de voorwaarden. (Geen misbruik...en vul maar aan met wat je nog meer kan bedenken.)

[Rone]

Erkens schreef op woensdag 31 januari 2007 @ 15:19:
[...]

ehm, ja dat was het "probleem" toch, vandaar mijn "oplossing", dus altijd editen toestaan

Oh, ik had niet verwacht dat je dát zou bedoelen gezien bijvoorbeeld BtM909 in "Call-for-features".
Dat je je replies in een (open) topic te allen tijde kunt wijzigen is logisch, maar is dit wenselijk in een DM?

In mijn ogen kun je een DM vergelijken met een email (of snailmail for that matter). Een eenmaal verstuurde email of brief kun je achteraf ook niet editten. Als je nog iets toe te voegen hebt verstuur je toch gewoon een nieuwe?

[ Voor 20% gewijzigd door Rone op 31-01-2007 15:54 ]

[CodeCaster]

Is het trouwens een idee om de usericons bij uploaden automagisch te laten resizen naar 60x60, mits geen .gif?

Saturnus schreef op woensdag 31 januari 2007 @ 15:46:
[...]

Ik denk dat er weinig misbruik gemaakt gaat worden, en er zijn ook niet super veel topics op GoT die steeds een volgende deel krijgen.
En als je dan van die functie gebruik zou willen maken moet dat per topic reeks aangevraagd worden en je gaat natuurlijk akkoord met de voorwaarden. (Geen misbruik...en vul maar aan met wat je nog meer kan bedenken.)

Ik denk dat de devvers het terecht teveel werk vinden om een functie te schrijven om per topic een non-mod user als mod aan te kunnen wijzen. En dan nog een mod die alleen mag sluiten, en niet editen. Maar dat is uiteraard aan hen.

[ Voor 76% gewijzigd door CodeCaster op 31-01-2007 15:52 ]

[Saturnus]

Tjah als het teveel werk is is het jammer maar helaas.

[BtM909]

Saturnus schreef op woensdag 31 januari 2007 @ 15:46:
[...]

Ik denk dat er weinig misbruik gemaakt gaat worden, en er zijn ook niet super veel topics op GoT die steeds een volgende deel krijgen.
En als je dan van die functie gebruik zou willen maken moet dat per topic reeks aangevraagd worden en je gaat natuurlijk akkoord met de voorwaarden. (Geen misbruik...en vul maar aan met wat je nog meer kan bedenken.)

Weinig misbruik?

NOFI, maar je weet waarschijnlijk niet hoevaak een TS slotje roept in een topic

[NMe]

CodeCaster schreef op woensdag 31 januari 2007 @ 15:51:
Is het trouwens een idee om de usericons bij uploaden automagisch te laten resizen naar 60x60, mits geen .gif?

Dat klinkt eigenlijk wel handig ja.

Ik denk dat de devvers het terecht teveel werk vinden om een functie te schrijven om per topic een non-mod user als mod aan te kunnen wijzen. En dan nog een mod die alleen mag sluiten, en niet editen. Maar dat is uiteraard aan hen.

En dat voor een feature die overbodig is gezien het feit dat mods dat prima alleen af kunnen. Het is niet alsof er 20 topics per dag "vol" raken in hetzelfde subforum.

[Rone]

CodeCaster schreef op woensdag 31 januari 2007 @ 15:51:
Is het trouwens een idee om de usericons bij uploaden automagisch te laten resizen naar 60x60, mits geen .gif?

Dat gebeurt toch al bij uploaded icons? Bovendien kunnen deze sowieso niet groter zijn dan 10 kB.
Een groter (als in: minder klein) probleem is de omvang van webicons. Die mag de 100 kB niet overschrijden, wat desondanks zo nu en dan toch gebeurt. De enige functie waar ik een nut van inzie is er één die eerst checkt wat de bestandsgrootte is van het opgegeven webicon alvorens hem daadwerkelijk als usericon in te stellen, maar in hoeverre dit te realiseren is...?

[CodeCaster]

r00n schreef op woensdag 31 januari 2007 @ 16:19:
[...]

Dat gebeurt toch al bij uploaded icons? Bovendien kunnen deze sowieso niet groter zijn dan 10 kB.
Een groter (als in: minder klein) probleem is de omvang van webicons. Die mag de 100 kB niet overschrijden, wat desondanks zo nu en dan toch gebeurt. De enige functie waar ik een nut van inzie is er één die eerst checkt wat de bestandsgrootte is van het opgegeven webicon alvorens hem daadwerkelijk als usericon in te stellen, maar in hoeverre dit te realiseren is...?

Nee hoor, kijk hier maar eens bijvoorbeeld. Met de PHP-functie imagecopyresampled() is een zeer redelijk tot uitstekend resultaat te behalen door te grote icons te verkleinen.

[Rone]

CodeCaster schreef op woensdag 31 januari 2007 @ 16:25:
[...]

Nee hoor, kijk hier maar eens bijvoorbeeld. Met de PHP-functie imagecopyresampled() is een zeer redelijk tot uitstekend resultaat te behalen door te grote icons te verkleinen.

Ja, ik weet dat je fysiek verkleinen bedoelt, maar wat is het praktisch nut ervan?
Oké, het ziet er mooier uit... en dan? De 'lelijke' icons kunnen toch niet groter zijn dan 10 kB, en aan de webicons kun je niets veranderen aangezien deze niet op een T.net-server worden gehost.

Maar goed, ik ben het met je eens dat een slecht geresized icon er niet uit ziet en heb het in het verleden meermaals voor iemand gedaan, dus als het een gemakkelijk te implementeren functie is heeft dat alleen maar voordelen... voor het oog.

[Spider.007]

CodeCaster schreef op woensdag 31 januari 2007 @ 16:25:
[...]

Nee hoor, kijk hier maar eens bijvoorbeeld. Met de PHP-functie imagecopyresampled() is een zeer redelijk tot uitstekend resultaat te behalen door te grote icons te verkleinen.

React doet dit gewoon hoor; als dit uitstaat moet crisp dat even aanzetten

[chem]

resizing kan al, maar staat uit hier.

het aanpassen van een serie topics etc. valt ver buiten wat react biedt. Dat zal dus ook niet komen

[CLB]

Kwam er net achter dat m'n signature niet meer dan 255 tekens mocht bevatten...
Opzich geen probleem maar welk als je naar meerdere sites wilt linken met 'n lange url!

Het wordt dan gezien als een lange tekenreeks terwijl je uiteindelijk maar iets korts te zien krijgt!

Zepto Znote 6214W/6314W

Dit zijn bv al 91 tekens terwijl je uiteindelijk dit ziet: Zepto Znote 6214W/6314W

dat zijn er dus 23

Lijkt mij persoonlijk wel leuk als het dan als 23 telt en niet als 255, dan is m'n signature snel vol

EDIT: Je kan dan ook werken met www.tinyurl.com maar toch

[ Voor 15% gewijzigd door CLB op 31-01-2007 18:54 ]

[Erkens]

CLB schreef op woensdag 31 januari 2007 @ 18:48:
Kwam er net achter dat m'n signature niet meer dan 255 tekens mocht bevatten...
Opzich geen probleem maar welk als je naar meerdere sites wilt linken met 'n lange url!

moto-moi schreef op woensdag 31 januari 2007 @ 11:44:

• echt 255 tekens ruimte hebben in de sigs, i.p.v. 255 voor een in html-geparsede versie

[CLB]

Hmm ik ben n00b, maar dat houdt in dat 't dus niet kan

Dit is in Word 234 tekens inclusief spaties:
Zepto Znote 6214W/ 6314W Zepto 6615WD Gamer Microsoft Zune Formac – 19” en 20,1” TFT's

en als ik dat dus copy-paste wordt er gezegd dat het meer dan 255 tekens zijn wat niet klopt

EDIT: Nu zien jullie 4 linkjes, als je op 'view' drukt zie je de 'code'

[ Voor 83% gewijzigd door CLB op 31-01-2007 19:07 ]

[Zoefff]

Dat is dus precies wat hierboven aangegeven word, die code ([url=waa]meukee[/]) word geparsed naar HTML (<a href="waa">meukee</a>), maar vervolgens word de limiet van 255 karakters over de HTML-string gerekend i.p.v. over de ongeparsede string. Dat zal natuurlijk wel door het database veldtype komen

[CLB]

en aangezien ik dus echt 'n monk ben begrijp ik dit niet... parsed/ unparsed

Dus als ik m'n linkjes in HTML zou plempen zou het wel moeten lukken?

[Victor]

CLB schreef op woensdag 31 januari 2007 @ 19:14:
en aangezien ik dus echt 'n monk ben begrijp ik dit niet... parsed/ unparsed

Dus als ik m'n linkjes in HTML zou plempen zou het wel moeten lukken?

Heel simpel: in de database kunnen voor de signature op dit moment maar 255 tekens worden opgeslagen. Hoewel jij misschien maar 20 tekens ziet, zijn er nog extra tekens nodig in de vorm van HTML om bijvoorbeeld een hyperlink te maken. Zeker met een beetje lange URL kunnen de zichtbare tekst en de HTML samen al snel groter zijn dan 255 tekens en dan kan het dus niet in de database worden opgeslagen.

edit:
En je hebt geen rechten om zelf HTML te gebruiken, dus dat gaat niet werken

[ Voor 6% gewijzigd door Victor op 31-01-2007 19:18 ]

[CLB]

Ahaa ik begrijp dat ik idd 'maar 20 tekens' zie en dat ik er dus meer gebruik!

Maar kan dat niet verandert worden? Niet dat iedereen 1000 tekens heeft,
want dan kun je de Bijbel daar overtypen, maar dat je 1000 tekens hebt voor url's ofzo..!?

[Zoefff]

Natuurlijk kan dat veranderd worden (al moet de database dan ook aangepast worden), maar de vraag is of je dat wel wil. Je kan ook je signature inkorten zodat het wel past. My guess is dat het lekker zo blijft

[Kaspers]

André schreef op woensdag 31 januari 2007 @ 11:33:
Als ik met de Quick Reply iets submit zou dat direct aan de pagina toegevoegd moeten worden zonder dat de hele pagina opnieuw moet laden. Het opslaan kan dan gebeuren middels xmlHTTP.

Dan zie je niet of iemand ondertussen al heeft gereageerd, wanneer jij aan het typen was.. dan klopt de volgorde dus niet..

[CLB]

nja sch**t dan maar, vind het al lang leuk dat je een 'signature' hebt, dan maar 255 tekens Thnx!

[AtleX]

CLB schreef op woensdag 31 januari 2007 @ 19:14:
en aangezien ik dus echt 'n monk ben begrijp ik dit niet... parsed/ unparsed

Dus als ik m'n linkjes in HTML zou plempen zou het wel moeten lukken?

Nee, want je hebt geen HTML rechten. Wat het probleem is is dat de code die jij gebruikt ([url=http://website.tld/bestand.ext]Tekst[/url]) omgezet wordt naar

HTML:

<a href="http://website.tld/bestand.ext">tekst</a>

De eerste is de ongeparste versie, de 2e is geparsed naar HTML, de taal die browsers wel kunnen begrijpen in tegenstelling tot UBB/RML.

Nu scheelt dat in dit geval maar 3 karakters, maar bij andere tags of constructies scheelt het wel een hoop. Bijvoorbeeld:

code:

[b][u][url=http://website.tld/bestand.ext]Tekst[/url][/u][/b]

Dat zou ik een extreem geval weleens geparsed kunnen worden naar:

HTML:

<span style="font-weight: bold; font-style: italic;"><a href="http://website.tld/bestand.ext">Tekst</a></span>

De UBB/RML code is 61 tekens lang, de geparste versie 110, een verschil van 49 tekens. Nu is dat omzetten van UBB/RML code vrij zwaar, en dus slaat dit forum alvast de geparste versie op in de database zodra je je signature wijzigt. Dan hoeft alleen de geparste versie maar opgehaald te worden bij een page view, ipv het ophalen van de ruwe versie, deze parsen en dan pas tonen. Helaas wordt de geparste versie van je signature opgeslagen in een veld met een maximale lengte van 255 tekens, en dat is dus nogal vervelend.

[ Voor 9% gewijzigd door AtleX op 31-01-2007 19:24 ]

[Victor]

Kaspers schreef op woensdag 31 januari 2007 @ 19:22:
[...]


Dan zie je niet of iemand ondertussen al heeft gereageerd, wanneer jij aan het typen was.. dan klopt de volgorde dus niet..

Dan haal je gewoon de laatste berichten op sinds de pagina geladen werd, inclusief die van andere gebruikers?

[CLB]

@ AtleX: Superuitleg! Weer wat geleerd! Thank you!

[Kaspers]

King_Louie schreef op woensdag 31 januari 2007 @ 19:28:
Dan haal je gewoon de laatste berichten op sinds de pagina geladen werd, inclusief die van andere gebruikers?

Denk je dat dat mogelijk is ?
Dan wordt alsnog de hele pagina ge-refreshed..

Schiet je dan weinig mee op toch ?

[elevator]

moto-moi schreef op woensdag 31 januari 2007 @ 15:44:
Dat zit er al in, maar we zien weinig nut in het meer dan 700.000 updates per dag extra op de db loslaten alleen maar omdat iemand een tellertje ziet ophogen

Op de frontpage zit dit er ook al in, dus waarom niet op GoT?

---

Verder mijn lijstje:
• Weinig bugs en ge-QA-de releases op betaGoT
• DM's ongelezen kunnen markeren of in een todolist kunnen zetten
• Hook(s) voor /myreact's usernotes' view te mergen met een andere data zonder dat crisp iets moet doen dat ie niet wil.
• En dan de feature die ik al 3 versies vraag - de huidige mail functionaliteit zo ombouwen dat het een "Communiceer met user" functionaliteit wordt waarbij de 'drager' van de boodschap danwel mail, danwel PM, danwel DM kan zijn waarbij er ook meerdere mogelijkheden moeten kunnen zijn.
• Bugfix van topic report counter probleem

[Victor]

Kaspers schreef op woensdag 31 januari 2007 @ 19:32:
[...]


Denk je dat dat mogelijk is ?
Dan wordt alsnog de hele pagina ge-refreshed..

Schiet je dan weinig mee op toch ?

Stel, er zijn in de tijd dat je de pagina hebt geladen en je het bericht plaatst 4 posts bij gekomen. Kwestie van de bovenste 5 wegknikkeren en die 4 posts, plus die van jou ophalen en onderaan neerplempen. Moet te doen zijn

[Kaspers]

Nou als jij denkt dat dat kan, zou dat inderdaad een erg mooie feature zijn !
Ik heb m'n twijfels...

[Victor]

Kaspers schreef op woensdag 31 januari 2007 @ 19:36:
Nou als jij denkt dat dat kan, zou dat inderdaad een erg mooie feature zijn !
Ik heb m'n twijfels...

De ID van de laatste post in het topic is beschikbaar. Dus als je die bij je POST meestuurt dan kan er een functie met een naam als "getAllPostsInTopicSincePost(postId)" alle nieuwe berichten ophalen.

[CLB]

elevator schreef op woensdag 31 januari 2007 @ 19:35:
[...]
Op de frontpage zit dit er ook al in, dus waarom niet op GoT?

Omdat alleen statsfreaks hierop geilen werd er gezegd Nja ik ben zo'n statsfreak dus

[chem]

met betrekking tot de signatures: [bug] parsen van URL's zonder "http://" in sigs

• dm's ongelezen zetten is al 4x genoemd geloof ik
• usernotes en pm's mergen kan al met custom query (tpl werk dus)
• er is al een send_directmessage die alle communicatiemethodes aanbiedt (tpl werk dus)
• topic counter mismatch heb ik nog niet achterhaald