The Views Our App Needs to Provide
In the last post[link], we identified the data entities our app needs to support. Now, we take a look at the Views our app needs to provide.
I promise, we are getting close to FileMaker.
What is a View? I use the term View to define how a user is going to “see and use” the app and its data. Or, from a different perspective, a View is a way the app provides data to the user. A spreadsheet is a view of data. A report is a view of data. A mail-merge is a view of data.
Too many times, I’ve seen designers and developers get hung up on the bells and whistles of a particular technical platform instead of focusing on how the users are going to View the app. It is vital to work from the other direction, on what the users need to accomplish. The technical doodads are not as important. But, for our purpose of identifying the Views our app needs, we do need to consider what FileMaker provides.
In FileMaker, a View generally corresponds to a Layout (a method of presenting data to a user). FileMaker supports four Layout types for computers and touch-screen devices: Form (to display one record at a time), List (to display many records at one time), Table (to display data in a spreadsheet-like format), and Report (which is fundamentally a List with the ability to group and total data). For printing, FileMaker supports Labels, Envelopes, and Reports (which can contain things like charts and Google Maps).
Notice anything missing? Mail merge. We need this ability for our app. FileMaker doesn’t quite support that functionality. Technically, it is possible to create a letter on a FileMaker form and insert the contact data as merge fields within a text box. However, this approach requires editing the Layout itself to enter and modify the form letter. In my opinion, a word processor is a much better tool for generating mass mailings.
Apple’s Pages doesn’t support mail merge, but Microsoft Word for OS X does. However, Word needs to import the data – the names, addresses, etc. – for the merge to work. So, another View into our app is the ability to provide (or Export) data for a Word mail merge.
Okay. Let’s look at our Views.
The Views our app needs to support.
We’ve identified nineteen Activities the app needs to support. Now, we need to identify how our users perform their Activities via Views. We do this by looking at the processes involved to support the Activities.
Let’s start with the first Activity: A1. Generate “Save the Date” letters for former sponsors and players, before the tournament. As mentioned earlier in this post, this activity specifically requires mail-merge capability. We need to provide name and address data to Microsoft Word. We also need to be able to generate envelopes to correspond to the letters. Will we do it with the Envelopes layout in FileMaker? Or will we do it in Microsoft Word? We don’t know how we are going to do it at this point, we’re in the Requirements phase. We just know which Views we need to specify for our app. In the case of the A1 requirement, this is simply to “provide” (or Export) contact data for the “Save the Date” letter mail-merge. (Notice, at this point, we are not worried about the best way to perform an Export, just that we need one).
If we go through this exercise for each Activity, we come up with a set of Views to support each activity:
Notice that some Activities correlate to multiple Views. That is normal. Requirements that specify capture and track likely can’t be supported by a single View. Notice also that some Views support more than one Activity. That is also normal.
We’ve identified Activities, data Entities and Relationships, and Views. In the next post, we’ll put this all together in our Requirements Matrix.
First Post – Links to all Simple FileMaker posts can be found on this page.