Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Native Development

Reply
Developer
Posts: 1,178
Registered: ‎03-20-2013
My Device: Red LE Developer Z10
My Carrier: Fido

Application Menu disabled on Sheet?

I just got a response from the Built for BlackBerry (BFB) team telling me that only one thing is preventing me from achieving BFB status... on my settings pages I have a Help button on the action bar menu instead of on the application menu. I use a navigation pane for primary application flow, and I have the Help button on the application menu there, but as per BB10 UI guidelines I use a Sheet for the settings pages since it is out of the normal flow of the application. The problem is that the application menu seems to be disabled while viewing a sheet.

 

I could refactor the app to open settings by pushing the settings page rather than opening it on a sheet, but that violates the BB10 UI guidelines, not to mention my feel for how the app should work. Seems kind of dumb to me to recommend using Sheet for non-flow portions of the app, then require help to be placed on the application menu for BFB certification, when that doesn't work on a sheet.

 

Am I missing something here? Does anyone know how to place the Help button on the application menu when viewing a sheet?



Developer of Built for BlackBerry certified multiFEED RSS/Atom feed reader and aggregator.  multiFEED Icon

Play nice: Clicking Like Button on posts that helped you not only encourages others to continue sharing their experience, but also improves your own rating on this board. Also, don't forget to accept a post if it solves your problem or answers your question.
Developer
Posts: 6,152
Registered: ‎07-05-2012
My Device: Playbook, Dev Alpha C, Z10 LE, Z30
My Carrier: Orange

Re: Application Menu disabled on Sheet?

What exactly was the wording from the B4B tester?

 

Do you need a sheet for settings, why not just add a navigation page for whatever the settings does and then remove it on setting?

 

I think you've maybe read the guidelines too literally, clicking Help from the Applications menu *is* a natural flow in the app and therefore can be handled by a navigation page.


If you've been helped click on Like Button, if you've been saved buy the app. Smiley Happy

Developer of stokLocker, Sympatico and Super Sentences.
Developer
Posts: 1,178
Registered: ‎03-20-2013
My Device: Red LE Developer Z10
My Carrier: Fido

Re: Application Menu disabled on Sheet?

[ Edited ]

BBSJdev wrote:

What exactly was the wording from the B4B tester?

 

Do you need a sheet for settings, why not just add a navigation page for whatever the settings does and then remove it on setting?

 

I think you've maybe read the guidelines too literally, clicking Help from the Applications menu *is* a natural flow in the app and therefore can be handled by a navigation page.


And I think perhaps you didn't read my OP literally enough. I CLEARLY stated that the Help button for every page in my app EXCEPT the Settings pages IS on the application menu. Of course help is part of the normal flow of an application, which is why I not only put it on the application menu, but made it context-sensitive so the button takes you to a page that is appropriate for what you are doing at the time. The issue is that there are three levels of settings for my application, and configuring the app is most decidedly NOT part of the normal flow. In fact this BlackBerry DevBlog page from March 2013 makes it very clear that Sheet is the preferred and logical page type for Settings. It says:

 

  • Sheet – This should be used whenever there is a break in the user’s flow. That is, anything that takes the user away from their current action(s) and navigation flow; the Sheet slides in from the bottom. Typically, a sheet is presented for things such as sending emails, taking user credentials and of course, for application menu items such as Info, Help or Settings! This is typically the easiest way to implement action items on the application menu.

That exclamation after "Settings" is their's, not mine. Note that they also suggest using a Sheet for Help, but it makes more sense to me to push a help page onto a NavigationPane since it is useful to be able to "Peek" back at the page you launched help from. That is not true for Settings, when you launch Settings you are not "using" the application in the normal application flow sense.

 

I also clearly stated in my OP that I COULD convert the Settings page to be pushed onto the main NavigationPage stack instead, but that I really don't want to if there is another way to satisfy the tester's requirement. I'm not sure why you'd need to see the tester's actual wording since saying they told me I have to move help from an action bar to the application menu is not at all ambiguous, but here you go:

 

  • Please remove the “Help” tab from the action menu and place it in the application menu.


I'd thank you for your reply, but you completely failed to answer the real question from my OP... does anyone know how to get the application menu to display when a Sheet is on top?

 

So to reiterate... BFB testing wants me to move a Help button from the action bar to the application menu. I already do that EVERYWHERE in my application EXCEPT on the Settings pages, since when a Sheet is on top the application menu is disabled. The only place where I have Help buttons on action bars is on the Settings pages. I don't WANT to convert my Settings pages to regular pages and push them onto the NavigationPane if I can possibly help it, since a Sheet is the logical page type to use for Settings. Does anyone know if there is a way to get the application menu to display when a Sheet is on top?

 

Thanks.

 



Developer of Built for BlackBerry certified multiFEED RSS/Atom feed reader and aggregator.  multiFEED Icon

Play nice: Clicking Like Button on posts that helped you not only encourages others to continue sharing their experience, but also improves your own rating on this board. Also, don't forget to accept a post if it solves your problem or answers your question.
Developer
Posts: 6,152
Registered: ‎07-05-2012
My Device: Playbook, Dev Alpha C, Z10 LE, Z30
My Carrier: Orange

Re: Application Menu disabled on Sheet?

[ Edited ]

Lovely attitude. My intention was only to help so if you took any offence at anything I wrote then you've read too much in to my response.

 

So to answer your question no there is no way to get an Application menu while displaying a sheet.

 


If you've been helped click on Like Button, if you've been saved buy the app. Smiley Happy

Developer of stokLocker, Sympatico and Super Sentences.
Developer
Posts: 6,473
Registered: ‎12-08-2010
My Device: PlayBook, Z10
My Carrier: none

Re: Application Menu disabled on Sheet?

You should probably dispense with the idea that a Sheet is the only way this should be done. Yes, it's one interpretation of the UI Guidelines' advice on this, but not the only one, and in fact those same guidelines direct state the contrary in a different location.

 

On https://developer.blackberry.com/devzone/design/bb10/menus.html at the bottom you'll see in the Application Menu section this text: "For actions that open a new view (such as Settings and Help), slide the menu up and slide the new view in from the right. For actions that open a dialog box or toast, slide the menu up and then display the dialog box or toast."

 

Note that originally a Sheet slide up from the bottom and was a more obvious break in the flow. Even then, my interpretation of the purpose of Sheet was that it be used primarily for user data entry forms. I wrote my app so my Settings pages were actually on a Page that slide in from the right, and it feels fine from a "flow" point of view. Now that Sheets also slide in from the right, I'm not sure there's any reason to keep using them in this case at all. The "Back" button you'll get when using a Page feels natural to users, and won't represent a reduction in the quality of the user experience.

 

And... it will address the issue of getting that menu back for BFB certification. ;-)


Peter Hansen -- (BB10 and dev-related blog posts at http://peterhansen.ca.)
Author of White Noise and Battery Guru for BB10 and for PlayBook | Get more from your battery!
Developer
Posts: 1,178
Registered: ‎03-20-2013
My Device: Red LE Developer Z10
My Carrier: Fido

Re: Application Menu disabled on Sheet?

Thanks Peter. I'm beginning to think this is the way I'm going to have to go. BTW, I hadn't noticed that sheets were sliding in from the right now, is this a 10.2 thing?

 

I hear what you are saying about push/pop feeling natural to users, but in the case of a Settings page where you have to handle "Save/Cancel/Prompt if Modified" having two buttons to close a page, one of them being the "Back" button, it just doesn't feel right to me, even if you change the back button caption to "Cancel". I feel like both ways to leave a page should be adjacent on the action menu, but I guess that's just me and my 25 years of desktop development. 

 

 

I started this app back in March and I used the UI guidelines as they existed back then to guide my design, but I guess the BlackBerry powers-that-be have evolved their UI sensibilities since then. I have emailed the BFB testers to see if they will reconsider moving the help on the Settings page, but if not I guess my Settings pages will be pushed onto the NavigationPane stack.

 

Seems to me there really is no practical use for a Sheet anymore.


peter9477 wrote:

You should probably dispense with the idea that a Sheet is the only way this should be done. Yes, it's one interpretation of the UI Guidelines' advice on this, but not the only one, and in fact those same guidelines direct state the contrary in a different location.

 

On https://developer.blackberry.com/devzone/design/bb10/menus.html at the bottom you'll see in the Application Menu section this text: "For actions that open a new view (such as Settings and Help), slide the menu up and slide the new view in from the right. For actions that open a dialog box or toast, slide the menu up and then display the dialog box or toast."

 

Note that originally a Sheet slide up from the bottom and was a more obvious break in the flow. Even then, my interpretation of the purpose of Sheet was that it be used primarily for user data entry forms. I wrote my app so my Settings pages were actually on a Page that slide in from the right, and it feels fine from a "flow" point of view. Now that Sheets also slide in from the right, I'm not sure there's any reason to keep using them in this case at all. The "Back" button you'll get when using a Page feels natural to users, and won't represent a reduction in the quality of the user experience.

 

And... it will address the issue of getting that menu back for BFB certification. ;-)






Developer of Built for BlackBerry certified multiFEED RSS/Atom feed reader and aggregator.  multiFEED Icon

Play nice: Clicking Like Button on posts that helped you not only encourages others to continue sharing their experience, but also improves your own rating on this board. Also, don't forget to accept a post if it solves your problem or answers your question.
Developer
Posts: 6,473
Registered: ‎12-08-2010
My Device: PlayBook, Z10
My Carrier: none

Re: Application Menu disabled on Sheet?

The Sheet-slides-from-right change came mid-summer in one of the 10.1 updates, sort of slipped in without prior warning by BB.

I do agree that if you have a Save/Cancel thing going on with Settings, that using a Sheet (i.e. the pair of buttons at top instead of the Back button at bottom) is a pretty reasonable idea.

I took the approach of mirroring how I saw most system apps (including Settings) handle settings changes, which is to say that changes affect the app/system as soon as you make them. You get no chance to Cancel a set of changes.

For the most part in my app, settings are not so closely related that I feel the need use a "transactional" approach to handle them, so you go to Settings, change one or more things, manually revert any changes you feel like reverting, and click Back.

One big reason why I went with this approach was one thing I noticed in testing with a Sheet. With the Sheet, you can still "peek" back at the underlying page. If any of the settings on that Sheet might affect the appearance of anything on the underyling page, then making a change to a setting and peeking should reflect those changes immediately. Not doing so felt like a usability flaw.

In my specific case, one of my settings was a date format selection. The underlying page uses that format to change the appearance of data in a ListView. Once I noticed that using the Save/Cancel ("transactional") approach didn't update that ListView in realtime as you changed the setting, I tried it with a Page. The "feel" from the user point of view was much better, so I ditched the transactional approach and went with how all BB's own stuff seems to work. I've been happy with the decision, and recommend you get rid of Save/Cancel as well unless you feel strongly that it's more appropriate in your case.

Also this peeking is related to one practical use for a Sheet... you can't make the sheet vanish by swiping it... You can peek, but it always snaps back to the sheet and you must close it with the top buttons (or other programmatic means). Note that this is also not necessarily appropriate or at least desirable behaviour (in my view) for settings... as a user, I want to just pop in, make a change, and pop out even if it's by swiping right. Very quick, and I hate having to move my finger way up to the top of the screen to hit the Cancel button even if I've made no changes.

Peter Hansen -- (BB10 and dev-related blog posts at http://peterhansen.ca.)
Author of White Noise and Battery Guru for BB10 and for PlayBook | Get more from your battery!
Developer
Posts: 1,178
Registered: ‎03-20-2013
My Device: Red LE Developer Z10
My Carrier: Fido

Re: Application Menu disabled on Sheet?

That's funny, just checked on my Fido Z10 running 10.1.0. 4633 and the sheets are indeed sliding in from the right now. I just hadn't noticed.

 

Anyway, I have to agree that the "modern" way is instant updating of settings, but I have to say I hate it. One of the earliest places I encountered it was the Google Chrome browser settings. I didn't like the paradigm then, and I still don't. My particular situation is rather unique too... my settings page lets the user enter up to 500 URLs (not all at once of course LOL) and many users will type some of these in manually. I have found that with the TextField control it is very easy to accidentally hit the "X" delete all button in the field while using the circle cursor on the right end of the text. Being able to revert without saving can be useful to recover from this. Also, the settings can be saved to a file and reloaded later. When the user reloads settings they may decide not to save them after seeing what was reloaded. If settings are saved immediately they are committed. That said, I will be giving some thought to how I could make instant settings updates work in my app.

 

As for being able to peek behind pushed pages, I have found that feature problematic too. On a settings page it would be fine, but my app pushes scrollable WebView in a ScrollView pages onto the stack. I can't tell you how often I am horizontally scrolling on the WebView and the pushed page accidentally pops because the peek is triggered rather than the ScrollView scroll. So while I like peek functionality, it does have its problems too.

 

Oh, and my Save and Cancel buttons on the Settings page are at the bottom on the action menu, not up top on the TitleBar.

 


peter9477 wrote:
The Sheet-slides-from-right change came mid-summer in one of the 10.1 updates, sort of slipped in without prior warning by BB.

I do agree that if you have a Save/Cancel thing going on with Settings, that using a Sheet (i.e. the pair of buttons at top instead of the Back button at bottom) is a pretty reasonable idea.

I took the approach of mirroring how I saw most system apps (including Settings) handle settings changes, which is to say that changes affect the app/system as soon as you make them. You get no chance to Cancel a set of changes.

For the most part in my app, settings are not so closely related that I feel the need use a "transactional" approach to handle them, so you go to Settings, change one or more things, manually revert any changes you feel like reverting, and click Back.

One big reason why I went with this approach was one thing I noticed in testing with a Sheet. With the Sheet, you can still "peek" back at the underlying page. If any of the settings on that Sheet might affect the appearance of anything on the underyling page, then making a change to a setting and peeking should reflect those changes immediately. Not doing so felt like a usability flaw.

In my specific case, one of my settings was a date format selection. The underlying page uses that format to change the appearance of data in a ListView. Once I noticed that using the Save/Cancel ("transactional") approach didn't update that ListView in realtime as you changed the setting, I tried it with a Page. The "feel" from the user point of view was much better, so I ditched the transactional approach and went with how all BB's own stuff seems to work. I've been happy with the decision, and recommend you get rid of Save/Cancel as well unless you feel strongly that it's more appropriate in your case.

Also this peeking is related to one practical use for a Sheet... you can't make the sheet vanish by swiping it... You can peek, but it always snaps back to the sheet and you must close it with the top buttons (or other programmatic means). Note that this is also not necessarily appropriate or at least desirable behaviour (in my view) for settings... as a user, I want to just pop in, make a change, and pop out even if it's by swiping right. Very quick, and I hate having to move my finger way up to the top of the screen to hit the Cancel button even if I've made no changes.





Developer of Built for BlackBerry certified multiFEED RSS/Atom feed reader and aggregator.  multiFEED Icon

Play nice: Clicking Like Button on posts that helped you not only encourages others to continue sharing their experience, but also improves your own rating on this board. Also, don't forget to accept a post if it solves your problem or answers your question.
Developer
Posts: 6,473
Registered: ‎12-08-2010
My Device: PlayBook, Z10
My Carrier: none

Re: Application Menu disabled on Sheet?


greenmr wrote:
So while I like peek functionality, it does have its problems too.

It can be disabled, by the way, though you probably knew that already. (In case other readers didn't know.)


Peter Hansen -- (BB10 and dev-related blog posts at http://peterhansen.ca.)
Author of White Noise and Battery Guru for BB10 and for PlayBook | Get more from your battery!
Developer
Posts: 1,178
Registered: ‎03-20-2013
My Device: Red LE Developer Z10
My Carrier: Fido

Re: Application Menu disabled on Sheet?

Actually, no I didn't. I think I may have seen something about it a while back but it didn't really sink in because at the time I didn't think I had a need to. I'm a bit leery of disabling it though when I'm trying for BFB status since peek is one of the "BB10 Experience" components. I'll certainly consider implementing it in a release after i get BFB approved.

 

Thanks.



Developer of Built for BlackBerry certified multiFEED RSS/Atom feed reader and aggregator.  multiFEED Icon

Play nice: Clicking Like Button on posts that helped you not only encourages others to continue sharing their experience, but also improves your own rating on this board. Also, don't forget to accept a post if it solves your problem or answers your question.