?"Access Developer" wrote in message=20
news:8n1nu7F586U1@mid.individual.net...
>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
>"Backstage View".
Actually, I think you're missing the point of backstage, the design view =
or=20
capability of editing or designing forms in access remains the same. In =
fact=20
to my knowledge NONE of those design and development features that you =
NEED=20
during the form design process has been moved to backstage.
The whole concept and idea behind backstage is that when you're editing =
a=20
word document, or editing data in a spreadsheet such as excel, or =
editing or=20
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 =
or=20
using or editing that data as a what you see what you get type paradigm=20
(WYSIWYG)
In other words doing things like backing up the database, doing a =
compact=20
and repair, setting security, even general over all ODBC connection =
options,=20
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 =
at=20
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 =
real=20
estate to display information about configuration and setup of the=20
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=20
particular document, it's not only a waste of screen real estate, but =
it's=20
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=20
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=20
the spark plugs or fluids while you are driving the car down the =
highway. It=20
is a DIFFERENT task.
Because the amount of configuration options in applications has =
increased so=20
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 =
office has.
In the case of access, options like backup, compact and repair, check =
for=20
web compatibility, even a nice handy dandy link to the published web =
sites,=20
trusted location setup for security, who edited the document last and =
this=20
list just GOES ON AN ON for a long way. NONE of these options make any =
sense=20
while editing a word document or doing data entry inside of an access =
form=20
(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=20
from the user interface required during regular type of working and use =
of=20
that application.
As more and more features are added, it became very important to start=20
distinguishing between particular tasks such as editing a document, or =
doing=20
design of forms inside of access, then that of the setup and maintains =
of=20
these applications.
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 =
process=20
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=20
the user interface task of working and using the application as opposed =
to=20
setup and configuration and maintains of the application works very well =
for=20
most typical access applications.
The first and obvious benefit is that NOW with one line of code in 2010 =
I=20
can hide virtually all of the user access interface, and that includes=20
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=20
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 =
in=20
the backstage to configure the above. (try that in previous versions of=20
access!).
The whole idea here is now we can easily pull out and hide so much of =
that=20
application part, because so much of the application part is now =
realized to=20
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=20
devoted to maintains and operation of the application are now hidden =
from=20
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 =
is=20
totally customizable by access developer. What this means is as people=20
being to expect good applications to separate out these types of tasks, =
then=20
they will expect applications are to be intelligently laid out. Now YOU =
can=20
also adopt this concept of features and functions that are centered =
around=20
maintains of the application. These would be features such as compact =
and=20
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 =
when=20
you're building and designing a form either.
So not only has moving all of these bits and parts out of the user =
interface=20
into backstage makes a lot of sense and de clutter the UI while working =
but=20
as a developer you also can logically and correctly layout your =
applications=20
in which much of the user interface has LESS clutter. This means you =
simply=20
allow the user to get their job done and the same time having to deal =
with=20
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=20
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 =
and=20
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=20
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 =
those=20
non user "and not in context" parts of the application is of itself is =
a=20
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 =
distinction of=20
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 =
I=20
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 =
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=20
applications by utilizing this paradigm. So the backstage system does =
not=20
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=20
our customers.
I think once the above has been explained, I'm hard pressed to come up =
with=20
a better name for backstage. And I also hard pressed to come up with =
anybody=20
who thinks it wasn't a great time, if not HIGH TIME that the amazing =
amount=20
of configuration and setup and configuration options (which are now =
growing=20
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 =
of=20
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 =
a=20
good thing, and I think the name chosen is quite reasonable. However, I =
open=20
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
kallal@msn.com=20
|
Search |
Post Question |
Groups |
Stream |
About |
Register
Bob
42108 articles. 
8 followers. 
4 Replies
1142 Views
