New New Since Last Visit Comments Comments


…new to the thread…

New Since Last Visit (NSLV) Formatting

Those of you paying close attention may have noticed that I’ve been adjusting the NSLV comment-formatting over the last few days.You may notice now that the function is working differently. Most users should be content just to absorb the change as it appears for them, and won’t really need to read this post or benefit from it: After a short transition period during which certain “cookies” in their browsers – yes, this site uses browser cookies! – get populated with data, things should, fingers crossed, go smoothly enough. After that we can see how we like it.

I don’t think the change will greatly affect anyone’s use of the site. For all I know, only nevermoor, Vikram, and I will care at all. I wouldn’t be surprised to learn that a lot of users never picked up or understood what all that blue comment highlighting as previously used even was supposed to indicate.

Anyway, for the record, here’s an explanation expanding upon a comment from the prior thread – #5 being the main functional alteration intended to answer user requests, though from a design perspective #1 may matter most:

1) On your first visit to a thread, all comments will appear without NSLV highlighting. (Previously, on a first visit, all comments would be highlighted as NSLV.)

2) After the first refresh, your current session will be “tracked” in the sense that the “entry-time” will be logged in a browser cookie.1

3) All comments posted since the session start will be highlighted as “new.” That “highlighting is now in effect” will be noted at the top of thread.


For now on highlighting new comments …and keeping highlighting in place on any new since previous visit.

4) On your first subsequent or return trip to a previously visited post, all comments since your previous visit will be highlighted. Currently the highlighting is set as a variation on what’s called “box shadow,” which will be supported by the vast majority of browsers (all “modern browsers”) that any of you are using or should be using – along with a bit of border formatting that’s even more broadly supported.


…blue box right shadow on new comments…

5) Those comments will remain highlighted during the new session. So, for the duration of this new session, you can comment or go away and come back without losing the indication of comments new since your previous visit. The session is defined by time period automatically set at entry on the thread. Currently, it’s set at 15 minutes. If anyone wants it longer or shorter (or the old way!), let me know…

6) Once the session period has expired, on the next refresh the old highlights will go away. A few from the most recent session, or the end of it, or the end of a second session – depending on how you want to look at it – may still be “captured.”

After more thorough real life testing, I will look at installing a “show new only” button – meaning you could for reading purposes make all comments but new ones temporarily disappear or collapse, but that’s for later, and may involve some further additions to comment thread functionality and interactions.


  1. If your browser is set not to take cookies, or you’re about turn them off, to make it harder for the NSAstapo to produce proof of your visits to OT, then none of this will matter for you. For those interested in the details: The old set-up used one browser cookie to do its work. This new one uses three – but all are set to expire and their potential growth is capped at a small size. []
Share this post!
TwitterFacebookRedditEmailPrintFriendlyMore options

56 thoughts on “New New Since Last Visit Comments Comments

            • Right. When you’re intensively investigating the functioning of the feature itself during an extended session or double session, this peculiarity of the sequencing< ->formatting relationship you’re noting will be more obvious. Trying to “code it away” would involve some lily-gilding that I don’t think would serve much purpose in relation to normal intended uses.
              • Fair enough. It seems to be on the side of showing NSLV rather than not, which I wouldn’t take as a bad thing. This visit, your 11:13 AM comment shows as New. That might not be bad though.

                I think I will have to use it in a diverse, 100+comment thread to get a feel. But at least what you’ve explained thus far sounds like what I was after. I’m curious what nevermoor has to say.

                • Right – that’s the desired functionality – no? So, throughout this session – now to be commenced “officially” – your comment above should remain “new since last visit” until the cookie expires in fifteen minutes from initial entry.
                  • Not for me personally. I tend to lurk/comment here in bursts where I’ll pass through 1-5 posts I’m interested in and then go back for a second pass. The long timeout window means the comments I read on the first pass are still marked as unread on the second.

                    Seems pretty clear to me that dropping the timeout (or making it very short) and allowing comments to post without a full list refresh would be better, though I get how the code I sent you for that may not play well with the post-comment editing.

                    That said, the implementation is definitely working as described and I’m trying to keep an open mind.

                    • Could be that you and VB were wanting something different, though I’m not clear how the shorter timeout window would improve things for you. You’d have to give me a step by step exactly-what-I’d-like-to-happen for me to understand, and I’m not sure it would be worth the effort for you or me.

                      I haven’t recently run across an Ajaxified comment system that allows for comment-formatting either, incidentally – and I don’t have a clear recollection of encountering one. The rule seems barebones flat text-box. Not sure how they interact with other process linked to commenting either.

                      I think this site, anyway, goes better at sub-hypersonic commenting-wise, but that doesn’t mean I’m going to stop looking around and experimenting.

                      • CK MacLeod: You’d have to give me a step by step exactly-what-I’d-like-to-happen for me to understand

                        It might not be. What the system is doing right now seems great to me. What is different than my expectations is that I’ve visited this thread today more than 15 minutes ago but still Michael Cain’s “Down in the weeds here…” comment has NSLV formatting.

                        I suspect (without evidence) that the reason is that that comment does have new replies underneath it that *are* new to me (e.g. this one), and Michael’s comment has somehow inherited that “new” status.

                        • That wouldn’t be the explanation, but if you’ve had an intervening visit, then stray leftovers may need a refresh to be cleared. To explain why, I’d have to give you a detailed rundown of how visit-time is a) calculated and b) re-calculated. Haven’t decided yet whether to try to eliminate that boundary slippage.
                      • In my perfect world, there isn’t a marking delay at all. NSLV means exactly that:

                        On comment-list load:
                        1. get LV time from cookie (or, better, DB)
                        2. set current time to LV
                        3. Load page
                        4. Mark NSLV comments

                        Then, if I reload the page, I only get comments since the time stored in (2).

                        What breaks that on OG’s system is that every comment forces a full page load (or, with that plugin you tried, a full comment-list load). So as I see it the benefit of the cookie-delay modifying (2) is that it allows me to comment through a thread without losing new comments at the bottom.

                        As far as ajaxified comments, I sent you code that doesn’t limit any behaviors except that you have to hand code any functionality you want in the temporarily-displayed AJAX comment. In other words, what the commenting user sees until refreshing the page, but what no one else ever sees. Hand coding is a pain, but doable for everything other than PHP functions that rely on being inside the comment loop (for example, on my site I couldn’t figure out how to make a reply link but determined I didn’t care as all that means is that you can’t reply to your own comment without refreshing a thread). Not sure if you could hand-code in the comment editing feature here, as I don’t have that at my site.

                        The benefit there is that I can comment/reply my way through a thread without losing any formatting simply because the originally-loaded content doesn’t go away. It also makes commenting MUCH faster, which is nice on busy days.

                        • Sounds like what you want is something more like “new since session start” – which an Ajax function will reflect in real time more or less. With a lengthier, not shorter, session term (30 minutes?) your refreshes would gather them as well.

                          Some day soon I’ll look into the possibility of letting the user toggle Ajaxification on/off.

        • Down in the weeds here…. In the /developing/ CSS, some of the font-family properties say

          font-family:”<fontname>”, serif !important;

          and some leave out the !important. The file uses both Domine and Goudy Bookletter 1911 for <fontname>, fonts which may or may not be installed for any given user (neither are in the default kit for my Mac). Since there’s no @font-face property pointing to sources for the specific named fonts, different users may get a different page appearance. Perhaps quite different, as the actual character size as rendered on the screen for a font-size of 18px (to take an example from the file) may vary substantially between fonts. The use of !important may vary from browser to browser, may interact in unexpected ways with the user’s own default CSS files, and doesn’t guarantee the use of particular fonts — is there really a reason to include it?

          • Note, this blog is itself “in development,” as noted elsewhere. It’s meant to be close enough to the main blog – OT – so that I can assess changes here without affecting things over there.

            Without going into a ton of detail, the two fonts you named that are used Over There are also used Over Here. They’re loaded via Google Fonts, and should appear as intended for most users regardless of what they bring to the party browser-wise, within reason. (If they’re using ca. 2002 Internet Explorer or something, no guarantees.) To make matters a little more complicated, OT doesn’t load GF directly, but via a plug-in and usage-limited account, and also interacts with the site theme in a somewhat complicated way, since the site theme is also a complicated theme that doesn’t load its own stylesheet in a conventional manner.

            The !importants in “Developing…” are leftovers of an incomplete attempt to emulate OT on a new, second “child theme,” which is the preferred way of introducing modifications to built-in functions and templates, while using Google Fonts in a more normal way.

            To make things more fun, Google now has a different font subscription service – I think. Or maybe it’s the same one under a different name. OT is now running on a different child theme than Developing – whose “sibling” theme may someday be the base theme or one of several base themes for other sub-blogs.

            Unless we nuke the OT theme and try out a completely different theme, of course.

            I was going to nail down these issues, and make a run at rationalizing the font set-up for all OT sites a few weeks ago, when a client asked to do a side-by-side comparison of Fonts for her site, exploiting the up-to-date Google set-up. However, that project fell unexpectedly by the wayside. So, “getting my font act together” shifted to the fabled back burner: One of those things, on a long list, that I really ought to get to one-of-these-days-in-my-nonexistent-spare-time. In the meantime, the !importants let me approximate, but not at this point duplicate, the OT look and feel via a style-kludger.

            I don’t expect I’ll do the big fix, but I think I may work on a bit of out-of-whackitude on this site… soon.

            • Did a couple things to improve the font loading (tho the effect may disappoint OG Likko, who apparently has a liking for the fallback font). Still haven to figure out why the sizes come out different on the main site from hereabouts.
              • OK, I think we’re a lot more conformerific now. Some differences remain, having to do with some different functions Imma testin out and such like. Guess one of those days came a little earlier today. Is good tho, since now is under control mostly prior to the Big Rationalization.
            • …and make a run at rationalizing the font set-up for all OT sites a few weeks ago…

              Good luck with that :^) Goudy, Domine, and Georgia as first choice for various page elements. Arial as the first fall-back for Goudy and Domine, Times New Roman as the fallback for Georgia. Non-standard line spacing in all cases, and that spacing independent of the font used.

              • Not sure exactly what you’re suggesting or describing, but Arial doesn’t really make sense as a fallback for either font, in my opinion (though I realize is still set that way on OT).

                95 – 99% of users 99% of the time, ought to get Goudy/Domine as intended, with other fonts occasionally imported via external plug-ins and processes, or applied in special cases.

                The one thing I that’s been glaringly off in the somewhat unconventional choice we’ve inherited from the old League’s nostalgic, sort of Steampunkish aesthetic is italics on Safari.

                Italics on Firefox:

                Italics on Safari:

                I’m surprised no one’s complained about them before, and I’ve never researched the matter. Maybe it’s “Safari via Windows” that renders it so poorly, for only a tiny minority of users, not Safari on Apple OSs? I don’t know. The regular text also looks a little sickly.

                • This is what I get on Firefox on my Mac, post my processing. Safari is almost identical, with a user CSS file that gets loaded with every page and takes precedent on font choice almost everywhere. OSX does a really nice job rendering Droid Serif, my font of choice (I tweak the character and line spacing slightly).

                  Random thought — is the full Domine family downloaded, or are the browsers forced to render italics using slant instead of an actual italic character set?

                  • Whachu get is nicer. What I’m curious about – since I don’t have immediate access to an Apple system, is what the vast majority of Mac or iPhone Safari users get. I could run an emulator, but I’m not 100% confident that what it will show me will be eggzactly what real-life in-the-field users get.
                    • (But in the department of really big, big news, I have finally cracked the threads at max-depth re-start problem. I do not know of anyone anywhere else who has done this. It is one small step for a developer, one giant leap for WordPressNestedThreadUserKind).
                      • A little research shows that… wait for it… Domine has no italic variant. Regular and bold is all that’s available, so all the browsers are going to use slanted text for italics.

                        Droid Serif regular face is very close to Domine regular. If you have a place where you can change it easily, at least for the development page, you could silently swap fonts, get real italics, and see if anyone notices the subtle improvement.

                        • Perhaps as an incentive, here’s the same comparison of fonts when <i> is used. Deep down inside, I’m a “print medium” sort of guy. It must be genetic; my father worked his way through school in the university print shop making academic books look good (when I was a kid, I knew what a “floating display” was, and I criticize Microsoft Word to this day for not supporting the concept), and my son has a graphics design degree but passed on web jobs while he found one where he could do print.
                          • Well, it’s true Domine doesn’t have an italic font, so the italic has to be approximated. I don’t have strong feelings about it altogether, but one of these days I’ll do a taste test with some other alternatives, especially if I can justify it in relation to some other project, or with a more ambitious aesthetic re-design of OT or successor…

                            I don’t want to get into the situation where we’re loading too many new fonts for variations in weight, size, and style, however. We’re still safely in the green here now, but at a certain point you start adding noticeable overhead.

                              • It’s similar, but not the same!

                                Since the base text font comprises, guesstimating here, 97% of all of the text encountered on this text-heavy site, before switching it out I think the whole community would have to be consulted – or at minimum the editors, while an explanation for the change would have to be prepared.

                                For people who are font-conscious, the differences between Droid Serif and Domine are HUGE. For some users, it will be as though their underwear was switched out when they weren’t looking: Suddenly, it’s all Fruit-of-the-Loom, when they’ve been committed to Hanes all of this time… I won’t say now it’s boxers when previously it was briefs, we’re not contemplating anything that radical yet.

                                On the other hand, people who aren’t particularly font-conscious probably also are okay with slanted rather than native-italic fonts. Hanes, FotL, who cares as long as it does what underwear’s supposed to do and’s the right size?

  1. That is handy, but…

    Maybe try keeping functionality changes in a quarantined part of the site, and then implement it widely during a posting slump?

    Because it seems like whenever you change something, the “last visited” highlights completely reset, and I wind up missing big chunks of the discussion–or having to wade through all of the posted comments like some neanderthal from early 2015.

        • The tinkering seemed to reset my “last visited” status to having never visited the page, so as expected for the new implementation, none of the comments were highlighted.

          The second half of my comment was merely an attempt to communicate the above. The bit about neanderthals in 2015 was to riff off the fact that I’m complaining about the effective disappearance of a feature that you just recently added to the site. All of the “find where the recent posts are on OT” skills that I’d been developing since 2010 have apparently already atrophied.

          • Who knows what unexpected capacities may yet evolve in response to the new selection pressure?

            If you’ve never been to the thread before, then they’re all “new to you,” but none since “last visit.” (As usual when trying to code any change at all to an interactive group process, in addition to getting the mind to wrap around particular methods, required entering into obscure contemplation of the specific meanings of “since,” “visit,” “session,” “new,” and other vague everyday terms…).

    • Good – so do I, and so does, apparently, Vikram, and so does, possibly, Alan, when he’s not a Neanderthal.

      I think that the functionality is functioning as intended today. So now I need to go through the fixes and figure out which fixes fixed what. Alternative is to let things ride a bit and accumulate reactions, data, see if anything else problematic turns up during normal use of the site.

      Please keep those cards and letters coming.

      • Add me to that list!

        It’s definitely a useful feature (imo a key to making any commenting-heavy site usable), which is why I’m engaging (too much) on the backend design.

  2. I adore the highlights. Absolutely adore them. Thank you. Some mechanism to navigate to them would be sweet, some day in a happy future.

    I have a style-book question: I would like the excerpt to format as a subtitle under the main title; so that one is granted the brevity from not excerpting. For that, again in a bright happy future, a pull quote would be the order of the day.

    Excellent, excellent work, CK. I’m gobbledygooked at how seamless and easy you’ve made this all seem. Congratulations. Kudos. Deep bows.

    • Thanks,

      1. NSLV navigation: Simplest alternative to navigating would be a simple hide/show button or tab. Press th e button, and all old comments disappear. Press it again, and they come back. Jumping to next NSLV comment would also be implementable. Or could even implement a “jump to next” for navigating the page, that would still be in effect when hiding all old comments. Have to think about which set-up would be most natural/useful.

      2. Not sure I understand.

      Are you saying that when we click to view the full post, the excerpt would automatically show up at the top in some distinctive format, under the title, like a “precis”?

      Twould be an option. Or did you have something else in mind?

      As for pull quotes, adding a PQ button on the editing page wouldn’t be hard: highlight text, press button, text copied and PQd. (Would appear wiithin the editor as bounded by shortcodes, as with the new “multi-block spoiler” that no one’s used yet.)

      Would writers (or editors) use them – much? Maybe!

      (I’ve also been thinking about implementing automatic display of the featured image at the top of single-page posts. Very easy to make automatic, possibly in some stylized format that merges with the excerpt, title, post and author “metadata.”)

  3. This AM, I seemed to be in a state such that there was a small set of comments on some pages that stayed highlighted as new no matter how many times I refreshed, or even restarted Firefox. Deleting all of the cookies seems to have fixed things (with the expected effect that on my first visit to a comment page, none of the comments were highlighted).
    • Setting aside certain session-before-last leftover comments of the type discussed above with VB, that will disappear on the first refresh, comments initially highlighted as NSLV will stay that way until the cookie expires, no matter how many times you refresh. That was the initial main objective of this change. Currently, expiration of “current session cookies” is set at 15 minutes. So, until 15 minutes from your return visit (to any post at the site) have elapsed, the NSLV will stay in effect. (Another alternative would be to bind session to particular post – so every post would have its own session cookie – also seemed like lily-gilding to me, and didn’t actually experiment with it.)
      • Just to make sure I understand. If I jump into the site at “State of the Discussion”, then from there jump to a particular post page, then back to the State page and refresh, then jump to a different post page and spend time reading and responding, then back to the State page and refresh, then back to the first post page, the same comments will be highlighted as NSLV as were the first time I jumped there? That so long as there’s no 15-minute span where I “do nothing”, the time against which comments are tested for NSLV doesn’t change?

        I see what that would be useful for, and am not criticizing.

        • I think you mostly have it: 15-minute session cookie is set upon first visit to what’s called a “singular” page: That would include State of the Discussion, but not the home page (at present – this could be change if there’s a reason to do it.)

          Once the cookie is set, it won’t be changed until it after a visit after it has expired (after fifteen minutes) – unless you actually delete it. When it’s set, the “latest visit” setting is also “frozen.” Only after the session cookie has expired can a) a new session cookie be created and b) a new “latest visit” time be set.

          So, since we’re virtually going line by line anyway, here’s where the “slippage” occurs: If I’m at the site for 30 minutes, then sometime after the first session cookie expires, I’ll be setting a new session cookie, and also setting a new “latest-visit time.” Rarely, however, will someone leave the site exactly at the moment of expiration. So we’re left with a cookie that will expire later, but no “real-time” proximate re-set of “latest visit.” In those cases – session cookie expired + a latest visit still active – we need to be able to re-set the latest visit, otherwise we will have the same value there that we had before, as though the intervening session never took place. In those cases, the info from a third cookie (essentially “last recorded current time”) replaces the stale/obsolete latest visit. (It’s in that zonality that the “slippage” on first return occurs.)

          Finally, a “visit time” also has to be assigned when we visit particular posts for the first time (and there’s a bit of minor glitchery here, having to do with the “first visit” vs “now highlighting” notice, that I need to address, too) but with one or both session and other-post’s last visit cookies set.

          As noted, there’s just a little blurring around the edges for a certain set of not-quite-new, not-quite-old comments that will be highlighted on some “first return visits,” and disappear on the first refresh. (I’d have to go through the code/logic really line by line for you to explain why this happens, and why it seems best to me just to let it happen.)

  4. Pingback: New New Comments New Since Last Visit Reloaded, Reloaded, Augmented | Developing...

Comments are closed.