Beauty may be in the eye of the beholder but – could it actually matter how “nice” your database looks? The impact of organized data entry screens goes well beyond aesthetics. Good design supports a logical workflow and eliminates the “friction” of a poorly designed interface.
A database can be difficult to use if you have to hunt for fields because they don’t appear in a logical order. If fields are poorly aligned then it’s difficult to track across the data entry screen. Likewise, a background color that’s garish can be very distracting.
- A sloppy-looking layout or neon colors can make the database needlessly difficult to use.
- A poor user experience negatively impacts user adoption.
- And, if users won’t use the database, the success of the overall system is at risk.
Here are tips to help design a highly functional database that supports users’ needs.
Consistent naming
If you have related fields – let’s say you’re tracking details about a contract – name them consistently:
- Contract renewal date
- Contract addenda
- Contract type
- Etc.
Rather than:
- Renewal date
- Type of Contract
- Terms and conditions and addenda
- Etc.
From a design standpoint, standardizing field names helps as you design the database screens – the fields are grouped together in the field list. More important is that this type of consistency makes it easier for users to create lookups or perform sorts without having to do a “What’s that called again?” double-think.
Consistent naming also applies to field names and labels. A field label is generated by default when you place a field on the layout. Think how an overly long field name could impact screen real estate as you design the layout. You want your fields to fit within the boundaries of a standard screen size so that users will not be required to scroll around the screens to get to all the fields. What to do?!
Consider the field above: Terms and conditions and addendums. It’s disproportionately long to fit easily into an otherwise compact design. This could be fixed by editing the field label; as you can see, below we’ve been able to regain the screen real estate by shortening the label. Tempting, but not a good solution!
When the field label and the field name don’t match, expect users to get frustrated when they attempt to sort on or look up the fields. Remember, we’re trying to avoid anything that adds friction for the users. The user sees a field named “Addendums” on the layout attempts to look it up. Selecting Lookup > Other fields, here’s what the Lookup Contacts dialog looks like:
The field list sorts alphabetically: You don’t see Addendums in the list because the list displays field names, not field labels. The actual field name is Terms and conditions and addendums,
Picking the right tool for the job
You can read an in-depth description of fields types and their intended use in the Field Types chapter of the Designing Your Sage ACT! Database guide, or in an ACT! KB, or in ACT! help.
What we want to do first is to help you to consider how important it is to pick the right type of field for the job at hand.
We’ll review a few of the most common mistakes committed when creating and using Sage ACT! custom fields.
The default field type upon creating a new field is “character”; most of your field content will probably be alphanumeric (department, customer number, sales rep, industry type, and so on) and the character field will probably be the primary type you’ll use. Rather than list each of the field attributes, here’s a list of “gotchas” that can box you in if you pick the wrong field type for its purpose:
Character vs. date field to keep track of dates:
Dates belong in Date fields. Don’t use character fields because if you do, you’ll see entries like this:
- Sept. 27, 2114
- 02-02-12
- January 2011
- 9/1/2015
Trying to look up, sort, or report on those variations will be impossible! Stick to the date field for accurate and consistent date information.
Character vs. Numeric:
It’s logical to think of a customer number or account number as number but that type of “number” does not require a numeric field. When unsure, ask yourself, could I ask if you could subtract, multiple, or divide the data in the field. If the answer is no, choose a character field.
Field length:
The default length of a character field is 50 characters. Consider the purpose of the field and be certain the field will accommodate the full length of the typical entry you expect to make in the field. Allow for just a bit more if you’re uncertain.
Character vs. Memo
Memo fields were added in recent ACT! versions. Memo fields enable you to add unlimited text and manage screen real estate more effectively. A description or note added to a character field will run out of room if it’s lengthy, plus that field needs to take up a lot room to make it useable. A memo field can scroll though an unlimited amount of data and can take up much less room on the screen as a result.
Numeric vs. Currency vs. Decimal
Each of these fields has a specific purpose.
- Numeric Numbers only, no decimal places or dollar signs.
- Currency Number format according to the currency settings in the Windows system.
- Decimal Numbers and decimal points. The default format uses 5 decimal places.
Avoid these pitfalls to build a powerful and functional ACT! database.