source collection: consolidate file-type and read/unread indicators

[cfm]

Description

The Journalist Interface's col.html currently displays two status icons for each submission:

Type	Status	Status Icon	Type Icon
document	unread	closed envelope	file
document	read	open envelope	file
message	unread	closed envelope	text
message	read	open envelope	text
reply	unread	reply arrow	reply arrow	reply arrow
reply	read	check mark	reply arrow

NB. In this table, the "Type" and "Status" columns are presented in what feels to me like their logical order, while the "Status Icon" and "Type Icon" columns are presented left to right as they are displayed in the Journalist Interface.

I propose consolidating these indicators into a single icon for each submission, where the file-type indicator is overlaid with the "unread dot" used by Slack, many mobile messaging apps, etc.:

Type	Status	Status Icon	Type Icon	Combined Icon
document	unread	closed envelope	file	file + "unread dot"
document	read	open envelope	file	file
message	unread	closed envelope	text	text + "unread dot"
message	read	open envelope	text	text
reply	unread	reply arrow	reply arrow	reply arrow + "unread dot"
reply	read	check mark	reply arrow	reply arrow

User Research Evidence

Prompted by #5985, where user story (2) below is the motivating case, and further considered in light of my own perusal of the Journalist Interface. Of course, if there are historical or other UX reasons for the current pair of indicators, those reasons should take precedence.

User Stories

1. As a user of the Journalist Interface, I want to be able to glance at a single icon to determine everything about the submission apart from its name and size.
2. As a user of the Journalist Interface with a screen-reader active, I want to hear this information narrated concisely, e.g.:
   • 1-off-line_motormouth-msg.gpg is an unread message for a single icon, rather than
   • 1-off-line_motormouth-msg.gpg is unread followed by 1-off-line_motormouth-msg.gpg is a message for separate icons.
3. As a developer, I want simpler template logic to maintain in col.html.

[ninavizz]

This is a terrific idea Cory, thank you for filing!

And so begins, the fun path we've all been treading and now invite you to tread along with us: how much work do we wish to invest, in a UI we seek to depreciate?

I've struggled with this one a lot, myself—because in "the real (cough, corporate) world" (big air quotes!) an interface that's expected to exist for another 1-2 years is not considered "poised for retirement." And yet, with the SD dev and newsroom coordinator teams as lean as they are, it can take much longer than in traditional software environments, to stabilize things to then sunset elder versions.

TL;DR, the Journalist UI is not "going anywhere" anytime soon, and yet we cannot outright ignore it. Hence, you working on its accessibility stuff.

Also, I'm really longwinded. But am working on that, too. :)

One of the ways in which we've sought to mitigate this thus far between the Workstation Client and the Web UIs, is to unify the use of visual and written language as much as possible.

The visual language for Read/Unread in the Client UI, is done with text being a heavier weight and a darker color on things that have not been read, and then a lighter weight and color on things that have been read.

TL;DR;2, it'd be my own preference to do something like that, for the JUI, if we eliminate the wonky open/closed envelope icons. I am very much with you in not liking them a whole heckufalot, tbh.

Open question, though: for accessibility, is there a reason why having an icon is preferable, over incorporating that visual language into the typography treatment? Relevant to other work I'm doing for Qubes rn, too.

[ninavizz]

Related: the dots we see in slack, are indications of people being online or not. Those have been a common semiotic, for many years in messaging apps. Mostly for that reason, I'm averse to appropriating that marker, for a different semiotic. I'm also averse to using a different visual mechanism to communicate the semiotic most folks seem to expect communicated via the bold/not-bold paradigm (or a close cousin variant) used in the client.

Happy to chat more, whenever! :)

[cfm]

On 23 Jun 2021, at 17:49, Nina Eleanor Alter wrote:

And so begins, the fun path we've all been treading and now invite you to tread along with us: how much work do we wish to invest, in a UI we seek to depreciate?

Yes, absolutely, and I mean to be sensitive to this question in general. I opened this ticket, in particular, because it offers a chance to (1) use an accessibility concern to (2) simplify, for as long as it’s still supported, the UI we seek to deprecate. Of course, there’s still a tradeoff in how much to invest at all in a UI we seek to deprecate. But my own wager is that the current accessibility effort will yield some valuable simplifications and few, if any, expensive complications. :-)

The visual language for Read/Unread in the Client UI, is done with text being a heavier weight and a darker color on things that have not been read, and then a lighter weight and color on things that have been read.

TL;DR;2, it'd be my own preference to do something like that, for the JUI, if we eliminate the wonky open/closed envelope icons. I am very much with you in not liking them a whole heckufalot, tbh.

So much the simpler. In hindsight, I realize this ticket as written begs the question. The real point of this proposal isn’t “use one icon for both type and status” so much as it is “use at most one icon per submission row”. “At most one icon for type” and “bold for unread state” meets that desideratum just fine!

Open question, though: for accessibility, is there a reason why having an icon is preferable, over incorporating that visual language into the typography treatment? Relevant to other work I'm doing for Qubes rn, too.

Not to my knowledge. For the purposes surfaced in #5985, either (a) icons or (b) typography treatment will be applied in CSS, and either way the table can be marked up with ARIA annotations for screen-readers to announce the content of these visual indicators.

On 23 Jun 2021, at 17:57, Nina Eleanor Alter wrote:

Related: the dots we see in slack, are indications of people being online or not. Those have been a common semiotic, for many years in messaging apps. Mostly for that reason, I'm averse to appropriating that marker, for a different semiotic. I'm also averse to using a different visual mechanism to communicate the semiotic most folks seem to expect communicated via the bold/not-bold paradigm (or a close cousin variant) used in the client.

Ah, good point. I was thinking less Slack “active” dot and more the sort of universal “notifications” badge first used on mobile apps. But your point holds: that indicates “there are unread items within”, not “this item is unread”. So, as you say, there’s likely an even simpler visual language we can adopt here than what I’ve proposed.