Deep Dive: Financials Page

The Financials Page in the nonprofit plan collects the set of numbers most often requested by foundations on their grant applications. It is a subset of the numbers found on a typical financial statement. As a 501c3 organization, a charity is required to publish their most recent financials, so this information should already be in the public domain. Foundations, however, don't want to seek this information out; they want just the numbers they want, and in the format they want it.

The financials contain numbers from the prior year, current year and next year, with the majority of the information coming from the current year.

'Prior year' asks for the budgeted and actual revenues, expenses and net income. Comparing budget to actual lets foundations evaluate a charity's planning skills, establishing how much confidence we should have in the budgeted numbers for next year.

A particularly important item is the list of funding sources, and the percentage raised from each. This shows how diverse the funding base is (or isn't), and the stability or vulnerability of that base.

The expenses are broken out to show how much is spent on fundraising, administration and programs. This is important because foundations and donors want the majority of their money to go to programs, not salaries and overhead.

Another item asks about any unusual events which may have impacted the numbers. This gives the charity an opportunity to talk about internal and external challenges that are threatening its viability.

A similar set of numbers is collected for the current year, but with two versions: the current year-to-date, and the projected full year numbers. This provides another reality check; if the YTD numbers are significantly different from the projected numbers, a red flag goes up in the minds of potential donors.

Next year numbers follow the same pattern, but reflect budgeted numbers only.

Once again, the credibility of these numbers is impacted by the accuracy of budgeted numbers from prior years. One would also expect the Next Year numbers to incorporate the impact of challenges mentioned for prior and current years, if they are ongoing issues. To not acknowledge these impacts in next year's forecast would indicate a lack of realism in the planning process.

The final pages in the nonprofit plan are the Program Pages, including a page for General Operating Support.

Deep Dive: Strategic Plan Page

The Strategic Plan page of the nonprofit plan focuses on information that describes the organization as a whole.

It has small sections for general information, such as 'year founded' and '501c3 status', contact information and key personnel information.

The heart of this page, however, focuses on strategic plan information.

The main topics in the strategic plan are purpose, populations served, goals and strategies, impact, SWOT (strengths, weaknesses, opportunities and threats) and resources.

When an item has been completed, the note is outlined in green. When a group has been completed, its header is outlined in green. This gives a quick visual overview of the structure of the plan and its current state of completeness.

When the planner clicks on a note, a dialog box opens.

In the first version of the solution, the long and short answers required two separate columns in Excel. Now they are two separate 'fields' in each note. The long answer is written first, because it is easier to be verbose. Crafting a pithy short answer from the long answer is a second step. Both answers are required because many grant proposals are documented in online systems with restricted word counts. If the targeted foundation has this type of submission system, the short answers should be selected when running the proposal generator.

The planner can also choose to work in the outline view of the KnowtPlan model (KnowtPlan is the current name for this special-purpose variant of KnowtShare). The outline view may be the preferred option for the more text-oriented user.

This view also uses green color-coding to communicate the plan's state of completeness, Both views let the planner type in answers or cut-and-paste from another document.

We are also developing an import option from Microsoft Word as a way to initially populate the plan. Ongoing revisions, however, will need to be done directly in the KnowtPlan system.

In my next post, I will give a brief overview of the other sections of the Nonprofit Plan.

Overview of the New Nonprofit Planning Model

My last post described how I came to the realization that our collaboration tool KnowtShare is a better tool for capturing content for the Grant Proposal Generator than Microsoft Excel. It's better because the required content is NOT a simple list of questions and answers, but a business plan - a plan specifically designed to meet the needs of nonprofits.

I knew it would be mechanically easy to build a hierarchical plan using KnowtShare, but I needed to decide the best approach for thinking through the model I wanted to capture.

I decided to use the bottom-up, intuitive approach to building a tree. I had the leaves of the tree -- they were the individual questions/information items gleaned from the series of foundation grant applications we had analyzed. Using the bottom-up approach, I began grouping these into small groups and creating headers for the groups. Sometimes these headers were new items; sometimes I used an existing note as the header. For example, I decided to use the Executive Director's Name as the header for the Executive Director's contact information.

Then I grouped my first level groups into higher level groups, and wrote headers for those new groups. I continued in this fashion until I reached one, comprehensive group, which was the overall plan. This basic process is called creating an Affinity Diagram, and I describe it in more detail in my book The Shape of Knowledge. Often this method is used to help a group of people develop a shared model, but I find it is a good approach for individuals as well!

The top level of the tree became my page headers: Strategic Plan, Financials and Program Plans. One of the challenges I faced while designing this nonprofit business plan was how to handle the program-specific content for multiple programs. I decided to make each Program Plan a separate page or branch of the tree, and that each should contain an identical template of questions.

I also decided to automatically generate a program page called "General Operating Support" for every plan (because every charity writes grant proposals for operating support) and then let the charity generate additional pages, one for each of their major programs. In this way, the plan is customized to match a charity's particular offerings. When it is time to generate a grant proposal, the charity will need to select one of these programs as the basis for their funding request.

In the next post we'll take a closer look at the composition of each of the major planning sections.

Lessons from the Field: My Initial Experience with the Grant Proposal Content Table

One month ago I began using Microsoft Excel to capture the answers of several small charities in the Content Table that provides the 'raw material' for the Grant Proposal Generator. This Content Table was described in my October 7th post.

As is always the case, the real-life application of tools and ideas surfaces many opportunities for refinement. That is, after all, why we do testing! In the last month I became more convinced than ever of the need for such a tool, and the value it can provide charities. But I learned a couple of important things - one about the need to be filled, and another about execution - that will impact our approach.

First, the need. From the beginning, I approached this as an opportunity to help charities generate grant proposals quickly and easily. We would do this by capturing their answers in a format that could be automatically configured to meet a foundation's requirements. What I didn't anticipate is that the charities would also need help developing those answers. In fact, by removing the impediments to proposal construction, we shone a light more brightly on the quality of the answers that were being assembled.

In other words, by focusing our efforts on capturing the one, best answer to a set of comprehensive, rigorous questions it became clear that those answers often did not exist. Or many versions of the answers existed, in many different documents. What became clear to me is that the first need the charity had was support for the business planning process. Without that, our automation efforts would churn out a high volume of low quality grant proposals.

The second thing I learned is that Excel was not the right tool for this job, primarily because a table is not the best shape for the knowledge we are collecting. The content required is a business plan, and the business plan is best described as a hierarchical model, not a table; it is a triangle, not a square. Here are some of the signs that told me a change in approach was necessary.

First, I love Excel, but it is designed to work with numbers not large blocks of text. Trying to type long descriptions into spreadsheet cells was pure misery! That's okay; I had a more fundamental reason that Excel was not the right tool for the job.

Just as a reminder, this is what the structure of the Content Table looks like:

The table has about 150 rows/questions and two columns for General Operating Support (long and short form), and two columns for each program described in the plan. So, if a charity has two programs they will have a total of six columns.

I said up front that the answers to some of the questions will be the same for GOS and all programs - contact information falls into this category. The mission statement of the organization is another example of an answer that doesn't vary. Multiple columns were required because many other important questions will have different answers for different programs: questions regarding populations served, communications strategy, and volunteer requirements, for example.

It's not until you are actually copying and pasting the same answers over and over that you stop and say 'wait! there must be a better way'. And there is.

The copying and pasting was a sign to me that I was using the wrong shape to capture the necessary knowledge. This was not a list of questions (a 'line') with multiple variations (a matrix or 'square'). It was a hierarchical business plan - a tree or 'triangle'. Some of that information I was copying and pasting many times was high level information that only needed to exist once for the whole organization, and sometimes it was information from a different branch of the tree and didn't need to be duplicated for each 'program' branch of the tree.

I knew I needed to rethink the structure of the content knowtifact. I had picked Excel because it was convenient and familiar, but our own KnowtShare application, which makes it easy to construct hierarchical models stored in JSON (a web-oriented data interchange format) was a better choice. So I went back to the drawing board to reinvent the content knowtifact for the tool we are now calling the Nonprofit Planner. My next blog posts will be about that reinvention process.

The Sequencing Table for the Grant Proposal Generator

The Content Table described in my last entry is the 'parts catalog' in the document configurator I want to build. The Sequencing Table will act as the assembly instructions.

The format of the Sequencing Table is similar to that of the content table, because they share a key field: the grant application questions.

Every row in the Content Table must have a corresponding row in the Sequencing Table for that content to be included in the grant proposal that is generated. There are a few headers added for organization purposes, like the "General Questions" text shown here, but they do not show up in the generated proposals.

A number in the column simply means that a given item is in that position in the proposal for that foundation. A blank means the information item is not required. In this way, the column of numbers shows both the subset of information required and the order it should be placed in to meet that foundation's needs.

This column of information needs to be filled out for each foundation that appears in the Grant Proposal Generator. My strategy for capturing this information is to prioritize foundations based on the needs of the charities that participate in our pilot program. I am working closely with the pilot program charities to help them find like-minded foundations that will have a higher probability of granting their requests. I will use the timelines generated from these prospecting lists to prioritize the foundations and schedule their addition to the system.

My goal is, eventually, to have foundations add themselves to the system by providing an intuitive, easy-to-use tool that helps them select the questions they want and arrange them in their preferred order. They will also be able to use the tool to modify their 'questionnaire' at any time. This will be the most efficient way to develop and maintain the Sequencing table, and will guarantee the Grant Proposal Generator is up-to-date with foundations' current requirements.

My next step is to work with my pilot charities to fill out the Content Table.

Creating the Content Table for the Grant Proposal Generator

My first challenge was to identify the comprehensive set of information items that would cover all the questions asked by foundations in their grant application forms. I started with the most comprehensive single form I could find: the one used by the Catalogue of Philanthropy, a Washington D.C. organization, to vet charities in the D.C. region for inclusion in their publication.

I decided based on my initial assessment that a table was the right shape for this information, and that I would use Excel to create my table.

I used the questions as the row labels, and created columns for the various types of proposals a charity would typically generate.

When a charity makes a grant request they must declare how the money will be used. Is it for general operating support? Or is is for a specific program or project? If it is for a specific program, which one? Once the intended use is declared, all of the following questions must be answered with that end use in mind. Some of the answers, like contact information, will be the same for both general support and specific programs, but many will be very different. To accommodate this variation, I setup separate columns to represent the various versions of the proposals. A charity will fill out a project-specific column for each project that requires funding.

I also setup separate columns for long and short form answers. This is necessary because many online application forms limit the number of words for each response. The approach I envisioned here is that the long form would be written first - it's easier to be wordy - and then a short, pithy version crafted next.

I started with the Catalogue for Philanthropy questions, which are in white. The next application form I reviewed was the Washington Regional Association of Grantmakers "Common Application", and the incremental questions from that were color-coded in yellow. I proceeded in this way, selecting application forms from large foundations, adding any new questions I found and color-coding them to show the source. As I had hoped, after only a handful of forms, the number of new questions dwindled to one or two per foundation. This consistency is important, because it confirms that an automated approach is truly possible! After reviewing five sources, the total number of information items was 130, with about 50 related to financial numbers.

At the same time I was creating the Content Table I was also working on the Sequencing Table, the other knowtifact required for the Grant Composer to work. I'll describe the Sequencing Table in my next post.

Knowtifacts Required for a Composer Application

As I said in my last post, a Composer is basically a document configurator. Two required inputs for any configurator are a parts catalog and instructions for how to select and assemble the parts to meet the current need. To build a Grant Composer, I needed to design those two knowtifacts  -- first, generic versions capable of generating any type of document and second, specific versions suitable for generating grant proposals.

My high level goal for The Shape of Knowledge -- the book, this blog and the Apprentice Systems website -- is to create an environment where people with knowledge can generate useful applications that embody that knowledge without writing computer code. To achieve this, people must be able to document their knowledge in easy-to-use tools like Microsoft Excel. A spreadsheet is perfect for capturing 'square' knowledge like tables. We created our own tool, KnowtShare, for documenting hierarchical triangle-shaped knowledge like decision trees. Between KnowtShare and Excel (Excel can also capture lines/lists and cubes/3D tables) we've been able to document many forms of important knowledge. The knowledge necessary to create a Composer is two tables, so only Excel will be required.

Then our job at Apprentice Systems is to create the Application Generators - - "apperators" - that can consume this documented knowledge and generate simple but useful applications. This method only works because underpinning the whole process is a highly reusable, generally applicable knowledge pattern that provides discipline and acts as a link between the documented knowledge and the app generator. Yes, two tables are all that's required, but the two tables must meet a consistent set of requirements for the Composer Apperator to work. My task is to design the two tables and identify those requirements.

The first table is the Content Table, and it will act as the 'parts catalog' for my configurator. It will be the comprehensive set of questions and answers that the Composer will draw from to generate a grant proposal. There will be multiple columns in this table, representing the various versions of the content.

The second table is the Sequencing Table, and it will act as the instructions for how to select and assemble items from the Content Table. There will also be multiple columns in this table, providing different sequencing instructions for different potential target audiences.

"To meet the current need" -- establishing the context for a particular document -- will determine which columns to use from each of the two tables. When running the Composer the user will select the version of the content and the target audience for that particular document, and the Composer will generate an HTML document that meets those specifications.

This is the general game plan. The next posts will show how this actually works for grant proposal generation.

The Composer: a Document Configurator

I said in my last post that one of the challenges a nonprofit faces is that every foundation has their own unique grant application. That's not exactly true.

There's at least one group, the Washington Regional Association of Grantmakers (WRAG), that has attempted to create a common application for their members. It is not unlike universities, who have a 'common app' that many colleges use for vetting students. But if you've applied to colleges you know that 1) many schools don't accept the common app and 2) those who do often have a supplement that asks the additional questions each university still wants answered.

This is because different institutions have different wants and needs. I don't blame them for wanting answers to all their questions; they have the right to know what they want to know before admitting a student to their school. Foundations definitely have the right to know what they want to know before giving another organization their money! In the case of WRAG, out of 100+ members only 18 accept the common grant application.

If you look more closely at the grant application process, you will see that while each application is unique, the questions asked are not. After all, there are only so many items of information you can request from a nonprofit organization. Maybe you can ask a prospective student a wild and innovative essay question to surface his or her true character, but most of the answers a foundation is seeking could be pulled from the nonprofit's business plan, if only they had one.

I felt instinctively that if I could develop a comprehensive set of questions, what would distinguish any particular application would be the subset of information being requested and the order in which the questions were asked. In other words, what I was trying to solve was a classic configuration problem.

Apprentice Systems has solved many configuration problems for our clients. Configuration is a design process where solutions are created by selecting from a set of predefined parts and assembling the parts to meet the needs of a particular situation. We've built systems to automate product configuration (part assembly), process configuration (task assembly) and decision configuration (criteria assembly). What was needed here was a special case of product configuration: document generation. We know how to solve that problem by writing custom code. Could I simplify it into a knowledge pattern that would put automated grant writing within reach of nonprofits everywhere?

After six weeks of research, I feel we are well on our way to making this goal a reality. The knowledge pattern that makes it possible I've dubbed "The Composer". The knowtifacts necessary to generate a Composer are two squares: a Content Table and a Sequencing Table. My next posts will describe my design and creation of these knowtifacts, and the challenges and opportunities for the philanthropic community that have surfaced along the way.

Finding a New Pattern: The Composer

I've written a series of blog posts about building a Recommender app by creating the required knowtifacts and dropping them into the Recommender Apperator to generate the app. My example was a Whiskey Recommender, and it was a more complex version of the Recommender pattern I introduced in my book The Shape of Knowledge. Earlier, simpler Recommenders covered in the book were the Beach Town Recommender and the Knowledge Artifact Recommender.

The Recommender knowledge pattern is one I created based on some of the work we've done at Apprentice Systems, building intelligent systems for clients. It is a simple pattern that contains both a triangle/tree (the Context Decision Tree) and a square/table (the Options Table). An optional component is a folder full of images depicting the various options in the table.

Once I defined the Recommender pattern I looked for simple examples I could use to build demo applications. In other words, the Recommender was a pattern looking for problems to solve. Now I am going to switch gears to a new pattern, one I discovered only recently, in the process of solving an important real-world problem. I believe this series of posts will make even clearer the potential of the methods I am laying out in The Shape of Knowledge. I am not espousing these ideas because they are nice to know. I am doing this because I want to make a positive difference in the world.

It was in the spirit of making a positive difference that I visited the local food bank two months ago, to see how I might volunteer. I went ready to pack boxes of food and make food deliveries, but after a brief interview with the volunteer coordinator, she decided I could make the biggest impact by helping them write grants.

Grant writing is actually the process of writing grant proposals to foundations, asking them to grant money to support nonprofits in their efforts. Charities rely on grants for both general support and project-specific support, and many nonprofits could not exist without these funds. Writing grants is a time-consuming and onerous task, and many organizations end up hiring a 'grant writer' to help them in this effort.

There is an industry of individuals and organizations that thrive on the fact that nonprofits have neither the time nor the skills to jump through the hoops of grant writing. Every foundation has their own process, which often includes filling out a custom application -- sometimes in hard copy, often online. The one-off nature of these applications means every grant proposal is usually a cut and paste exercise in Microsoft Word, using past proposals as the raw materials for new proposals. This process can be haphazard and inefficient.

It's also hard to find foundations that are likely to support the request of the charity, based on mission and geographic fit, so database companies have sprung up to meet this need -- for a stiff monthly subscription fee. My personal experience with the quality of the leads coming out of these services would indicate this is not a good investment.

I don't begrudge anyone making a living, but personally I have a problem with so much of a charity's funds being diverted into the process of writing grants. I would like to see the food bank's money going to feed hungry people! I think foundations that support the food bank would want this as well.

I also think that funds should be directed to the nonprofits with the best programs, not the best grant writers. With that principle in mind, I decided that philanthropy is a sector that could benefit from a bit of technology disruption. A high potential piece of that disruption is a pattern I identified by working with the grant writing process -- I call it the Composer.

Deb's Whiskey Recommender

Earlier posts have described the processes, both mental and physical, that I went through to create the knowtifacts necessary for generating a Whiskey Recommender. I used basic Excel skills to create the Options table. I used KnowtShare to generate the Context Decision Tree. I used Google and Bing's image search tools to find suitable images and placed them in a folder. I uploaded these three components into the Recommender Apperator, and it generated "Deb's Whiskey Recommender" for me.

For each of these steps I needed some basic computer skills, but I never needed to write computer code. What was most essential for me to provide was the knowledge of whiskey and an opinion about which type of whiskey was the best choice in different contexts. 

Since I wasn't an actual whiskey expert, I had to use the internet to educate myself. I also realized, too late, that I had taken on a really, really complicated subject for what was supposed to be a simple tutorial! This forced me to make several compromises between completeness and manageability. I had to cut corners. Each time I did, I noted that if I were building a real application I might have made different choices, and suggested how a more complete approach might be pursued.

So what did my efforts get me? Here are some screenshots of Deb's Whiskey Recommender, the app generated by the Recommender Apperator:

The logic I embedded in the Context Decision Tree is transformed into a simple wizard.

As the user makes choices, those choices are placed into the 'breadcrumbs' at the top of the page. This navigation device not only makes it clear which path has been taken through the tree, it makes it simple to backtrack to any one of the decisions and change it. When a user clicks on a prior choice, he or she will be taken to that spot in the wizard.

From a 'Shape of Knowledge' perspective, it is worth noting that the Context Decision knowledge is captured in a triangle shape, a tree, but the user interface serves that knowledge up in a linear fashion. This is an example of one of the best practices I talk about in my book: use the best knowledge shape for capturing the knowledge, but use the simplest shape possible when presenting it to a user. In this case, the triangular knowledge is flattened to a line by the wizard-like UI.

Based on this particular set of decisions, a long list of whiskeys is recommended. This path takes the user to the bourbons, both Tennessee Whiskey and Kentucky Straight Bourbon. Here is a sample of the recommended list:

The baseball card format lays out information from the Options Table. Shown are three of the many Kentucky Straight Bourbons in the Whiskey Table. At this point, the implications of the compromises I made become clear: everything on these three cards is identical, except for the brand name. Because all three whiskeys are from the same manufacturer, they have the same image. Because they are all the same type of whiskey, they have the same taste profile. Even though the price levels were calculated individually, they all happen to fall into the same price group. It would have been nicer if I had documented this information down to the individual brand level, but with 450 brands in the data table that wasn't feasible.

The options for knowledge authors building future Recommenders are these: pick a simpler topic, with fewer options; crowd-source the information in the Options Table; or be prepared to do a whole lot of work yourself, which is worth it if you are creating a Recommender to sell, establish your expertise, or to create competitive advantage. 

Meanwhile, it is important to remember that the amount of effort required to create a complete data table is minor compared to the effort required to build this sort of application from scratch! The data has to be there, in any case -- there's no avoiding that work. But the ease of building the decision logic in KnowtShare is unparalleled, and the user interface and the computer logic that knits the pieces together comes for free. 

This demo application achieved my goals: to document the process of building a Recommender, and to demonstrate that a potentially sophisticated application can be created based solely on domain expertise, no computer code required.

Creating the Whiskey Context Decision Tree - Part Two

My last post described the general challenges of building a context decision tree, and the specific challenges surrounding my search for expertise regarding whiskey selection. In the end, I decided I would have to rely on my own ideas, developed during the many hours of research I conducted while building the other inputs to the Whiskey Recommender. My immediate need was to create a context decision tree so the Recommender Apperator could generate a Whiskey Recommender app. Once that example is published, I hope to find some real, live whiskey experts that can help me build other, alternative Whiskey Recommenders.

I created my decision tree using our free KnowtShare web application. KnowtShare was designed to make it easy to build tree-shaped models. We, at Apprentice Systems, know from our many years of building intelligent systems that trees - hierarchical, non-cyclical models - are essential for capturing several modes of reasoning. Classification, composition and multi-pronged evaluation are all best described using trees. The branching behavior of a decision tree is also easy to document with this sort of model.

While some trees are best built bottom-up, a decision tree is usually built top-down. In other words, you decide the first question you are going to ask, list the possible choices, then determine what choices will be presented based on that first choice, and so on. The tree will document all the possible paths through the context collection process, but users will only travel one of those paths each time they use the application. At the end of each path, a 'leaf' on the tree, will be a recommended option - in this case, a type of whiskey.

I decided, pretty easily in fact, what the first question in my decision tree would be: "Are you going to mix your whiskey or drink it straight up?" I think this is a good first question because most whiskey connoisseurs agree that if you are going to mix your whiskey with Coke, it really doesn't much matter what you drink! Just don't waste a good Scotch! Of course, there are those who will mix an expensive whiskey with Coke, and I need to allow for that possibility as well.

Here is the 'mix it' side of my whiskey decision tree:

The next set of choices I present are using a flavorless mixer (water or club soda) versus a flavored mixer. You can still be a whiskey purist, of sorts, if you only use water or club soda. If your whiskey is to become part of a cocktail, however, it will be difficult to taste the whiskey itself - which is perhaps one of the goals of drinking a cocktail.

I'm pretty comfortable with these first few questions; I think I am on safe ground. Now the going gets much more difficult. I knew the 'flavored mixer' path was taking me towards the cheaper whiskeys, such as Canadian and American blended whiskeys, so I created the next set of choices: do you care more about price or status? If the user selects 'status', I decided to recommend either a Kentucky Straight Bourbon (like Wild Turkey) or a Tennessee Whiskey (like Jack Daniels). Picking 'price' leads to a variety of inexpensive American and Canadian options.

The real puzzler is the next set of options for the non-flavored mixer path. Remember, choices have to be presented in a language that represents the user's perspective (this was covered in the last post). Waxing poetic about the process differences between Scotch, Irish Whiskey and Bourbon won't work here! The target audience of the Whiskey Recommender is someone who is new to the world of whiskey, not an expert. Newbies couldn't care less about the finer points of distilling whiskey, especially since their palates probably can't distinguish the taste differences that result. So I decided to keep things simple, and make the next set of choices "do you prefer American products, or not?"

Finally, at the next level, I reached a point in the tree where I relied on taste profiles to make a distinction. American products were split into 'spicy', which leads to American Rye, and 'sweet', which leads to the bourbons. The non-American choice was split into 'light and smooth' (Irish Blended and Canadian Single Malt) and 'smokey and robust' (Scotch Blended and Single Grain).

This is the point where I need to reiterate an important message from the last post: this is all subjective! Even if I were a whiskey expert, which I'm not, this would still just reflect my opinion. A recommendation, by definition, exists in the world of subjectivity. Otherwise, this would be an 'Answerer', not a Recommender.

The power of the Recommender pattern is that I can create "Deb's Whiskey Recommender" just by building this tree in KnowtShare and combining it with the Whiskey Data Table in the apperator. Then my friend Richard, a real whiskey expert, can generate "Richard's Whiskey Recommender" by creating his own decision tree. He can even reuse my Whiskey Data Table. Better yet, in the future we can crowd source a much more complete data table and make that a community asset we all tap into when we build our own unique Whiskey Recommenders. That's the vision.

Back to my Recommender. Let's take a look at the other major branch of my decision tree, the 'straight up' branch:

I reused the 'do you prefer American products' choice again, and early on in the question sequence, because I needed to account for American Single Malts and I can't do it through a taste profile. American Single Malts are all over the board, taste-wise, because American distillers are using a wide variety of processes to create their single malts. Some are following the Scottish methods, and beating high-end Scotches in blind taste tests. Some are creating their own unique processes that are leading to unique taste profiles. All that binds them together is their country of origin, and that American origin is important to some people, including me. I like our underdog status in the Single Malt arena, and I like to support these distillers when I can.

As for the rest of the 'straight up' branch, it is a taste-driven breakdown between Irish Whiskey and Scotch, and within Scotch, a breakdown into the various regions. While some regions have distinct flavor profiles (like Islay) and some are more diverse (like the Highlands), taste is still the easiest way to direct a Scotch drinker to a particular region.

A real Whiskey Recommender, as opposed to this demo application I am building, could recommend specific Scotch brands, like Laphroaig. To keep things manageable, I have decided to stop my recommendations at a type of whiskey, like Islay Single Malt Scotch. If you've read the other posts about building the Whiskey Recommender, you will know that this is one of many simplifying assumptions I have made during this process.

Now that I've built my Whiskey Context Decision Tree and saved my KnowtShare file, I have all of the knowtifacts necessary to generate my app. The next step will be to enter them into the Recommender Apperator and generate my own custom web app.

Creating the Whiskey Context Decision Tree - Part One

Now that my Whiskey Data Table (or Whiskey Options Table) is complete, I can turn my attention to creating the context decision tree. The context decision tree in a Recommender contains a series of questions the user will be asked to determine his or her needs and gather any information about the current situation that may impact the decision being made. It also contains the link between each path through the decision tree and the options, or rows, in the data table.

Given these two important roles -- determining the user's needs and pointing to a particular set of options or solutions -- it is not surprising that the context decision tree is the knowtifact that contains the most critical 'expertise' in a Recommender application. In a complex subject like whiskey, there are hundreds of questions one might ask before making a recommendation, and even then it is not obvious what the best recommendation should be. In other words, creating a context decision tree is hard and full of subjectivity.

Because it is such a subjective exercise, if you ask ten different domain experts to build a context decision tree you are likely to get ten different results. This diversity of opinion reflects real life; if decisions were simple and obvious, we wouldn't need to consult with experts. The value of capturing expertise in a Recommender is multifaceted: it makes knowledge available to a wider audience by embodying it in a web app, it makes it possible to compare and contrast the decision processes of multiple experts, and multiple experts can leverage the same options table to build their own Recommender just by building different context decision trees.

The single biggest benefit of creating a context decision tree, however, is both subtle and surprising, and that is that it forces experts to actually articulate their knowledge. You might think getting experts to talk about what they know is not such a difficult thing to do, and that is true. But getting them to create a context decision tree can be very tough, and it raises issues like 'tacit vs explicit' knowledge and 'shallow vs deep' knowledge.

First, much of an expert's knowledge is typically tacit, especially when it comes to their decision making process. They just 'know' what to do, and they often can't explain why they do it. Building a context decision tree requires that they make this tacit decision process explicit.

Second, much of what passes for expertise is really 'shallow' knowledge like product and historical information, and rote process knowledge. This sort of expertise only requires a good memory. Building a good context decision tree often requires 'deep' knowledge, knowledge not only about what and how things are but why things are the way they are. It requires the ability to apply knowledge, not just repeat facts.

I've said from the beginning, I am not a whiskey expert. I started down the road on this demo application because I found a really cool classification chart for whiskies. I was able to take the next step and build the Whiskey Data Table because collecting data is more about diligence than expertise. But now I needed to find a whiskey expert.

Once again I turned to the internet, which is chock full of websites that claim to contain whiskey expertise. I started doing searches with phrases like "how to pick a whiskey" and "how to select the right whiskey". The search engines were able to pull up hundreds of links that purported to answer that question, but when I read what they had to say it was always a regurgitation of the same information over and over -- the differences between Irish whiskey and scotch, between Kentucky straight bourbon and Tennessee whiskey, between the bourbon process and the scotch process, between the mash bill for Canadian rye whiskey and American rye... The closest anyone came to providing useful information for the task at hand was the taste profiles for different scotch regions. Yes, taste is something a beginner whiskey drinker would care about. Mash bills? not so much.

Which brings us to a classic marketing problem. Users/consumers/customers are always looking for benefits -- touchy-feely, use-case specific benefits that will accrue to them as users. Manufacturers/sellers/retailers tend to want to talk about product features -- concrete, well-documented facts about the item or service they are selling. The marketing people are the ones who must make the connection between the two, and advertising and product literature exist to create that bridge.

In a similar fashion, a context decision tree, which is a series of questions that will be answered by the user, needs to be written in the language of benefits and use-cases. My web research surfaced very little knowledge that would help someone new to the world of whiskey decide where to begin. With so many choices, some of which are quite expensive, how can a relatively inexperienced drinker make a selection that is a good fit for his or her current needs? That is what I needed to know to create a good Whiskey Context Decision Tree.

After approximately 100 hours of total research time -- between building the classification tree, the data table, and general whiskey research -- I was going to have to use my own creativity and judgment to build the context decision tree. It was sure to have a lot of flaws, but at least I would be able to generate an initial version of a Whiskey Recommender.

Adding Images to the Whiskey Recommender

While images aren't required for a Recommender app, there is a place for a picture in the 'baseball card' template, just as you would expect for any baseball card. Here is an example of the template, as it is used in the Beach Town Recommender:

I want to add images to the Whiskey Recommender, but this is more difficult than it was for beach towns. The challenge arises, once again, because I am working with a much larger set of possible options -- 450 different whiskey brands!

The Beach Town Recommender has about 30 towns in it, so it was relatively easy to search the internet for good medium-sized images of my beach towns and save them to a folder on my computer. I won't be able to do that for 450 whiskeys; it's just too much work. I'll have to find different images for different types of whiskeys, and stop there.

The basic process I used was to (1) locate images using a search engine, and then (2) save those images to a folder using a simple, consistent naming convention. Then I added a "Picture" column to my data table and (3) entered the file name of the image I wanted to display for that particular whiskey.

I started out with a nice, generic picture of whiskey that I could use for my default image. This is the one I selected:

I named this 'whiskey.jpg' and I copied that name into the entire "Picture" column in my data table. I would copy and paste over this name if I found a better/more specific picture.

Now I moved on to my top level classes in my classification tree: American, Scotch, Canadian and Irish. What sort of images could act as generic images for these high level classes?

I learned after doing a bit of image research, which I did in the image section of both Google and Bing, that there were pictures available that showed groups of whiskey bottles, selected to represent different types of whiskeys. Here's an example:

This is the image I decided to use for 'American'. Someone else had already created this for me -- I could see that different bottles had been cut and pasted into the image -- but that's okay, it saved me some time. What I liked about this picture is that it had a selection of Tennessee Whiskey, Kentucky Straight Bourbon and Rye Whiskeys, making it a snapshot of a variety of American types and brands. I found similar images for Canadian, Irish and Scotch. At this point, rather than copying and pasting image names into my data table, I decided to hold off and see what other pictures I could find.

I was able to find similar multi-bottle pictures for several sub-classes: American rye, Kentucky bourbon, Tennessee whiskey, single malt scotch, and blended scotch. I would have liked to have pictures for the other sub-classes as well, like 'American blended' or 'American corn', but I couldn't find anything appropriate. So I used the generic 'American' image for those types, just as I had to settle for only one image for all of the Canadian whiskeys. At this point, I copied the names of the most specific image I had available into the appropriate cells in my "Picture" column.

Now I assessed the situation. I realized that when someone used the Whiskey Recommender, if they were directed to a particular type of whiskey, like single malt scotch, they would see 20+ 'baseball cards' -- all with different information on them but with the same picture, this one:

That's a little too boring, even for a demo! So I knew I needed to push one more level down in the data, if I could.

There were a couple of different options I could pursue. In single malt scotch I had another column in my data table: "Region". I could look for images that went with Speyside, Highlands, Islay, etc. But the other possibility was to look for images that went with the "Company" dimension, images for Diageo, Suntory/Beam, Sazerac, and the like. I decided to look for company-specific images, because that could add visual diversity to all of the whiskey types, not just single malt scotch.

I was able to find images for Beam Irish, Beam American, Forty Creek Canadian, Sazerac Canadian, Diageo Scotch and Pernod Ricard Scotch. Here is the image for Pernod Ricard Scotch:

After adding these images to my image folder, I copied and pasted the image names into the appropriate cells of my data table. I would love to have a picture of every specific whiskey brand, but for this particular demo, I decided to stop at this point. The Whiskey Data Table -- one of the two knowledge artifacts required to create a Recommender app -- was complete.

When I build the Whiskey Recommender using the Recommender Apperator, I will need to upload my folder of images along with my Whiskey Data Table and Context Decision Tree so that the pictures can appear in my web app.

One final comment about finding appropriate images: I always use my search engine's tools to limit the images I am shown to medium-sized files. That is big enough to provide good resolution in my web app, while saving data storage and reducing load times during execution.

Now I need to move on to creating the final 'knowtifact' that is required to generate a Recommender: the Context Decision Tree.

Adding Taste Attributes to the Whiskey Data Table

Now that I had a price level attribute in the table (see my last post) I wanted to add something about taste. I wasn't sure what information would be available about taste. There are plenty of qualitative descriptions on the web, describing particular types of whiskeys, but I wanted a single source that covered most of the whiskeys in my database. I found this very helpful graphic:

This picture reminds me a lot of the poster I used as my original knowledge source. It calls out the same four high level classes: Canadian, American, Irish and Scottish. It also has many of the sub-classes but not all of them. For example, it has some of the Scottish single malt regions, but not Campbeltown and Island. And there is no single malt listed under American whiskey, though there are several in my database.

This chart uses what is called a 'radar chart' to depict its information.

There are eighteen axes coming out of the center that show the whiskey's rating on 18 different taste dimensions: sweet, smoky, grainy, vanilla, honey, spicy, briny, malty, cocoa, buttery, toffee, fruit, bacon fat, oaky, caramel, corny, biscuity, and peaty. A given whiskey can have one of three scores on each of these dimensions: 0, 1 or 2. I decided to change these numbers into written descriptions. If a whiskey scored a zero, that flavor is not mentioned at all. If it scores a '1', the flavor is mentioned, and if it scores a '2' I added the word "very". So single malt scotch from Speyside could be described as "very sweet, very honey, very fuity, very oaky, grainy, cocoa, buttery and caramel."

Once again, judgment now plays an important part. While I love this graphic, I think most people's taste buds are not refined enough to taste the subtleties conveyed here. Most of us would be lucky to perceive the "very" strong flavors, let alone the secondary mentions. So I made the decision to simplify even further and only mention the flavors that were strongly associated with the whiskey, the "very" flavors.

I had to decide how to record this information for my data table, because that will have an impact on how it is displayed in the 'baseball card' shown in the final recommendation. I could make a column for each of the 18 flavors and record the score -- 0, 1 or 2 -- but that doesn't seem very user friendly. There would be eighteen attributes listed for each whiskey, many of which will not be applicable. Instead I decided to create a group of columns and label them 'taste1', 'taste2' and so on, and fill in the strong flavors associated with that whiskey. My data table now looks like this:

The number of flavors ranges from a high of seven for Highland single malt scotch to a low of one for several types of American whiskey. I'm okay with this; I think this reflects the differing complexities of different types of whiskey. People aren't buying American corn whiskey -- "moonshine" -- for its sophistication. My only real problem is the fact that I have several whiskey types with no taste information at all, because they are not listed in my taste knowledge source.

To fill in the blanks, I did further research. I found several sources that had taste profiles for both Island and Campbeltown single malts, so I filled those in, using the terminology I had already established.

The real challenge was American single malts. I found a New York Times article that talked about how this is an up-and-coming category, so it is important to have good data, but it also said this is such a diverse group it defies being summarized with a single taste profile. So I did what I have been resisting so far in this project: I created individual taste profiles for each whiskey.

I was able to find reviews for each American single malt in my database, and I used these reviews to create a taste profile containing my established terminology. Once again, if we were crowd-sourcing the data, or if this project were being funded by a customer, this individualized approach could be used for all of the whiskeys in the database, but this is a demo application that I am building to illustrate the process of building a Recommender, so I am going to keep things as simple as possible. There is a similar dynamic tension between effort and completeness in the final step of data preparation: adding images. That will be the topic of my next post.

Adding the Price Attribute to the Whiskey Table

My next challenge in building the Whiskey Recommender is to add attributes to the data table that will become the core of the information shown on the 'baseball card' for the recommended whiskies.

I'm going to start with 'price'. I already know I won't be adding actual prices to the table because I've decided to stop my decomposition process at the 'brand' level. Since all the variants of a brand, including bottle size, will have a significant impact on the actual price I need to aggregate that pricing into something more conceptual, like 'price level'.

I start by searching the internet for a downloadable source of whiskey prices. I found one pretty close to home: I live in Northern Virginia, and the liquor stores are state run, or at least state controlled. I found a downloadable file with all the current liquor prices. It looks like this:

This type of file is called a "csv" file, which stands for 'comma separated values'. The first row in a csv file usually contains a description of the data that follows. In this case, I learned that each row in the table contains seven items of information: the description of the item, an identifying code of some sort, the brand, the bottle size, the age of the liquor, its proof, and price.

It's pretty simple to import this kind of file into Excel, which will create a table using the first row for column headings and placing the data in the correct cells beneath.

The next thing I did is eliminate all the rows that did not contain whiskey information. The VA liquor stores sell many different alcoholic products and I needed to pull the irrelevant ones out of the analysis. I also eliminated columns that weren't relevant to my analysis: code, age and proof. If I were decomposing my whiskey brands to a lower level, like different ages, I would need this information, but since I have made the decision to aggregate all the variants into a single price level I can eliminate these columns. Now I was down to description, brand, bottle size and price.

One variant I can't ignore is the impact of bottle size.To make sure I am aggregating 'apples to apples' prices, I need to average prices for one bottle size only; this is called 'controlling' for bottle size. I notice by looking at the data that 750 ml is the most common bottle size, so I used the Excel data functions to filter the data and keep only the rows for 750 ml bottles. This is now the data set I will use for my analysis.

I then used Excel's average function to calculate averages for each description. For example, the data shown above would be included in the 'scotch' average. It's clear from inspection that there are some outliers  -- some bottles are very expensive! But our hope, as data analysts, is that the existence of outliers is spread out across different categories, and if there are clusters of them (like in scotch) that is a fair representation of the relative price for that category. Remember, we are trying to calculate a price rating of some sort, not an actual price. Scotch, and in particular, single malt scotch, is relatively expensive.

Once I had calculated an average for each description, I created a 5 point scale and a price range for each, with "5" being the most expensive. I used the description to map as closely as possible into the classification structure I had created in my data table and entered the price rating. To keep with our scotch example, I set the price level for every scotch in the table to "4". Now is where judgment comes in.

If I were building this application for a client, I would take the time to breakout sub-classes like 'single malt' in the Virginia price list so I could actually calculate the average price for that group. But since I am building this app as a demonstration piece, I was comfortable with sampling the single malts (I mean statistically sample, not literally - though I have done some of that in the course of my research) and giving single malt scotch a '5' on price level.

As a final pass of the data, I looked for brands that were priced significantly lower than other brands in their cohort. Different companies will have portfolios of brands in which one is used as their entry price point and is priced lower than the rest. If I can call those out without too much additional effort, I will. So I gave Dewar's a '3' and a scotch called Passport a '2'. I'm not sure that I caught all of these special cases, because the Virginia liquor stores don't sell every whiskey that's in my database, but I did the best I could with the data that is readily available.

Here's a sample of the whiskey data table with the price attribute added:

Notice Speyburn is a single malt scotch that I gave a '3' price rating, based on the actual price being significantly lower than other single malt scotches in the Virginia price list.

Creating the Whiskey Data Table

As I mentioned in the last post, the whiskey poster I am using as my initial knowledge source has almost 450 different whiskey brands listed. These brands represent the many options a whiskey drinker has from which to choose. In a Recommender with a smaller number of options, like the Beach Town Recommender, these possible choices can be added as notes to the KnowtShare file and dropped directly into the classification tree, becoming the 'leaves' of that tree. However, 450 notes would be difficult to work with in a visual environment. Data tables are better at that.

So I switched from KnowtShare to Excel and began creating my data table.

I began by creating columns that aligned with the classes and sub-classes I had established in my classification tree.

Each row in the table is an option that can be recommended. The first column should always hold the option name; in this particular example it is a particular brand of whiskey. 

I should point out that 'brand' is not the lowest possible level I could go in whiskey database. A particular brand can have many variants. For example, Macallan, a very fine scotch, comes in Macallan 12, 18 and 21, the number in the name referring to the number of years the whiskey has been aged. There is a basic Macallan, which is aged exclusively in sherry seasoned casks, and a Macallan Fine Oak, which is aged in a combination of sherry and bourbon seasoned oak for a lighter flavor.

In fact, the variants of whiskey seem to be endless, so to make the Recommender manageable I decided to stop at the brand level. This has its own challenges, because my next step will be to add some attributes to the table, attributes like 'taste' and 'price'. Any attributes I add will need to be generalizations, in a sense, because they will be referring to a group of whiskeys that vary in age, process and bottle size. If the data in this table could be crowd-sourced in some way it would be possible to account for this complexity, but as a demonstration app (which is what I am building) I will need to make some simplifying assumptions.

My next task is to expand the table by adding attributes to the whiskey brands.

Creating a Whiskey Recommender: The Classification Tree

The whiskey poster I found in an issue of Fast Company (see my last post) showed a complex network of specific whiskey brands and types, but on closer inspection it's clear that it is a single classification tree bound together by class/subclass relationships. There are four major classes of whiskey in this chart: American, Canadian, Irish and Scotch. These classes then break down into sub-classes in a variety of ways, based on the ingredients and process used.

I needed to capture the knowledge from the Whiskey poster in an actionable form, so I used KnowtShare to create a classification tree. This is the American Whiskey branch:

The window in the lower right hand corner is a navigation pane that shows the complete tree.

The KnowtShare app lets me create notes and group them quickly and easily into a hierarchical structure.

The American Whiskey sub-classes are a mix of grain used (wheat, rye, corn) and process (single malt and blended). Bourbon is a unique designation based on both grain requirements (at least 51% corn) and process (charred barrels).

Some of these sub-classes are further broken down based on region and company. The whiskey poster goes on to name specific brands in each of these categories, but with 450 brands listed I opted to stop the KnowtShare tree at this level and handle the brands in another knowtifact: the options data table.

Here are the Canadian and Irish branches of the tree:

The Irish whiskey branch has two new sub-classes: single grain and single pot.

And finally, here is the Scotch whiskey branch:

Scotch is unique because it calls out six different regions for single malt. Each is considered to have its own special taste based on process, but all are made from malted barley.

In KnowtShare, when working with a very large tree such as this, you can use the page itself as the top node of the tree (here it equals "whiskey"). This allows you to arrange the next group of classes in any way that works best visually. The text view will show everything as one comprehensive outline and the .knt file that is saved will combine the four groups into a single hierarchical file.

The next task will be to create the options data table.

Creating a Recommender

I am going to do a series of posts that document the process of creating an app using a knowledge pattern. I am going to use a particular pattern we call a 'Recommender'. The Recommender pattern is shown in both The Shape of Knowledge eBook and in Part 2 of the video series that provides an overview of the eBook's content.

You can view the videos at these links:
Part 1 https://www.youtube.com/watch?v=ui8kjxGmjE0
Part 2 https://www.youtube.com/watch?v=Hma_ho2fHck

The Recommender pattern is made up of one optional knowtifact and two required knowtifacts.

The optional knowledge artifact is a classification tree of the options under consideration. The two required knowtifacts are a context decision tree and a data table that lays out all of the options and their attributes.

In the book I talk about two simple Recommenders: an app that asks a potential knowledge author questions about what they want to achieve and then recommends the best knowledge artifact for the job (the KA Recommender) and a Beach Town Recommender that asks a future traveler a series of questions and then recommends the best beach towns for vacation.

For this example I am going to create a Whiskey Recommender (or "Whisky" Recommender, if you prefer that spelling of the word; I learned in my research that whiskey aficionados feel passionately about this question).

I picked whiskey NOT because I am an expert - I'm not. I picked it because I ran across this great visual in an issue of Fast Company:

This poster, which is very cool looking, appears to be a hopelessly complex constellation of whiskey names and types, but I knew immediately that it was something much more fundamental -- it is a classification tree for whiskeys.

In The Shape of Knowledge, the classification tree is one of my prime examples of the Triangle shape. This whiskey visual doesn't look very much like a triangle, or 'rooted tree', but it is. My first task in building the Whiskey Recommender is to transform this content into a usable form, and I will do that by organizing the basic tree structure shown in the diagram, using KnowtShare.

Video Overview of The Shape of Knowledge

I wanted to create a fast and easy entry point to the content of my eBook The Shape of Knowledge. I decided to make a video but I didn't want to do a traditional PowerPoint presentation - too boring - so I created a Prezi for the visual portion of my presentation.

If you're not familiar with Prezi, it is a visual presentation platform that lets you layout your content on a big whiteboard, in any way you want. Then you create a presentation path through the space, zooming in, zooming out, panning back and forth... there are tools that make it easy to create this path, including simple animations within individual frames. It is a real playground for the imagination, and the basic version of the service is free to use.

I like Prezi because I am very visual - that's why I am focused on shape and structure. What I liked about using Prezi as the vehicle to tell my story is that it let me layout my visuals the way I see them in my head, as a tree. But the presentation path is, by definition, a 'line' shape. This made my presentation both a story and an example of the story's main message: that there are best practices in knowledge shaping that make the transmission of knowledge more effective.

Best practice #1: Pick the best shape to store the expert knowledge. My Prezi shape is a composition tree.

Best practice #2: Prune the expert knowledge to fit the context of the current situation. I ended up breaking my story into two parts, the first focusing on the conceptual foundation and best practices, the second focusing on implementation. The unnecessary content was pruned away during the creation of each part.

Best practice #3: Present the solution with the simplest shape possible. The shape of my solution is a line, a linear path that represents my story-line.

I created narration using Adobe Audition and put the videos together using Techsmith's Camtasia. The videos are posted on YouTube.

Here is Part One:

Here is Part Two:

Relationships ≠ Structure

Here is an image I removed from The Shape of Knowledge:

I removed it, not because it isn't a great visual - it is - but because I didn't want to violate the copyright of the creators. But here, in a blog entry, it falls into the 'fair use' category so I will show it and not just describe it, as I did in the book. This illustration is famous; it did, after all, make the front page of the New York Times!

This diagram was in a presentation made to General Stanley McChrystal, during the time he was  leading the United States' efforts in the Afghan war. On seeing it he is said to have remarked "when we understand that slide we will have won the war".

One of the premises of TSOK is that structure arises from relationships, from connections. The 'materials' cause that Aristotle wrote about is about 'things' or concepts; structure is about the relationships between things or concepts.

My point in showing the Afghanistan slide is that the existence of relationships, depicted by the many arrows in the diagram, does not ensure the existence of structure. A logician would say that relationships are 'necessary but not sufficient' for structure to exist. The absence of structure is what General McChrystal was bemoaning when he made his ironic statement. Here is a visual that 'connects the dots' but no picture emerges.

Sense-making arises from structure, and the best structures for sense-making are those that naturally fit the patterns of relationships our brains make when we are exercising important cognitive skills such as classification and composition. The Shape of Knowledge is about recognizing structure in our thought processes and mirroring that structure in the knowledge artifacts ("knowtifacts") we create to communicate those thought processes.

Knowledge is more than a group of facts or collection of interesting information -- it's knowing how to link those facts together to solve a problem or achieve a goal. Communicating knowledge is about communicating a way of thinking that is useful, and doing it in such a way that others can replicate that thought process successfully in new situations. Creating artifacts to transmit knowledge successfully requires more than domain expertise, it requires an understanding of best practices for creating knowledge artifacts.

I think a good analogy is teaching. A good teacher knows a subject really well: for example, a good science teacher knows a lot about science. But a good teacher also knows a lot about teaching. Teaching is a skill; it can be taught and it is perfected through practice. Creating knowledge artifacts to convey knowledge is also a skill, one that requires an understanding of the role of structure in transmitting knowledge.

The PowerPoint slide above is a knowledge artifact. It was intended to transmit knowledge about the conflict in Afghanistan. It is clear from General McChrystal's comment that it fell short of its goal. Why? How could structure have been used to make its message clearer?

The Four Causes and Custom Chairs

One of the foundational concepts of The Shape of Knowledge is a mental model created by Aristotle called The Four Causes.

Aristotle said that every human artifact requires four inputs, or 'causes', to exist.

The first is the intent of the creator, the reason why the artifact is being created. Aristotle actually called this the 'final cause' because it represents the ultimate goal of the creative process, but it is the first cause from a time standpoint. Next, the artifact needs both a form, or shape, and materials. Finally, there is the act of actually forming the materials into the chosen shape. Aristotle called this the 'efficient cause' but I prefer to use the word process.

Intent, form, materials and process are the four elements necessary for the creation of any human artifact.

I give several examples in the book of the Four Causes in action -- building a house, knitting a sweater and writing a book -- before moving on to how they relate to the main topic of the book, knowledge artifacts.

Yesterday I ran into another excellent example of the Four Causes and how we interact with them daily in the course of our lives. I found this example in a Home Decorators catalog, on a page selling custom upholstered furniture. This page is designed to appeal to the customer whose intent is to buy a chair that perfectly fits her own particular tastes and decor.

This is how the catalog communicates the form, or shape, of the custom chairs. Each is shown in a neutral white fabric so the viewer can focus on the shape alone. The chairs are given names that often describe the form itself, names like 'Button Tufted-Back Dining Chair'.

The opposing page of the catalog shows the fabrics that can be used to make the chairs, the materials.

Some chairs can also be built with different colors of wood, another materials choice.

If the customer places an order specifying the form and materials, the manufacturer will execute the process of building that custom chair.

When stock furniture is designed, form and materials choices are made by a designer whose intent is to create a popular design that will appeal to many potential customers. The designer will study industry trends and will have a target customer in mind when he or she makes these choices, but the same form and materials choices must be made. Every act of creation requires the selection of a form and materials.

Aristotle's model is useful because it clarifies components of design that we tend to blur and conflate. The catalog creators used white fabric on the sample chairs because they know the viewer will be influenced and distracted by colorful or patterned fabrics. A customer may reject a chair shape because she doesn't like the fabric used on the sample, without ever realizing she is reacting to the materials and not the shape.

Realtors confront this problem all the time when showing houses to prospective buyers. They try to get the buyers to focus on 'the bones' of a house rather than the paint color and floor coverings that can be easily changed. This is easier said than done. People tend to react to the gestalt, the whole of something, and have difficulty thinking about shape and materials as two separate contributors to the final product. But designers must make this distinction, and when we are designing artifacts to embody our knowledge and transmit it to others we must think like designers as well. We must move beyond a focus on content and think about the best shape for conveying our knowledge.