No need for customized menus, toolbars, or ribbons in 2007????

D

dbguy_atlanta

I'm evaluating a jump from Access 2002/2003 to 2007 for complex Access
applications (many forms, many reports, significant amount of code, etc.).
I'm aghast at the poor performance, odd latencies, and massive (mostly
needless) reorganization of 2007 but still considering it for various
reasons. At the moment I'm more concerned with something I (think) I've found
that I find very ominous. When you look at what Microsoft has done and not
done as far as custom menus, toolbars, and ribbons in 2007, it almost seems
as though they want to discourage serious application development with
Access. Hopefully I'm wrong and have missed something in 2007. Please confirm
if the following is correct or not...

1. Custom toolbars and menus created in earlier versions of Access work fine
(for the most part) in 2007 but there's no way to modify them (other than
with VBA) in 2007? Microsoft's answer is to use previous versions of Access
for this purpose? Huh?

2. Microsoft provides no way to easily create and modify custom ribbons??
I've seen references to third party tools and a messy manual approach (adding
rows to some table and writing XML) but unless I've missed something
Microsoft felt this was not really necessary? Again, huh?

I'm hoping I'm wrong on both counts and somebody can point me in the right
direction to customize a menu system in 2007.

I know some would suggest a switchboard instead but with previous versions
of Access I've been able to write applications that look and behave like
commerical applications and I'd like to continue that approach.

Thanks in advance.
 
J

James A. Fortune

dbguy_atlanta said:
I'm evaluating a jump from Access 2002/2003 to 2007 for complex Access
applications (many forms, many reports, significant amount of code, etc.).
I'm aghast at the poor performance, odd latencies, and massive (mostly
needless) reorganization of 2007 but still considering it for various
reasons. At the moment I'm more concerned with something I (think) I've found
that I find very ominous. When you look at what Microsoft has done and not
done as far as custom menus, toolbars, and ribbons in 2007, it almost seems
as though they want to discourage serious application development with
Access. Hopefully I'm wrong and have missed something in 2007. Please confirm
if the following is correct or not...

1. Custom toolbars and menus created in earlier versions of Access work fine
(for the most part) in 2007 but there's no way to modify them (other than
with VBA) in 2007? Microsoft's answer is to use previous versions of Access
for this purpose? Huh?

2. Microsoft provides no way to easily create and modify custom ribbons??
I've seen references to third party tools and a messy manual approach (adding
rows to some table and writing XML) but unless I've missed something
Microsoft felt this was not really necessary? Again, huh?

I'm hoping I'm wrong on both counts and somebody can point me in the right
direction to customize a menu system in 2007.

I know some would suggest a switchboard instead but with previous versions
of Access I've been able to write applications that look and behave like
commerical applications and I'd like to continue that approach.

Thanks in advance.

The following are simply guesses. You have to expect poorer performance
with later versions because more code and features are added with each
new version unless MS devotes itself to specific functionality. In that
case the newer version is capable of being faster than the older version
in some respects.

Microsoft is not trying to discourage serious application with Access --
well somewhat serious application with Access anyway :). The rationale
for the ribbon seems to be part of an effort to simplify the
increasingly complicated interface supplied for Word, and then that idea
was extended to all of Office for uniformity. The reason for using XML
is partly related to an attempt by Microsoft, aided by court decisions
in Europe, to use more standards based programming as a way to prevent
locking out competition through the use of proprietary formats. It
seems that Microsoft learned a lot through the process, though they seem
to have backed away from the vision of completely open formats on their
flagship software and moved more toward the clever idea of using
standard formats for application to application interaction. The result
of trying to use some open format concepts within Access 2007 resulted
in a hybrid of XML for the ribbon and moving VBA into Macros for the
unlikely future possibility of continuing to move Access to rely even
more on XML. So, for a change, a lot of the pain developers are going
through is not, IMO, really the fault of Microsoft. I think most
developers would now agree that going to completely open standards for
everything within Microsoft, while a grand idea, is not good for either
Microsoft or developers. An example of what I'm talking about can be
seen in how the PDC05 materials were packaged. Everything used mostly
open standards -- CSS, HTML, GIF files, etc. Even with a massive effort
by Microsoft, the result wasn't nearly as smooth as people have come to
expect. Now I'll try to answer your questions.

1. Use an earlier version of Access or learn XML. Take your pick. I'm
amazed that Microsoft was able to retain the VBA capabilities as well as
they did.

2. Microsoft knew that dealing with XML for the ribbon was not going to
be simple. They seem to have tried to make up for that deficiency by
creating more XML tools and making them available to developers. My
guess is that the situation with the EU courts did not make leaving XML
out of the picture an option.

Hopefully Microsoft can find the right amount of open standard support
that will make the most people happy and thereby allow them to dump
using XML for parts of the Access user interface (ignore temporarily the
need for backward XML compatibility with an older Access 07). Maybe
some new software application would be a better candidate than Access
for experimenting with a move to open standards. Even then, you'd have
to have some way to protect parts of your software from being stolen.

James A. Fortune
(e-mail address removed)

JK: With the symbolic sleuthing of my debugger I can get interpreted C
source code for most commercial software in about four hours to a day,
including library calls.

JF: If Microsoft stole your debugger, why not anonymously post
interpreted C source for Windows?

JK: I wouldn't do that if I could. I could possibly do it for Windows
3.1, but later versions of Windows code have dead ends called stubs that
make it much harder to recreate the code.
 
D

dbguy_atlanta

A thoughtful and reasonable analysis of the situation but I don't think moves
towards open standards precluded Microsoft from offering some simple and
convenient way to create a customized menu system for our applications. Every
product that preceeded Access, going way back to dbase, Foxbase, Rbase,
Clarion, Dataflex, etc., provided simple tools to create custom menus. It's
something I always took for granted.

So it still leaves me wondering, has Microsoft taken the "let them eat cake"
position on this (i.e., tough folks, we didn't get to menu customization in
the first release, go figure something out) or is there some underlying
effort to push application development out of Access and into VB or other
..net approach? I have no doubt the percentage of Access users that do serious
application development is tiny compared to the number of users that do
simple list management, reporting, queries, or just dabble in the product
occasionally.
 
A

Albert D. Kallal

Microsoft from offering some simple and
convenient way to create a customized menu system for our applications.
Every
product that preceeded Access, going way back to dbase, Foxbase, Rbase,
Clarion, Dataflex, etc., provided simple tools to create custom menus.
It's
something I always took for granted.

Actually, while FoxPro did have a menu builder,
a rather large number of people used
code, or took existing menu **code** and copied it.

Looking at my tons of FoxPro code, I had lot of:

* define the master menu
DEFINE MENU mainmenu COLOR SCHEME 3
DEFINE PAD File OF mainmenu PROMPT ' File '
DEFINE PAD DATECON OF mainmenu PROMPT ' Set Dates
DEFINE PAD Reports OF mainmenu PROMPT ' Reports
DEFINE PAD system OF mainmenu PROMPT ' Configure
DEFINE PAD develop OF mainmenu PROMPT ' Developer
ON PAD File OF mainmenu ACTIVATE POPUP Filepop
ON PAD DateCon OF mainmenu ACTIVATE POPUP DatePop

So, we did resort to wrting code back then for our menus.

And, in fact a significant portion of people who build custom menus in
ms-access
also write code to create those menus.

And, even quite a few KB articles/example use VBA to build menus for access.

With xml, you don't really write code anymore, you "define" the menu. Here
is a custon menu I use for reprots

<customUI xmlns="http://schemas.microsoft.com/office/2006/01/customui">
<ribbon startFromScratch="true">
<tabs>
<tab id="MyReport" label="Report">

<group idMso="GroupPrintPreviewPrintAccess" />
<group idMso="GroupPageLayoutAccess" />
<group idMso="GroupZoom" />
<group idMso="GroupPrintPreviewClosePreview" />

</tab>
</tabs>
</ribbon>
</customUI>

The above is clean and easy to maintain.

In fact, after you built a few menus in 2007, you will find it is EASIER
then the
previous way to build a menu.

Another fantastic feature of those xml ribbons is that you can go on a
Easter hunt and lift individual buttons and portions of ribbons from your
EXISTING library of applications . Previous versions of access forced you
to
import ALL BUTTONS. It was a messy all or nothing affair . It really did
not encourage good coding practices , and it also made it difficult to move
menus and buttons between applications .

Remember the difference between a good developer and a bad developer, is a
good developer builds up a good library of reusable code and routines that
they can use from one application to the next. The use of xml for the
ribbon encourages and gives one the ability to lift portions of previous
menus from previous applications into your new applications. This ability to
grab parts and pieces feature alone tends to win over what we had in the pre
2007 days.

To be frank, the old system in ms-access was poor at developing menus.

Virtually ALL OF my applications before 2007 had custom menu bars, and now
they have custom ribbons. It really not a big deal, and in fact once you
build a few ribbons...you use those as starting points for new ones...
tough folks, we didn't get to menu customization in
the first release, go figure something out) or is there some underlying
effort to push application development out of Access and into VB or other
.net approach? I have no doubt the percentage of Access users that do
serious
application development is tiny compared to the number of users that do
simple list management, reporting, queries, or just dabble in the product
occasionally.

Well, lets not become too weak minded here. If you a serous coder and
developer, then spend an afternoon learning how to build ribbons. As I
said, after you build a few, you just cut+paste your way to building these
ribbons.. It becomes easier then building menus via the gui.

The lack of a custom menu builder is really only a hindrance for the non
developers. Perhaps you are a non coder and not really a developer. (but
then
again how could you be complaining about developer features then?).

If you really are a developer and really serious about this, then this will
be
a non issue for you.

You have to be willing to make the effort to learn this new system, and
invest the time required to get productive. Once you do this, then you will
be as productive as before, in IMHO, you be more productive then before.

If you're telling me that some kind of custom ribbon builder should be
included as part of the access system, then I agree with you. Having that
builder would cut down the learning curve, but after certain point that
editor not going to help you at all anymore.

This is just not a really a big deal if you're a capable and experienced
developer.
 
D

dbguy_atlanta

Thanks for taking the time to write a thoughtful response Albert.

I meant to imply with my first sentence, where I said "complex Access
applications (many forms, many reports, significant amount of code, etc.)",
that I have been doing serious Access developement for a long time. And the
thrust of the post was to try and confirm that Microsoft had completely
discarded any simple way to manage menus in the 2007 version of Access.

All of us have different needs and priorities. I create relatively large
systems with many screens and reports that require a great deal of time for
database modeling, design, layout, training, etc. I spend way more time than
I would like now on programming for data entry and reports, I simply don't
have time, nor do I want to do much additional programming for menus. For my
situation it makes no sense anyway, rarely do I need to do more than create a
menu and enable/disable options. The need to programatically add and remove
menu options, change colors, change icons, etc., is a situational issue (and
to some extent religous/taste) which is not really related to my original
post.

Many of us actually developing systems with Access are trying to use Access
as a RAD tool. We want to spend most of our time on the database model,
analyzing the customer's requirements, laying out excellent screens and
reports, etc. For people like me, spending a lot of time coding is not the
best use of our time. I wish I had a programmer working for me but I don't.
It's just me. And frankly, when I hear about people doing a great deal of
coding in Access I always scratch my head wondering why they don't use
another tool like Visual Studio, that serious coders would normally prefer.

I understand your point about how quickly one can learn XML and actually XML
is on my list of important areas to spend more time on. I get it. But this
logic (gee, look what you can do in code) can also lead to spending a great
deal of time programming instead of doing the things my customers need, see,
and care about.

Finally, you're right, many folks do "hand-code" their menu systems in
Foxpro and Access (as have I in both products) and I think it's great to have
that option. And that was never my point. I just want the other option as
well. I want to be able to quickly throw up a menu system and enable/disable
menu options easily in code. What Microsoft has done in Access 2007 by
leaving out a simple menu builder is like constructing a building with no
toilets and telling the residents to simply go down the street and use
somebody else's toilet.
 
D

dbguy_atlanta

Albert I take it from your post that you're doing serious Access
developement. I have been trying, with no luck, to hear about experiences
with multiuser systems deployed in Access 2007 that have at least 5 or 10 or
users doing moderate data entry at the same time and some number of addtional
users doing light (occasional) inquiries and reporting. I would be interested
in all approaches (shared MDB, ADP, or ODBC connections).

Can you report any experience with this scenario using 2007?

Thanks
 
A

Albert D. Kallal

dbguy_atlanta said:
Albert I take it from your post that you're doing serious Access
developement. I have been trying, with no luck, to hear about experiences
with multiuser systems deployed in Access 2007 that have at least 5 or 10
or
users doing moderate data entry at the same time and some number of
addtional
users doing light (occasional) inquiries and reporting. I would be
interested
in all approaches (shared MDB, ADP, or ODBC connections).

Can you report any experience with this scenario using 2007?

Thanks

I found very little difference in performance. In fact, for data, I really
can't see any at all.

On the other hand, my previous applications always performed very well. We
often see posts in this newsgroup where an application with ONE user runs
slow. Well, if the application runs slow with one user, there not going to
be much hope for mult-user good performance on a network...is there?

I of course always assume that one uses a mde (or now accde), a split
application, and a persisting connection. These are still a must for
good performance on a network.

Poor performing applications is usually the result of the developer and
one's design.

However, do keep in mind that 2007 will like and use some additional
resources.

If you been in this industry for 20 years, then you likely NEVER
recall a situation where the next version of <insert any product>
uses less memory or less resources then the previous version?

However, on any PC that been built in the last few years,
you not have really any noticeable problems, and not really much less
performance then using 2003.

Speaking about productivity tools and not wanting to code, I think the new
stacked controls for report and forms is the 1st major productivity design
in
ms-access in 15 years that substantially IMPROVES the non coding design side
of
applications.

Access has always had one of the best report writers, but if
you have a report with lots of columns, it was pure pain to insert a new
column in the the middle of the report. You had move all of the headings by
hand,
and then move all of the detail text boxes over to the right..and then try
to make sure they are just aligned right. You then try and size in the hole
you made with a text box, and THEN have to place a text label in the heading
section (and size it again!!). Really, a nutty amount of work in this day
and
age.

In 2007, you
simply just drop in the text box..and wham...everything moves over!

Note that even your heading inserted and sized for you. This is without
question the best change in ms-access in many years (in fact likely in
all of it years). The report writer was starting to drive me nuts, and
now it so much better to use. (this kind of change has been LONG LONG
over due). Even more important is forms now have anchored controls that
resize when you re-size the form (again, about time).

The other change is we finally have a built in date picker (gosh...how long
did we have to wait for that???).

Another nice feature is we can finally now include pictures in our
applications
without bloat. This means that access users can build applications with
pictures and photographs and not suffer from huge bloat. This opens up a
whole new area of applications for access that one would normally avoid
because ms-access was so limited and suffered a lot when using pictures.

Even even more cool is we now can have continues forms with DIFFERENT
pictures in
each row....in other words, we can have continues forms that shows things
like different catalog items, or even a county flag without having to resort
to a
3rd party activeX grid control.

All in all, if you one that don't want to write truckloads of code, access
2007 likely has the MOST features that lets one do more without having to
resort to 3rd partly code or add-ins, or writing extra code to make up for
its shortcomings.

I even love the navigation pane. For applications that have 120,000 lines of
code and 260+ forms, once you learn how to use the navigation pane, you
NEVER
want to go back to the old way of having a big huge tab of forms, reports
etc. that you can't filter or search on. However, you MUST spend a bit of
time
learning how to use the filter/search options for the navigation pane. Once
you do
this...you not miss pervious versions of ms-access at all...
 
J

James A. Fortune

Albert said:
...
The above is clean and easy to maintain.

In fact, after you built a few menus in 2007, you will find it is EASIER
then the
previous way to build a menu.

Another fantastic feature of those xml ribbons is that you can go on a
Easter hunt and lift individual buttons and portions of ribbons from your
EXISTING library of applications . Previous versions of access forced you
to
import ALL BUTTONS. It was a messy all or nothing affair . It really did
not encourage good coding practices , and it also made it difficult to move
menus and buttons between applications .

Remember the difference between a good developer and a bad developer, is a
good developer builds up a good library of reusable code and routines that
they can use from one application to the next. The use of xml for the
ribbon encourages and gives one the ability to lift portions of previous
menus from previous applications into your new applications. This ability to
grab parts and pieces feature alone tends to win over what we had in the pre
2007 days.

To be frank, the old system in ms-access was poor at developing menus.

Virtually ALL OF my applications before 2007 had custom menu bars, and now
they have custom ribbons. It really not a big deal, and in fact once you
build a few ribbons...you use those as starting points for new ones...

A heavy proponderance of my work lately has been corporate support in an
environment containing heterogenous versions of Access so I haven't had
much opportunity to do much XML editing for menus, so I have to trust
Albert's experience. I actually enjoy working with XML so I hope to
share his experience soon.

James A. Fortune
(e-mail address removed)

Windows XP shortcuts:

Shutdown:
C:\WINDOWS\system32\shutdown.exe -s -t 00

Log Off:
C:\WINDOWS\system32\shutdown.exe -l -t 00

Restart:
C:\WINDOWS\system32\shutdown.exe -r -t 00

-- From Turbocharge Windows XP, Robert Strohmeyer, Future Network USA

Note: %SystemRoot%\system32\SHELL32.dll contains the standard icons for
Shutdown and Logoff.
 
D

dbguy_atlanta

There is an excellent video presentation on the origin and design of the
ribbon here:
http://blogs.msdn.com/jensenh/archive/2008/03/12/the-story-of-the-ribbon.aspx

This video offers a very detailed account of the problems with the old menu
and toolbars and the thinking behind the new ribbon. Good stuff, very
interesting for anyone that's deeply into user interface design issues.

I have to admit, the video removed my skepticism of the ribbon with regards
to Word for sure and possibly Excel. However, I remain a strong skeptic of
the Ribbon in Access. Yes, yes, yes, in some particular areas the ribbon
approach is helpful in Access but on balance it still seems like 'cotton
candy' to me in a database environment, less productive than the boring but
effective traditional toolbars and menus.

For me, the Access ribbon killed my productivity during the first day or
two. Later, after becoming somewhat accustomed to the ribbon, it struck me as
inert. Now I don't really care about it one way or the other in Access except
for not having the ability to customize it built-in to Access. What I wanted
more than anything was to shut off the ribbon, get the old menu and toolbars
back, and revisit the ribbon issue after I had made up my mind if Access 2007
was even useable (i.e., trustworthy) for production databases. Too bad that
kind of vetting has to be done on a released product but that's the reality
of the current situation in software.

Frankly, Microsoft could have made me happier by simply shipping a better
command button control with Access, one that could handle both text and
graphics at the same time, about 10 or 15 years ago. It's not clear to me
what alien technology they had to uncover first before that became possible.
The third party controls are fine, but I've got better things to do than fool
around with custom install scripts, Installshield, and all of that nightmare
(been there, done that, don't want to go back).

I wonder if anybody in the Microsoft user interface group secretly agrees
with me that slavish devotion to a homogeneous user interface across
applications that perform fundamentally different tasks is quite possibly
wrong headed to begin with? It makes sense if all you care about are the
newbie and light users, but what about the proficient and expert users that
prefer a user interface tailored strongly to the task at hand regardless if
it breaks the consistency doctrine?
 
J

James A. Fortune

dbguy_atlanta said:
There is an excellent video presentation on the origin and design of the
ribbon here:
http://blogs.msdn.com/jensenh/archive/2008/03/12/the-story-of-the-ribbon.aspx

This video offers a very detailed account of the problems with the old menu
and toolbars and the thinking behind the new ribbon. Good stuff, very
interesting for anyone that's deeply into user interface design issues.

I have to admit, the video removed my skepticism of the ribbon with regards
to Word for sure and possibly Excel. However, I remain a strong skeptic of
the Ribbon in Access. Yes, yes, yes, in some particular areas the ribbon
approach is helpful in Access but on balance it still seems like 'cotton
candy' to me in a database environment, less productive than the boring but
effective traditional toolbars and menus.

For me, the Access ribbon killed my productivity during the first day or
two. Later, after becoming somewhat accustomed to the ribbon, it struck me as
inert. Now I don't really care about it one way or the other in Access except
for not having the ability to customize it built-in to Access. What I wanted
more than anything was to shut off the ribbon, get the old menu and toolbars
back, and revisit the ribbon issue after I had made up my mind if Access 2007
was even useable (i.e., trustworthy) for production databases. Too bad that
kind of vetting has to be done on a released product but that's the reality
of the current situation in software.

Frankly, Microsoft could have made me happier by simply shipping a better
command button control with Access, one that could handle both text and
graphics at the same time, about 10 or 15 years ago. It's not clear to me
what alien technology they had to uncover first before that became possible.
The third party controls are fine, but I've got better things to do than fool
around with custom install scripts, Installshield, and all of that nightmare
(been there, done that, don't want to go back).

I wonder if anybody in the Microsoft user interface group secretly agrees
with me that slavish devotion to a homogeneous user interface across
applications that perform fundamentally different tasks is quite possibly
wrong headed to begin with? It makes sense if all you care about are the
newbie and light users, but what about the proficient and expert users that
prefer a user interface tailored strongly to the task at hand regardless if
it breaks the consistency doctrine?

Thanks for the link.

My comments about Word were based on the PDC05 presentation:

OFF201: Office “12â€: Introduction to the Programmable Customization
Model for the “Office 12†User Experience (Part 1)
Speaker: Jensen Harris

Many of the early slides in the PowerPoint presentation from your link
were the same as the ones from that PDC05 presentation. My guesses,
though not necessarily correct, are based on publicly available information.

There's something to be said for consistency. There's also something to
be said for customization. Microsoft made a cogent argument that
something needed to be done, at least in Word.

James A. Fortune
(e-mail address removed)
 
A

Albert D. Kallal

in a database environment, less productive than the boring but
effective traditional toolbars and menus.

I found the ribbon far easier to use than menus. Even better is the ribbon
tends to let you develop more muscle memory. When a user navigates a
cascading menu, one little mouse jiggle the wrong way, and it like a bowling
ball falling off into the gutter. When this happens the user has to start
over again from the menu and cascade their way through again.

Furthermore those menus force one to move up/down and that means you have to
move your whole arm up/down. The ribbon encourages left/right movement to
select something and you can use your wrist to do that. And, even when you
have to move your whole arm, you still have that left/right wrist movement
available to make your shot at the button more accurate.

I'm certainly open to some debate that people might like old style menus
better, but they take far better motor skills. And, one little slip up on a
menu system and you've picked the wrong one or you have to start over. With
a ribbon if you miss your target you just fire again and away you go. It is
a more of a point and shoot process as opposed to try to navigate the mouse
down a little maze of turns.

Frankly, Microsoft could have made me happier by simply shipping a better
command button control with Access, one that could handle both text and
graphics at the same time, about 10 or 15 years ago. It's not clear to me
what alien technology they had to uncover first before that became
possible.

You do realize that one nice feature 2007 is the buttons now do have both
text and graphics capability, something we wanted for years and years?
Perhaps you explain what this new button control is missing then?
 
D

dbguy_atlanta

You might be right about basic benefits in menu mechanics/movements, I'll
have to take another look at that aspect. Unfortunately, very few of my
clients have been willing to upgrade to Office 2007. Some are large
organizations with huge training costs that are always a version behind, so
I'm not getting much feedback "from the field" regarding the ribbon and
whether a lot of people feel it's a step forward in general.

On the command button control issue, I meant to imply that I think it's
shameful we have had to wait all these years for the simple ability to have
text and graphics displayed on a command button at the same time (let alone
all the other features that are available in third party button controls).
Like many others, I'm quite capable of adding third party controls to my
projects, using the various installation tools to get them installed at
client sites, etc. I've done it in the past for Visual Basic systems and
Visual Foxpro. But in my opinion, distributing custom controls and dealing
with InstallShield (and the like) is a horrendous waste of time and resources
for a small Access shop unless you really can't avoid it based on what a
client needs to do. Seems to me that small Access shops need to concentrate
on systems analysis, database modeling, screen and report layouts,
documentation, training, etc.

Microsoft was very close to providing a good set of controls in Access, the
omssion of a good command button always stuck out like a sore thumb.
Especially when they never bothered to correct it, year after year.

I look forward to many of the benefits in AC2007 when I'm comfortable
deploying it. Buggy deployments cause too much havoc for me in my business.
The one 2007 application I have a lot of experience with, Outlook 2007, is in
my opinion very buggy and not ready. I got rid of it after several months of
use. I know plenty of others would disagree, and to them I say "go with God,
if it's working for you, great!" However I doubt whether quality in Access
2007 is much better than what I found in Outlook 2007 so I remain skeptical,
testing, and accumulating experiental data from other consultants.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top