The Two Keys to Building Great Access Applications

Mike Wolfe -

What makes a great Access application?  To start, you need to make sure you are using Access for the right purpose.  Access excels in one very specific role: as a rapid application development (RAD) platform for building data-driven applications.

So what exactly is a "data-driven application?"

I'm pretty sure "data-driven application" is just an alternate spelling of "CRUD app."  But it sounds fancier, so let's just go with it.

A data-driven application is one whose primary purpose is the management of data: creating, reading, updating, and deleting (hence, CRUD).  

And to build great data-driven applications, you need to optimize for two things:

  1. Discovery
  2. Efficiency

Discovery

What good is having lots of data if you can't do anything useful with it?  

Discovery is the user's ability to find the information they are looking for within your application.

A good data-driven application provides the user with several tools to find the data they need:

  • Combo boxes
  • Lookup forms
  • Reports
  • Data exports (Excel, .csv, etc.)

Efficiency

It's good to be fast.  It's better to be faster.

Efficiency is the user's ability to perform their tasks as quickly as possible.

The most efficient data-driven applications:

  • Use sensible defaults
  • Build workflows that match real-world business processes
  • Tailor interfaces based on frequency of use
  • Minimize the number of decisions they require of their users

Building Great Access Applications

Let's be honest.  Most Access applications are not solving new programming problems.  Their value lies in managing data and optimizing user productivity.  

In other words, the best Access applications prioritize discovery and efficiency.

The thing that separates good Access applications from great ones is not the code that runs them; you need only a base level of competency with VBA to build great Access applications.  More important is to design your interface in harmony with the business domain.

Designing for business domain harmony

This sounds all touchy-feely.  What does "designing for business domain harmony" mean in practical terms?

Understand how your users think.  What terms will they want to search for?  And, just as importantly, what terms will they NOT search for?  

What information is required and what is optional?  When will they acquire the information?  What if some information is required at the end of a process but won't always be available at the start of the process?  

Where does each piece of information originate?  I mean this quite literally.  Is there an existing form–perhaps one mandated by the government–that contains the information.  Do the names on that form appear last-first or first-last?  Does the order of those fields on your program's form match?

These are the little details that contribute to software that feels intuitive.  These are the little details that make for great Access applications.

And these are the little details that you can't help but get right when you optimize for discovery and efficiency.

Image by Joshua Woroniecki from Pixabay