Access 2010 Backstage and the Custom Ribbon

Bob Darlington

unread,

Dec 13, 2010, 9:24:56 PM12/13/10

to

Can the Backstage items 'visible' property be reset through a custom ribbon
XML, or only for the entire database by selecting an application ribbon from
the Options - Current Database screen?
I've tried the following and can't get it to hide the Backstage items.

</tab>
</tabs>

</ribbon>

</customUI>
--
Bob Darlington
Brisbane

Albert D. Kallal

unread,

Dec 16, 2010, 6:41:40 AM12/16/10

to

?"Bob Darlington" wrote in message
news:4d06d572$0$25359$afc3...@news.optusnet.com.au...

>Can the Backstage items 'visible' property be reset through a custom ribbon
>XML, or only for the entire database by selecting an application ribbon
>from the Options - Current Database screen?
>I've tried the following and can't get it to hide the Backstage items.

The backstage xml ONLY works for a application specified ribbon (file ->
options)

So a form (or report) with the ribbon above as you have will NOT WORK nor
effect backstage.

However, if you specify your above ribbon in the options for the application
ribbon, the back stage options you have WILL work.

So, just keep in mind that backstage items are a one time load deal, and
must be part of the application ribbon you specify in the options for the
application wide ribbon, NOT the ribbon for each report or form.

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
Pleasenos...@msn.com

Bob Darlington

unread,

Dec 16, 2010, 8:59:41 PM12/16/10

to

Thanks Albert.
I'll try working around that.

--
Bob Darlington
Brisbane
"Albert D. Kallal" <PleaseNOOO...@msn.com> wrote in message
news:YVmOo.56956$wf4....@newsfe05.iad...

Access Developer

unread,

Dec 17, 2010, 1:19:58 PM12/17/10

to

When will Microsoft make up their minds whether their products are for
serious business use (end-user or developer) which would more logically
still have "Design View" or just for entertainment, as implied by "Backstage
View".

I'm sure some 'Softie with influence is smugly grinning over getting that
name accepted and included. I'm pretty sure Jensen Harris, the Product
Manager who was the moving force behind The Ribbon, is grinning -- he got a
promotion out of that work and his manager was promoted to VP!

Larry Linson

Albert D. Kallal

unread,

Dec 21, 2010, 2:24:33 AM12/21/10

to

?"Access Developer" wrote in message
news:8n1nu7...@mid.individual.net...

>When will Microsoft make up their minds whether their products are for
>serious business use (end-user or developer) which would more logically
>still have "Design View" or just for entertainment, as implied by
>"Backstage View".

Actually, I think you're missing the point of backstage, the design view or
capability of editing or designing forms in access remains the same. In fact
to my knowledge NONE of those design and development features that you NEED
during the form design process has been moved to backstage.

The whole concept and idea behind backstage is that when you're editing a
word document, or editing data in a spreadsheet such as excel, or editing or
designing forms in access, there's a tremendous amounts of parts of the
application that makes absolutely no sense in the context of designing or
using or editing that data as a what you see what you get type paradigm
(WYSIWYG)

In other words doing things like backing up the database, doing a compact
and repair, setting security, even general over all ODBC connection options,
the startup form, the web startup form (they can be different from each
other), etc, these ALL DO NOT benefit from the fact that you're looking at
and using or designing of a form.

Why waste all that screen real estate with a blank document in word, or
couple of forms on the screen in Access when you can use that screen real
estate to display information about configuration and setup of the
application? You're not doing WYSIWYG design or editing of data anymore.

Virtually none of these tasks makes sense while you're actually looking at a
particular document, it's not only a waste of screen real estate, but it's
also a different type of task that you're accomplishing at that point in
time.

I mean we all agree that when you driving your car it makes sense to have
use of the steering wheel or use of the radio controls. However no one
here is going to suggest that you should be able to open the hood to change
the spark plugs or fluids while you are driving the car down the highway. It
is a DIFFERENT task.

Because the amount of configuration options in applications has increased so
much (in fact near exponential with all the new web based options),
therefore it does not make sense to pile in a HUGE mumble jumble of user
interface tasks such as editing and designing forms with the VERY MANY
maintenance tasks and OPTIONS we now have in modern applications such as
office has.

In the case of access, options like backup, compact and repair, check for
web compatibility, even a nice handy dandy link to the published web sites,
trusted location setup for security, who edited the document last and this
list just GOES ON AN ON for a long way. NONE of these options make any sense
while editing a word document or doing data entry inside of an access form
(or even during the design process of an access form).

It was high time that a logical grouping and removal of a huge amount of
options that are for maintains and setup of the application were moved out
from the user interface required during regular type of working and use of
that application.

As more and more features are added, it became very important to start
distinguishing between particular tasks such as editing a document, or doing
design of forms inside of access, then that of the setup and maintains of
these applications.

I don't know what is a better name then backstage would be, perhaps the
trunk? The boot? I suppose it could be just called the options area.
However by calling the backstage we're giving the whole concept and process
and an name that we can all use in this community.

I should also point out and keep in mind that this logical breaking out of
the user interface task of working and using the application as opposed to
setup and configuration and maintains of the application works very well for
most typical access applications.

The first and obvious benefit is that NOW with one line of code in 2010 I
can hide virtually all of the user access interface, and that includes
backstage and everything. The result is this screen shot:

http://cid-b18a57cb5f6af0fa.office.live.com/self.aspx/.Public/Accesshelp3/formonly.png

The above is the WHOLE access interface and you SEE NONE of it. I did the
above with one line of code in 2010! And I did not use any custom xml
either. The above was done with ONE LINE of code and then using options in
the backstage to configure the above. (try that in previous versions of
access!).

The whole idea here is now we can easily pull out and hide so much of that
application part, because so much of the application part is now realized to
not necessarily be just for working or editing data on a form .

The result is now all that configuration and user interface parts that are
devoted to maintains and operation of the application are now hidden from
the end user!

I cannot imagine that any developer would not welcome this distinction
between these two distinct tasks, that of maintains and setup and
configuration, and that of actually doing your work and editing data.

The other big bonuses of course is that the user interface in backstage is
totally customizable by access developer. What this means is as people
being to expect good applications to separate out these types of tasks, then
they will expect applications are to be intelligently laid out. Now YOU can
also adopt this concept of features and functions that are centered around
maintains of the application. These would be features such as compact and
repair, re linking of tables, or even setting up of sales tax rates or
whatever. We can build our own back stages.

These types of tasks do not belong in a menu while you're editing and
entering some customer information into a form. And they don't apply to when
you're building and designing a form either.

So not only has moving all of these bits and parts out of the user interface
into backstage makes a lot of sense and de clutter the UI while working but
as a developer you also can logically and correctly layout your applications
in which much of the user interface has LESS clutter. This means you simply
allow the user to get their job done and the same time having to deal with
less of the user interface that the whole application has.

In the case of access, as I pointed out, to my knowledge NONE OF the design
and editing features for forms (design or use) have been moved into
backstage. The only features and options you'll find in backstage are
things like web publishing, compact and repair, and the General Security and
options etc. that we had in access for a long time.

The options for editing designing and building applications for the most
part remains in the front part of the application, and in the backstage has
only parts that would simply get in the way of daily working anyway.

I should also point out, that even in the context of me making this
conversation, the fact that I can use the term backstage to refer to those
non user "and not in context" parts of the application is of itself is a
great step forward for ease of the conversation I am having about user
interface and application development here in this group!

So I see this as a great idea and I think is good to make the distinction of
the type of task being done in the typical application. When I speak of
backstage options, you KNOW what I am talking about and the TYPE of task I
am talking about.

As noted, a really great feature backstage is that is completely
customizable and that means as a developer you can build your OWN backstage.

This means as access developers we are in a far better position to build
nice rich applications and even configuration and set up screens for our own
applications by utilizing this paradigm. So the backstage system does not
only apply to using access for development, but we can also utilize this
concept and use our OWN backstage system for the applications we develop for
our customers.

I think once the above has been explained, I'm hard pressed to come up with
a better name for backstage. And I also hard pressed to come up with anybody
who thinks it wasn't a great time, if not HIGH TIME that the amazing amount
of configuration and setup and configuration options (which are now growing
in exponential rates due to web based features being introduced into all
these products) were now simply moved out of the front interface of the
product in question into a back area.

I also think that is you can see as the above discussion shows, just a
conceptual design and the ability of me to distinguish between the types of
tasks in a general conversation here, and referring to backstage TYPE of
tasks gives me that general ability to distinguish between the type of
conceptual user interface and other types of tasks we're talking about.

So at the end of the day, I think this conceptual type of distinction is a
good thing, and I think the name chosen is quite reasonable. However, I open
to anyone suggesting a better term, and if it is a better term, then the
community here can adopt that term and I would welcome that suggestion.

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

kal...@msn.com

Message has been deleted

hatm...@gmail.com

unread,

Jan 9, 2014, 2:48:59 PM1/9/14

to

I don't give damn what you call it. Call it "IT" for all I care. But "IT" needs to be a hell-ov-a-lot easier to use, as in preventing the end user from accesing the "File Tab > Privacy Options" which allows them to Re-Enable all the options I disabled! Hiding that and still allowing the end user to see he other Tabs as needed suc as the Prnt tab is STILL confounding me!!!!! I Just don't get the logic at all!!!!!
Why would such a simple LOGICAL task of preventing my end users from accessing the "OPTIONS" be sooooo confoundingly complicated?!?!?!?

hatm...@gmail.com

unread,

Jan 10, 2014, 8:24:13 AM1/10/14

to

hatm...@gmail.com

unread,

Jan 23, 2014, 1:10:25 PM1/23/14

to

Albert D. Kallal

unread,

Jan 24, 2014, 4:54:25 PM1/24/14

to

> preventing the end user from accesing the "File Tab > Privacy Options"

I not sure what your problem really is, but about 10 seconds of BinGoogle
finds the answer.

Simply in the back stage section of your ribbon, hide the option dialog with
this:

Note that the backstage ribbon area is APPLICATION wide and thus settings
for back stage items ONLY belong and ONLY work and ONLY apply for the system
wide ribbon.

In other words you cannot change/control/hide/show back stage items in
ribbons specified for forms - ONLY the application wide ribbon you specify
has an effect on backstage.
(in plain English this means that backstage settings MUST be placed in the
application wide ribbon you specify for the application
(file->options->currentdabases->Ribbons and tool bar options area).

It is easy to hide most items - in fact the REAL hard trick/issue is to hide
the most recently used file list (MRU).

best regards,

-
Albert D. Kallal Access MVP.
Edmonton, Alberta Canada
PleaseNoS...@msn.com

PR

unread,

Mar 19, 2015, 6:55:37 PM3/19/15

to

Albert

I´m sure you have absolute certainty that you are right !

But the real world is different.

I have developed access applications for almost 20 years and I NEVER needed to include any FILE option for my users.

This because they don´t need and don´t want IT !

This FILE button has no USE at all to any of my applications.

So if there is no way of hiding just say it.

Thanks for trying anyway.

PR

Albert D. Kallal

unread,

Mar 20, 2015, 4:29:29 PM3/20/15

to

"PR" wrote in message
news:6f488eb0-71a2-4021...@googlegroups.com...

>Albert
>
>I´m sure you have absolute certainty that you are right !
>
>But the real world is different.
>
>I have developed access applications for almost 20 years and I NEVER needed
>to include any FILE option for my users.
>

I much accept. However, have any of your applications EVER allowed you to
export data?

So not all my applications export or import data, but a SIGNIFICANT number
do.

So the user does not need the file option, but take 1 MILLION computer users
and ask them the following question:

If you were to guess in a typical program where would you find the "option"
to import or export data?
(say data from a spreadsheet - worked on SEVERAL Access applications that
would launch the file browse and allow the user to import a Excel sheet).

Once again, often one will have some type of import or export option in
Access.

So back to the MILLION users that we going to ask a question:

Where would you GUESS without a instruction manual would the option be to
import a data file into a given application?

A VERY VERY high % of those people would suggest and GUESS the file menu!!!

So the issue then is to reduce training and use THEIR EXISTING mental
model - put the option behind the File menu.

I explain this in the following article:

http://www.kallal.ca/Articles/UseAbility/UserFriendly.htm

NOTE CAREFULLY in above how I suggest to use File and even the Edit menu in
your application.

If EVERY user knows that File->new to create a new word document, then WHERE
do you think they would guess to create a new email out outlook?

And where do you think they would guess to create a new invoice in your
program?

If ONE MILLION users will state that THEY USE THE FILE menu to create a new
Excel document, and ONE MILLION users ALSO state they use the FILE MENU to
create a new word document.

Want to GUESS where the SAME 1 million users would GUESS as to where a new
invoice can be created from in YOUR program?

Why of course the File menu!!!!

In other words DARN NEAR EVERY SINGLE program for windows has a file menu
option. This includes the Ribbon, or before when we had menu bars.

You would STAND VERY alone, in fact VERY VERY alone in the computer world to
suggest that users will not "naturally" gravitate towards the file menu to
create something NEW in software since nearly EVERY single application they
used will have a file menu.

>This FILE button has no USE at all to any of my applications.

Well, it has for 20+ years of everyone else in this computer industry. I
would say near every single software vendor on the planet sees it this way.
And MORE important is EVERY SINGLE computer user on planet earth ALSO has
come to expect such a option!

It is possible that your users are different then the last 20+ years of the
computer industry?

>So if there is no way of hiding just say it.

Never tried to dodge or obfuscate this issue - the simple fact is EVERYONE
on planet earth who used a desktop computer has COME TO EXPECT a file
option.

The idea to hide this option no more occurred to me then asking humans to
stop breathing air.

Use of the File option is a GREAT way to leverage the users EXISTING
knowledge of using computers. It possible that you have a BETTER way then
the everyone from Apple, Oracle, Adobe, Microsoft, SUN, Word Perfect etc.
and in fact near EVERY vendor of software! - but they all clearly don't
agree with you, do they? Even with the advent of the ribbon, the file
option remains! However, office 2007 tried to replace File with the Pizza
button - it was a disaster and even Microsoft back peddled on this!

So I am just the messenger here. I am telling you the sky is blue, and I
simply pointing out that looking at the history of this software industry
for 20+ years you find that MOST software has a file option.

So while you don't think you need a file option, it can be used to reduce
the learning curve in your software since ALL USERS are familiar with the
File option.

>Thanks for trying anyway.

No, not trying anything at all - simply pointing out the fact that the WHOLE
SOFTWARE industry worked this way for over 20 years, and pointing this out
has nothing to do with my opinion at all. It just a simple observation.

To be fair, one often does not need a file option in a typical Access
application, but the "case" to cook up and use the File option often results
in a surprising use case and this "use case" means that new users of such
applications can often "guess" where to find such a option as opposed to
being told where to find such a option.

As to me liking or dis liking the File option is really moot, but we ALL
know that users of computers are familiar with such a option.

One can hide the file option and ribbon with this:

I think the "instant" one starts to include a ribbon in a application is
quite much the time that some use of the File option likely will occur also!

Regards,

--

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

PleaseNoS...@msn.com