locked
2010 Ribbon - Backstage RRS feed

  • Question

  • I'm trying to come to grips with all of the 2010 new features.
    One is the ribbon enhancements.
    This whole concept of the "Backstage" sort of baffles me.
    For one, why would new ribbon controls like radioGroup be relegated ONLY to the backstage and not the "regular" ribbon ? I would love to have this type control "on top".

    Secondly, what use is the Backstage for normal applications....I mean what does it bring to the table that the regular ribbon cannot ?

     

    Friday, September 9, 2011 6:22 PM

Answers

  • Duh ! I wasn't thinking.....all you need to change is the label attribute, correct ?

    Still, upon further thought, is there ever a need to make mass changes to the XML, and then Invalidate it ?

    Or better yet: switching out one set of XML for another.....thus eliminating the need to make a ton of changes using the callbacks. For instance, you want to disable all of the controls......

    Just some thoughts....

    I think some sets of xml are needed when you want to make different UI for different users or groups of users. And they should be really different, otherwise it''s easier to make this at callback level. To disable all of the controls, I think it's exactly a matter of callbacks. For example, you can add getEnabled="GetTabEnabled" to every tab and then check whether the temp variable is set to -1.

    Public Sub GetTabEnabled(ctrl As IRibbonControl, ByRef enabled)
        enabled = Not CBool(TempVars("DisableAll"))
    End Sub
    


    And when you need to "switch'em off" you just call smth like:

    Public Sub DisableAllTabs()
        TempVars("DisableAll") = -1
        MyRibbon.Invalidate
    End Sub
    
    I think all these things are rather new and there is no best practice yet. 



    Andrey V Artemyev | Saint-Petersburg, Russia
    Russian blog artemyev.biztoolbox.ru
    English blog enblog.biztoolbox.ru
    • Proposed as answer by Bruce Song Thursday, September 22, 2011 8:10 AM
    • Marked as answer by Syswizard Thursday, September 22, 2011 4:46 PM
    Sunday, September 11, 2011 11:27 AM

All replies

  • I obviously can't answer the first question, but can show an example for the second one.

    I modified a Northwind sample exactly for Ribbon and Backstage tests. One application was showing 5 last opened reports in the Backstage view and an ability to reopen them with the same parameters (criterias). Here is a screenshot:

    Backstage

     

    I think it looks more attractive than would they be on Ribbon. + radioGroup you mentioned.


    Andrey V Artemyev | Saint-Petersburg, Russia
    Russian blog artemyev.biztoolbox.ru
    English blog enblog.biztoolbox.ru
    Friday, September 9, 2011 6:30 PM
  • Hello Syswizard,

    Syswizard wrote:

    I'm trying to come to grips with all of the 2010 new features.
    One is the ribbon enhancements.
    This whole concept of the "Backstage" sort of baffles me.
    For one, why would new ribbon controls like radioGroup be relegated ONLY to the backstage and not the "regular" ribbon ? I would love to have this type control "on top".

    It´s by design MS.

    Secondly, what use is the Backstage for normal applications....I mean what does it bring to the table that the regular ribbon cannot ?

    other Controls like RadioGroup, Hyperlink and other...
    See also: http://www.accessribbon.de/en/?New_Features_in_Access_2010
    and
    http://www.accessribbon.de/en/index.php?Access_-_Ribbons:Ribbon_XML___Controls:Backstage_-_Controls

    HTH
    Gunter


    Access FAQ: http://www.donkarl.com

          http://www.avenius.com - http://www.AccessRibbon.com
    http://www.ribboncreator.com - http://www.ribboncreator2010.com

    Friday, September 9, 2011 6:32 PM
  • Hello Andrey,

    Andrey Artemyev wrote:
    ...

    I modified a Northwind sample exactly for Ribbon and Backstage
    tests. One application was showing 5 last opened reports in the
    Backstage view and an ability to reopen them with the same
    parameters (criterias). Here is a screenshot:

    <http://artemyev.biztoolbox.ru/image.axd?picture=2011%2f5%2fLRTask.PNG>
    I think it looks more attractive than would they be on Ribbon. +
    radioGroup you mentioned.

    Nice :-)

    HTH
    Gunter


    Access FAQ: http://www.donkarl.com

          http://www.avenius.com - http://www.AccessRibbon.com
    http://www.ribboncreator.com - http://www.ribboncreator2010.com

    Friday, September 9, 2011 6:35 PM
  • I agree...THAT IS a very slick use of Backstage since it is related to reporting....which is an output type of task.

    Still, for application functions, I don't see the need. I see backstage good for utility type of functionality. Another good one may be showing the last 3 forms opened or the last 3 functions performed, etc.

    And AGAIN, if I wanted to use a radioGroup "on top", I cannot...I am forced to send the users to the backstage.
    IMHO That's not "right". What was the big design consideration and/or limitation ?
    (BTW: I do have major concerns over MSFT's technical decision making process....)

     

     

    Saturday, September 10, 2011 1:10 AM
  •  modified a Northwind sample exactly for Ribbon and Backstage tests. One application was showing 5 last opened reports in the Backstage view and an ability to reopen them with the same parameters (criterias). Here is a screenshot:

    I think it looks more attractive than would they be on Ribbon. + radioGroup you mentioned.


    Andrey V Artemyev | Saint-Petersburg, Russia
    Russian blog artemyev.biztoolbox.ru
    English blog enblog.biztoolbox.ru

    Andrey - since this would be changing all of the time, to maintain the XML here, would you use an API or just simply do a string search and replace ?
    I am curious as to how developers maintain the ribbon XML dynamically.

     

    Saturday, September 10, 2011 11:13 AM
  • Hm, I can give you a link, but the text there is in Russian, you can check code blocks and screenshots.

    http://artemyev.biztoolbox.ru/post/2011/05/05/CustomUI-Intermediate(Ribbon_1).aspx

    http://artemyev.biztoolbox.ru/post/2011/05/10/CustomUI-Intermediate(Ribbon_2).aspx

    http://artemyev.biztoolbox.ru/post/2011/05/11/CustomUI-Intermediate(Backstage_1).aspx

    http://artemyev.biztoolbox.ru/post/2011/05/11/CustomUI-Intermediate(Backstage_2).aspx

    The only place where I modify the xml itself - it is before loading custom UI, to make some differences between .accdb and .accde versions. All other actions are done with callbacks which hold all the logic. I also find TempVars collection vwry useful to store Ribbon controls values. Once assigned the current Ribbon UI to a global variable you can use it further wherever you want with .Invalidate, InvalidateControl, .TabActivate etc. methods.

     


    Andrey V Artemyev | Saint-Petersburg, Russia
    Russian blog artemyev.biztoolbox.ru
    English blog enblog.biztoolbox.ru
    Saturday, September 10, 2011 11:23 AM
  • Duh ! I wasn't thinking.....all you need to change is the label attribute, correct ?

    Still, upon further thought, is there ever a need to make mass changes to the XML, and then Invalidate it ?

    Or better yet: switching out one set of XML for another.....thus eliminating the need to make a ton of changes using the callbacks. For instance, you want to disable all of the controls......

    Just some thoughts....

     

    Saturday, September 10, 2011 2:53 PM
  • I'm not really sure which radio group or type a button you're talking about, but there's a really amazing amount of button choices for

    However, a radio button is usually something for a form, or some type of "setup" screen, and probably does not make a whole lot of sense in a Ribbon from a UI point of view anyway.

    If you are wondering what the conceptual idea behind backstage is, well it's really just a separation of the type of task or work you're doing in the particular application.

    The problem is over the years each of the applications like word excel and even access continues to absolutely have HUGE growth in the amount of features. The problem is there's a whole class or set of features in applications that are not used while you're actually editing data. So in word, Excel, Access etc. you might be editing word or entering data into a form. The other area of the application is a set of options to "setup" the options in the application.

    So for display of options like who edited the document last, default page layout, even the startup options in access, all of these things are tasks that you don't generally use during regular running of the application when you're manipulating and editing data. You do not have to "see" the data when using these options.

    So what they did is they took all this mass of huge amount of options that displays who edited the document last, the ODBC options, and moved all of this stuff OUT OF the standard UI area.  In other words all of the options in your application that's not used for actual editing of data should be placed in backstage.

    It makes no sense to see the word document or even an access form when you using a set of options that has little to do with actual editing of data. Thus we can now use the WHOLE computer screen to layout these options on one nice big easy to read page. And it means that the user will not be attempting to edit data when you use such options.

    So backstage would NEVER be used for cut and paste options because you actually can't see the document in question anyway! However backstage would certainly be used in your application where you want to set up the sales tax rate. You also might have screen for setup of default city and setup of default area code. Perhaps setting for a special invoice printer etc.

    From software organizational point of view backstage is thus a great concept and it's simply moves tons of junk and clutter out of the main application.  This moving out of tons of features that are not really required during regular editing means that the "regular" part of the application ALSO has FAR less clutter and options in your way. In fact this design concept is what contributes to the overall clean look and de-clutter we see in office 2010.

    It is a win win since a user does not now have to look through "tons and tons" of editing data menus to find some setup option since once you go to backstage, then all of the "main" editing options are now unavailable and un-seen.

    If you look at competing products to office they continue to clutter up their main part of the application with ever more and more options. So the engineering and design concept of the backstage is really something that been long overdue in the software industry and something that competition to office likely will have to adopt once they grasp and understand what backstage is all about.

    When word came out it had under 100 options, I think today it up around 3000+ menu options.  Something had to be done here from a software design point of view.

    This simple idea of separating menu options for editing vs. that of setup type options is a simple but fantastic design addition to office 2010.

    Albert D. Kallal  (Access MVP)
    Edmonton, Alberta Canada

     


    • Edited by Albert D. Kallal Saturday, September 10, 2011 10:18 PM
    • Proposed as answer by Bruce Song Thursday, September 22, 2011 8:10 AM
    • Unproposed as answer by Bruce Song Thursday, September 22, 2011 8:10 AM
    Saturday, September 10, 2011 10:18 PM
  •  In other words all of the options in your application that's not used for actual editing of data should be placed in backstage.

    Thanks Albert....and this now makes sense.

    Unless I am missing something, am I wrong in saying MSFT did not coherently convey this important point in their discussions of Backstage ?

     

    Sunday, September 11, 2011 12:13 AM
  • I kind a thought the whole design philosophy was rather obvious.  I mean every system and thing that Microsoft builds is done by a group of very highly skilled engineers.  They have among the best developers in the world.  I think what is more amazing about backstage is not only did they develop a whole system and software methodology to solve this problem in our industry, but they also exposed it to developers so we can do the same thing in our applications.

    I cannot really say the average office user needs to care or know what backstage is for. In fact the average user probably does not give this any more thought about this than when they're on a airplane and they think about how wings generate lift? I suspect this is why this message is not so clear here. However users and developers are two big differnt groups but Access is one of those products that really has a interesting mix of both groups.

    On the other hand if you’re a group of aircraft engineers you better understand how wing produces lift else you not be in a great position to make intelligent decisions about how wings should be designed.

    Fact is I don't think Microsoft has ever been a great marketing company and I'm not sure to for the vast majority of users this backstage message needs to be conveyed anyway.  Users will pretty quickly find out there is this place were application setup stuff seems to be and reside. After a while when they want to find more application setup stuff then there is a good chance users will go look into the same area where the found most of the setup stuff anyway.

    I can't find a link right now, but at a sharepoint conference (last year or so) there was a marvelous presentation by one of the Microsoft devs on how to build applications for the ribbon.  (this presentation is on line, but I cannot find it right now).

    One of the interesting things pointed out of the presentation was in fact that in the ribbon you actually group your options not necessarily by category like often done with menu bars, but you now group options by task.  So instead of the old way of having a menu bar with a bunch of reports in a group to print, the task at hand might be doing some invoice.

    So in the ribbon you'll have a bunch of options to print the invoice, perhaps check the balance of the invoice and maybe email or fax the invoice. All these buttons are now an easy one click point and shoot affair as opposed to winding through some menu bars.

    So you group by what "most" users do at that point in the application  and not necessary group options by category like menu bars often did.  And most things do start to make sense, since I could point out how rare it is to see radio buttons in a ribbon - such buttons up in a ribbon does not make a whole lot of sense anyway in terms of what parts belong in a ribbon.

    Keep in mind that things in the software industry are becoming more complex and the Engineering Solutions are thus based on ever more skill and greater efforts. This means more and more things will become less and less obvious. In the 1950's they could come out with a new fighter jet in about 8 months. Today a new airframe will likely be around 30+ years. So our industry is maturing and thus so is the complexity of problems being solved today.

    At the end of the day you have to trust those aircraft engineers when you jump on a plane or in this case the office suite and assume that those software engineers made great decisions based on the information they had at hand. 

    In other words you don't always have to agree with all the design decisions being made, but at for the most part given the criteria those software engineers had at hand, my experience with them is such that they generally make great decisions.

    Albert D. Kallal  (Access MVP)
    Edmonton, Alberta Canada

    • Proposed as answer by Bruce Song Thursday, September 22, 2011 8:10 AM
    Sunday, September 11, 2011 1:55 AM
  • Duh ! I wasn't thinking.....all you need to change is the label attribute, correct ?

    Still, upon further thought, is there ever a need to make mass changes to the XML, and then Invalidate it ?

    Or better yet: switching out one set of XML for another.....thus eliminating the need to make a ton of changes using the callbacks. For instance, you want to disable all of the controls......

    Just some thoughts....

    I think some sets of xml are needed when you want to make different UI for different users or groups of users. And they should be really different, otherwise it''s easier to make this at callback level. To disable all of the controls, I think it's exactly a matter of callbacks. For example, you can add getEnabled="GetTabEnabled" to every tab and then check whether the temp variable is set to -1.

    Public Sub GetTabEnabled(ctrl As IRibbonControl, ByRef enabled)
        enabled = Not CBool(TempVars("DisableAll"))
    End Sub
    


    And when you need to "switch'em off" you just call smth like:

    Public Sub DisableAllTabs()
        TempVars("DisableAll") = -1
        MyRibbon.Invalidate
    End Sub
    
    I think all these things are rather new and there is no best practice yet. 



    Andrey V Artemyev | Saint-Petersburg, Russia
    Russian blog artemyev.biztoolbox.ru
    English blog enblog.biztoolbox.ru
    • Proposed as answer by Bruce Song Thursday, September 22, 2011 8:10 AM
    • Marked as answer by Syswizard Thursday, September 22, 2011 4:46 PM
    Sunday, September 11, 2011 11:27 AM

  • And when you need to "switch'em off" you just call smth like:

    Public Sub DisableAllTabs()
        TempVars("DisableAll") = -1
        MyRibbon.Invalidate
    End Sub
    
    I think all these things are rather new and there is no best practice yet.

    The advantage of using the SAME callback procedure for all controls is now becoming apparent.

    Note: Using TempVars with a string is a bit haphazard....for instance, one might forget the exact string value and use "Disableall" by mistake and then it wouldn't work. I try to use enumerators wherever possible to eliminate this source of error.

    • Marked as answer by Syswizard Thursday, September 22, 2011 4:45 PM
    • Unmarked as answer by Syswizard Thursday, September 22, 2011 4:45 PM
    Thursday, September 22, 2011 1:11 PM
  • Do you mean that a TempVar name is case sensitive? Just can't understand a little your last statement.
    Andrey V Artemyev | Saint-Petersburg, Russia
    Russian blog artemyev.biztoolbox.ru
    English blog enblog.biztoolbox.ru
    Thursday, September 22, 2011 1:21 PM
  • Strings as parameters can be hazardous to reliability, that's all.

    Ever wonder why Access and Excel VBA object models have a million enumerations ?
    There you go....there's your answer.

     

    Thursday, September 22, 2011 2:39 PM