Or zoom in and out in maps. It's odder to have the zoom in button disappear than having a consistent interface. Worth keeping in mind that these use cases are nearly all very rare on the services we make.
I think it depends on the context. We normally use 'Back' would to take the user to the 'page they were previously on' - ie not a specific page. Though there may be contexts where it could be closer to how 'back' is used on iOS - ie up one level.
In this case the user has started on 'Business overview', gone through a process to amend business details and at the end of this clicks to return to 'Business overview'. So in their mind they are very much returning to 'Business overview' rather than continuing to it.
If this green button is on a screen that confirms the amended business details, 'Continue' would be my preference. If it shows amendments that have not yet been confirmed, it would be 'Submit'. 'Back to business overview' doesn't seem a CTA; if the user would logically expect to return to business overview after confirming amendments, 'Continue' makes more sense. However, this is just one example and the query I received was more in general about use of capitals when referring to screen titles.
hm, good question on capitals, I'm not sure to be honest - We normally use sentence case throughout. So "Continue to business overview" or just "Business overview" - but this might be a question for a content person like Stephen Gill
I think it's sentence case. You either understand what we mean by 'Back to business overview' label or you don't - I don't think capping up 'Business' helps. If people don't understand what you mean, the answer is probably to change the label.
Has the "Before you start" been always tested below the 'Start" button? I can see this approach working well for rushers but isn't it a bit confusing to name it "before you start", if it's then placed after it?
Pietro Desiato Yes, it's arguably a little odd. Basically, the GOV.UK start page template places the 'Before you start' heading on the page automatically, in that position. The GOV.UK core product team were looking at improving the start page templates, but I'm not sure where they're up to with that.
If you need to focus your user's attention on to a single piece of content, without taking them to a new screen then modal dialog boxes may be an appropriate way to do that.
Another view is:
They offer considerable problems for some types of users, especially low skills/low confidence users who may be struggling to understand the basic layout and use of the ordinary screens and don't need to be confronted with another sort of dialog box.
Typically, we reach for modal dialog boxes because the page has become too complicated. Try simplifying and splitting up the underlying page first.
Before you even consider a modal dialog box, make sure that you have strong evidence that:
There is a real user need to have attention focused on a single piece of content AND
That need cannot be met by taking the user to a new page in the same flow that contains the crucial piece of content.
Stephen G[Reckon on when it might be a good idea to use a modal] -
A form is a conversation between the service and the user. Generally speaking, you don’t want to interrupt it.
But sometimes you may need to interrupt the conversation with a message from the system (as opposed to the service). For example, you might need to tell people that their session is about to time out.
Provided you can do it accessibly, a modal can be a good way of presenting this kind of ‘system’ message. You’re effectively saying “Sorry - before you continue, would you mind dealing with this thing?"
Make sure the modal dialog box is accessible
Caroline JIf you use a modal dialog box then you must make sure it is accessible by doing these things:
on open, keyboard focus must be taken to the start of the dialogue
whilst open, keyboard focus must be constrained within the dialogue
itmust be possible to close the dialogue via a close button and/or with the escape key
on close, keyboard focus must be returned to the original point on the page
It should be Yes / No, not yes / no. Labels for radio buttons, check boxes etc are treated as separate screen artifacts - not part of a continuous piece of text. So they use sentence case (much like a page title). Plus it looks weird.