Microsoft Access Team Blog

PingBack from http://www.artofbam.com/wordpress/?p=5295

PingBack from http://msdnrss.thecoderblogs.com/2007/10/04/access-2003-access-2007-ui-guide/

That's neat. I'm just getting into Access 2007 in a serious way, and have been stumbling a bit trying to find things. I found this clever, helpful, and fun!

Thanks!

I recently posted in an Access user group some issues I have with Access 07 development policy. (See here: http://groups.google.co.il/group/comp.databases.ms-access/browse_thread/thread/b6685f4b9caf7488/08c5946a73ca33c6?hl=en#08c5946a73ca33c6)

I got some interesting responses there. I would like to try to organize my thoughts again here, with the hope that it will be read here by the people that make things happen for Access.

For my argument I want to make a distinction between two general types of innovation:

1, Large leaps, new functionality.

2, Incremental changes that improve and maintain the existing functionality.

I believe the Access team policy suffers from three problems:

1) I believe that a balance should be found between these two types of innovation stated above and that the Access team prefers the first and very much downplays the second.

2) Not only that, but these leaps of development have often been incomplete and discarded before completion, so the product has been maintained in a state of construction and work in progress over the years, and never really reached satisfactory stability for a very long time. (eg DAP, Security)

3) When these incomplete innovations are introduced they sometimes replace existing functionality without giving the developer a choice between the two. (eg ribbons vs toolbars and the interface to build them)

My guess is that the preference for more radical innovation is due to the fact that it is more fun for creative people to involve themselves with ingenuity rather then with maintenance. Maintenance is boring and radical innovation is futuristic and pioneering.

Also, as one commentator pointed out, it is possible that this way they hope to keep people in a frustrating state of need so they will have to keep upgrading. This can be a good business policy but it can also backlash when people get so tired of promises for the next version.

Let me make it very clear that I very much like Access and also like radical innovation, but only if these improvements are “baked” enough and only if the product maintains some stability that I can work with. I find it unacceptable that, as many people say, the last stable version was 97.

Let me give some examples for the current 07 version

- Navigation Pane as a substitute for the old Database window (see discussion here: http://blogs.msdn.com/access/archive/2007/10/03/sorting-nav-pane-objects-by-description.aspx)

-The security being removed

-The introduction of ribbons without an easy user interface to implement them. (I need to learn a new language to implement them and I don’t like how they hoard screen resources. I want and need the previous toolbar scheme.)

-The removal of the interface to handle the toolbars.

-The terrible inconvenience when running the 07 runtime on a machine with Office 03 installed (an extremely likely scenario). The office CD needed each time the application is run? (see discussion at bottom of page here: http://blogs.msdn.com/access/archive/2007/09/27/ribbon-customization-using-a-dynamicmenu-to-show-a-list-of-open-objects.aspx)

This issue is really a killer as far as deployment goes.

-Package and Deploy wizard is provided free, but it is not ready to be used. I wonder who will ever use this feature since it provides no way of marking files as ‘never overwrite’ or ‘always overwrite’. For me this renders the feature as completely useless.

And there are many more issues, as described here: http://allenbrowne.com/Access2007.html

Over the years there were similar issues in previous versions as well (ADO replacing DAO and back again comes to mind, but I am sure many developers can recite numerous other examples if you don’t like mine).

Because of these issues I don’t believe a lot of people use access to deploy shareware over the net, like off the shelf software programs for different purposes. Isn’t that a big enough and unique market that Access is missing out on? My guess is that it is used by people to develop their own simple applications that do not take advantage of Access’s real capabilities, sort of like Excel for advanced users. But isn’t this a relatively small market? Or it is being used by developers who are hired by companies to build custom solutions and which require much onsite maintenance.

To further clarify my point here is a list of what I would call mainly maintenance issues that would make Access better for me:

I want the toolbars back. I want the 07 runtime to be able to run on machines with 2003 without causing the user to want to poison me. I want the choice of developing ribbons with an easy user interface or the choice of not using or at least minimizing their size. I want security. I want improved deployment. As I continue to develop my applications, I want to easily deploy the upgrades to my users via Internet, preferably with minimal effort on their part, if any (this will help Access compete with Internet applications that have no deployment problems at all since all a user needs is a browser).

What is frustrating is that it seems most of these issues should be relatively easy for the access team to incorporate, but they will make a very big difference for me. I will be able to try and deploy my applications as shareware products with less worry about support issues.

So what I am basically asking for is more consideration for us developers who are also looking for stability and maintenance to accompany the innovation in Access.

Again, I didn’t mean to rant but to provide constructive criticism in the hope that it will have an incremental effect somehow in developing Access further. I like Access and care that it will stay and develop.

Thanks for reading

Gilad

Gilad, thank you so much for your feedback.  One of the most important reasons we have the blog is exactly this: so that the product team can get direct candid feedback from the developer community.  

The overall sentiment of your post seems (at least to me) to be right on.  There is a balance for us to strike between providing incremental improvements and making big bets that are major functional changes to the product.  It is never easy to strike that balance, and it is something we think a lot about.  One example of how we're always considering the needs of our customers with in-market solutions is the VBA/COM OM interfaces.  From the outside, it may seem like this would be easy.  Just don't change that code, and there is nothing to do there.  In reality however, we put a tremendous amount of time and effort into trying to keep developers' solutions running from one version to the next.  Office is one of the biggest and most complex software development projects of all time, and just making small changes can have wide reaching and unexpected ramifications. We've got ~25 of the smartest C++ software engineers you'll ever meet.  Each version they spend < 20% of their time writing new features.  The rest of it is devoted to security, reliability, internationalization, new platform support (e.g. Vista), and backward compatibility.  Believe me, we really want to keep your solutions working from version to version.

That said, you've made some great points, and I really want to take the time to try and address the product group's perspective on each of the issues you've listed as your primary concerns.

On the Navigation Pane: conceptually the nav pane is very similar to the DBC.  There are lists of items that you can organize different ways.   Its implementation is definitely different than the DBC in some ways though.  As part of the redesign of Access 2007 to use tabbed UI instead of the old circa Win95 multiple-document interface, we needed a way to host the database objects that was integrated into the Access Window.  Do you use tabbed documents, or are you still on overlapping windows?  We've found in usability that tabbed documents are dramatically easier to switch between than the the old style overlapping windows were.  You see this kind of metaphor all over today, especially in the web, were tabs have recently been added to IE, FireFox having them for some time.  The Navigation Pane is very flexible, and as I mentioned in that cross-listed post you reference, I find the search functionality to be very compelling.  I've had to re-train myself to use search to find objects, but now that I have, I have to say it is much faster than the DBC for me. That said, if you've got some specific feature requests for functionality you had in the DBC that you can't get in the Nav Pane, please let me know!  

On security, you may or may not be aware that the old Jet users and groups functionality is not recommended for use as a security feature.  The reason for this is because Jet is a file based database.  Because it is just a file, custom Windows code can be written to read and write the contents of the file without ever using Jet.  If Jet isn't in the picture, then the users and group permissions are not being enforced.  In this way, any user with access to the file and that tool can read any part of the data file, bypassing the Jet user and group semantic entirely.  I totally understand your desire to provide security between users.  This is a great scenario, and absolutely something that I can see a need for.  Jet users and groups is not the right technology to provide that support, which is why we took it out of .accdb files (still in .mdb files, again for backward compat).  The only way to build in meaningful security in a database system is to secure access to the storage file itself.  What this means for Access developers today is that they should be using Windows security to secure the file, or if you need per-user permission within the file, SQL server, SharePoint, or another secure ODBC back end.  If what you're looking for is personalization (keeping honest users honest) instead of security, check out Northwind 2007.  It shows how you can accomplish this, having different forms for different users.  You don't have to use a dropdown UI like this one if you don't want either.  One of the things I like to demo is using the Windows user name to accomplish the same kind of experience without the user having to select their ID.  Again, this is not security, but personalization.

Yeah, I agree that Ribbons are hard to build, and that it would be nice to have some easier solutions.  We're working on that right now, and you can expect to see some good stuff coming out of VSTO in the near future.  Here's a link to a demo on their blog of the new ribbon customization feature for Access 2007:  http://blogs.msdn.com/vsto2/comments/590108.aspx

On Command Bars, these should still work if you've got a deployed app that is in runtime mode with custom menus and commandbars.  On the whole though, Office is moving to the ribbon, and this isn't really something Access gets to make its own call on.

For setup, hmm... you shouldn't need the CD each time.  That only happens if you choose to not cache the installation sources on the local machine (not the default).  I imagine Anders has the same problem with switching between any two versions of Office on his computer.  For what its worth, we're looking and making some investments here which will go a long way toward improving this experience in the future.  That said, those don't help you now, and your feedback is well taken, although with a share of frustration.  The reason previous versions of Access don't have this re-setup logic is because Access was running some special logic to re-fixup the registry when it starts, so that the most recently started version of Access could run correctly.  Having the current version be the running version is absolutely required because of the way COM works and libraries are registered, and there is really no workaround.  In 2007 we fixed the bug where Access was re-registering itself without using setup because although we got away with that behavior for years in WindowsXP and previous versions,  the enhanced security system in Windows Vista calls our bluff, and we're not allowed to change the registry on startup anymore.  Believe me, this change was not made lightly.  We didn't make it because we wanted setup to be slower for side-by-side.  On the contrary, it is really, really, really important for side-by-side to work as well as it can, which is why we've done extra work in SP1 to make the re-setup of 2007 run more quickly.  Access is always the biggest proponent for side-by-side in the whole of the Office group.  We absolutely want it to work, and work well.

On the package and deploy wizard: good feedback.  I can see why you would want that.  If it is a requirement for you to have very granular control over the setup process, then your best bet is to pay for your own copy of Visual Studio, or to purchase another 3rd party setup solution.  The package wizard is a free lightweight tool which should work well for simple install scenarios, but which definitely won't fulfill everyone's deployment requirements.

Finally I want to address one of your questions: "My guess is that it is used by people to develop their own simple applications that do not take advantage of Access’s real capabilities, sort of like Excel for advanced users. But isn’t this a relatively small market?"

Great question.  Fabulous question, in fact.  Let me answer it this way: Access is installed and used by >100M users around the world at least once a month.  The vast majority of these are users in a corporate environment using Access just as you describe, as a lightweight data tracking, analysis, and reporting platform.  Access databases are great for spinning up quickly, solving a targeted data management problem, and then going away.  Generally speaking, people who are building shareware, or who are doing other types of more traditional software development will be better off choosing a platform like VB.Net.  Access is always going to be quick and easy to get going with.  Where we have opportunities to invest in making it more approachable and more usable by a less technical crowd, you'll see us take them.  Why?  Because Access is Office.  Office is chartered to help individual users, groups, and organizations meet their business needs, and Access participates in that charter as the tool for building custom data tracking and management experiences.  By contrast, the Visual Studio group is chartered to enable software developers to build generic software solutions.  VS is the platform, with a goal to make it possible for developers to build anything they can dream up.  For that reason, you'll see that they are very careful to make investments that give developers the flexibility they need to accomplish almost any scenario.  Overall capability is the focus for VS, whereas for Access the focus is on accomplishing specific business goals.  

Zac:

"On Command Bars, these should still work if you've got a deployed app that is in runtime mode with custom menus and commandbars.  On the whole though, Office is moving to the ribbon, and this isn't really something Access gets to make its own call on"

Me:

Ribbons are not enough flexible: you cannot customize the height and include your own icons (like with old commandbars).

Moreover Ribbons does not replace the ShortCutMenuBars: why Access 2007 doesn't support a shortcutmenu editor?

Zac:

"Office is chartered to help individual users, groups, and organizations meet their business needs, and Access participates in that charter as the tool for building custom data tracking and management experiences

By contrast, the Visual Studio group is chartered to enable software developers to build generic software solutions.  VS is the platform, with a goal to make it possible for developers to build anything they can dream up.  For that reason, you'll see that they are very careful to make investments that give developers the flexibility they need to accomplish almost any scenario.  Overall capability is the focus for VS, whereas for Access the focus is on accomplishing specific business goals"

Me:

Are you joking Zac?

In the world there are hundreds of Access commercial-DB applications, and you write it?

This blog is attended *only* from DATABASE (!!!) developers: if Access is *only* a product for stupid final-users, you must close it (the blog).

And you can cut from Access ODBC connectivity, Visual Basic language and Runtime-Developer edition...

Microsoft developers are (rich) *professional* developers: therefore MS software SHOULD not contain any bugs.

WE are that we choose the product that WE prefer in order to develop our  (DATABASE)  applications, and ANY *professional* MS product  (Office, Excel, Access, WORDPAD, PAINT, WIN CALCULATOR ...)  DOES NOT contain serious bugs.

If a *professional* DB-RAD works fine (Access 2.0 and Access 97 as an example), it can be used from final customers AND also from developers!

OK?

Bye

Gosh Zen, I guess I don't agree with your assesment of the intellectual prowess of Access users.  I actually think Access users tend to be some of the brightest of all users of Office.  They are capable of managing a mental model of realatively complex data tracking systems and building a targeted solution which addresses a specific business need.

Make no bones about it, connecting to ODBC data sources such as SQL, scrubbing that data, and creating reports on it, is something Access is uniquely well suited to, and something that one does not need to be a professional developer to do.  

On your comment about Microsoft developers being "rich", I only wish that were true.  I've worked here for 8.5 years, and I can afford a 1600 square foot 3 bdrm house 45 minutes from work for my efforts.  People who work here do it becasue we feel passion for what we do, not because we are getting rich by doing it.

You're absolutely right about one thing though, Access is used by a broad spectrum of users.  It is an awesome tool for data-minded people who need a quick solution to a business need.  We recognize this, and if it wasn't clear from my previous post, we continue to make investments to enable developers who want to take advantage of our new feature sets.  Every feature we add has VBA programmability support.

I found the creation of a ribbon one of the easier parts of the conversion of a Access 2000 application to 2007.

I have lots of past experience with XML and I generated the initial ribbon XML from business requirements using VBA.

I even got a book for demonstrating my ribbon efforts.

http://blogs.msdn.com/clintcovington/archive/2007/04/28/tell-me-about-your-ribbon-app-get-a-free-copy-of-access-2007-inside-out.aspx

During the conversion I demonstrated several of the bugs in Access 2007. A couple of them even have hot-fixes (but the hotfix won't "fix" runtime-only installs, a manual overwrite of the patched dll was required there).

However the biggest problems I faced were internal. That is trying to add new business requirements to very old code, then test to see if anything was broken. These problems had nothing to do with Access itself, just the way it was built upon.

Yours

Keith Morris

Dear Zac,

Thank you for your detailed response. I appreciate it very much. I do not take for granted that I can have direct access to a member of the Access development team. I don’t know if this is possible for other programs, like the development team of Excel or PowerPoint for example. On the other hand I assume there is less need for such communication with those program’s teams, which brings me to my next point:

I want to address your final comment that:

“.. Access is Office.  Office is chartered to help individual users, groups, and organizations meet their business needs, and Access participates in that charter as the tool for building custom data tracking and management experiences.”

I can’t argue with your numbers, but I find this difficult to understand. Access is a complex program to learn how to use. I believe that in order to begin to benefit from it you need quit a bit of training, sometimes even years. This is very different then all the other programs in the Office suit. I know several engineers that after trying to learn Access they still try to treat it as Excel. They don’t understand why it is so much easer to create a table in an excel sheet so why should they bother to do so in Access. If you try to target the end user market for such a program then it will probably just like keeping piano lessons to three year olds. After you are four please move on to the next instrument. Isn’t it a shame that the level of playing for this instrument will never rise? Sorry for being a little metaphoric. It’s this time of morning and I am still a little dreaming.

Basically what you said to me is to move on to Vb.Net. But I don’t want to. I will have to learn a complete new set of skills. It will take me years and I just don’t have that kind of time or will power. I’m not getting any younger you know. I already have a good set of skills that I spent and exorbitant effort in acquiring.

I think you are very professional in your attitude. Your response is cordial and sincere as always, but I still got the feeling my complaint somehow passed you by. I don’t really know the degree of influence you have on the rest of your team either, so even if you would have agreed with me I can only hope it will have a real effect somehow. But it is still my impression that when it comes to the core content of your reply, and not just to its polite form, these complaints that are sounded by many people are not really treated as valid or important enough to make any change. You think it is either based on my mistake, lack of knowledge, fear of the challenge, laziness, or that I am using the wrong instrument or that there are things that are required of the Access team from above so you can’t do anything about it anyway.

Just to give another small insignificant example: From what I read Access 07 has a new feature for Form resize. The forms resize and so do the controls, but the font size stays the same. So if a screen resolution changes by the user, she may end up with a full screen form with ever so tiny fonts that would look ridiculous. This is not a ready feature.

I also recommend you have a look at the first post I referred to in my first comment above. More experienced developers are adding their interesting replies there as well.

I do appreciate your time reading this very much.

Maybe the recap message should be that developers are people too, or something like that.

Have a great day

Cheers

Gilad

Zac, just a few comments in response to some of your statements.

1)  "The only way to build in meaningful security in a database system is to secure access to the storage file itself."

With all due respect, I don't buy that.  Lotus Notes manages to secure local files in such a way that they've never been hacked in the product's 20 years and they provide granular user-level security.  I consider that proof that it is possible.  Maybe you should talk to Ray Ozzie or Gary Devendorf.  :-)

2)  "Believe me, we really want to keep your solutions working from version to version."

Again, I'm not buying this.  If this were true you wouldn't be ripping out features and making wholesale changes that render applications useless or inoperable on newer versions.  I've been using Access professionally since 1995, and I used the Access 97 developer exam as an elective for my MCSD in VB5.  However Access 2003 is going to be the last version I work with unless meaningful enterprise development features start reappearing.  I use VS.Net, too, but that's for an entirely different class of software than what Access and Lotus Notes targets.  If Access could provide replication and granular security (meaning, row-level, which even SQL Server doesn't have out of the box) I'd drop Notes in a heartbeat.  It doesn't, and the trend seems to be to gut the professional grade features and turn Access into Excel with a reporting engine.

Thank you Gilad, you are quite eloquent in your responses, and it is cear to me that you've thought hard about what you wanted to say here.  That is awesome.  I love that we have people who are emotionally involved in the product, and want to see it succeed.  

Regardless of the outcome of this discussion, I want you to feel like really am listening to you.  I absolutely hear what you're saying, and I understand why you want it.  I'm also our MVP coordinator, and I can tell you that many of the folks in that group would hardily agree with many of your sentiments.

In the end of the day, the focus of the Access business will always be to try and grow our installed base, try and bring new customers to the platform.  Just like with any business, we need to keep growing in order to survive.  In order to do that, there are two things I think we need to do.  

1) We need to continue to make invesments to help our existing customers improve their own apps, so they can stay competitive in the quickly evolving world of data tracking

2) We need to do things that appeal to a new breed of users so that we can increase the size of the total user base for Access

Like you state above, we always have to balance this new work with the work to just make changes we know people want to have today.  Examples of things we did there in 2007 are export to PDF, Scroll-wheel support in VBA, Date Picker for Date fields, Trusted Locations (no security prompts on boot), Better Image Support (PNG, GIF, etc...), Pictures with Captions on Buttons, Report View, Easier Filtering in Datasheets, Layout View for Reports, etc...

The feature you mention for forms... do you have more detail here?  If you're talking about anchoring, this is a feature that allows you to have a control automatically resize with the form window (.net windows forms also has this feature).  We know a lot of people write VBA to do this in 2003, so we just built it in as a feature to 2007.  It is governed by a property on the control, and it doesn't happen by default.  You as the developer need to explicitly enable this behavior by setting the property.

Cubert: I'll be interested to see what you think of Access 14.  

Zak, You stated in an above comment:

"One example of how we're always considering the needs of our customers with in-market solutions is the VBA/COM OM interfaces."

I have been using ActiveX Controls from DBi Technologies (www.dbi-tech.com) for several years and have had to suffer with the fact that only SOME features worked because of the NON-STANDARD implementation of the ActiveX Com model.  Access has long been blamed by most ActiveX control developers to the point that they won't even support their products with Access.

Like many developers I want to use advanced controls like treeviews, shortcut bars, HTML frames and editors, etc.  My questions are these:

1. Will there be any greater success in using existing ActiveX Controls within Access 2007?

2. Will there be any new controls provided for the next version of Access?

3. Are you working with any 3rd party control companies to create new controls for Access?

4. Are there any general architectual issues with using 100% ATL Controls with Access?  (like those at Exontrol.com)

5. Is ATL an approach that makes sense for Access Developers using Vista and Office 2007 and above?

Thanks for any comments on these issues.

Mike

Thanks for the UI guide.  End users at our campus have been using the one for Excel since our Office 2007 roll-out and it's been very helpful.  I had hoped to eventually see one for Access, and here it is.  Thanks also to the powers that be for making the downloadable Flash-player (.exe) versions available.  

Thanks wheat!

Michael: thanks for the feedback on this.  Check out my latest blog post.  This is a great issue to bring up with Dany: http://blogs.msdn.com/access/archive/2007/10/11/a-chance-to-influence-the-direction-of-access.aspx

Beyond the new security model and trusted locations, there are no significant changes to our ActiveX model in Access 2007.  ATL/COM is always an option for Office developers, but it his really hard to generically state whether it makes sense without knowing your situation in detail.  The best place to work through hthis kind of question is definitely the community sponsored newsgroups.  If you've got a thread going there that you'd like me to read or jump in on, I'm more than happy to do that, just give me a pointer.

http://blogs.msdn.com/access/archive/2007/07/31/access-communities.aspx