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!

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 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.

blogs.msdn.com/.../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: blogs.msdn.com/.../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. blogs.msdn.com/.../access-communities.aspx