A small button for 'go to first unread' ?



  • When entering in a topic most times I do a bit of scrolling and the toaster 'goto first unread' disapears.
    Adding a small button (a 'u' into a circle by example) in the navigation thingie would be more confortable and discoverable.

    What people thinks about this ?



  • @cabrito I agree with whatever @cabrito just said.



  • I would actually prefer if the link on the topic list would jump me to the first unread post in the thread so I didn't have to click anything extra. I pretty much always want to continue reading wherever I left off.


  • sockdevs

    @cabrito Tonight, I'm going to be looking into making the toaster less sensitive to timing and scrolling; my aim is to have it up for at least 10 seconds, unless you scroll more than, say, 300px. Hopefully it'll be a simple thing, and we can get it on here soon.



  • @RaceProUK said:

    @cabrito Tonight, I'm going to be looking into making the toaster less sensitive to timing and scrolling; my aim is to have it up for at least 10 seconds, unless you scroll more than, say, 300px. Hopefully it'll be a simple thing, and we can get it on here soon.

    Can you also look into the positioning of the toaster? It would be better placed in the corner closest to where you just clicked to get into the thread. As it is, it seems like I always have to traverse the full diagonal of the screen just to hit it...


  • sockdevs

    @Mikael_Svahnberg I could do, but I don't want to get too carried away; I want to ease myself into NodeBB hacking bit-by-bit so when it comes to bigger changes, I'll be able to do a better job


  • sockdevs

    @RaceProUK said:

    my aim is to have it up for at least 10 seconds

    Turns out that's already the case :)

    @RaceProUK said:

    unless you scroll more than, say, 300px

    This bit I think I have a fix for; @ben_lubar, can you confirm whether this change does what I think it does?
    In src/client/topic.js, line 217, change updateTopicTitle to this:

    	function updateTopicTitle() {
    		var span = components.get('navbar/title').find('span');
    		if ($(window).scrollTop() > 50) {
    			span.html(ajaxify.data.title).show();
    		} else {
    			span.html('').hide();
    		}
    		if ($(window).scrollTop() > 300) {
    			app.removeAlert('bookmark');
    		}
    	}
    


  • @RaceProUK said:

    my aim is to have it up for at least 10 seconds

    :giggity:?



  • @RaceProUK How about infinite seconds?

    Until you scroll past the last-read post. Then and only then would I want it gone.

    It probably also shouldn't be stacked with the rest of the notifications, it should be its own widget somewhere else. So it won't shift around randomly.



  • @blakeyrat @RaceProUK's patch makes it stay visible until you've scrolled 300 pixels from the top or 10 seconds have elapsed.


  • sockdevs

    @ben_lubar Does it work though? I've not got a test NodeBB setup yet, and I want to be sure it;s good before I submit the PR.



  • It would also be nice to have the text in the popup readable on dark themes.



  • @cabrito said:

    When entering in a topic most times I do a bit of scrolling and the toaster 'goto first unread' disapears.
    Adding a small button (a 'u' into a circle by example) in the navigation thingie would be more confortable and discoverable.

    Oh, it's already there!

    0_1458589533212_upload-f86f244d-6101-4835-9b69-f8554844c47d

    You just need to change the view to mobile. It's not on desktop for... reasons.



  • @ben_lubar I understand that, but I'm saying why have a timer at all? Just have it always on the screen until its no longer relevant.



  • You just need to change the view to mobile. It's not on desktop for... reasons.

    NOT mobile? That's different.



  • @RaceProUK applied locally. Give it a try.


  • sockdevs



  • @blakeyrat said:

    I understand that, but I'm saying why have a timer at all? Just have it always on the screen until its no longer relevant.

    This. Just leave it there until I get to the bottom or dismiss it.



  • @RaceProUK Doesn't that only dismiss it if the user scrolls 300 pixels?


  • sockdevs

    @loopback0 The 10-second timeout is in a different bit of code:



  • @RaceProUK Ah, yeah. Also I'd misread the function that was changed anyway. :facepalm:



  • Question for @RaceProUK or the peanut gallery:

    • Does the 10 second timer apply only if the tab is active?
    • If not, can this behavior be further changed so that inactive tabs don't disappear the toaster?

    That has been one of the most jarring changes to my forum flow so far. I center clicked a bunch of big threads, and by the time I got to each one after the first, the "go to where you left off" toaster was quite gone.


  • sockdevs

    @izzion said:

    Does the 10 second timer apply only if the tab is active?

    Not as far as I'm aware; focus appears to be irrelevant

    @izzion said:

    If not, can this behavior be further changed so that inactive tabs don't disappear the toaster?

    Probably, but that's a change I want to get a proper test instance for before making it



  • @izzion said:

    Does the 10 second timer apply only if the tab is active?

    No this is the thing that annoys me about it.



  • @izzion said:

    can this behavior be further changed so that inactive tabs don't disappear the toaster?

    Reloading the page will reappear the toaster, so it's probably not a high-priority fix.



  • @anotherusername Doesn't always reappear after a refresh IME


  • sockdevs


  • Impossible Mission Players - A

    @RaceProUK said:

    If the URL ends with a post number, the toaster doesn't appear

    Yeah, which makes it so much crappier when NodeBB helpfully scrolls a bit for you so you get a number.
    I refreshed quite a few times before figuring that one out.



  • @RaceProUK said:

    If the URL ends with a post number, the toaster doesn't appear

    No, it's not even that consistent. I had that theory yesterday, and proved myself wrong almost immediately.



  • @Maciejasjmj That button just links to the last post for me.



  • @RaceProUK said:

    @Mikael_Svahnberg I could do, but I don't want to get too carried away; I want to ease myself into NodeBB hacking bit-by-bit so when it comes to bigger changes, I'll be able to do a better job

    No rush. I was just trying to subtly get you to scratch my issues too.


  • sockdevs

    @Mikael_Svahnberg said:

    I was just trying to subtly get you to scratch my issues too

    No offense, but I'd rather scratch @accalia's issues :giggity:


  • Discourse touched me in a no-no place

    @anotherusername said:

    I would actually prefer if the link on the topic list would jump me to the first unread post in the thread so I didn't have to click anything extra. I pretty much always want to continue reading wherever I left off.

    This is the most useful behavior, and it goes all the way back to the 80s and Usenet. NodeBB's behavior is weird.


  • Impossible Mission Players - A

    @FrostCat said:

    NodeBB's behavior is weirdperformant.

    FTFY?. NodeBB's implementation doesn't need to know where you last were for every visible topic link in the list.


  • Discourse touched me in a no-no place

    @ben_lubar said:

    @blakeyrat @RaceProUK's patch makes it stay visible until you've scrolled 300 pixels from the top or 10 seconds have elapsed.

    Ben, that or essentially ruins my workflow, and probably a bunch of other peoples': I prefer to open-in-new-tab a bunch of topics and then read them one at a time. You can't do that with the toaster unless you then immediately go to each new tab and click that tab's toaster.

    I'm not intending to bash NodeBB; I actually like it better than :disco::carousel_horse: so far (@julianlam), but the entire idea that you shouldn't automatically jump to the first unread post is just plain wrong.



  • @FrostCat said:

    I prefer to open-in-new-tab a bunch of topics and then read them one at a time

    This. The toaster needs to stay put until it gets actively dismissed, or it needs to go straight to the first unread post.


  • Discourse touched me in a no-no place

    @Tsaukpaetra said:

    FTFY?.
    Nope.

    @Tsaukpaetra said:

    NodeBB's implementation doesn't need to know where you last were for every visible topic link in the list.

    Why not? If it's done right it is like one additional DB lookup. I actually added "hide read posts and jump to first unread" to a forum about 10 years ago. It's not exactly rocket science, assuming a simple/sane schema like a table that simply has {userid, topic id, last unread post}. You've already got to look up (if you're on Unread, say), every topic to know whether or not to display it (or, if you're not on Unread), to color the topic's link, not to mention other stuff like the data on the right.

    It should be a trivial change, and one with relatively low impact given all the other stuff that's got to go on to generate the topic list. And again, it's the right thing to do in virtually all circumstances. Why would you ever not want to go to the first unread post when you enter a topic?


  • Winner of the 2016 Presidential Election

    @FrostCat said:

    If it's done right it is like one additional DB lookup.

    Depending in how you implement it, it's not even that. You could have a /t/numbers/new link that takes you right to the post and only look that up when the link is clicked


  • Impossible Mission Players - A

    @FrostCat said:

    assuming a simple/sane schema like a table

    That's a rather large assumption for these newfangled things. :wink:

    But I agree, should be a default setting.



  • @anotherusername said:

    I would actually prefer if the link on the topic list would jump me to the first unread post in the thread so I didn't have to click anything extra. I pretty much always want to continue reading wherever I left off.

    I vote with @anotherusername . It's only about 1% of the time I want to restart at the top of the thread and read all 2,000 posts again. It's only about 1% of the time I want to go to the end of the thread and then try to scroll back and find which post I read last. Both top and end of thread are 1 click away if I do want them.

    But that means that 98% of the time I want to pick up where I left off, with the first post I didn't read. Why put me at the wrong place 98% of the time and make me select something to go to where I want to be?


  • Discourse touched me in a no-no place

    @CoyneTheDup said:

    It's only about 1% of the time I want to restart at the top of the thread and read all 2,000 posts again.

    And it's only one key (home) to go to the top if that's what you want! (Plus the thing you mentioned below.)


  • area_deu

    @anotherusername said:

    I would actually prefer if the link on the topic list would jump me to the first unread post in the thread so I didn't have to click anything extra. I pretty much always want to continue reading wherever I left off.

    This. So much this. Why the fuck is this not the default behavior? Where's the use case in "oh yeah, let's show the user this huge-ass thread under 'unread' because there is one new post at the end, but if he clicks on it, let's throw him right to the first post"? Because everybody likes to read old shit all over again EVERY SINGLE TIME, right?


  • Winner of the 2016 Presidential Election

    Ok , I tested the button on mobile that was pointed out above. As suspected, it's "go to last", not "go to last unread". From a bit of poking around I did it seems that the ID of the last unread post is not sent with the topic list, and not even the topic JSON when you initially open it, so we can't hack this together client-side.


  • Discourse touched me in a no-no place

    @RaceProUK :beers: I approve thoroughly of improving this sort of thing. I guess having a reliable link to “last unread” from the list of threads would be the ideal as it would put people where they want to be. Nuclear Power? Toasters for fundamental navigation functionality? No thanks!

    A more important thing would seem to be to actually go to the first unread post, as opposed to some random other place that appears to be the first post not read by anyone at all. Right now, I've got this workflow “enter thread, click to go to first unread post, scroll up a whole bunch to get to the first post that I've not read” and it's really irritating. This might even be the principal bug remaining in the nodebb core, and I've no idea if it is because it sometimes loses track of where it is, translates it into the wrong load position on return, just fails at actually getting to that load position, or what.

    Of course, there might be a link in the topic list that is already supposed to offer this functionality but fails because of the problem with what is read and what isn't. (I'm not going to play hunt the bug on this; too much else that I'm busy with.)



  • @Onyx said:

    From a bit of poking around I did it seems that the ID of the last unread post is not sent with the topic list, and not even the topic JSON when you initially open it, so we can't hack this together client-side.

    I suppose we can (although that may take more than one request). The "go to last unread" toaster has to get the info about the last post from somewhere, so it shouldn't be that difficult to just do the same request it does and emulate the click.


  • Winner of the 2016 Presidential Election

    @dkf said:

    A more important thing would seem to be to actually go to the first unread post, as opposed to some random other place that appears to be the first post not read by anyone at all.

    I think that's the "read tracking" messing up. It seems like it want the top of the post you "read" to be in the middle, or above, of the screen. If you pay attention to the newlevator in the header, sometimes (when the last reply or two are short) you can't reach the last post.

    @Maciejasjmj said:

    The "go to last unread" toaster has to get the info about the last post from somewhere, so it shouldn't be that difficult to just do the same request it does and emulate the click.

    I think that's the best we could do for now, yeah. I buttume that that bit of information is transmitted in a separate block of data you get after the thread has loaded, possibly as some user-related data instead of thread data.

    How the hell did we manage to go directly from "software sends too much JSON" to "software doesn't send enough JSON"?


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.