Toast :: No way to block UI interaction since beta9

[awe-sim]

Toast component no longer has the option to prevent UI interaction as "enableBackdropDismiss" option has been completely removed.

I was suggested by @jgw96 in this thread about an Alerts issue that a better UX would be to show a Toast on top of the first Alert. But since the Toast can no longer block UI interaction, it fails to achieve the objective in my case.

Short description of the problem:

1. An Alert with an input and two buttons 'OK' and 'Cancel' (with role 'cancel') are shown.
2. User enters an invalid value and taps 'OK', triggering the OK handler.
3. The handler detects invalid input and shows a Toast informing the user of the input problem (earlier, I was showing a second Alert on top of the first one).
4. The user accidentally taps on the page background, thinking that the Toast will be dismissed.
5. Instead, this causes the CANCEL handler for Alert to be triggered, dismissing the dialog, but leaving the Toast. If the Toast is not configured with duration or showCloseButton, there is no way for the user to close the Toast now.

What behavior are you expecting?

1. The user accidentally taps on the page background, thinking that the Toast will be dismissed.
2. The Toast should be dismissed, firing it onDismiss handler which allow the user to interact with the Alert dialog, correct her mistake and continue on.

Way forward

I will have to wait for the Alerts issue to be resolved as I cannot use Toasts in this setting. I understand that the enableBackdropDismiss option was removed due to Material Design Specs, but it could've been done like so:

• showBackdrop (boolean, default false) // shows backdrop, blocking UI interaction
• enableBackdropDismiss (boolean, default true) // if backdrop is showing, closes Toast when background is tapped.

Steps to reproduce:
Already listed above.

Which Ionic Version?
2.0.0-beta-9

Run ionic info from terminal/cmd prompt:
Cordova CLI: 6.1.1
Gulp version: CLI version 3.9.1
Gulp local: Local version 3.9.1
Ionic Framework Version: 2.0.0-beta.9-201606221959
Ionic CLI Version: 2.0.0-beta.31
Ionic App Lib Version: 2.0.0-beta.17
ios-deploy version: Not installed
ios-sim version: 5.0.8
OS: Mac OS X El Capitan
Node Version: v4.4.2
Xcode version: Xcode 7.3.1 Build version 7D1014

[trakhimenok]

Just an opinion, I believe the errors should be part of the form and be in-place either shown next to an input or before/after submit button. The Toast component does not seem to be a good fit for the validation use case.

I would treat the Toast more as a notification of completed actions or as a tool to display notifications from outside (or delayed).

I don't think the Toast should be changed to support this use case.

[awe-sim]

@astec .. my opinion is that a framework should give you options to do something, not restrict you from doing something.. i should be able to decide how i want my application to show errors, not the framework's.. the framework can provide an opinion (via defaults), but nothing should prevent me from overriding the defaults..

as an example, consider a scenario where i might want to use a toast to show an error notification when a server fetch fails.. the toast would show a message to the user.. i might not want to show a CLOSE button on the toast (a button represents a small target and slows down user experience).. and i might not want to want to use a duration to automatically dismiss the toast (i dont want to close the toast before the user has read and understood it completely, and i dont want to force the user to bear seeing the toast on his screen for 5 minutes).. in this case, i would prefer that the user be able to tap the background to dismiss the toast..

[trakhimenok]

I believe restrictions are good. Components should have limited scope, predictable behavior and preferably isolated environment.

I don't quite get it how the "background" should be linked to the Toast and if it should be at all (taking into account the tasks it is trying to perform). In my mind with this approach it gets unnecessary coupled with other components (like Alert) via shared background (for example if we have an Alert and 2 Toasts - which one should be dismissed?). It makes things over-complicated and source to potential bugs and confusions.

It may solve 1% of rare use cases but make life harder for some others (may be 10%).

And in your examples the OK button seems to be a good enough solution.

It's up to Ionic team to decide - I just wanted to raise a concern.

[jgw96]

Hello @awe-sim ! So this is actually by design. As the toast component is meant to be used as a notification (like the native toast for both ios and android) it is not meant to be blocking, so we removed the backdrop. I suggested the toast as it is a notification component, therefore you could show it to alert the user to an error. Because a toast on either native android or ios does not block user interaction, this actually made our toast different, and therefore confusing for users who are used to native applications. I completely understand your ideas about the framework being too opinionated in this aspect, but our goal is simply to act like a native application as much as possible and provide simple, focused components to achieve this easily. In the mobile world users are used to using apps a certain way, thats why their are design and interaction docs such as the Apple human interaction docs and the Google material design docs. There are certain behaviors that users expect, and when something is different it can cause a jarring experience for your users. On the other hand, the good thing about ionic 2 is that its just Angular 2 under the hood, so you can definitely create your own custom component that can have the exact behavior you want. I hope this explains everything well for you. Also, we are going to fix the alert issue, so you can always continue to use that if you desire! Thanks for using Ionic!

[awe-sim]

hello @jgw96 .. thank you so much for the detailed explanation.. i think i will wait for the alerts fix.. :)