Set up VPN page breaks navigation pattern

[Nekhelesh Ramananthan]

Every page that I have come across in Ubuntu Touch apps, use a back header button to exit the page. The "Set up VPN" places the "Cancel" and "Ok" buttons at the bottom of the page which makes it confusing and undiscoverable for a user. To compound the issue, if the user panics and just closes the system settings app at that point, a VPN connection is still created (bug 1558530).

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Jean-Baptiste Lallement (jibel)]

Thanks for your report. confirmed with krillin rc-proposed 286

[Matthew Paul Thomas (mpt)]

Thanks for reporting this, Nekhelesh.

Most settings in System Settings are in pages, because they are “instant-apply”. Individual controls are usefully changeable by themselves, and seeing/hearing each change instantly makes it easier to understand (and to correct or undo if necessary).

But some things involve a group of values or settings, that makes most sense when it is validated or acted on all at once. Entering VPN details is one of these things (as suggested by bug 1558530): a partly-complete setup is more confusing than useful. Other examples are printing a document, changing a SIM PIN, entering an APN config, registering a fingerprint, or creating a user account.

Therefore, all those things should be done in dialogs, that you can not just back out of — you have to cancel or commit the information entered.

So, “Set Up VPN” is supposed to be a dialog, with “Cancel” and “OK” buttons. <https://wiki.ubuntu.com/Networking#Setting_up_a_VPN_manually> You could say this “breaks [the] navigation pattern”, but it’s worth it. We can’t use instant-apply everywhere, but it’s so darn useful when we do have it, that it’s worthwhile having an inconsistency between instant-apply pages for ~95% of settings and commit-to-apply dialogs for the other ~5%.

Now, the design for dialogs is that, just like any other screen, the body area should scroll when the screen is not big enough. In a page, while the body area scrolls, the header should not scroll. Similarly in a dialog, while the body area scrolls, the title *and* the button area should not scroll.

Unfortunately, the toolkit developers have not yet implemented that last part. Until they do, individual apps that have even slightly-complex dialogs need to implement this layout themselves.

I think the discoverability problem here is 80% that the buttons are not always visible, and 20% that the visual design for this pseudo-dialog does not look different enough from a page. It may not be worthwhile fine-tuning the visual design until toolkit dialogs have visual design finalized, so … I would consider this bug fixed if the buttons were made always visible.

[Andrea Bernabei (faenil)]

@Jonas: the current implementation pushes a page on the stack (but without a back button) and doesn't seem to solve any of the issues Matthew pointed out. Is there any other reason why you didn't go for a dialog instead? (which would be the correct component, based on Matthew's comment)

[Bill Filler (bfiller)]

we attempted to use the dialog and it had many usability issues:
1) width of dialog smaller than the available screen real estate made typing in entry fields (i.e. Server field) difficult and typically having to scroll when entering a common servername
2) scrolling within the dialog not discoverable - while scrolling the view in the dialog is functioning it was not intuitive . Also became more dificult to use when the osk was on top of the dialog
3) the ok/cancel buttons were at the bottom and not fixed in a visble area

For those reasons we decided to use a page, If we move the "Cancel" to an "x" button on the header, and move the "Apply" button to a "Apply" button on the header, then it will be consistent with the page stack and still acheive what mpt describes, would still be commit to apply.

[Andrea Bernabei (faenil)]

@Bill: thanks for the info :)

1) yeah, well, this is the nature of a dialog, isn't it...not sure if it warrants an exception :/

2) indeed, but how is it different from the page?

3) same with the page

Sure, you can move the actions to the header, I think this is more of a design decision though (as it needs to be consistent with the patterns the platform already uses)? Matthew?

[Andrea Bernabei (faenil)]

regarding 1), I think it would make more sense to tweak visuals/UX of Dialog to be more comfortable to use on narrow screens, more than putting something that (according to the designer) belongs to a dialog outside of a dialog :)

[Selene ToyKeeper (toykeeper)]

I tested the fix and it does not appear to make the UI any more consistent compared to the rest of the system-settings app.

For example, look at the UI to add a new APN. Instead of "cancel" and "ok" at the bottom, it has a back button and a checkmark in the header.

[Selene ToyKeeper (toykeeper)]

I personally don't care which style is used, but at the moment it's still not consistent. Here are the VPN and APN config screens.

[Matthew Paul Thomas (mpt)]

The problem there is with the APN setup screen, not the VPN setup screen. The APN screen is laid out as a page stack page, which makes it non-obvious what happens if you make changes then exit the page. Just like the VPN setup screen, it is supposed to be a dialog, with no header at all, but a title at the top and buttons at the bottom. <https://wiki.ubuntu.com/Networking#apn-setup>

[Pat McGowan (pat-mcgowan)]

Opened bug #1579079