Redesign make new request process

[TomSteinberg]

• Select authority
  • Split select authority in to discrete pages (Split select_authority into discrete pages #1663)
  • Move "Browse all or add a new one" to right column ([#1663] split select authority page #1921)
  • Reword to "find authority" (TBC)
  • Update URL to /find_authority (TBC)
  • Minor text changes
  • Add a "Make request" button to each body in search results to skip "Show authority" page (Add make request button to search results #2114)
• Show authority
  • Add logic to decide if we've just come from a search (Add logic to show authority page to decide if we've just come from a search #2051)
  • Improve request listing section
  • Re-add Follow/Other Info to wireframe
  • Re-add search & filters to wireframe
  • Improve search and filter design
  • Split some components into partials (Code changes required for Authority page redesign #2032)
• Make a request
  • Improve typeahead search (Changes to typeahead search on new request page #1666)
  • Minor layout tweaks
  • Minor rewording
• Preview your request
  • Minor layout tweaks
  • Minor rewording
• Sign in/Sign up (Design change to sign in/sign up screen #1680)
• Check your email
• Final Screen (Changes to final screen once a new request is complete #1682)
• Update WDTK theme? (Align new request button, subscribe/unsub button and follower count. whatdotheyknow-theme#183)

---

Mammoth PR covering various areas: #1681

---

Deployment Tasks:

• Check translations to see if we can reuse (Check the translations of new request process #2050)

[wrightmartin]

Flow diagram breaking down the process of making a new request: https://docs.google.com/document/d/1ovHGXu2E9Ay1-ozQ_4-BL9pM1juBfae5QmT8GLc6JOs/edit

[garethrees]

For reference:

[wrightmartin]

Here's a new wireframe, based on the above process, related tickets and observations from the user testing. It's not drastically different, but simplifies a couple of the pain points. The biggest change is the removal of the AJAX 'Find an authority' process that put the authorities on the right of the search screen, instead it's a more simple separate page.

http://firefly.ukcod.org.uk/~martin/alaveteli-wireframes.pdf

[garethrees]

Looks really good.

A few comments on the duplicate request page:

• A) +1 on the close button. Would the internal scrollbar interfere with the main window scroll? I wonder if there's a better way of doing this?
• B) The wording/meaning of 'Or search their website for this information' is quite confusing (Reword "Or search in their website for this information" #1503). Once clicked it takes a while to orient yourself with the fact you're doing a Google site search.

[garethrees]

We should probably consider the "request made" page in the context of making a conversion as part of this design exercise. Is there anything we can do to help users stick around?

[wrightmartin]

@garethrees as I read that I realised I'd completely missed the final off these wireframes. I'll do it now.

on your other points:

a) yes, probably, I floated it as a compromise for having a limited list of other requests, happy to drop it for a low, hard limit.
b) Ah, I misread the ticket, thought the problem was the wording. If we had a usage figure for that link this would be an easier decision I'm sure (cut it!)

[garethrees]

a) yes, probably, I floated it as a compromise for having a limited list of other requests, happy to drop it for a low, hard limit.

Could have a 'Load More' link which replaces the existing with new results, but then we'd probably have to think about having a 'Previous results` link. Really we should track how many people actually click on those results to see if they're worth having at all.

b) Ah, I misread the ticket, thought the problem was the wording. If we had a usage figure for that link this would be an easier decision I'm sure (cut it!)

IMO it's both the wording and what happens when you actually click it. I don't have a good suggestion of how to make it better though.

[wrightmartin]

We need to determine which is more likely, that either a) the user is submitting a request because they've searched for the info elsewhere or b) they're submitting an FOI request because it's more convenient than Googling for information.

[wrightmartin]

Now I've seen it written down I think b) is really unlikely

[garethrees]

Now I've seen it written down I think b) is really unlikely

This might be something the Alaveteli research could look in to @paullenz?

[wrightmartin]

I've updated the pdf with the final screen http://firefly.ukcod.org.uk/~martin/alaveteli-wireframes.pdf

[garethrees]

I've updated the pdf with the final screen

At the moment we take people to the actual request page at the end of the transaction, which I think is a good idea so that they can see how it will look and bookmark it etc.

[wrightmartin]

At the moment we take people to the actual request page at the end of the transaction, which I think is a good idea so that they can see how it will look and bookmark it etc

Updated again - it would be cool to have the content above it when you see it this time.

[garethrees]

Updated again - it would be cool to have the content above it when you see it this time.

+1, I think its a good space to prompt users to stay engaged.

[TomSteinberg]

@wrightmartin Please note that on the very last page of the request making process - the completion page - it would be sensible to offer users the chance to share their new request, as per https://docs.google.com/document/d/1PF5refZ033Enh-cgw_x-yWacHZNUUxOeLPIdU674u60/edit#

[wrightmartin]

@TomSteinberg it is there, but it's not pushing it much, 'Tell people about your request' under 'what next?'. I'll make it more prominent

[wrightmartin]

I've updated the document with better sharing on the final screen
http://firefly.ukcod.org.uk/~martin/alaveteli-wireframes.pdf

[wrightmartin]

To build the search back in we could either use the space to the right of the requests listings, or compact it in to a nice panel:

I've been thinking about this one and I'm not sure - in wanting to make sure they've got the right authority are we in danger of putting too many tempting drop-off points? Will people second guess themselves out of making a request at all?

[garethrees]

I've been thinking about this one and I'm not sure - in wanting to make sure they've got the right authority are we in danger of putting too many tempting drop-off points? Will people second guess themselves out of making a request at all?

My gut feeling is no. The filter keeps them on the same page, and its good that they don't submit repeat requests which have already been answered.

I think we should commit to testing this though:

1. Update the page with the improved design, retaining existing functionality
2. Figure out how to A/B test different UI components on the same page (also see Make plan for A/B testing new WDTK design #1244)
3. Either create a new template or hide components of this template and test which gets better results

It would be great if we could monitor the levels of duplicate requests too, but I have a feeling that could be difficult.

EDIT: We should make a new ticket for parts 2 and 3 if everyone agrees its the way we want to go.

[wrightmartin]

Here's a tweaked version of this wireframe with feedback applied

[garethrees]

@wrightmartin cheers. Doesn't look like it "Re-add Follow/Other Info to wireframe" (see the checklist at the top of this thread). It also lacks the filter options (all requests | successful requests | unsuccessful requests | unresolved requests).

[garethrees]

Here's a URL to the page today https://www.whatdotheyknow.com/body/south_lanarkshire_council

[wrightmartin]

Ah thanks gareth, got hung up on the search and forgot the rest.

[wrightmartin]

Here it is with the missing bits.

In this version I've mostly removed the 'other matches' bit and replaced it with a simple back link. I think I was overthinking that somewhat, and adding clutter to an already busy page.

[wrightmartin]

Here's the write request screen, reworked slightly to address #1526 (comment)

[zarino]

Regarding sharing: it's worth pointing out that my recent introduction of three "next steps" to the FixMyStreet design, used dead simple sharing links for Twitter and Facebook…

<a href="https://twitter.com/intent/tweet?text=[% twitter_comment | uri %]&amp;url=[% share_url | uri %]&amp;related=fixmystreet,mysociety">
  <img src="/cobrands/fixmystreet/images/next-step-twitter.png" alt="Tweet it" width="120" height="37">
</a>
<a href="https://www.facebook.com/sharer/sharer.php?u=[% share_url | uri %]">
  <img src="/cobrands/fixmystreet/images/next-step-facebook.png" alt="Share on Facebook" width="120" height="37">
</a>

No javascript, no iframes. Simples.

[wrightmartin]

Thanks @zarino - very helpful

[garethrees]

[11:28:50]  <gareth>     hmm, I prefer the original title actually ("ask for information")
[11:28:57]  <gareth>     but we can change that later
[11:29:15]  <Martin>     It was inconsistent I thought, all the way here we've called it request
[11:29:34]  <Martin>     You could use a subtitle or something, becuase, yea, ask for information is a bit nicer
[11:29:47]  <gareth>     Yeah. I like how "ask for information" is less technical