A proper unread marker

[xPaw]

This PR has two issues:

• Doesn't work correctly if unread message is in the unloaded buffer
• Need to look into using document visibility API.

This PR however has proper server state tracking, so the marker isn't lost between page loads.

[maxpoulin64]

Looks good to me. My only comment is that I think the unread bar could be a bit more subtle and thicker. I liked the one from #169 better for that, because it doesn't constantly grab your attention.

Also probably should have one per theme. I'm going to guess yours is based on morning considering the blue color :)

[xPaw]

I didn't really mess with the styling just yet, I wanted to get a working prototype out. I still don't know how to deal with unread marker not showing up for hidden messages (joins etc).

[richrd]

Regarding hidden messages: Using :after for the implementation is something that I like and I think is rather elegant. Unfortunately it's probably not directly possible with hidden elements. (http://stackoverflow.com/questions/14049423/in-css-use-displaynone-on-the-element-but-keep-its-after)

If a pseudo element is required I would suggest hiding child elements with something like this: #chat .messages .msg * {display: none} That way the pseudo element will be shown. I guess one of the other options would be adding a 'real' element before the first unread message (or action etc).

Just my 2 cents. And thanks for all the work you guys have put in to this project, love it! 👍

[xPaw]

Your * approach won't work due to the table layout chat uses.

[richrd]

I tried using #chat .msg.join * {display: none} in Chrome via the inspector, and it worked fine for me. The unread marker was shown but the join line wasn't.

[xPaw]

Hmm. I remember fixing an issue that was related to hiding joins and the layout messing up, but I can't remember what it was exactly.

EDIT: I think this is it: 8bbb0ab #227

[xPaw]

I've updated the PR to create a separate marker line in DOM, the solution ends up being cleaner over all using this method.

[maxpoulin64]

Is this TODO still relevant? Seems you do append the marker (well, prepend) to the DOM? I think you just need to move it to the right place in the on("more", handler right?

[xPaw]

Yes it's still relevant. To move it on more handler, firstUnread needs to be persisted then, the unread marker has to remain in DOM and hidden. But as we consider channel read as soon as we open it (not when we load the unread message), this becomes slightly more trickier.

[maxpoulin64]

Okay, been using it for the day. Just dumping some notes for now, I will truely investigate later probably tomorrow.

• I think the marker gets trimmed with the other messages when the backlog gets too big. When I either restart the server (and ZNC plays the buffer back) or I've been in a channel for too long, the marker just stops working. I'll have to investigate further to confirm, just observations so far.
• The marker is never visible on mobile because the spans are no longer table cells. I removed the spans and just gave the div a height in custom CSS as a workaround and it worked.

[xPaw]

@maxpoulin64

1. I think I fixed this.
2. Fixed.

[williamboman]

Been having this issue (might be running on a very old version of this PR though)

[xPaw]

@williamboman Are you hiding joins or anything like that? I assume that would break the last-child selector

[williamboman]

Yeah I hide join/parts etc.
On 7 Jun 2016 20:47, "Pavel Djundik" notifications@github.com wrote:

@williamboman https://github.com/williamboman Are you hiding joins or
anything like that? I assume that would break the last-child selector

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#332 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AGZQCM3HAkHCd2A87FOMqOxP_h9xlmG3ks5qJbyugaJpZM4Iek9x
.

[maxpoulin64]

Yep, I can confirm both issues are fixed. I think the only issue left with this is the hiding of joins and parts. I honestly have no idea how this one can be fixed short of tracking the visibility state in JS :/

[xPaw]

There's still an annoyance with it. When you open a channel and write a message, it shows the unread marker above your message. This isn't exactly the desired behaviour.

Also, the line is quite an eyesore, need to design something for each theme that doesn't look ass.

[xPaw]

More fixes!

• Fixed /clear breaking it
• The line now moves to the bottom when receiving a self message (e.g. after sending a message)
• Made the line thinner

I think this is stable enough to make it into 2.0. /cc @thelounge/maintainers

[williamboman]

Seems much smoother now, nice. One thing, when joining a channel with a lot of unread messages the marker is (naturally) placed at the top, but when loading more messages it stays on-top of the previously top-most message.

edit: The issue with it being displayed at the bottom still remains though

[xPaw]

@williamboman It's mentioned in the OP, and it's not entirely easy to solve due to new bugs it can introduce.

[xPaw]

@astorije What I mean is, the messages are going to have to move down when the unread marker is moved down, to compensate for lost space. If you want to tweak styles, feel free to commit it yourself.

[astorije]

@astorije What I mean is, the messages are going to have to move down when the unread marker is moved down, to compensate for lost space.

I see now, and I got to play with it when there is said padding/margin, it didn't shock me. Yes, messages are moved a tiny bit, but I don't see that as an issue.

If you want to tweak styles, feel free to commit it yourself.

I did actually, in a separate commit. I'm pretty happy of the result: it's eye-catchy so you can't miss it, and yet it integrates with the current design (designs actually, tweaked per theme to look even better). Here are the results:

Default	Crypto	Morning	Zenburn	Default on mobile

I got inspired from a few apps out there, that got me into specifying the "New messages" text. A few thing:

• I had to remove that display: table on #chat .messages. I tried many things and didn't see any consequences, both in Chrome and Firefox, but I had to if I wanted to truly center the text. Do you know of any potential consequences?
• I wanted to place that text in CSS (using content) so it can be easily tweaked per theme and not including in a selection for copy/paste somewhere. I couldn't find a way to avoid the extra span because the outer div already uses :before ... content. If there is a way, I'd be happy to know.
• I re-used the red color used in different places of the app, plus some transparency on light themes to not make it look aggressive/like an error.

I hope you'll like it 😄

[maxpoulin64]

Looks pretty good to me @astorije!

For the table, I was sure we introduced it but apparently it comes from e4d6f8f long before we forked.

[astorije]

Tiny modification between the screenshot and the commit: I extended the margins around the line (to somewhat align with the timestamp) and between the line and "New messages" from 5 to 10px. I'm all set now :)

[AlMcKinlay]

At first glance, it does seem much better than the default colour. I've even removed my colour override, and it seems much more obvious. I'll keep this on for hte day and see how it works. It does seem to have a lot more space around it, and I'm not sure how I feel about that. We'll see how it goes over the day. But absolutely a much better colour (on zenburn).

[AlMcKinlay]

Just to put it here, there was a slight issue with @astorije's changes. If someone had a very long name and you are using zenburn, you would get some really weird formatting issues because the name field was different lengths at different points. It has now been fixed.

[AlMcKinlay]

Also, it was mentioned on the irc that it might be nice to have the unread marker only disappear on channel change, because the jumping when you send a message is a bit odd. I am not decided what I think about this, yet. I'm kinda of the opinion that it might be better to do that. What do others think?

[williamboman]

Also, it was mentioned on the irc that it might be nice to have the unread marker only disappear on channel change, because the jumping when you send a message is a bit odd. I am not decided what I think about this, yet. I'm kinda of the opinion that it might be better to do that. What do others think?

I think the way the messages jumps when removing the unread marker is bad UX, so I'm def in favor of this.

[dgw]

To illustrate what I'm used to as far as unread marker behavior goes, I'll point at Textual. It does the following:

• Unread message comes in, channel in focus:
  • Marker stays where it was, visible; it does not hide.
• Unread message comes in, channel out of focus:
  • If first new unread message since channel lost focus:
    • Marker moves to position just above new message.
  • Else:
    • Marker stays where it was.
• User sends a new message while unread marker present in channel view:
  • See "Unread message comes in, channel in focus"

I don't think removing the unread marker when the user sends a message looks good. Textual provides a keyboard shortcut and menu option to move the marker to the current position, but that might not be practical/necessary for The Lounge to implement. As much as possible, I think the marker should move while the channel is not visible, to avoid sudden changes in the positions of lines.

[astorije]

To illustrate what I'm used to as far as unread marker behavior goes, I'll point at Textual. It does the following: [...]

Thanks for the feedback, @dgw, that's helpful!
FYI, current behavior is very much like what Slack and Telegram do. A difference I see is Telegram removes the marker after a few seconds on the focused window, even without sending a message.

I think the way the messages jumps when removing the unread marker is bad UX, so I'm def in favor of this.

How is that bad UX?! Debatable UI, maybe, improvable feature, for sure, but bad UX, definitely not. The alternative offered here means that when sending a message, therefore acknowledging unread messages, the unread messages marker stays, losing its meaning. Assigning different behavior to a component than what it actually is, that becomes bad UX.

That being said, I'm not saying the current behavior/UI/whatever is final, but thousand times better than nothing. As a matter of fact, I can find at least 4 minor things that need improvement. And that's key, here, I think: the feature works very well as is, and apart from the issues reported by @YaManicKill, others are nitpickings that can be resolved later. Well, I know I'll be opening issues on the things that bug me, at least :-)

So, in a nutshell, @YaManicKill, @maxpoulin64, are you still 👍 on this, as a very decent first version?

[williamboman]

How is that bad UX?!

I meant that the unread marker disappearing itself is not bad UX, but the way an entire chunk of messages repositions themselves while doing so. Creates a momentary disconnect with the content of the chat.