Show disabled Back button when screen has invalid input RRS feed

  • General discussion

  • The NavigationBackButtonNormalStyle hides the Back button whenever it's disabled.  I'm considering disabling the Back button until the user corrects invalid input.  If the back button is hidden, then I think that the user will be confused.

    Am I breaking some "best practice" by showing a disabled back button?  Should I instead enable the Back button then popup an error message if the user clicks it before fixing her invalid input?

    Saturday, March 28, 2015 8:13 PM

All replies

  • I don't think you'd break any rules showing a disabled back button, but I don't think it would be good UI. Typically, in Windows apps you don't show UI unless it's currently active, though this is gradually changing.

    I think a popup error message will work just fine.

    I'm a self-taught noob amateur. Please take this into account when responding to my posts or when taking advice from me.

    Sunday, March 29, 2015 1:52 PM
  • Actually, I have come across a "best practice" from Microsoft for Windows Store apps that says not to show disabled buttons on the main app canvas.  And since NavigationBackButtonNormalStyle hides the Back button whenever it's disabled, I'll probably just let it be hidden when there are unresolved issues with user input.

    I'm still conflicted, though, since this may confuse users.  At the same time, I think it's misleading to let a user click a button just to tell them, "No, actually you can't click that yet."

    I hope to get more opinions chiming in here.

    Monday, March 30, 2015 10:40 PM
  • I would say stick with the convention unless you have a very good reason for going against it.

    If you're sitting on the fence err on the side of best practice.

    Is there a scenario in which the user would want to back out of this page without completing the input (e.g. cancel)? If so you should let the user back out. Maybe show on warning on the page ('incomplete!') until the input is finished, and/or show a similar message on the previous page that remains there if the user cancels before finishing.

    As a user there is nothing worse than an app forcing you to do something even if it really does need to be done. Let me cancel if I want, and remind me that I will need to go back and enter that data to use the app.

    I'm a self-taught noob amateur. Please take this into account when responding to my posts or when taking advice from me.

    Tuesday, March 31, 2015 4:00 AM
  • Hi pumpkinszwan, thanks for your interest in my question.

    By "convention", I guess you mean letting the user click the button even when there's invalid input.  I agree that's the convention, since most webpages do it that way.  I won't fully follow the web convention, however, since I show input errors even before the user first clicks the button (it's one point I won't compromise on).

    I'd love to "err on the side of best practice" if Microsoft would indicate what that is. Maybe they don't know either, which would explain their silence on this thread.

    Regarding the user having an option to cancel, that's a good point and it crossed my mind too.  I'm planning to have a "Cancel Order" button on the app bar to facilitate such a scenario.  The option will not always be available but, when it is, clicking it will delete the order from the database and local memory.  As for letting the user "back out" of the page while there's still invalid input and expecting they'll come back later to fix it -- that won't work well in my app's usage scenarios.  The data really does need to be correctly entered at the beginning.  But thanks for brainstorming with me.

    Tuesday, March 31, 2015 5:51 PM
  • Locking users into the page will be confusing and frustration.

    If the entries aren't valid then remember them but let the user back out of the page without committing the data. You say your usage pattern won't allow for this, but it needs to. There are other ways out of the page that the app needs to be able to handle gracefully. If you don't commit the entry until it's in a valid state then there shouldn't be any problems with database inconsistencies.

    As bad as removing the back button will be, popping up an error message is worse. Put messages inline so the invalid fields are obvious. See Choosing the right UI surfaces: Errors.

    You can find guidelines and design principles on http://design.windows.com

    Saturday, April 11, 2015 1:54 AM
  • Thanks for your reply, Rob.  I wish it came sooner, although I think it has issues anyway.  I've already implemented a Back button that stays enabled/visible and shows an error flyout if clicked with invalid input on the page.

    As for your recommendation to allow the user to go back even with invalid input on the page, it won't work in some cases:

    1. If an inline error is scrolled out of view, then the user may click the Back button without even knowing there are still issues on the page.
    2. My Order Details screen allows the ability to edit its set of parent objects. An empty parents list is invalid.  If the user is allowed to go back to the parent screen in that case, then the order would thereafter be inaccessible from the parent screen.

    As a second "better than bad, worse than good" recommendation, you say that hiding the back button is better than popping up an error message.  I haven't yet solicited enough user feedback to decide whether or not I agree with this preference.  In the meantime, implementing that advice would be the more difficult route, since the validation errors would have to reactively "bubble up" the tree of domain objects to inform the button command of its CanExecute status.  Thus, I'll stick with my current popup solution until I have a compelling reason to instead hide the Back button.

    Saturday, April 11, 2015 4:40 AM
  • How do you handle those cases if the user switches away from the app?

    Saturday, April 11, 2015 5:52 AM
  • I haven't yet dealt with application suspend and resume, although I don't foresee major issues.  In general, when the user switches back to the app (within a reasonable amount of time), everything should appear the same as when she switched away from it, right?  This includes invalid input and inline validation errors, which should appear the same as before switching away.  As for the Back button's flyout, that only reappears if the user again tries clicking the button with invalid input still on the page.
    Saturday, April 11, 2015 5:37 PM
  • I've already mentioned two cases where your advice to allow the user to back out of a page with invalid data won't work.  I thought about it some more, and realize it won't work in the first case that came to my mind either.

    Sometimes the user needs to input a piece of data at a particular moment for a business process to work correctly.  For example, when an employee is taking a customer's order over the telephone, the employee must collect some information that identifies the customer.  If the employee doesn't, then fulfilling the order will be problematic since there's no record of who that order is for.  Once the employee and customer hang up the phone, the opportunity to collect that data is lost.

    Wednesday, April 15, 2015 9:08 PM
  • This may be a dumb answer, but this thread is interesting...

    What about changing the back button to a 'Cancel incomplete order' button? And make it red?

    Or some kind of notification that the data is incomplete until all the data is filled.

    I think the problem is more of a human one than a development one...people are going to find ways of breaking your design (as Rob said, anyone can simply close the app with no warning or pull the power cable out of their computer).

    Visit http://blog.grogansoft.com/ for Windows development fun.

    Thursday, April 16, 2015 1:08 AM