Writing FF&E Specs: Word Processors vs. Spreadsheets vs. Databases
Personal computers became the dominant type of computing device for a simple reason: They handed actual computing power to the business people "in the trenches," allowing them to develop their own solutions to common problems — problems that had long been beneath the interest (and outside the funding) of corporate IT departments. This group of self-taught power users had two obvious qualities: 1) an informal training in software design where they literally learned from their own mistakes and 2) an understanding of the problems they wanted to solve that the average graduate of a math sciences curriculum cannot match.
For FF&E specifications, they often used some combination of word-processing and spreadsheets to collect and tabulate the FF&E data in a design project. This was good (because it's so much better than inching a pre-formatted sheet through a typewriter (the horrifying sight that started the process that led to FF&EZ) and bad, because there is much more efficiency to be gained from more powerful solutions. In this entry, I'll compare the use of these approaches to using database software.
In discussing the relative merits of these approaches to documenting FF&E data, we can judge them with several criteria:
- General ease of learning
- Ease of making single changes
- Ease of making repetitive changes
- Ease of making related changes
- Ease of math calculations
- Ease of printing in multiple formats
- Degree of systematization
- Susceptibility to user error
General ease of learning: How easy is it for a non-techie person to understand how to use the software? Although most people don't use more than a small percentage of what a modern word-processor can do, the word-processor's mimicking of a printed page makes it very accessible.
Ease of making single changes: How easy is it to make a single change to a document? Can you make it on whatever it is you are viewing, or do you have to do it on a particular screen?
Ease of making repetitive changes: How easy is it to make the same change that may occur in many places? Example: Correcting a consistently misspelled vendor name, revising the "tag" or ID of an item or a price in all the places where you used it.
Ease of making related changes: If a change in the data affects other data, how easy is it to make the related changes? Example: Changing a "room mix" quantity that in turn changes the total project quantity of items in the rooms and their extended cost and price.
Ease of math calculations: Since FF&E specifications involve quantities, costs and prices, the ability of the software to create extended costs and prices, subtotals and totals, calculate taxes, etc. is an important feature.
Ease of printing in multiple formats: How easy is it to print the same data in a format different from the original one? How easy is it to sort and subtotal the printed data in different ways?
Degree of systematization: To what extent are the pieces of a particular approach part of a unified system vs. being separate, unconnected files?
Susceptibility to user error: Can the user of the software create problems or "break" the system with incorrect entries or changes? Does the system start to fall apart if the person who created it leaves?
Below is a table that summarizes the differences between the approaches, using a scale of Very Poor, Poor, Fair, Good and Excellent:
To explain these ratings in a little more detail, here is the reasoning:
Word-processors are easy to use (although using tables and style sheets can be a challenge). It is easy to make single changes on them because you can make the change on the final format. However, the only easy ways to make duplicated changes is to use either copy and paste or a "search and replace" tool. Changing related information does not differ from single changes (that is, it's basically a manual operation) and any math operations in a word-processor are very simple (if the user knows how to use them at all).
Multiple formats are not possible unless you use a mail-merge approach (but now you are using a database-like approach that offers no specific features for interior design work and is often cumbersome to use). There is no systematization beyond the ability to store blank templates and copy pages from previous work. The "what you see is what you get" simplicity of the word-processor interface means that users only need to check what they see on the screen for errors.
Spreadsheets offer more power, especially with calculating extended prices and totals. They are relatively easy to use, although there is an art to maintaining formulas. Users can easily make simple changes. However, they have to use copy and paste for duplicated changes, unless they can create a formula with an "absolute" reference (e.g., to a room count in a header area).
Related changes involving math formulas are of course a major strength of spreadsheets, however related changes involving text (e.g., changing a vendor or product name) are less easy to implement except with a find-and-replace function (unless the user is an expert at using "absolute" references).
Although spreadsheets can easily calculate extended amounts and total them, creating totals across spreadsheets (for instance, adding up the total quantity of a single product used in many room types) requires a multi-dimensional formula that may be hard for the average user to maintain or an extended grid layout that is difficult to print.
In theory, a spreadsheet can function as a simple database that can be sorted by different columns, but the creation of print formats that differ from the original row/column format is not easy to do. One can build a spreadsheet system that pulls totals from different sheets to create summary sheets elsewhere in the workbook.
However, the more complex a spreadsheet gets, the more vulnerable it is to user errors and using it with anything but very repetitive designs may not be worth the risk of creeping errors: Spreadsheets are notorious for "coming apart at the seams" over time, especially in the absence of the original author. Spreadsheets that are not locked down are also vulnerable to row inserts and deletions that leave formulas pointing at something other than the correct end points. This is a critical weakness, because in a large spreadsheet full of rows and columns, end-point errors in formulas are hard to detect.
Databases offer much more power and security at the price of a learning curve whose "hump" is the shifting from a "document-oriented" approach to a "data-oriented approach" (more about that in another post). In a database, single changes are relatively easy — just as easy as the other two approaches as long as you understand how the data is organized. However, duplicated changes, related changes and math operations are extremely easy, because the system makes all of them for you automatically. Since you only change an item once on its source document (e.g., the vendor's record or the screen where the item "tag" is first defined or the specification where the price is entered), the database simply refreshes its screens and reports by looking up the source data again.
Printing data in multiple formats is a major strength of a database: By organizing data along its natural relationships instead of a fixed document format, the system can reorganize data in any way that makes sense.
Of course, database software is by definition a self-contained "system" in which all the parts support the production of documentation while taking advantage of a computer's ability to store, copy and organize data.
Finally, database user interfaces are designed to help check user input in real-time, and special queries can help check for missing data. The user can still check their entries on the source document (screen) as needed. The only aspect of a database that keeps it from having an "Excellent" rating for user errors is that a document-oriented user who does not understand how a database works can make changes that work exactly as expected — but not as they expected. Of course, the strong error-checking that is typical of a database system's user interface and can offset this with a little training.
Moving from word-processors and spreadsheets to a database system is really a matter of asking one question: Is the ability of doing a few things easily really "better" than taking the time to learn how to do a lot of things very easily? That learning process begins with moving from a focus on final documents to a focus on how data can be organized and used efficiently.