New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error summary #46

Open
govuk-design-system opened this Issue Jan 12, 2018 · 24 comments

Comments

10 participants
@govuk-design-system
Copy link
Collaborator

govuk-design-system commented Jan 12, 2018

Use this issue to discuss this component in the GOV.UK Design System.

@stevenaproctor

This comment has been minimized.

Copy link
Collaborator

stevenaproctor commented Mar 16, 2018

It would be good to have a consistent heading in the summary.

"There is a problem" has tested well with users.

The "Optional description of the errors and how to correct them" does not add any value to the screen. It does not provide context or help describe what has gone wrong. The heading does the first and the error does the second.

@ignaciaorellana

This comment has been minimized.

Copy link
Contributor

ignaciaorellana commented Mar 19, 2018

Thanks @stevenaproctor The Working Group will be reviewing this change in the next review session (April) because of lack of time (already have 5 contributions to look at on the 22nd)

@fofr

This comment has been minimized.

Copy link

fofr commented Mar 27, 2018

We used this component as part of the publishing workflow alpha:

We tested it with 5 users and noted that none of them interacted with the red links in the error summary box. This didn't prevent them from reading the message and they were able to find and fix the errors.

This was also true when the error summary was shown on a document summary view, where the errors were in forms on a different page (where we considered the links to be most useful).

whitehall-prototype herokuapp com_new_document-tasks

cc @BlancaTortajada

@BlancaTortajada

This comment has been minimized.

Copy link

BlancaTortajada commented Mar 27, 2018

We haven't specifically used the "Optional description of the errors and how to correct them" text in our error summary box in the publishing workflow prototype, but whenever there was some guidance text between a heading and an interactive element on another page, the text tended to be overlooked almost every time.

@timpaul

This comment has been minimized.

Copy link
Contributor

timpaul commented Mar 27, 2018

Thanks both. The intension is that the links are primarily for the benefit of people using screen-readers and keyboards, as it gives them a quick way of jumping to the relevant errors, rather than having to navigate through the whole form.

However, I'm not aware that we've validated whether this approach works for these users or not. If you ever do some research with users of assistive tech then this would be something to look out for.

@stevenaproctor

This comment has been minimized.

Copy link
Collaborator

stevenaproctor commented Mar 28, 2018

@fofr
I think you still need to show the errors at the field level using #47. This will make it easier for them to find the errors on the form.

@BlancaTortajada
The "Optional description of the errors and how to correct them" never actually adds anything to the screen. I think we are looking at removing it from the pattern.

@BlancaTortajada

This comment has been minimized.

Copy link

BlancaTortajada commented Mar 28, 2018

@timpaul Thanks Tim! We'll let you know if we find anything about that in our upcoming missions.

@fofr

This comment has been minimized.

Copy link

fofr commented Mar 29, 2018

@stevenaproctor Yep, we do both. The screenshot is an example of a summary page without any of the fields. Clicking through to the sub-pages shows the relevant error and highlights the field.

@timpaul timpaul added the component label May 21, 2018

@adamsilver

This comment has been minimized.

Copy link
Collaborator

adamsilver commented Jul 2, 2018

Currently:

  • the error summary is 100% width. Should we give the component a max width?
  • when using the one thing per page pattern whereby the h1 is the label/legend, the error summary's h2 title comes before the h1. We don't want that, nor do we want two h1's. The question is, what do we want? :)
@nickcolley

This comment has been minimized.

Copy link
Contributor

nickcolley commented Jul 2, 2018

Should we give the component a max width?

I don't think so, all our components fill their parent containers. This consistency means we make no assumptions on the layouts these components will be used in. For example if someone decided to make their own grid layouts they might be forced to override this max-width.

In the most general case we'd want to use the grid layout classes, which will be consistent across our components (or we've talked about having a 'measure' layout wrapper too)

@adamsilver

This comment has been minimized.

Copy link
Collaborator

adamsilver commented Jul 2, 2018

@stevenaproctor

This comment has been minimized.

Copy link
Collaborator

stevenaproctor commented Jul 3, 2018

In elements, the error summary was inside a div with a column-two-thirds class. Would it be a good idea to put the examples here inside a div with a govuk-grid-column-two-thirds class?

@adamsilver

This comment has been minimized.

Copy link
Collaborator

adamsilver commented Jul 3, 2018

Yep, so I spoke with Nick about this before. The two-thirds grid acts a little differently to a max-width.

The grid 2/3 means it's always two thirds (except for mobile). But that means it's unnecessarily small (unless at full width).

The measure (max width) version, would mean it's 100% until it hits X pixels. This is the behaviour I want on quite a lot of components.

For me, grid, should only be used when you want things to be next to each other.

@stevenaproctor

This comment has been minimized.

Copy link
Collaborator

stevenaproctor commented Jul 3, 2018

Do you have any screenshots for how it would look? For me, the 2/3 grid acts like a measure. When content is outside the measure it can make a screen look disjointed. What do you think?

@adamsilver

This comment has been minimized.

Copy link
Collaborator

adamsilver commented Jul 3, 2018

Note: the width of my prototype is wider than normal.

Using grid (full width viewport)

This is basically fine.

image

Using grid (half width viewport)

Here the error summary is unnecessarily narrow.
Using a max-width approach instead, would make the error summary full width under this scenario.

image

@stevenaproctor

This comment has been minimized.

Copy link
Collaborator

stevenaproctor commented Jul 3, 2018

So the error summary would be as it appears in the first screenshot but the decision notes box would be like the second?

@adamsilver

This comment has been minimized.

Copy link
Collaborator

adamsilver commented Jul 3, 2018

Well, that's another thing. I'd say this max-width thing should be put on the <form> (or similar) too.

Basically, for pages that are single column (that's probably the majority) don't need to use a grid—just need the max-width applied for certain elements.

For other things, such as tables with lots of columns, I'd let them go full width (max width 100%)—so wouldn't need a max width there at all.

@stevenaproctor

This comment has been minimized.

Copy link
Collaborator

stevenaproctor commented Jul 3, 2018

I am not a frontend developer so I am not sure the best solution from a CSS point of view. The grid makes sense to me as a container for the content of the page and means I do not need to put a class on every element to control its width. It is a guaranteed way to make sure no line of content is more than 75 characters.

I worked on a service that had full width tables and 2/3 width content. It did not make the screen less usable but it looked disjointed. Because I know this can cause problems for some people I always try to keep content in the 2/3 grid. If a table has lots of columns and does not, it may be better as more than one table especially for people using a mobile.

the error summary is 100% width. Should we give the component a max width?

I do not think it is. Because the examples are snippets, there is no grid. If you look at the examples from elements that show the errors in context, the error summary is in the grid. http://govuk-elements.herokuapp.com/errors/

when using the one thing per page pattern whereby the h1 is the label/legend, the error summary's h2 title comes before the h1. We don't want that, nor do we want two h1's. The question is, what do we want? :)

We used to use 2 h1s but that was changed to a h2 above the h1. You can see the pull request and discussion at alphagov/govuk_elements#510

@adamsilver

This comment has been minimized.

Copy link
Collaborator

adamsilver commented Jul 3, 2018

Hey Steven, reading back I don't think I was very clear.

I think the page should conform to a grid, but I don't think a single column page (like the one I showed above) needs to use the grid classes.

If we were to have say a .govuk-measure-x class then perhaps I'd suggest the max width value would match the 66% (2/3 grid) class used for grids.

That said, I suspect it's not that simple, because a 66-33 grid isn't the only combination. We can use 50-50 etc.

Also, I'd say the max width of the error summary should be the same across all screens, even if it sits above some pages with single column, some with 66-33 and others with 50-50.

Is that a bit clearer?

(Thanks for the note about the h1/h2 thing.)

@jonathaninch

This comment has been minimized.

Copy link

jonathaninch commented Jul 10, 2018

What would be good practice for an error summary involving a radio button?

For example, if we ask the user "Is this the registered name of your business?" (and show a business name pulled from the backend) and they have a Yes / No radio button option I would have an error message something like "Select if this is the registered name of your business" but I'd struggle a bit with the error summary.

"Select an option" - too generic for an error message (but acceptable for a summary?)
"Select if this is the registered name of your business" - same as the message (or is this acceptable?)
"Indicate if this is your business name" - using fofr's example above?

Radio buttons seem a bit tricky when it's potentially just Yes / No.

@stevenaproctor

This comment has been minimized.

Copy link
Collaborator

stevenaproctor commented Jul 10, 2018

@jonathaninch For your example, I would say 'Select yes if this is the name of your business'. But I would consider adding the name of the business into the H1 and then saying 'Select yes if [name] is the name of your business'.

The guidance in the Design System says "show the same error messages next to the inputs with errors". There is more information about this on the error message guidance. See https://design-system.service.gov.uk/components/error-message/#be-consistent

@jonathaninch

This comment has been minimized.

Copy link

jonathaninch commented Jul 10, 2018

@stevenaproctor Cheers Steven - that guidance managed to go down the plughole in my brain today, so thanks for pointing it out.

@stevenaproctor

This comment has been minimized.

Copy link
Collaborator

stevenaproctor commented Aug 7, 2018

The error summary border is 4px. The error message left border is 5px. Should these both be 4px or 5px?

@joelanman

This comment has been minimized.

Copy link
Member

joelanman commented Aug 7, 2018

Hi @stevenaproctor just checked the code - I think that would only happen on mobile, which still seems like it might be a bug

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment