Zavarna egy „olvasottnak jelölve” gomb a HUP-on?

Címkék

Sziasztok!

Jelenleg a hozzászólásoknál nincs lapozás, mert elrontana bizonyos kényelmi funkciókat. Az egyik ilyen, hogy a tartalom megtekintésekor és lapozáskor az összes, az adott tartalomhoz tartozó hozzászólást olvasottnak vesz. Akkor is, ha nem láttad, mert pl. a másik oldalon volt. Ez egy ismert Drupal probléma és elég szerencsétlen, ennek a kivédésére lett az, hogy a tartalom összes hozzászólása jelenjen meg új lapon.

Viszont a jelenlegi működés annyira leterheli a rendszert, hogy kb. 1400 hozzászólás felett megadja magát az oldal. Lehet ezen finomítani valamennyit, elodázni, de hamarosan szükség lesz valami végleges megoldásra. Bár eredetileg nem akartam már ezzel a hibával foglalkozni, viszont most eszembe jutott egy ötlet:

Mit gondoltok arról, hogy egy adott tartalom megtekintésekor nem jelölné automatikusan olvasottnak a hozzászólásokat, hanem egy külön gombot (linket, bármit) kellene megnyomni hozzá?

Ebben az esetben a lapozót is be lehetne üzemelni a hozzászólásokhoz, kevésbé lenne terhelt az oldal és nem kellene lezárni a túl sok hozzászólással rendelkező tartalmakat.

Rossz ötlet, maradjon minden a régiben!
33% (133 szavazat)
Jó ötlet, legyen így!
61% (248 szavazat)
Tudok jobbat, van konkrét ötletem, leírom.
3% (11 szavazat)
Egyéb, leírom.
4% (16 szavazat)
Összes szavazat: 408

Hozzászólások

Szerkesztve: 2020. 09. 03., cs - 10:24

Tipikusan az a dolog, amit előtte ki kellene próbálni egy tesztkörnyezetben élesben, mielőtt az ember véleményezni tudná. Elsőre ez plusz munka, amihez nem sok kedvem van. Kb. egy 20 éve megszokott működést szüntetne meg, ami nem hangzik túl jól. Inkább a lapozó. Alig van olyan topik, amelyik túllépi az 1000-es hozzászólást. Amelyik pedig igen, annak a kommentjei már 300 után is irrelevánsak.

trey @ gépház

Ez pont a lapozóval együtt kellene, hogy ne vesszen el funkcionalitás. Jelenleg az a szerencsétlen megoldás van, hogy ha valaki lapoz a hozzászólások között, akkor a rendszer az összeset olvasottnak jelöli, akár látta, akár nem. Ez a gomb ennek a kivédésére szolgálna és akkor minden hozzászólás új, amíg meg nem nyomod.

„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Tudom mi a lapozó hátulütője. Régen is úgy volt, hogy lapozáskor nem volt új jelölés. Engem nem nagyon zavart, mert mint feljebb leírtam, amihez annyi komment jött, hogy már lapozni kellett, ott már értelmes eszmecsere nem nagyon volt.

trey @ gépház

Megoldás: egyedi user beállítás (a saját adatok résznél lenne), hogy minden maradjon a régi, vagy meg kelljen nyomni, hogy elolvastam. Én nyomogatnám a gombot inkább, továbbá kellene egy olyan gomb lentre és fentre is, hogy "mindent elolvastam", ilyenkor az oldalon lévő összes olvasatlant beküldené. Fontos, hogy nem az adatbázisban lévő összesre, hanem ami nálam a képernyőn van, mert simán lehet, hogy mire mindent elolvasok, addigra más is hozzászól, amit viszont még nem láttam.

Legzavaróbb a mostani oldalban, ha hozzá szóltam valahova, hogy hozzászólás után ellenőrizni kell, kézzel rá kell keresni, van-e új egy hosszú témában, ami nem szép megoldás.

Példa: van nagy téma, amit én nyitottam, írtak mások 10 hozzászólást nekem, amire szeretnék válaszolni. A lépések:

1. rákattintok, látom a 10 új hozzászólást, más színnel és oda van írva, hogy új. (Amúgy az új lehetne jóval eltérőbb színű, láttam a hupot olyan régi monitoron, ahol alig látható a 2 között a különbség)

2. az 1. új hozzászólásnál a válasz gombot megnyitom új ablakban, megválaszolom. Amikor a hozzászólást beküldtem, át kell néznem, hogy azóta jött-e új, mert nem látom többet újnak, ha itt nem nézem meg. Ha jött új hozzászólás, akkor azt ebben a részben kell megválaszolnom, vagy nem látom többet, hogy új. Ha megválaszoltam, újra átnézni, hogy jött-e új válasz ide, akkor azokat is itt megválaszolni, ha 2 jött, akkor nyitni még 1 ablakot... ha nem jött több, bezárom az összes új itt nyitott ablakot, és kész ennek a megválaszolása.

3. ugyanez, a 2. hozzászólással.

...

11. ugyanez a 10. hozzászólással

Mindent megválaszoltam, majd rányomok a saját követett tartalmakra, és onnantól ott látom, hogy hozzászóltak-e.

Sakk-matt,
KaTT :)

Fontos, hogy nem az adatbázisban lévő összesre, hanem ami nálam a képernyőn van, mert simán lehet, hogy mire mindent elolvasok, addigra más is hozzászól, amit viszont még nem láttam.

Ez!

Ha megoldható így, akkor legyen, ennek a hiányában viszont nem támogatom, mert jól pörgő threadnél csak azt eredményezi, hogy az ember a kommentek feléről lemarad. 

A legtöbb esetben a friss tartalom érdekel, nem az, amit Pistike 2006-ban mondott.

 

Lehetne úgy átírni a lapozót, hogy a friss tartalom legyen elöl?

 

Ez beágyazásnál ugye kemény, de mégis tele van irreleváns információval az egész...

Szerintem borzasztó. Az utóbbi időben max 5 db 1000 kommentes topik jut eszembe, emiatt adnál ekkora pofont a UX-nek?

Én pl. nem emiatt szeretném, hanem azért, mert gyakran előfordul az, hogy van egy 10 hozzászólásos topic, elolvastam, de nem csuktam be a tabot.

Aztán valamiért böngésző bezár, később böngésző megnyit, új tabot nyitok, megnézem mondjuk az emailjeimet, bezárom.

Megnyitom böngészőt később, megkeresem a topicot, amiben 10 hozzászólást olvastam. Most azt írja, hogy van 3 új, és egyébként meg 20 hozzászólás van. Persze, mert amikor az emailjeimet akartam elolvasni, akkor a böngésző betöltötte a hupról ezt a topicot, akkor bizonyára volt 7 új hozzászólás, és ugyan rá se néztem, de elkönyvelte, hogy akkor ezeket elolvasta.

Ha a UX-et tartjuk szem előtt, én minimum azt tenném, hogy akkor állítsa automatikusan olvasottra az új hozzászólásokat, ha azok legalább megjelentek az oldalon.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Igen. Inkább működjön szarul, vagy egyáltalán sehogy, mint hogy állandóan gombokat kelljen nyomkodni. Azzal eddig is tisztában voltam, hogy ha kinyitottam, és nem olvastam el, akkor ij, Inkább élek ezzel együtt. Ráadásul teljesen biztos vagyok benne, hogy nagyságrenddel többször lesz az baj, hogy nem nyomtam meg azt a szart, mint ez. És akkor a különbség annyi, hogy eddig legközelebb az olvasottból kellet vizualgrepelni, hogy mi nem az valójában, ezután majd az olvasatlanból kell. Csak sokkal többször. Kösz, de kösz nem.

Lehetne azt is csinálni, hogy az utolsó 1 oldallekérés időpont helyett az utolsó párat tárolnánk (úgyis az elérés ideje a sok, talán párszor annyi bájt még beleférne), és _utólag_ lehetne undózni egy olvasást. Mondjuk ha csak félig jött le az oldal (ritka, de előfordul pl Wifi probléma miatt, vagy újra kellett bootolni, vagy ilyesmi). Persze a lapozós rendszert nem oldja meg... IMHO a lapozást úgy kellene megoldnai, hogy 1 oldalon legyen minden. A szerver oldali renderelést cache-elni kell, és kliens oldali lapozó kell JS-sel megvalósítva: pl úgy, ahogy valaki írta, hogy collapse-elni lehessen az olvasott szálakat. Jó bonyolult lenne, de tuti meg lehet csinálni.

És akkor most egy sokkommentes topicban egyesével jelöljön meg az ember minden posztot olvasottnak?

Még ha lenne olyan opció, hogy ezt a szálat jelöljük meg olvasottként...

Az oldalak határai ide-oda csúszkálnak, ahogy a szálak össze-vissza bővülnek; egy AJAX-os olvasottság-meglelölő könnyen lehet, hogy kiszúr veled, mert olvasod már vagy fél órája az oldalt, nyomod, hogy oké, elolvasva, aztán kiderült, hogy érkezett pár komment a folyam tetejére és azokat is olvasottnak jelölted meg, viszont közben a következő oldalra csúszottakat meg nem. Ezt persze ki lehetne védeni azzal, hogy konkrét commentID-kat ad át a rendszernek, hogy ezeket, de akkor most küldjünk vissza ilyenkor 1000 ID-t?

Amikor lapozol a hozzászólásokban, akkor az oldalletöltéssel együtt automatikusan jelöli a rendszer, hogy te ez a bejegyzést és a hozzászólást már láttad. Most ez nem lenne automatikus, ennyi.

„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Oh, sorry, félreértettem. De ettől függetlenül ez sem jó, mert így össze fog akadni azokkal, amik azután érkeznek, hogy kinyitottam a topicot: ha rányomok, akkor az újakat is megjelöli olvasottként, ha meg nem, mert lecsekkolom, hogy jött-e új, akkor kvázi nekem kell számontartani, hogy ok, az előbb még csak 10 új hsz volt, most már 13, tehát 3 új hozzászólás érkezett azóta és akkor utána végigiterálni, hogy mit olvastam már és mit nem.

Így van. Ennek csak úgy lenne értelme ha a gomb megnyomásakor a kliensről kapná vissza az adott oldalon lévő hozzászólások azonosítóit a szerver amiket olvasottnak jelöl. Különben a megnyitás/olvasás elkezdése és a gombnyomás között a szerverre érkező újakat is olvasottnak jelöli, azzal meg ugyanott vagyunk hogy olvasottnak jelöl olyan hozzászólásokat amiket nem láttam...

Az a megoldás, hogy per hozzászólás tároljuk, hogy láttam-e, sehogy sem tud takarékos lenni, függetlenül attól, hogy a kliens mit küld át.

Ha egy időpontot tárolunk csak, amihez képest mérjük az újdonságot, az még működhet, de az meg nem oldja meg az alapproblémát, mivel a szálakban lehet újabb hozzászólás, mint a következő lapon.

Nekem tetszik az ötlet. Ha elvész az infó, mi az új, akkor nem látom a válaszokat.

Azt nem lehet, hogy a viselkedás a profilban egy checkboxban állítható, s akkor mindenkinél úgy működne, ahogy szeretné?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

LOL, ne már. Azért a vicc inkább az, hogy 1400 hozzászólás megjelenítése és renderelése megfekteti a rendszert.

Ott nincs minden látogatónak egyedi nézete (hogy hozzászólásonként megmondja, hogy mi új, mi nem), ott nincs komment +1 / -1, azért tud sokkal gyorsabb lenni + szét van cache-elve infóim szerint.

Megoldás:

Úgy lehetne nagyon meggyorsítani a jelenlegi oldalt, hogy legenerálódna fixen minden hozzászólás után az egész oldal az összes hozzászólással, majd user-enként amint megkapja ezt az egységeset, egy Javascript kód egyenként egy egyben lekérdezi aszinkronként, hogy melyik hozzászólás az új nekem, aki nézi, és hol van +1, hol tudok nyomni -1 -et. Így kicsit lassabb lenne, mint az index, viszont újra kellene írni kb a komment kezelést, megjelenítést.

Sakk-matt,
KaTT :)

de minek bonyolitani? minden hsz-be bele kell irni az idopontot pl. unixtimeban amikor irtak/modositottak, es csak azt kapja meg az user hogy o utoljara mikor latta ezt az oldalt (1db unixtime/topic), igy a js azt szinezi at ami az adott unixtime utan keletkezett.

sot az user unixtimejat meg akar cookie-ban is lehetne tarolni az usernel, bar akkor ha masik geprol/eszkozrol nezi akkor nem jo.

Elgondolkodtató, kiindulási alapnak tök jó! De egyébként a lapozásra, tehát egy post több oldalon lévő hozzászólásaira kéne megoldást találni, de szerintem így is használható az ötleted, legalábbis lehetne a végleges megoldás egyik pontja.

Szerk.:
Még egyszer elolvasva, tk. akár le is fedted a lapozást is ezzel...nem szóltam.

Biztos, hogy nem én gonoszoltam le!

Akkor csak kellene egy DOM parser ami ajaxal pinpongozik kliens és szerver között egy-egy URL meghívásnál. Tudom, hogy költséges szerveroldalon, de lehetne lapozó, aztán a kliensek 2020-ban csak elbírják, a szerver meg bírja el. :)

Ezen az oldalon írtam a sessiont, az sem kell, csak nincs kedvem módosítani a hozzászólásom. Na szóval én valahogy így zárnám rövidre a kérdést, és az sem zavarna, hogy egy URL-en +2/3 hívás menne, pakoljon Trey alá vasat. Meg lett neki mondva, hogy ne vegyen új autót, hanem a HUP-ra költse a pénzt! :D

Biztos, hogy nem én gonoszoltam le!

inkabb azt oldjatok meg hogy ne 20 masodperc alatt toltson be 500 hsz-t. lehet a db nem jo alatta vagy nincs jol indexelve, cache-lve stb...

Ennyi hirdetésből ennyit lehet kihozni. Annak idején azt ígértem, hogy nem lesznek zavaró hirdetések a HUP-on. Most sincsenek. A max. 2 (néha három) kiemelt szövegdobozból ennyit lehet kigazdálkodni.

Tetszik vagy nem, mindenki ideje pénz.

Az 1400 komment lerenderelése egy oldalra probléma nem az én asztalom, de feltételezem, azért nem látok nagyon sehol ilyet, mert nem triviális megoldani. Melyik oldalon látsz te több ezer kommentet egy kattintásra betöltve?

Ráadásul - mint többször említettem - nem tudom mennyire kardinális ez a kérdés (nem is értem miért rugózunk rajta), amikor a kommentek kevesebb mint egy százalékát érinti tippre.

trey @ gépház

Én azt vettem észre, hogy a laptop és a telefoncsere után a HUP számos funkciója gyorsabb lett.

Szerver oldalon is lenne mit tenni. Többször jeleztem pl. hogy swapel a szerver ennyi memóriával stb. Gondolom majd eljutunk oda, hogy történik valami. Nyilván, a RAM bővítés sincs ingyen.

trey @ gépház

Szerintem almát hasonlítunk a körtével. Nyilván lehet gyorsabb egy egy bizonyos szűk funkcionalitásra megírt valami, mint egy általános keretrendszerből, nem kifejezetten erre a célra gyártott másik. Ebben nincs vita.

Ahol bukik, hogy míg itt egyéb dolgoknak is meg kell felelni, igény szerint a rendszert bővíteni stb. addig ott valószínűleg sosem lesz igény az alapfunkciók bővítése, s ahogy nézem erősen kérdéses a jelenlegi működőképessége is:

http://oscomp.hu/chathu.html

http://oscomp.hu/romanum/index.php

trey @ gépház

Nyilván nem ugyanaz a kategória.

> addig ott valószínűleg sosem lesz igény az alapfunkciók bővítése

Tévedés. Ez a portál folyamatos fejlesztés alatt áll. Folyamatosan kap új funkciókat. Nemrég pl. a kereső kapott egy nagyobb adag feature-t, a minap meg a spamvédelem.

> s ahogy nézem erősen kérdéses a jelenlegi működőképessége is:

Rosszul nézed, semmiféle jelenlegi működőképesség nem kérdéses. A kutya nem használta a fórumot, tehát becsuktuk (már vagy úgy 12 éve), a chat (ami egyébként egy nem általunk üzemeltetett IRC szerveren ülő szoba) meg köszöni szépen, működik, bár azt se használja a kutya sem.

Ráadásul - mint többször említettem - nem tudom mennyire kardinális ez a kérdés (nem is értem miért rugózunk rajta), amikor a kommentek kevesebb mint egy százalékát érinti tippre.

Sőt, ha az új hozzászólások számlálásával kapcsolatos bug fixálódik, a hup8bug topic is szépen elsüllyed (én tuti leiratkoznék róla :) ). Most mégis az a téma, hogy a hup8bug-on legyen lapozó, ahelyett, hogy az ott említett bug ki lenne javítva.

+1 ötlet, ha valóban performancia gondokat okoz, zárjátok le 1000 hozzászólás felett a topicokat (legyen read-only, az azért elég jól cache-elhető)

Itt leírtam, hogy szerintem miért lassú, a kód és a db vizsgálata nélkül. Azért, mert mindenkinek konkrétan "egyedi" oldal van generálva az új hozzászólás jelölése miatt és a +1 / -1 miatt. Ha ez a 2 funkció nem lenne, szét lehetne cache-elni az egészet, így viszont mindenkinek egyedileg kell generálni, ráadásul előtte lekérdezni, hogy a te usered melyik hozzászólásokat olvasta, melyikeket nem. Ez mindenkinek egyedi. Sok adatbázis lekérés. Minél több a téma, hozzászólás, ugyanazon a szerveren annál lassabb lesz, mert több az adat. Ennek semmi köze a böngészőhöz. Arra várunk sokat, hogy a userem alapján, és a témában már olvasott és nem olvasott hozzászólásokat egyedileg jelölje és előtte ezt lekérdezze, majd hogy megnyitottam, azokat olvasottnak jelöli, tehát ha újra megnézem az oldalt, az adatbázis nem tudja cache-ből visszaadni az előzőt, mert azóta megváltozott, bővült, hogy miket olvastam el. Még aggregáltan sem lehet előre készülni, előre generálni, amit küldeni kell, mert ha 20 másodpercenként hozzászólnak, akkor mikor generálja, és nem is biztos, hogy lekérdezem akkor az adott témát? Az meg nem reális, hogy a téma összes hozzászólójának percenként előregenerálja a rendszer a témát, hátha megnyitja pont akkor... nem is beszélve a sok száz csak olvasóról, nekik is generálni kellene. Ennek a funkciónak ez az ára, szerintem megéri, még az is, ha egy nagy téma lassú.

Én maximum annyi erőforrást fordítanék ennek a gyorsítására, hogy megnézném, hogy minden lekérdezésen van-e index, és nem-e lehet több lekérdezést egybe rakni, vagy éppen nem-e gyorsabb, ha egy komplexebb, left join vagy bármilyen sok táblás adatlekérést több, egyszerűbb, külön lekérdezésben megkapni és kódból összerakni. Esetleg finomhangolni az adatbázis konfigurációt.

Hálás vagyok, hogy ez a nagyszerű közösség létezik és a tagja lehetek, és köszönöm újra trey, hogy ezt működteted és időt szánsz erre. Remélem hogy nagyon sokáig fog működni ez az oldal, akár változatlan formában, mert nagy érték, hasznos tudásbázis és archívum.

Sakk-matt,
KaTT :)

> Ennek a funkciónak ez az ára, szerintem megéri, még az is, ha egy nagy téma lassú.

Szerintem is kb úgy lehet megvalósítva, ahogy írod, de kliens oldali JavaScript használatával simán lehetne gyorsítani a meglévő működés mellett is:

* A tartalom minden topikhoz 1-féle, azaz két hozzászólás között cache-elni lehet. Az időbélyeg kommentenként benne van a HTML fában metaadatként.

* Egyedül az az időbélyeg dinamikus tartalom, hogy az adott user mikor nézte meg utoljára.

* Az "új" dekorációt JS teszi fel az időbélyeg alapján

* Az utolsó megnézés időbélyegét a szerver tartja karban - ahogy eddig is, csak nem csinál belőle dinamizmust, hanem 1-1ben "leküldi".

Ez a legkisebb átalakítás, és mégis sokkal gyorsabbá válhatna a szerver oldal. Kliens oldali lapozót és ilyeneket is "könnyen" lehetne fejleszteni hozzá.

Még kliens oldali olvasottság megjelölőt is el tudnék képzelni, ami egy gépen simán működne kommentenként is. Esetleg saját szerveren keresztül szinkronizálhatna, és akkor trey szerverét nem is kellene felskálázni :-)

 

Szerk.: amúgy én sosem tapasztaltam, hogy lassú lenne a hup, úgyhogy számomra ez a kérdés eléggé elméleti.

tobbesszamot azert hasznaltam, mert van egyreszt a fejleszto (nevergone) masreszt a hoszting ceg embere(i) es mindket oldalrol lehet segiteni talan a probleman.

tobb szerverrol en nem beszeltem, tudom hogy 1 gepen fut, sot ha jol sejtem nem is dedikalt gep vagy vps, csak egy tarhely?

Valószínű nem ilyen egyszerű, meg át sem gondoltam a dolgot, meg ugye nem is ismerem szerveroldalon sőt kliensoldalon mi van, de ha nekem kellene megoldanom, akkor valami ilyesmi irányba mennék, ami természetesen útközben alakulna, hiszen meló közben jönnek az ötletek, lehetőségek:

1.) Adott egy URL, pl.: /node/154527

2.) 500-as lapozóval

3.) Megnyitom az URL-t és AJAX-al visszakapja a kliensem sessionban, hogy milyen hozzászólások az újak, tehát az összes új hozzászólás belekerül egy listába.

4.) Függetlenül attól, hogy 1-2-3. oldalon vagyok végigszalad a DOM-on egy each hogy van e egyezőség a session listámban és a DOM-ban lévő egyedi azonosítók között. Ha van, akkor beszürkítí majd kiveszi azokat a listámból. Tehát akkor szürke egy doboz ha még nem láttam, és akkor láttam ha valóban elém került a DOM-ból.

Biztos, hogy nem én gonoszoltam le!

Szerkesztve: 2020. 09. 03., cs - 11:40
Tudok jobbat, van konkrét ötletem, leírom.
 

 

Egy topikban az osszes regi* komment alapesetben osszecsukva jelenne meg, es kattintva nyilna meg (akar egy lekerdezessel a hatterben, ahol az osszes szal is lejonne a hatterben, mert valoszinu, hogy az az emberke a tobbi szalat is kinyitogatja). Vagy lehetne egy osszes szal kinyitasa gomb.
 
 
regi komment: mindegyik beagyazott thread mondjuk 4 melyseg utan csak az utolso 4-5 melyseget mutatna.
Vagy ido alapu, minden 1 honapnal regebbi komment becsukodna.
 
 
Igy amikor az indexes topikban megjon a varva vart 1400. hozzaszolas, akkor se kell azert az egy uj hozzaszolasert vegigporgetni a komplett oldalt.

 

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Köszi, erre nem emlékeztem. Simán lehet, hogy mobilon olvastam, ahol nem tudtam kipróbálni, utána pedig már elfelejtettem.

Köszi a beletett munkát és az emlékeztetést, hamarosan ki fogom próbálni, addig is könyvjelzőztem.

„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Nincs mit.

Ja, én onload-dal csináltam meg, hogy végigiteráltam és ráhúzogattam az eventeket a gombokra, de ez csak azért volt, mert kliensoldalon nem tudok mást csinálni; értelemszerűen a szerveroldalon generált HTML-ben kitöltve az onclick-eket sokkal gyorsabb lesz, mint így.

Ez jo, csak az uj hozzaszolasokat ne lehessen becsukni, vagy csak addig csukodjanak be.

Igy akit az uj hozzaszolasok miatt nyitja meg a topikot, akkor rogton latja kontextusaban az ujakat.

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Alternatív javaslat: csak olvashatóvá tenni az eredeti témát és nyitni egy Topikcím 2. rész nevű új topikot. Előnye hogy nem kell hozzá semmilyen új fejlesztés és kikerüli a problémát. Hátránya: kézzel kell elvégezni az átállást, illetve ha valaki egy régi szálba akarna hozzászólni, akkor be kéne másolni az új topikba az eredeti hozzászólást, hogy lehessen látni, mire válaszolt az illető.

Mi lenne ha JS-ből kicsit "Lazy load" szerűen lenne megoldva?

Minden új hozzászólás kapna egy viselkedést, hogy ha a böngésző látható szekciójába ér, akkor elküldi a szervernek, hogy "Engem láttak". Nem kell visszacsatolni, tehát amíg az oldalon van a felhasználó, addig megmarad az új jelzés.

Ezzel a lapozás visszatérhetne, mert ha a második vagy további oldalakon van az új hozzászólás, az továbbra is új marad, mert nem került látótérbe.

Ezzel az a gond is megoldódna, hogy ha rengeteg hozzászólás van és egyből nem sikerült végigmenni az összesen, akkor továbbra is megmaradnának a jelzések az olvasatlan üzenetekre, sőt még az is megtalálható, hogy hol tartott a felhasználó. Plusz az első szálak új hozzászólásai is ott vannak.

Ehhez én pluszba vennék egy gombot, hogy minden jelenlegi hozzászólás olvasottnak jelölése, így ha nem azt akarod látni, hogy van még X új olvasatlan hozzászólás, hanem csak az ez után érkezőkre vagy kíváncsi, akkor rányomsz és mindet olvasottnak veszi.

Ezzel együtt én az ÚJ jelzést inkább Olvasatlanra nevezném át.

 

JS nélkül sajnos kompromisszummal járna, hogy a régi működés szerűen ha már másik oldalon van az Új, akkor sajnos a téma megnyitásával már olvasottnak jelölné.

"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"

Ha ilyen gombos megoldás lenne, akkor ajánlom, hogy legyen a téma alján vagy az oldal alján egy Minden olvasottnak jelölő gomb.

A hozzászólások esetén meg olyan, hogy ne csak az adott hsz-t jelölje, hanem a hsz fa felette levő tagjait is, tehát a szülő hsz-eken lépkedjen és jelölje azokat is, mert szerintem általában mindenki elolvassa az adott ágat, hogy mire mi érkezett. Így egy-egy ágat nem kell egyesével végignyomni, hanem egy gombbal megvan.

"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"

nézzünk már rá a db-re / kódra ami performancia-problémát okoz ilyen nevetséges adatmennyiségnél! valami git*-re ki tudnátok rakni?

~ubuntu, raspbian, os x~

Tudok jobbat, van konkrét ötletem, leírom.

Nem tudom hogy jobb-e, de ötlet:

Meg lehetne különböztetni a követett/feliratkozott/kommentelt és a random olvasott cikkeket. Előbbiek nyilván érdekesebbek adott olvasónak valamiért, így ezeknél kézzel kellene jelölni az oldal olvasását, míg random bejegyzés alatt automatikusan olvasottnak lehet jelölni a bejegyzést.

Hátránya, hogy bonyolít egy picit, de talán megszokható.

Szerkesztve: 2020. 09. 03., cs - 14:29

Ha netan egyszeru workaroundokat akarunk megszavaztatni ezutan:

- lapozas 1000-nel + 1000 folott "manualis mark as read"

- 1000 +- 50 (random) comment eseten read onlyva valjon a thread (ezt meg lehet fejelni hatekony cache-elessel)

- 1000 folott csak kapcsoljuk ki, hogy "what's new"

Szerkesztve: 2020. 09. 03., cs - 15:32

Egyszerű megoldás:

Minden hozzászólási oldalnál küldje el AJAX-al a servernek, melyik hozzászólások voltak olvasatlanok (amik most már már olvasottak ugye), és azok aztán olvasottként lesznek flagelve a DB-ben.

Így a többi oldalon nem lesz addig olvasottnak jelölve semmi, még oda nem lapozunk.

 

De talán még JS sem kell hozzá. Hiszen tudjuk, hogy mely hozzászólások lesznek renderelve az adott oldalon. Azokat akkor egyből lehet olvasottnak jelölni szerver oldalon, nem kell visszaküldeni a klienstől.

Azt kene tudni hozza, hogy igazabol mi lassu. Nem tudom hogy van a forum felepitve, en valahogy igy csinalnam (kb. 0 gondolkodassal, lehet, hogy van benne buktato):

Van egy tabla, amiben benne van a topic_id, user_id, a szoveg, bekuldes idopontja, parent, egyeb adat. Amikor lekerdezik a topic_id-hoz tartozo hsz-eket, akkor (mivel erre, a parentre, esetleg az idopontra tennek indexet) ezekbol felepitheto a teljes fa, sorrendhelyesen. Ha bejelentkezett user olvassa, akkor - egy masik tablaban - tarolnam, hogy melyik topicot mikor olvasta utoljara, ez az idopont es a hsz idopontja meghatarozza, hogy milyen szinu legyen szamara a hatter. A DB lekerdezes eredmenye cache-elheto (a legujabb 10-20 topicot fogjak leginkabb olvasni, a tobbinel belefer, hogy varjon kicsit tobbet az olvaso), a szinezes/"UJ HSZ" szoveg meg megoldhato akar a bongeszo oldalan is JS-bol.

A +1/-1 kicsit megkavarja, de abbol szerencsere nincs olyan sok. Felveheto a hsz-ek tablajaba egy szummazott ertek (akkor ugyanaz marad felhasznalotol fuggetlenul, es cache-elheto a DB oldalon), az meg, hogy az adott olvaso +1-ezett-e ra, kulon tablabol, userenkent lekerheto (topic_id, user_id, hsz_id), eleg egyszeru tabla. Ha ugy egyszerubb, meg az sem baj, ha JS nelkul nem megy a +1/-1, vallalhato hatrany.

Aztan fene tudja hogy csinalja, aki nalam tobbet gondolkodott mar ilyenen.

When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

igen az uj hsz szinezest en is 1db timestamp alapjan csinalnam. es megfejelnem annyival, hogy amikor megnyitod a topicot, akkor a js a timestampet parameternek hozzarakna a lapozo linkjehez, igy a lapozasnal nem mulnanak el az uj hsz jelolesek, es ez az egesz topic okafogyotta valna :)

szerintem annyi ido alatt amennyit elszenvedtek a drupal foltozgatasaval mar reg meg lehetett volna 0-rol irni az egeszet.

Nálam az a bejáratott munkamenet, hogy odamegyek egy oldalra, valahogy megtalálom az első új hozzászólást. ideális esetben ott kezdünk, vagy fent van egy gomb, ami az első új hozzászólásra visz. Gyakran azt kellett tennem, amikor random helyre tett le egy oldal közepén, hogy akár szemmel akár keresés funkcióval kerestem egy új hozzászólást, aztán a vissza nyilakkal elnavigáltam az elsőig.

Az első hozzászólástól aztán a következő új hozzászólásra ugró nyíllal haladok előre.

Azt nem szeretem, ha egy halom hozzászólást olvasottnak jelöl a hup, csak azért, mert a topic tetejét megmutatta egyszer. Viszont azt se szeretném, ha emiatt mindenhol egyszer az elolvastam, aztán a next gombra kellene kattintgatnom hozzászólásonként.

UX szempontból számomra ideális megoldás: ha egy bármilyen új hozzászóláson a next gombra kattintok, akkor az a hozzászólás egyben legyen olvasottnak jelölve.
Elfogadható megoldás: az utolsó új hozzászólás mellett, vagy a lap alján legyen egy extra gomb, hogy a topicban szereplő összes új hozzászólást jelölje olvasottnak.

És persze akár mindkettő is ott lehet az oldalon, egy kattintással mindet olvasottnak lehessen jelölni, vagy egyenként a next gombbal.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Ez a láttamozó gomb még úgy is jó ötlet lenne, ha nem lennének problémák a mostani megoldással... szeretem a manuális kontrollt :)

“May have been the losing side. Still not convinced it was the wrong one.”
"The clitoris has 8,000 nerve endings and still isn't as sensitive as a conservative man on the Internet"

Az nem lenne megoldás, ha elfelejtenénk (vagy opcionálisan lenne ilyen nézet) a szálak direkt megjelenítését. Időrendben egymás alatt a hozzászólások és mindegyik alatt meg lehetne nyitni (pl. show/hide gomb) az előzmény hozzászólást és/vagy átugrana az előzményre és/vagy új oldalon lenne csak a szál szintén időrendben.

Időrend esetén az újak egy "kupacban" vannak, nem elszórva, amit kényelmesebbnek találok mint keresgetni az új jelölőre.

Másrészről talán még követhetőbb is, mert most a behúzás miatt a második válasz már nem egyértelmű melyik hozzászóláshoz tartozik, ha az előtte levőre sok válasz/viszontválasz érkezett.

Egyetértek. Érdemes megnézni, hogy a Discourse - ami szerintem ma a legjobb fórumrendszer, én csak ezt használom - is ugyanezt a módszert követi: https://www.discourse.org/ 
Időrendben vannak single threadben a hozzászólások, a UX mégis köröket ver a HUP fórumra...

Érdemes ezt is megnézni, a Discourse egyik vezető fejlesztője írta (nem mostanában): https://blog.codinghorror.com/web-discussions-flat-by-design/

 

Edit: Sajnos a Drupal - Discourse integrációs modult nem frissítették Drupal 8-ra, pedig ez is lehetne egy megoldás, hogy a fórum motor Discourse-ra legyen migrálva...

Sok igazság van abban, amit mond. Szerintem a jó válasz itt is valahol középúton van. Nem örülnék egy teljesen flat rendszernek, de szerintem egy olyan ami limitált mértékben enged szálasodni (2-3 szint) teljesen jó lenne. A 3. szinten nem tudnának szálak kialakulni, de első pár szinten értelmes beszélgetéscsoportok tudnának kialakulni egy témában.

Megjegyzem szimplán egy ilyen limitáció is csökkentené a kommentek pörgését, és lehet megszüntetné a problémát, mert szimplán nem alakulnának ki több ezer kommentes topicok.

-1

Nem kell minden szar ötletet másolni. A HUP azért jó, mert rendes, hierarchikus a fórum alatta. Az egyetlen, amit normálisan lehet követni; az ilyen Youtube meg Disqusting szerű förmedvények csak állatorvosi öszvérnek valók, fórummotornak nem.

De ha már, akkor összecsukható(!) szálak lehetnének, így user szinten el lehetne rejteni a nem kívánt threadeket.

A Youtube-féle folyamatosan betöltődő hozzászólásoktól falra tudok mászni.
Egy dolog, hogy időnként nem igazán egyértelmű, mi szerint rendezi oda pont azokat a hozzászólásokat (ok, okkal vannak kiemelve), de, amikor elkezdem olvasni a hozzászólásokat bizonyos mélységben, majd véletlen rákattintok egy hivatkozásra, visszamegyek, és egyszerűen nem található meg az adott hozzászólás, csak n+1-szer lejjebb görgetve és utána rákeresve... az kiábrándító.

Ilyenek voltak az Indiegogo kampány alatti hozzászólások is.
Nem vicces dolog, utálom az ilyesmit.

Az összecsukható szálak egyébként jó ötlet, remélem, bekerül a TCH által közzétett vagy hasonló megoldás.

Az én megoldásom kliensoldali browserhack-nek készült, csak úgy érdemes implementálni, ha inline formába kerül, szerveroldali generálással, mert egyébként istentelen pazarlás lenne és sokposztos topicoknál még lassú is. Szerveroldalról kitöltve az eventeket ez nem lesz probléma.

A folyamatosan betöltődő, neverending fosra +1k.

Egyetértek, a HUP-nak mindig is ez volt a legzavaróbb oldala, ez a szálak szerinti megjelenítés.

Egyébként meg ha már szálak, akkor a jelenlegi rendszer jobb, ha meg van nyitva az oldal, azon legyen az összes hozzászólás is olvasottnak megjelölve automatikusan, akkor is, ha a user nem görgetett le végig. Külön olvasott gombot nyomkodni nem sok embernek lenne energiája. Max. ezt az olvasottnak jelölést gombbal összoldal szintjén tudnám inkább elképzelni, nem minden egyes topikhoz.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Egyetértek, a HUP-nak mindig is ez volt a legzavaróbb oldala, ez a szálak szerinti megjelenítés.

Na ja, de ha az indexes topikban 1000+ komment mindenféle hierarchia nélkül renderelődne, akkor biztos a kutya sem olvasná el. Bár ezzel megoldódna az 1000+ kommentes probléma. :D

topic lock letezik? es akkor nem lesz 1000 komment, aki akarja folytatni egy szalbol a huszarkodast, nyisson uj topicot neki.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Hmm, erről a topic lockról más ugrott be. :)

Ha lehetne adott topicra (vagy akár user szinten) beállítani, hogy frissüljön-e az új hozzászólásokkal kapcsolatos timestamp, abból érdekes funkció is lehetne.
Egyrészt menne a lapozás, majd végignézve az oldalakat ez visszakapcsolható.
...másrészt át lehetne futni az új hozzászólásokat úgy, hogy később újra meg lehessen nézni őket és adott esetben válaszolni rá.

Persze ez is csak egy workaround lenne...

Maradjon, ahogy van. Ha valaha lesz rá pénz, meg lehet csinálni rendesen, hosszú távra. Addig be kell lőni azt a hozzászólás-korlátot, amit a rendszer elbír.

(Olyan érzésem van, mintha újra és újra belekapaszkodnál valamibe, csak hogy véletlenül se kelljen lelépned a színről. :D)

:)