Notes on the book "Why Not?" (How to Use Everyday Ingenuity to Solve Problems Big and Small)

A while back I finished a great book on problem solving (and ideas) called Why Not? How to Use Everyday Ingenuity to Solve Problems Big and Small. (There's also a website called Why Not Open Source Movement.) I wanted to post my notes from the book, summarizing their points. If you think these are interesting, I urge you to buy the book. I found it a great resource.

The authors present two basic idea-generating methods, and four problems-solving tools:

1. Problems in search of solutions
   
   1. What would Croesus do (WWCD)? (UNCONSTRAINED CONSUMER)
      
   2. Why don't you feel my pain (INTERNALIZATION)?
      
   
   
2. Solutions in search of problems
   
   1. Where else would it work (TRANSLATION)?
      
   2. Would flipping it work (SYMMETRY)?
      
   
   

Following are some details on the main points.

1.1 What would Croesus do (WWCD)? (UNCONSTRAINED CONSUMER)

• Have someone else solve problem first.
  
• Customers: product misuse -> new problem and solution; Good to think of what hypothetical customer would do.
  

1.2 Why don't you feel my pain (IMPROVED INCENTIVES)?

• Self-interest -> doing wrong thing.
  
• "Negative externalities" (misguided or missing incentives).
  
• Look for inefficient behavior by buyers or sellers.
  
• Solution: INTERNALIZE external effects -> feels my pain so does right thing.
  
• Look for systematic customer mistakes.
  
• Penalty vs. incentive.
  

2.1 Where else would it work (TRANSLATION)?

• "Don't think, look!"
  
• Look in other cultures, countries, religions, etc.
  
• Look at neighbor.
  
• Different context - 1) identify attributes of solution that concisely explain solution of problem. 2) generalize description.
  

2.2 Would flipping it work (SYMMETRY)?

• Stress test: 1) Stress different words in declarative description of problem/solution. 2) Flip stressed words.
  
• Anti-symmetry possible good too.
  

Here are a few notes from the final chapters.

Chapter 7: Principled problem solving (identify PRINCIPLES)

• Think inside the box (constraints can help make search more productive).
  
• Identify problem's PRINCIPLES (axioms) - what you *do* know (knowing 75% of answer -> easier to find other 25%).
  
• Beware false (artificial) principles, but they're possibly useful for applying elsewhere for solutions.
  
• Confidence - be a "Platonist" - assume discovery, not creation.
  

Chapter 8: The case for honest tea

• Use DISSONANCE to discourage others from entering your market (new product would be very inconsistent with current).
  

Chapter 10: Implementing Why-Not

• Karl Marx: We shouldn't be satisfied with just analyzing or interpreting the world: "[T]he point is to change it."
  
• presenting: elevator pitches - one line
  
• KISS - keep it SIMILAR, silly.
  
• WHO to pitch to: pay attention to who would have interests (identify audiences).
  
• Install the CO-VENTURER perspective in audiences - e.g., give up rights.
  
• Open source - "just share it"; can cause demand as originator get reputation as "idea person."
  

To summarize - a very helpful book, I believe.

An XML Clipboard for Semi-Structured Data

The problem: Data is still frequently transmitted as semi-structured ASCII text, but applications require structured information. For example, I often want to input an address into an electronic address book based on text from an email or web page, esp. a signature. (Yes, there's vCard, but I think consistent usage is still rare, and using it requires extra steps.) Another example is inputting financial transactions into a finance program from an on-line banking page - I now do much of my bill paying on-line using a web interface from my bank, and I hate having to laboriously (and erroneously) copy each section of the transaction's output (HTML) into GNUCash.

The solution I'm playing with has two parts: a) a general-purpose data recognizer clipboard that converts semi-structured text to XML, and b) support by applications for recognizing XML on the clipboard. The thought is that by converting to XML (i.e., semi-structured data that has been marked up), we've done the hard low-level data recognition work, leaving it to the applications to 'take what they can use'.

Usage scenario: consider copying the following email signature (from this example) to the clipboard:

    Jim Frazier, President
    The Gadwall Group, Ltd. -  IT and Ebusiness Strategies
    Batavia, Illinois     630-406-5861      jfrazier@gadwall.com
    http://www.gadwall.com      http://www.cynicalcio.com
    Seminars and Training - Consulting - Publications

(I don't know him - it's just the first public signature I found.) It's easy to envision a straight-forward regular expression-based tool that pulls out the following:

    <clip>
      <name>
        <first>Jim</first>
        <last>Frazier</last>
        <title>President</title>
      </name>
      <location>
        <town>Batavia</town>
        <state>Batavia</state>
        <country>Batavia</country>
      </location>
      <phone>630-406-5861</phone>
      <email>jfrazier@gadwall.com</email>
      <url>http://www.cynicalcio.com</url>
    </clip>

Here's what the text copied from a bank's on-line statement might look like:

  04/27/05 | Checking | Check 2067 | 2067 | $-45.00

Where the columns are: Date, Account, Description, Check #, and Amount. In this case the date might be:

    <clip>
      <date>
        <month>04</month>
        <day>27</day>
        <year>2005</year>
      </date>
      <text>Checking</text>
      <text>Check 2067</text>
      <number type="integer">2067</number>
      <currency unit="dollars">-45.00</currency>
    </clip>

You get the point - basically it's just a set of lower-level recognized data. It's up to the application to put the pieces together in a more specific and meaningful way.

Thoughts:

• It would be great to program custom rules using a nice scripting language, such as in JavaScript (used to program Konfabulator widgets).
  
• As a work-around to requiring applications to recognize XML, we might try the XML clipboard plus a mouse/keyboard macro playing program (e.g., QuicKeys).
  
• There would need to be a DTD standard for this. (I'm sure one exists somewhere.)
  
• Hasn't this been done (partly) by Apple's old Data Recognizers idea? A few references here and here.