Adobe AIR Development

[peter9477]

Yikes! I had no idea that a modal dialog in one app would pop up in front of the system screen or even another active app.  (It does... just tested.)

There's a real usability flaw here, even assuming there's a good reason to do that in a given app, since the dialog gives no indication which app opened it!

Folks, if you do use a modal dialog (one where you call just show() without the "IowWindow.getAirWindow().group" parameter), keep this in mind, and consider indicating clearly in the title which app is showing it.  Consider also not using one!

Non-modal apps show only on top of your own stage, so they won't interfere.

While I'm on the topic, remember that dialogs in general are a very crude type of notification, and really I would never consider using one for any kind of "low battery" indication or similar things.  They're brutal to the user experience, and in almost any case where they're merely informational (and you don't really need the user's click to acknowledge things), you'll be far better off with just some little animation or whatever to draw the user's attention to a message somewhere, or an in-app popup that goes away on its own after a moment.

[noahnu]

A good feature to prevent unnecessary dialogs (since I'm sure some people will create unnecessary dialogs) would be for a 'toggle' in the settings menu for every application installed. The toggle would allow you to control whether or not deactivated apps can show dialogs.

If not that then - not sure if they have it already - there should be some function that can be called within an application to block any dialogs/notification from other applications. Imagine playing a game, you are about to beat it and set a world's record, an alert dialog then appears and ruins your day!

Otherwise I completely agree that dialogs diminish the GUI's appearance.

[UberschallSamsara]

Other platforms have exactly this sort of thing (API call for an app to block system messages that would detract from user experience) in their game-centric SDK's:

http://developer.palm.com/index.php?option=com_content&view=article&id=1948&Itemid=342

[noahnu]

I guess we will have to wait to see what RIM has to say about this feature. They might not like it because it gives a single app too much control over the system. Who knows.

[UberschallSamsara]

IMO a well designed app (e.g. immersive game) would be a good citizen by giving the option to block system messages to the user.  In the Palm example the developer could easily have a setting under the game's options to let the user control whether to have SMS'es blocked during gameplay or not.

[jtegen]

In terms of the battery notification, I slept on it and realized that "notification" does not have to equate to an alert dialog.  My apps have a little battery indicator that updates based on the battery events.  It goes orange < 40% and red < 10%.  This might be sufficient "notification".  I guess I could also add an audible alert when it gets really low.  The OS has a battery indicator and I assume "notifications" when it gets low.  Other than application state savings on very low battery, I personally dont think the individual applications should actively (via alert dialog) notify the user (passively OK).

In terms of other apps throwing up alerts when not active, another argument to use the client side alert system.  Modal alerts are still in the applications stage and will never bother other apps.  Additionally, alerts should be tied to user action and not displayed because of a non-user action (eg. lost internet connection, data saved, low battery, etc).  If everyone only places alerts on direct usser action, then we should not get into the case of other apps throwing up alerts.

[noahnu]

"My apps have a little battery indicator that updates based on the battery events."

Are our apps always running full screen? I imagined that there might be a notification toolbar at the top of the screen like the iOS devices. I guess it allows us more control of the UI to have the full screen.

[peter9477]

Our own apps, for now, always run full-screen.  You could experiment with making your app transparent (in the blackberry-tablet.xml file) and letting the system status bar show through, but I don't recommend it. :-)

I believe (this hasn't been confirmed) that there will be an LED near the front-facing camera, which will alert users that there are notifications to check.  

Whether they are alerted by an LED or not, they can at any time do a top-right or top-left swipe (50-pixel-wide region at either edge of the screen along the top bezel) and the app will be pulled down and they can see the system status bar.  Note that you can do this in what I call "peek mode", where you don't actually lift your finger off... just drag down, check status, and drag up again then release.  Quite elegant, really.  You can also do a normal swipe down in those regions, and the bar will stay visible after you release.

[jtegen]

Yes, all apps are full screen.  Once I get a PB, I know I will need to change things in my app to be more harmonious with the OS, but since we really dont know the acutual device and how it interacts with the apps and the user, there are probably a few things that I dont "need" in my apps.

[jffurlan]

John,

I defintely agree. I had thought about doing a battery event notification similar to your idea after you had mentioned, but thought against it when I realized the user just needs to give a small swipe from the top left or right corner to view the status bar. I know this isn't seamless for the user, but until I have my hands on a device and I can really get a feel for usability, I think I'll hold off on some experimentation.