Home > Blog > Writing FF&E Specs: Word Processors vs. Spreadsheets vs. Databases

Writing FF&E Specs: Word Processors vs. Spreadsheets vs. Databases

Posted by henrythe5th on August 29, 2011

project_spreadsheet_product_sheet.png

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 been long beneath the interest (and outside the funding) of corporate IT departments.  This group of self-taught power users is known for having two qualities:  1) an informal training in software design where they very literally learn from their own mistakes and 2) an understanding of the problems they want to solve that cannot be matched by the average graduate of a math sciences curriculum. For FF&E specifications, this has produced methods that often use some combination of word-processing and spreadsheets to collect and tabulate the FF&E data in a design project.  This is good (because it's so much better than inching a preformatted sheet through a typewriter — remember those?) and bad, because there is much more efficiency to be gained by using 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 different 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:

Comparison of Software Used for FF&E Specifications
Criteria Word Processor Spreadsheet Database  
General ease of use Excellent Good Good  
Single changes Excellent Excellent Good  
Duplicated changes Fair Fair Excellent  
Related changes Poor Good Excellent  
Math calculations Very Poor Good Excellent  
Multiple formats Very Poor Poor Excellent  
Systemization Very Poor Fair Excellent  
User error Excellent Fair Good  

 

To explain these ratings in a little more detail, here is the reasoning:

Word-processors are generally easy to use (although using tables and style sheets can be a challenge).  It is easy to make single changes on them because the change is made right 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.  Making changes to related information is no different 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 generally 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 something of an art to maintaining formulas.  Simple changes are easily made, however duplicated changes are generally done by copy and paste, except where a formula with an "absolute" reference (e.g., to a room count in a header area) is possible.  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 system like this 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 data can be reorganized in any way that makes sense.  Of course, database software is by definition a self-contained "system" in which all of the parts are created to 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 be created to 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, this can be offset by the strong error-checking that is typical of a database system's user interface and, of course, 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 — a subject I will cover in a future post.

Bookmark and Share

Comments: