Access : Admin tool for web apps

Published 31 October 07 01:55 PM

A common challenge with custom web applications has always been customer maintainability. In most cases the admin interface is left until the last min of development when budget is short and all resources are tied up fixing bugs and making the end user experience better. Once an application goes live it's very rare to see a large commitment made to the back end admin site since the pressure is always on to make the public face better. The net result is customers need to rely on external developers to support many aspects of the site as well as deal with poorly designed and rough around the edges admin tools often requiring workarounds just to get their jobs done.

Access had a great role to play here and I have used it several times in my old company to get some great results. Releaseme.ca is a small Canadian startup that helps you get our of your car lease early by matching you with someone looking to take over your lease. Most of the work was on the public facing website as they needed to create a rich and inviting user experience (Check out the cool AJAX Search). At the end of the day however they have a business to run and the back end admin is a very important component in the success of the site. Since we knew they needed a flexible, cost effective solution that they could extend and update without us, we created their web admin tool in Access. This allowed us to create a rich user experience and work side by side with them to make sure it matched their needs. The rich client provided an easy way to get rich ad-hoc reports, give them a powerful query engine into their web site data that they used to track order trends and sales. It also allowed them to add a CRM infrastructure around their customer database which helped support an affiliate and referral system as well as a dealer program. Now when they need to add functionality they can call my old company, any other access developer or as with most of my old clients take a stab at it themselves. I have never seen a VP program Ruby or C# but I have witnessed plenty creating their own Access reports and custom queries.

Web

  • Rich end user experience (for the public)
  • Search for cars, post listings, get reminders and feeds, save searches and sign up for programs
Web Application Content Page
Web Screen Shot

Access

  • Rich end user experience (for admins)
  • Track & report on sales and programs
  • Process and approve listings
  • Control web site meta info (Car Makes & Models, Engine Types etc...)
  • Grow and manage customer relationships
  • Manage website text content (Using the nBit ActiveX HTML Editor)
Access Content Manager
Access Client Editing Screenshot

Modern web apps mixed with the user empowering richness of Access are a great combo. 

We would love to hear about other solutions to web integration from the Access community!

Comments

# Tony D'Ambra said on October 31, 2007 6:15 PM:

This is fine for web developers, who may be doing such integration, but how about some substantive articles on the real issues that faces most of us in moving from earlier versions.

# Ryan McMinn said on October 31, 2007 6:31 PM:

Heya Tony; Oli has a great site at http://www.access-freak.com/ that's all about moving from Access 2003 to Access 2007

# Steve Goldring said on October 31, 2007 9:02 PM:

Ryan,

I'm impressed. Generally I stay away from custom controls in Access because of a terrible deployment experience on different PCs, but you've made a good case for the nBit. In A2007 would you consider the new built-in rich text option, as it outputs HTML?

# Gilad said on November 6, 2007 12:10 AM:

I would like to comment on one of the previous topics of this blog from the 16 October titled “Millions of blog hits and template downloads”. In that topic Clint mentions some impressive numbers relating to Access. I already wrote there in response, that these numbers may not actually tell the whole story and may not testify to the success of Access as it may seem. There may be more to these numbers that need clarification. To be sure, I do think that access does deserve to be popular because I believe that it is a very good application creator and a great program.

Now I would like to continue and add some numbers of my own. In the gigantic world of software, there are probably millions and millions of freeware and shareware applications that developers and companies have built over the years, and have distributed through the net and through various other channels. Please correct me if I am wrong but it is my impression that of these incalculable number of applications, only a miniscule marginal fraction is build on the foundations of Access. I am not referring to what you may call “in house” or “consulter” development, where a company hires a developer to tailor an application to their needs, so the number of times the program is distributed to other users is relatively small. Examples of such have been given in this blog in this current topic above and in the previous one as well. What I am on the other hand talking about, is software that many end users can, on their own, download and install on their personal computers and/or local networks.

Assuming that Access is usually not the preferred development environment for such applications (again, please correct me if I am wrong here), I want to try and understand why these distributable programs are usually not written in Access. Perhaps you can help me in that quest.

Is it because Access is not as good an instrument to build applications with?

No, I believe it probably is better then most other options for many purposes.

Is it because it takes longer to built software with Access?

No, as a matter of fact it is probably much faster. It is said to be three times as rapid as VB or C++ or .net etc.. and some say faster.

Is it because the user interface or the reporting is limited and the functionality options are reduced compared to the other options?

No, as a matter of fact these are some of Access’s advantages.

Is it because it was not built for the purpose of writing distributable software in the first place? Was it built for the end user just like the rest of the Office suit, like Word, Excel or Outlook.

So what? This is not a good excuse. Access has what it takes to build applications, so who cares what it was planned for. Besides, I think that most end users do not know how to begin to take advantage of what Access has to offer because it requires a steep learning curve. Unlike the other office programs you really need to invest time and effort into learning how to create applications that are more then just another more cumbersome version of Excel. I do not consider myself to be an authority in Access (although I do know quit a bit), but even to reach my knowledge level, a tremendous effort was required of me, so I can only guess what was required of those of us who are the real experts. So the result is that if Access is left for the end users then it is probably not used much at all. I find it hard to believe that Microsoft would invest so much into building such a robust application infrastructure only to have it not being used properly and sufficiently as it actually can be.

I think I know some of the answer to this riddle but I am curious to read if anyone has any more input on this matter to help me understand it better. I assume the answer has to do with the issues involved in the final steps of application development and deployment. I believe that this final step has not been addressed properly by the Access team over the years. This final step requires that after an application has been tested and refined, it will be possible to pass it on to many users, and that if upgrades are created it will be possible to easily disseminate them to these users.

Here are some of the issues in this final step that need to be addressed by the Access team:

If you want to package and deploy a real application you can not be content with the free runtime extensions, so you absolutely need a third party tool (you can not mark files as never overwrite using these extensions, as one example of the lacking in this instrument). Also, there are problems when the same application is distributed to different users that have different versions of Windows or of Office, or sometimes multiple versions of these products. There is a problem with different users having different service packs for these products. (As a wild solution to these problems I think it would have been better if the runtime files would have been distributed as part of Windows. That way at least some of these problems would have been solved. They are free anyway so why not? And Windows gets updated automatically). And what happens when Access is upgraded and the data file changes format. If users have already accumulated some data in an mdb backend file for example, you must have an easy way of allowing them to transfer this data into the new accdb format if you want to use it on your upgrade. All this reshuffling that happens every two or three years, and the fact that there are many issues with cross platform compatibilities creates a lot of instability and confusion that deter developers of such programs that I am talking about here.

Maybe the reason for not attributing enough importance to this final step in shareware development is because there isn’t anything in it for Microsoft to gain. What does M$ have to gain if one developer sells some software to some other users? It is preferable to target the end users themselves from M$ point of view, because then their money will go directly to M$ instead of to the developer. But I have already written above that these will be relatively few because of Access complexity so I don’t believe that this strategy will work for Access. So think of all those developers that developed those millions of shareware applications in a platform other then Access. They could have used Access to develop their products. Isn’t their money green?

Maybe the problem is that even if developers do select a different platform other then Access, it will still probably be just another Microsoft product, so the giant will not loose anything anyway, so why bother. But then why should M$ invest in Access in the first place? According to this logic it is best for M$ to just get rid of Access and invest all of its resources in these other more successful platforms.

I am at odds here. Perhaps some other people can shed some more light on this for me.

The reason I am writing this as you may have guessed is that I have a couple of such programs that I want to distribute. I worked very hard in perfecting them, but this final step if deployment seems to be very difficult and intimidating.

Thanks for reading.

Yours truly,

Gilad

# Gilad said on November 7, 2007 4:00 AM:

I tried to post a message here twice but it still doesn't appear. Am I being censored? I think it is ok to censor but I thought the overall gist of my comment was very positive towards Access, but it also contained my concerns and constructive criticism.

I thought this was the right place to post such comments. Was I wrong?

Gilad

# Matt Carmichael said on November 7, 2007 2:20 PM:

I have been creating custom Web / MS Access solutions for several years.  I develop the web-site admin tools in MS Access.  

Check Out: https://www.mbheducational.com/courses/Shop.asp?SID=1&RID=

This asp application is administered trough a custom MS Access FE.  Managing shopping cart items, managing student records, providing reports, and communicating with students are all features within the MS Access FE.  

Using MS Access to manage website text content is a great idea!  I will try implementing this feature in my next project – thanks for the tip.

New Comments to this post are disabled
Page view tracker