Give us feedback – How can we help you work faster and more efficient?

Raymond B Starkey said: "Can we have a small area in the query and table designer to make notes so that someone supporting the code can be advised as to why the query/table was put together in a particular way." YES YES YES PLEASE!!!!

Query Designer needs to have a Yellow Post-it-Notes ability

I agree to Banana, I would like MDE to me more secure so please Can MS license Wayne Phillips' tool to strip out the compiler stuff/junk to make the reverse engineering much harder. Thanks

A couple of really simple things (some of which could even make it into 2010 perhaps!). When dragging a field onto a form please, please,please can you copy the field Description to the status bar text and tool-tip - I use this for my user notes and it is far more useful than copying the fieldname to the tool-tip (which is the current default in 2010 and is virtually meaningless to the end-user). I often copy objects within a database (such as to make a backup of a complex form/report/query before editing it or copying a template form). Would be nice to have 'Duplicate' as a right-click menu option, instead of copy, paste, type in name (just default the duplicate to 'Copy of objectname') In the old database window (pre 2007)you could do a click-pause-click on an object in order to rename it. Would be nice to have additional metadata fileds against objects, e.g. author. The thing I miss most about the old database window is the ability to quickly view and sort objects by their metadata, especially when working on a database containing a lot of objects. The team have done a lot of great work on the 2010 release. It would be nice to incorporate even a few of the simple UI suggestions, which by comparison would be quick, easy and low risk to do, but would make a BIG difference to the everyday experience of developers. I am hoping the Office Team will follow the excellent example of the Windows 7 team which did this late in the development cycle following feedback and ideas from participants in the public beta...

Thanks for asking. I have faint hopes these ideas will find their way into Access. - Re-read our feedback on the navigation pain from a previous blog question. I’m always clicking and scrolling, hunting and pecking trying to find objects. It is disappointing to not see changes in Beta 2010. I’m still hoping you will fix it before it is final.

- Make it easier to fill down a series of fields. Excel fill down is so useful—why not in Access?

- Hold down on the next/previous buttons use to quickly scroll through records. This was broke in the 2007 “upgrade.” Please bring it back.

- Find and replace in SQL view. Quite amazing you have to copy and paste into notepad for a simple find/replace operation.

- Please, please, please maintain query formatting. I use SQL view for almost all queries and it is painful.

- Love to see Speed Ferret integrated into Access. Changing field names is too hard.

- Bring back command bars. Switching between objects in design view always shows the wrong ribbon. Command bars worked perfectly. I’m always hunting and pecking for commands with the ribbon.

- How about a close x on the tabs? Even better—give us a Close Other Tabs right click option.

- Not a big fan of macros but if you must for web apps—give us find and replace. - It would be super cool to allow design of SQL link tables.

- Link table manager is horrible. Please fix.

- Community VBA code library would rock. I’m lazy and would rather not write new code.

Neha: People hate the ribbon because they don't know how to edit the ribbon. Please give access a way to create a custom ribbon, and edit an existing one, with a nice UI. people will love the ribbon if you guys do this. Other than that, we need better SQL integration. keep on doing the good work. . Edwin

@Edwin: "People hate the ribbon because they don't know how to edit the ribbon. Please give access a way to create a custom ribbon, and edit an existing one, with a nice UI. people will love the ribbon if you guys do this." It is a mistake to assume that people will love the ribbon if you just to this or do that. Yes, I'm well aware that YOU like the ribbon, from your previous inputs. But do not assume that everyone likes the ribbon. I'm forced to use the ribbon in my copy of Snag-It from TechSmith, and I hate it just as much there, as I do in Office 2007! Tom Wickerath

Edmin - "People hate the ribbon because they don't know how to edit the ribbon. Please give access a way to create a custom ribbon, and edit an existing one, with a nice UI." I have to be emphatic here: This is not the solution we want, and ability to customize will only worse the state of affairs. I'm all for easy customization for _finished application_, but as a way to fix problems with ribbons to use Access itself? No. Bad defaults can't be fixed by simply enabling customization. There are several great software that are practically unusable because it has been heavily customized between each installation that nobody but the owner can use it. If you don't think that happen, take a look at Eclipse, a IDE for programming in Java. Nobody is willing to share down on someone else's installation of Eclipse because then they'd have no idea how it was customized. So, bad defaults simply must be fixed. Customization is only a band-aid and will make the problem even more worse. Finally, just because people hate the ribbon doesn't mean they do so without cause. That remains true even if they don't completely understand the reasons why they hate it. It's one of those things that can be difficult to articulate for some people. I've already gave some of reasons why it can be a frustrating interface and I still feel it's ultimately a wrong solution. If you look at Access 2010, "File" button is back. I'm given to understand that Microsoft developed ribbons out of heavy research on how users use, but the fact that there are far more people who are dissatisfied with ribbon than not suggests to me that the research may have not been complete or comprehensive, and indeed others has provided research into why ribbons doesn't work as well as menus. For all its fault, nobody thought to try and customize Office 2003's menu systems. It was "just good enough". If we need to customize the ribbon just to use Access, then that's a worse state of affairs to me.

Quote from Edmin -

“I'm given to understand that Microsoft developed ribbons out of heavy research on how users use” I wrote this here before and I will write it again. The head of the team that researched and developed the ribbon stated that it was intended to help deal with the many thousands of commands that have accumulated in the Office programs like Word or Excel over the years of their development. Even if it is helpful in that respect, you can not compare Access applications to ‘applications’ like Word or Excel. It is rare that an application developed with Access will need to handle many thousands of commands and menus. So I think that to take research done on heavy Office programs and draw conclusions from it that will apply to light Access Applications is just silly. Maybe the Access team is neglecting the issue of the Ribbon and its customization in order to force users to look into Web applications. Gilad

Gilad, I do believe that's my words. :) Now to be fair, remember that Access is a part of Office, and from what I understand ribbon is an Office construct, and it kind of makes sense they want a uniform UI for all products in the Office suite, so it is possible that it may have been not Access team's decision to make. That said, that doesn't negate your excellent point - we have to remember that Access is itself an IDE, a database engine and an application rolled into one package, and while it's possible that ribbon is wonderful for the finished application (indeed, I do see good uses for it myself and believe it's more flexible than the old commandbars, barring the fact that you have to know XML and some programming techniques and WYSIWYG editing but I'm thinking more about portability and reusability), I really can't agree with using it as an IDE.

Banana,

I am sorry for making the mistake in which I did not correctly attribute the quote to you :)

You are the rightful owner :) As for the comment itself, I was not referring to the development environment (IDE). I agree with you that Access is part of Office, and that it makes sense that they want a uniform UI for all products in the Office suite. So for the IDE maybe the ribbon would be justifiable. I was rather talking about the fact that the applications we develop using Access are not part of the Office suit. When you develop an application to run a small business or a small Hospital or a Disk Cataloger or what ever else, you no longer develop an application that needs to be uniform with Office, and thus does not necessarily need the ribbon. You develop an application that does not need a ribbon that was developed in order to contain thousands of menus and commands suitable for the Office programs. There must be some other internal reasoning behind the decisions made by the team with regard to the ribbon, because as it seems it does not make any sense, at least not to me. I do like the direction that I am learning about here with regard to Sharepoint. It seems very neat. I just hope this will not come at the expense of existing technology, like MDE, ACCDE, rich client etc. Gilad

Gilad - No worries on the misquote. It wasn't really that obvious so my bad as well. :) Thanks for the clarification. I still feel that ribbon as the UI for Access the IDE is not the optimal solution - earlier in this comments thread, I posted asking whether there's a plan to introduce ribbons to Visual Studio and SQL Server Management Studio and if not, then why not? Those should benefit more from ribbon UI than other applications. If that's not the case then a hard look at ribbon may be warranted, IMPOV. Your point about deploying an application within Access is very well taken - I never thought about that way but yes, I can see why a "finished application" shouldn't have to look like an Office application. Though I disagree with the ideas of ribbon, I can confidently say I'm quite optimistic about Access 2010 and the future version. :)

1) In previous editions of Access, reports were able to be saved as Excel. This was supposedly remedied with Service Pack 2 (maybe someone at Microsoft can explain why it was removed during the initial release and we had to wait a year and a half to get back some basic Access functionality). I spent hours and hours but SP2 did NOT solve this. I really hope that the next version does not have this problem. I'm amazed that people at Microsoft really thought that saving a query as Excel is really the same thing as exporting a report. Don't they know that we create reports because of formatting and grouping? 2) Applications created with previous versions of Access were created with menus and toolbars which are not editable in Access 2007. Creating a new version of Access does not make the millions of actively-supported applications "legacy". Going from being able to drag and drop commands to a toolbar to having to code in XML is called "progress"? I'd gladly forgo the functionality offered by the ribbon in exchange for being able to manage my existing toolbars. I almost laughed when I read from someone on the MS development team that this won't be solved in Access 2010 because there are third party tools for this. Paul

@ Paul Two quick notes here: Access 2010 reports export as excel like in previous versions. I not aware this was changed. As for the ribbon? There is also now a ribbon customizer that you can use and you don’t need to see or learn XML. So, you can just right click on a ribbon and select customize to add new groups, tabs and buttons to that ribbon.

@Albert 1) Good to know that the Excel export has been restored. I know that upset many people. It begs the question: what will they remove this time when Access 2010 is released and promise to restore only in a few years to come in a service pack? 2) Can the new ribbon customizer modify existing toolbars or will we still be stuck only being able to modify them using Access 2000-2003? Thanks Paul

@Paul I don't believe the export to excel was removed. There was a issue of linked excel data due to a lawsuit (someone had a patient on editing of linked data in a spreadsheet - go figure!). The courts ordered that functionally removed. So some functionally was removed here. So, while editing of linked sheets was not possible, exporting of non linked tables should have continued to work. The ribbon customization system is for ribbons only. So, it has nothing to do with menu bars and toolbars. So, to be clear: The answer is no there is no relationship to menu bars here. The ribbon underneath is still xml, but you just don’t have to see it or look at it when you use the ribbon customer in access now. Nothing here is for the menu bars. There’s no use having two paradigms when you are developing applications. You wind up with two sets of code, two sets of documentation for training and a whole bunch of other issues. Pretty much the ribbon is the way forward here. Even the paint program inside of windows 7 now is a ribbon. And, even in a web browser for most of the SharePoint management features use a ribbon. The ribbon works well in a browser as it provides MUCH larger targets when using an iPhone or simply just shooting at a big icon on the ribbon with a pen based tablet. Those little menu bars are hard to use with your mouse or fingers if they slides off as you try to navigate down that menu bar. And, if you accident drop off that menu bar as you slide down, then you have to START over again. Big easy targets that you can shoot at and take another stab at is just a tap tab tab type of process and works better for finger touch and pen based computing. And, with auto-hide on, you get more screen room then you had with a menu bar. I found that using xml in 2007 for the ribbon was easy. In fact, once you built one, then it is a simple matter of cut + paste, and it even faster then the menu bar system. I always found that menu bar system quite difficult to learn in access, and it was VERY hard to go to other access applications and pull out parts of menus. With xml, you can go raid any other menu bar in ANY of you your access applications, and it then a simple cut + paste. We could never do this rapid pulling out of bits and parts of menus out of previous access applications with such speed and ease like you can with 2007. The real power of xml is this easy cut + paste ability. Importing and worse exporting menu bars in access 2003 was terrible, in fact worse then terrible and was near impossible to manage as a developer (access was weak in this area). I often had a few buttons on a menu bar in one application, and trying to move those buttons around to other applications is painfull (worse then worse). In 2007, it is just oh so easy to grab those ribbon parts. You eventually need some strategy here. We are just a month away from the 2nd version of office that has the ribbon and it is here to stay (like it or not). The only thing I can suggest is to come up with a productive way of working with the ribbon. Once you learn the cut + paste, you find this approach many times the speed and more flexible then trying to work with those menu bars. And, most important is this cut + paste allows you to build ribbons far faster then the old way.