Open wrightmartin opened 6 years ago
Here's a couple of ideas for tweaks to this (compared to current):
Some specific feedback from Lucas
Framing each piece of correspondence with: a number (1, 2, 3 etc) and metadata (such as from, to, date, time) would be useful.
There's a minor conflict between this and the expand/collapse icons https://github.com/mysociety/alaveteli/pull/4219
I'm not sure whether this would distinguish individual pieces of correspondence on a really long thread (think 10+ bubbles). It would differentiate incoming vs outgoing a bit more, but if you had 3 incoming in a row, and all were a screen's length, it would still be hard to identify which is which.
I'm not sure whether this would distinguish individual pieces of correspondence on a really long thread (think 10+ bubbles). It would differentiate incoming vs outgoing a bit more, but if you had 3 incoming in a row, and all were a screen's length, it would still be hard to identify which is which.
Lucas suggested numbering responses, I wonder if showing a number rather than an icon would help?
We could show the message ID, but they're getting pretty long these days https://www.whatdotheyknow.com/request/implementation_costs_and_timesca_4#incoming-1070270
We could obviously number from 1 onwards per request, but I think that would get really confusing.
I honestly don't know if it adds much from the top down, but when you're linked into a long request thread, knowing that you're on the 13th piece of correspondence could help with the 'where am i?' question
Yeah, in principle its nice.
My concern is that those IDs would simply be based on position – not the actual database ID of a message.
For example, when we link to a correspondence, we use the database ID (#incoming-1070270
). I don't think that correspondence can get reordered, but IDK, it just worries me that people will start to use these "fake" IDs and we'll be stuck with them. I'd much rather use the real ID somehow.
Perhaps we could put the date/timestamp in that highlighted box? Something like…
If date is in the past show:
If date is today show
The problem with dates are they don't tell you anything about the thread itself - a date alone needs another date to make a relation, and you need the initial date of the request to make that relation, and so on.
What a number does it give you immediate orientation and some confidence in that orientation - "This is the 5th message in this thread. If I scroll up I will see there are 4 messages above me."
They're ordered by created_at, ID, so I doubt they will (should) ever get reordered. It would be nice to have the internal links be numbered from 1 rather than internal ID, much as GitHub here does for issues :)
I've renamed this issue to tackle the simpler problem of making the incoming/outgoing distinction clearer. I don't think the left/right arrows make this particularly clear. Couple of off-the-cuff alternatives:
I've ticketed the ID numbers issue at https://github.com/mysociety/alaveteli/issues/4561.
I'm against the icon approach because I don't think they're distinct enough from each other - at a glance they have the same silhouette and take some overhead on the behalf of the user to decipher.
I'm going to do some research into established patterns for this, but before I start I quickly threw together something @zarino suggested - right and left aligning the alternating message ala the ios messages app.
Here's what I was thinking in place of the arrow idea:
I accept that its probably not the best solution here, but when investigating and implementing I'd keep in mind that I was initially budgeting this as a ~ 0.25 day type solution. Do have a bit of a think about this, but I don't think its that broken to justify a really big redesign.
Have we ever shown a from: to: style message header like gmail does?
Might be worth sketching how you think that could work in our context. I can't really visualise it.
Adding the "To…" line is nice, but I don’t think it actually helps solve the problem at the start of this ticket:
When scrolling long request threads it can be hard to spot where messages end and begin
My impression is that we need something much more visual, that people can spot while they’re scrolling quickly down a page. No?
My impression is that we need something much more visual, that people can spot while they’re scrolling quickly down a page. No?
Yes you're right, we're a little bit off-mission here.
If we refocus on that problem, and with @garethrees's 0.25/day budget how would we feel about putting together a PR of https://github.com/mysociety/alaveteli/issues/4504#issuecomment-405958676 for an internal test?
Re pull #488…
This is an attractive solution, but, I'm concerned might make it harder for folks with visual impairments or SpLDs such as dyslexia to read responses as there will be a difference in the flow of content on the page.
Could greater use of colour perhaps be explored to delineate responses?
A very crude example could be something like this - it's not by any means the best example, but, hopefully it gives a sense of what I'm thinking.
In essence there is two possible options shown here, expansion of the delineating colours used within the WDTK theme to show correspondence type (e.g. in/out), and, iconography which could be put in the area of the request background which would typically be whitespace (not so opaque as to otherwise be a visual distraction).
Neither necessarily feels great (especially when combined), but, it may provide enough of an easy visual indicator without causing unforeseen issues for users who may then have some trouble reading information.
Of course, this is just my own perspective, but, hopefully it's of some help
P.S. Apologies for the rather hacked up styling, it's a very quick mockup from Axure and it's not very refined!
Thanks for the feedback @mdeuk!
This is tricky – pale backgrounds and potentially ambiguous icons feel like they won’t be clear enough indicators when you’re quickly scanning a thread page. (See discussion above.)
I’m having a hard time finding any guidance about, specifically, indented flows of content and visual impairments / SpLDs – it sounds like maybe you might now a bit more. Do you have any links I could read up on?
Just noting that we tried indents, but decided against it https://github.com/mysociety/whatdotheyknow-theme/pull/488. We're going to try approaching https://github.com/mysociety/alaveteli/issues/4505 instead, to see if we can get more mileage that way.
Just came across this when doing some triage and looking again, I think the problem is not so much with the header but the fact that when you scroll past the header of any piece of correspondence, it's difficult to remember who sent the correspondence.
The place where we might actually need a design intervention is down the side of a correspondence box.
when you scroll past the header of any piece of correspondence, it's difficult to remember who sent the correspondence.
Why not make the header of the correspondence sticky, then? Here you go: https://dracos.co.uk/temp/2023-07-12-wdtk/ (would go well with numbers too, but I won't push that again :) )
CSS change I made for that page:
/* Make the correspondence headers sticky */
.correspondence__header {
position: sticky; top: 0; }
/* Move the colour indicator from the
correspondence so it stays visible */
.outgoing.correspondence {
border-top: none; }
.outgoing .correspondence__header {
border-top: 8px solid #f4a140; }
.incoming.correspondence {
border-top: none; }
.incoming .correspondence__header {
border-top: 8px solid #a94ca6; }
When scrolling long request threads it can be hard to spot where messages end and begin