mysociety / alaveteli

Provide a Freedom of Information request system for your jurisdiction
https://alaveteli.org
Other
389 stars 195 forks source link

Add clearer incoming/outgoing identifiers to correspondence headers #4504

Open wrightmartin opened 6 years ago

wrightmartin commented 6 years ago

When scrolling long request threads it can be hard to spot where messages end and begin

wrightmartin commented 6 years ago

Here's a couple of ideas for tweaks to this (compared to current):

stronger title bars copy

wrightmartin commented 6 years ago

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.

garethrees commented 6 years ago

There's a minor conflict between this and the expand/collapse icons https://github.com/mysociety/alaveteli/pull/4219

screen shot 2018-02-06 at 12 02 57

garethrees commented 6 years ago

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.

wrightmartin commented 6 years ago

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?

garethrees commented 6 years ago

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

garethrees commented 6 years ago

We could obviously number from 1 onwards per request, but I think that would get really confusing.

wrightmartin commented 6 years ago

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

screen shot 2018-02-06 at 16 00 44

garethrees commented 6 years ago

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.

garethrees commented 6 years ago

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

wrightmartin commented 6 years ago

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."

dracos commented 6 years ago

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 :)

garethrees commented 6 years ago

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.

wrightmartin commented 6 years ago

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.

www whatdotheyknow com_request_financial_support_agreed_with_as

garethrees commented 6 years ago

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.

wrightmartin commented 6 years ago

Have we ever shown a from: to: style message header like gmail does?

screen shot 2018-07-18 at 16 10 08

garethrees commented 6 years ago

Might be worth sketching how you think that could work in our context. I can't really visualise it.

wrightmartin commented 6 years ago

screen shot 2018-07-18 at 16 54 42

zarino commented 6 years ago

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?

wrightmartin commented 6 years ago

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?

mdeuk commented 6 years ago

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).

image

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!

zarino commented 6 years ago

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?

garethrees commented 6 years ago

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.

garethrees commented 1 year ago

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.

Screenshot 2023-07-12 at 17 21 58

The place where we might actually need a design intervention is down the side of a correspondence box.

Screenshot 2023-07-12 at 17 19 48
dracos commented 1 year ago

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; }
garethrees commented 1 year ago