Develop prototype design for standard request pages

[TomSteinberg]

Dependent on delivering #1015

[Jedidiah]

Wireframes for request page:

[crowbot]

Questions/comments specifically relating to the non-design work that elements of the design imply:

• Does 'email alerts' in the top nav imply a new general page that describes the kind of alerts you can sign up to? Or does it link to some existing page on the site?
• Does 'share' imply a new page/widget for sharing on social media?
• Where does "If you have been affected by the issues in this thread" go? It seems a bit out of place.

More general comments:

• I like the positioning of the "want to know what happens next?" button at the bottom of the thread
• I like the handling of attachments - much more like a regular email client - presumably the link at the top of each email saying how many attachments there are goes to the attachments themselves at the bottom of the mail?
• Wording changes now may imply that the new design won't be usable by international Alaveteli sites until they translate the new versions of the wording - we could mitigate this using their translations of the old wording in some cases, but this is just something to be aware of - we should be fairly confident that any change to existing text is worth the cost.
• It seems like the user testing has shown that moving away from "follow" is a change that's worth the cost as it baffled people, but I think "Get updates on this request" is clearer than "Get updates" (assuming that this is the specific link for this request)
• It may not have been the requester who marked the request as successful - it goes into some states in response to an event - e.g. initially requests have the state 'waiting_response' without anyone marking them as such. Also, after an interval, other people can set the state of an unclassified request, or admins might do it at any point.
• There will be a modest cost in development time and page render time for each extra piece of information that has been added to the "user" and "public body" panels to the right hand side of this request page - given that the username and public body names can be links, and that "more info about the user" is only on the medium priority list for this page, and "more info about the body" isn't anywhere in the list, I would suggest we drop these boxes in favour of emphasising the really important things.
• 'Report as offensive' applies to the whole request, not to individual bits of correspondence and has been the source of largely erroneous support mail (see discussion on https://github.com/mysociety/alaveteli/issues/517) - I suggest we have one link on the page, de-emphasised.
• Similarly, annotations are added to the end of the current request thread, so unless we change that, I think the annotation buttons per bit of correspondence incorrectly raise the expectation that your annotation is going to appear under that bit of correspondence.
• We've lost the "do you own commercial copyright to anything on this page", which is annotated in the codebase with the following comment: "this link with this wording is here for legal reasons, discuss with board and our lawyer before changing or removing it" <- do we need to have that discussion?

[Jedidiah]

Thanks for the feedback Louise,

Non-design work:

• Does 'email alerts' in the top nav imply a new general page that describes the kind of alerts you can sign up to? Or does it link to some existing page on the site?
• Does 'share' imply a new page/widget for sharing on social media?

I was thinking that these would appear in a modal window showing the various options, so it would still be on the same page. I should add another mockup showing how it would look.

• Where does "If you have been affected by the issues in this thread" go? It seems a bit out of place.

I can't remember exactly what the thinking was on this one. We added it on Monday. I think it was maybe a replacement for the related questions, would have to check with @TomSteinberg

[Jedidiah]

• I like the positioning of the "want to know what happens next?" button at the bottom of the thread
• I like the handling of attachments - much more like a regular email client - presumably the link at the top of each email saying how many attachments there are goes to the attachments themselves at the bottom of the mail?

Yes, I was imagining it would just scroll you to the attachments

• Wording changes now may imply that the new design won't be usable by international Alaveteli sites until they translate the new versions of the wording - we could mitigate this using their translations of the old wording in some cases, but this is just something to be aware of - we should be fairly confident that any change to existing text is worth the cost.
• It seems like the user testing has shown that moving away from "follow" is a change that's worth the cost as it baffled people, but I think "Get updates on this request" is clearer than "Get updates" (assuming that this is the specific link for this request)
• It may not have been the requester who marked the request as successful - it goes into some states in response to an event - e.g. initially requests have the state 'waiting_response' without anyone marking them as such. Also, after an interval, other people can set the state of an unclassified request, or admins might do it at any point.

I'll remove the line about who set it and just have the status badge.

• There will be a modest cost in development time and page render time for each extra piece of information that has been added to the "user" and "public body" panels to the right hand side of this request page - given that the username and public body names can be links, and that "more info about the user" is only on the medium priority list for this page, and "more info about the body" isn't anywhere in the list, I would suggest we drop these boxes in favour of emphasising the really important things.

I've been thinking along similar lines after looking at the simplicity of the mobile layout, though I was thinking about dropping them to the bottom rather than removing completely.

• 'Report as offensive' applies to the whole request, not to individual bits of correspondence and has been the source of largely erroneous support mail (see discussion on #517) - I suggest we have one link on the page, de-emphasised.

Ok, I'll look at options for this, should I also mockup the page with the dropdown reasons mentioned in #517?

• Similarly, annotations are added to the end of the current request thread, so unless we change that, I think the annotation buttons per bit of correspondence incorrectly raise the expectation that your annotation is going to appear under that bit of correspondence.

I'll revise the mockup, though personally I'd have that expectation of being able to comment on a specific point just from the title annotate.

• We've lost the "do you own commercial copyright to anything on this page", which is annotated in the codebase with the following comment: "this link with this wording is here for legal reasons, discuss with board and our lawyer before changing or removing it" <- do we need to have that discussion?

No I think we should add that back in, I don't think it made it to the diagrams.

[crowbot]

Thanks Jed. Personally, I'd like to see a version of the design without the user and public body panels. No need to do any specific design work around #517 - the page with dropdowns is already live on the site, so should just be included in whatever general style changes we make.

[Jedidiah]

Here is a single col layout with some of the other points addressed, bar is fixed to the bottom of the screen and the "What is going on with this page" is only shown for new visitors.

[crowbot]

I think 'report as offensive' and 'view event history' are pretty low usage/low importance links - perhaps they should be at the bottom with the commercial copyright notice, not in the bar, which suggests things you might want to do quite a lot.

[Jedidiah]

Yes, I'm just worried about the bottom becoming a bit of a dumping ground. I'll have another go.

[Jedidiah]

I've moved bits round, the "Event History" is under the status as that seemed to make sense. "Download Zip" is under the thread and "Report Offensive" is with the copyright note.

I think this works a lot better.

[Jedidiah]

Added mockup based from this wireframe to #1016

[Jedidiah]

Moved these from the mockup ticket as they are roughs not mockups

Alt. Header Roughs

Kaleidoscopic Logo roughs

[crowbot]

So following on from the discussion on #1016, I think

• Having the event history under the status makes a lot of sense
• Can we have 'view' and 'download' options for each attachment a la gmail, rather than the "download all attachments"
• I'm happy to combine the commercial copyright link into the general reporting link if we run it by our lawyer (ticketed as #1050)

[crowbot]

I've created a separate ticket for header, footer and logo designs at #1052

[crowbot]

Latest design for standard request page

[crowbot]

OK, so I think for me, the steps to signing this off as the view for a non-request owner are:

• [x] Close #1052 and update this mockup with the signed-off header, footer and logo
• [x] Remove "Download all attachments" and have a 'view' and 'download' link for each attachment
• [x] Move "Download zip of all correspondence" to underneath the "event history" link
• [x] Change the colour of the success label so that it isn't the same as button colour - a different green would be fine, but the green for buttons is quite subtle, so I think we probably don't want to use it anywhere else - it should always mean "click me"
• [x] Just one link for 'report something offensive", no separate commercial copyright link.
• [ ] Add a visual indication of the RSS feed somewhere (I'm open to persuasion that this should live somewhere else, but I think we need a plan). Maybe under the event history link too?
• [x] A link to similar requests

[Jedidiah]

[Jedidiah]

Add a visual indication of the RSS feed somewhere (I'm open to persuasion that this should live somewhere else, but I think we need a plan). Maybe under the event history link too?

I think our original plan was that this was under "Get Updates", I'll make a mockup for that and for share..

[Jedidiah]

[Jedidiah]

[Jedidiah]

Combining "Report Offensive" and "Report Copyright"

[crowbot]

So the remaining tasks here are:

• [ ] mockup of 'get updates'
• [x] mockup of how this page looks to a requester (both desktop and mobile) - only really need to see the bits that will be different
• [ ] mockup of how this page looks to someone from the authority - again, be good to see both mobile and desktop and only need to see the bits that are different if that's easier.

[Jedidiah]

Top of the page if you are the requestor. The Notifications button would also be like that if you are signed up for email notifications.

Corresponding button at the bottom of the page

[Jedidiah]

What do you think about repeating the status message with the options?

Do we need a explanatory sentence to go with the options? Edit: Corrected inconsistant date formatting

[crowbot]

The only reservation I have about the 'edit notifications' button for the request owner is that I don't think you can unsubscribe from notifications of your own requests. We could just drop the updates buttons for the requester. I think the follow up options look good, but we also need a design for what the requester sees when they opt to update the status of the request - current screenshot attached.

[Jedidiah]

Again forgive the missing font, I've bolded the same key words as the original

[Jedidiah]

[crowbot]

I like the partitioning of the 'update status' options, I think the background colour for the container should be the same as the general notice colour for the site so there's a consistent visual message that that colour means you have to do something. I do think we should retain the 'and we'll tell you what to do next' text after the submit status button though - this is quite a good motivation for users to update the status.

I'm not convinced about the 'get updates' popup - it's now going to take two clicks to get updates on a request rather than one, without adding all that much extra information. I'm still thinking that it could be better to have an unobtrusive feed icon somewhere on the page, and have the 'get updates' buttons immediately subscribe you to email alerts without further clicking (assuming you're logged in).

I like the sharing options

[crowbot]

OK, we've nixed the 'get updates' popup, and are keeping the "what to do next" text. I'll note the colour importance on the templating ticket, and I'm closing this in favour of that ticket - https://github.com/mysociety/whatdotheyknow-theme/issues/99