?"Access Developer" wrote in message=20
>When will Microsoft make up their minds whether their products are for=20
>serious business use (end-user or developer) which would more logically =
>still have "Design View" or just for entertainment, as implied by=20
Actually, I think you're missing the point of backstage, the design view =
capability of editing or designing forms in access remains the same. In =
to my knowledge NONE of those design and development features that you =
during the form design process has been moved to backstage.
The whole concept and idea behind backstage is that when you're editing =
word document, or editing data in a spreadsheet such as excel, or =
designing forms in access, there's a tremendous amounts of parts of the=20
application that makes absolutely no sense in the context of designing =
using or editing that data as a what you see what you get type paradigm=20
In other words doing things like backing up the database, doing a =
and repair, setting security, even general over all ODBC connection =
the startup form, the web startup form (they can be different from each=20
other), etc, these ALL DO NOT benefit from the fact that you're looking =
and using or designing of a form.
Why waste all that screen real estate with a blank document in word, or=20
couple of forms on the screen in Access when you can use that screen =
estate to display information about configuration and setup of the=20
application? You're not doing WYSIWYG design or editing of data =
Virtually none of these tasks makes sense while you're actually looking =
particular document, it's not only a waste of screen real estate, but =
also a different type of task that you're accomplishing at that point in =
I mean we all agree that when you driving your car it makes sense to =
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 =
the spark plugs or fluids while you are driving the car down the =
is a DIFFERENT task.
Because the amount of configuration options in applications has =
much (in fact near exponential with all the new web based options),=20
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=20
maintenance tasks and OPTIONS we now have in modern applications such as =
In the case of access, options like backup, compact and repair, check =
web compatibility, even a nice handy dandy link to the published web =
trusted location setup for security, who edited the document last and =
list just GOES ON AN ON for a long way. NONE of these options make any =
while editing a word document or doing data entry inside of an access =
(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 =
from the user interface required during regular type of working and use =
As more and more features are added, it became very important to start=20
distinguishing between particular tasks such as editing a document, or =
design of forms inside of access, then that of the setup and maintains =
I don't know what is a better name then backstage would be, perhaps the=20
trunk? The boot? I suppose it could be just called the options area.=20
However by calling the backstage we're giving the whole concept and =
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 =
the user interface task of working and using the application as opposed =
setup and configuration and maintains of the application works very well =
most typical access applications.
The first and obvious benefit is that NOW with one line of code in 2010 =
can hide virtually all of the user access interface, and that includes=20
backstage and everything. The result is this screen shot:
The above is the WHOLE access interface and you SEE NONE of it. I did =
above with one line of code in 2010! And I did not use any custom xml=20
either. The above was done with ONE LINE of code and then using options =
the backstage to configure the above. (try that in previous versions of=20
The whole idea here is now we can easily pull out and hide so much of =
application part, because so much of the application part is now =
not necessarily be just for working or editing data on a form .
The result is now all that configuration and user interface parts that =
devoted to maintains and operation of the application are now hidden =
the end user!
I cannot imagine that any developer would not welcome this distinction=20
between these two distinct tasks, that of maintains and setup and=20
configuration, and that of actually doing your work and editing data.
The other big bonuses of course is that the user interface in backstage =
totally customizable by access developer. What this means is as people=20
being to expect good applications to separate out these types of tasks, =
they will expect applications are to be intelligently laid out. Now YOU =
also adopt this concept of features and functions that are centered =
maintains of the application. These would be features such as compact =
repair, re linking of tables, or even setting up of sales tax rates or=20
whatever. We can build our own back stages.
These types of tasks do not belong in a menu while you're editing and=20
entering some customer information into a form. And they don't apply to =
you're building and designing a form either.
So not only has moving all of these bits and parts out of the user =
into backstage makes a lot of sense and de clutter the UI while working =
as a developer you also can logically and correctly layout your =
in which much of the user interface has LESS clutter. This means you =
allow the user to get their job done and the same time having to deal =
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 =
and editing features for forms (design or use) have been moved into=20
backstage. The only features and options you'll find in backstage are=20
things like web publishing, compact and repair, and the General Security =
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 =
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=20
conversation, the fact that I can use the term backstage to refer to =
non user "and not in context" parts of the application is of itself is =
great step forward for ease of the conversation I am having about user=20
interface and application development here in this group!
So I see this as a great idea and I think is good to make the =
the type of task being done in the typical application. When I speak of=20
backstage options, you KNOW what I am talking about and the TYPE of task =
am talking about.
As noted, a really great feature backstage is that is completely=20
customizable and that means as a developer you can build your OWN =
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 =
applications by utilizing this paradigm. So the backstage system does =
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 =
I think once the above has been explained, I'm hard pressed to come up =
a better name for backstage. And I also hard pressed to come up with =
who thinks it wasn't a great time, if not HIGH TIME that the amazing =
of configuration and setup and configuration options (which are now =
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=20
product in question into a back area.
I also think that is you can see as the above discussion shows, just a=20
conceptual design and the ability of me to distinguish between the types =
tasks in a general conversation here, and referring to backstage TYPE of =
tasks gives me that general ability to distinguish between the type of=20
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 =
good thing, and I think the name chosen is quite reasonable. However, I =
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