Good User Feedback

Via Fiona (Austhink's Education Coordinator):

1. Startup screen is great, but how do I get it back?
2. Spell-check please!
3. Some well-heeled schools are getting the powerful combo of tablet PCs for staff and all students in conjunction with a projector (in preference to smart-boards)
4. Text pane open/close button goes missing
5. Some lap-tops have neither mice nor track-pads, making dragging of maps painful

Observations:

• Many (most?) secondary-school students kick off an argument map with a question
• Often encouraged to do so by their teachers
  
• Students asking for links between boxes -- other than hierarchical relationships -- within a map
• Kids are becoming more visual and audial
• Connection to the synthesizing mind and the disciplined mind in Howard "multiple intelligences" Gardner's latest opus, Five Minds for the Future.

Other positives:

• .NET is becoming more pervasive (as more products require it)
• Installation process is smooth

Abstract or Separate

As Rationale evolves we at Austhink -- the designers and programmers -- are again and again faced with a tension between on the one hand simplicity through separation, and on the other hand power through integration.

Each time we add a new feature we face the design decision of whether it should be deeply integrated into existing features, or tacked on somewhat separately. [Of course there is something of a continuum here.]

For example, the ability to add an image to any box generalizes the facility for images which were previously available only for basis boxes (and were in that case compulsory). The generalization has the following consequences:

1. Basis boxes may now have other images than the pre-defined ones
   
2. Basis boxes are now less special than previously

I claim point 2. because whereas previously basis boxes were

1. Visually distinct (on account of being the only boxes with images)
2. The only terminal category of box
3. Had a separate place in the epistemology of argument-mapping
   

Now that point 1 has been eroded, we are left with points 2 and 3. The argument in favor of these points are that they provide good "scaffolding" to ease the learning of the system, making them good for beginners, so they should be retained.

This is argument is analogous to the following:

Bicycles are difficult to learn to ride on account of their instability, so all bicycles should have training wheels.

Of course, in the case of bicycles we allow the training wheels to be removed, and we provide tricycles for small children and even for adults with limitations to their balance or who failed to learn to ride a bicycle sans training wheels when young.

So, when examining simplicity vs. power trade-offs the bicycle metaphor may be a good source of inspiration.

The 10 Comapments

Today is Shavuot, which marks the giving of the 10 commandments to Moses (photo) and his homies.

To celebrate this occasion there we will be cheesecake for morning tea. Why cheesecake?

And to demonstrate that Shavout is not just about artery hardening goodies I have constructed a comparison chart of the original 10 commandments and a respected modern interpretation.

	The Ten Commandments	The Ten Comapments
Given to	Moses	Dan
By	God	Some dude
On	Stone tablets	A slightly soiled napkin
Where	Atop Mt Sinai	Outside a small cafe in Carlton
1	I am the Lord your God who brought you out of slavery in Egypt.	I am RationaleTM your mapping tool who freed you from the bonds of confusion.
2	You shall have no other gods but me.	You shall have no other mapping software but me*.
3	You shall not misuse the name of the Lord your God.	You shall not omit the little TM symbol.
4	You shall remember and keep the Sabbath day holy.	You shall have a nice break between mapping exercises.
5	Honor your father and mother.	Pay your subscription / buy the upgrades.
6	You shall not murder.	You shall not own a Mac.
7	You shall not commit adultery.	You shall follow the Holding Hands rule, but that's all!
8	You shall not steal.	You shall use many sources, and give references.
9	You shall not bear false witness against thy neighbour.	You shall not construct defamatory example maps about your colleagues.
10	You shall not covet.	You shall not ask for too many new features at once.

*And bCisive.

A suspect for murder

Joseph Laronge presents a useful comparison of two different styles of mapping applied to the problem of whether Bob is a suspect for murder.

The first is an argument map:

and the second uses Laronge's own "path-mapping" conventions which he calls "pyramid style":

I have taken the time to do my own argument map, which in a way which gives I think the best of both worlds:

• The structure is largely taken from Laronge's particular path map, but
• The co-premises are pulled out, making it easy to show where the reasoning and evidence are open to challenge

It looks like argument mapping in a legal context is ripe for advancement. It will need people with skills in both mapping and the Law to work together to figure out how best to do it, both in terms of refining the method and conventions, and developing a sufficiently rich visual language.

In my example I would like to have been able to indicate through a strong visual device the following "legal concepts", which are somewhat implicit at present:

1. A piece of cited law
2. Which which "side" is favored by each premise

This could be accomplished in a few ways, but I will not go into that point at this stage. I am amore interested in finding out what else deserves to be reified in these kinds of maps.

Ideally, once the visual language is sorted out it should be possible to provide "road-maps" and templates that can be readily molded to reflect a particular case.

A big job indeed!

Clumping: The Missing Mode

Rationale -- the product that my working life revolves around -- currently has three mapping "modes": grouping; reasoning; and analysis.

Reasoning mode is for loose informal reasoning:


To tighten up the argument I use analysis mode, which allows me to break out the hidden premises:


Grouping mode allows me to create tree-like structures for non-reasoning purposes:


So while the reasoning and analysis modes provide specialized support for argument mapping, it is grouping mode that one turns to for all other tasks. I.e. Less sophisticated = more general.

And through the magic of our powerful "morphing" facilities it is possible to start working in one mode and then have Rationale convert the map into either of the other modes almost instantly. Very useful when you find yourself in the wrong mode!

So what's the missing mode?

In fact, it is possible to do reasoning in grouping mode, just without quite as much constraint as in reasoning mode, because fundamentally both of these modes manipulate "tree" structures.

What's missing is a mode which generalizes analysis in the same way that grouping
generalizes reasoning. Let's call this new mode clumping or clustering.

I am not quite sure what the applications will be, but I am confident that they will emerge.

Spare Cycles and cyber-Citizenship

Chris Anderson points out that people seem to have an awful lot of time on their hands, or "spare cycles" to write blogs, author open-source and free software, write and edit articles for Wikipedia, etc.

In the 21st century it looks like this kind of volunteer-ism is the new Citizenship.

Naturally the amount of spare cycles available to the individual must vary. Amusingly, a commenter accuses Anderson of not having kids, but he replies that he has -- gulp! -- four young children!

My comment is that these are engaging, creative, altruistic efforts to which people are donating their spare cycles, and such endeavours give you a warm inner glow and beget more energy. Hence they benefit both the individual and society.

And -- up to a point -- they benefit employers too because the energy induced in the individual by this kind of engagement washes into the rest of the employee's day.

Of course the challenge for the deeper-thinking boss is how to get an even-higher level of interest and engagement in the official work than can be found in cyber-Citizenship. On the other side of the fence are the social-website entrepreneurs who are after those spare cycles for their own enterprises.

Tipping Points and Diminishing Returns

I used to have a motto: "If something is worth doing, it's worth over-doing!"

While I have got older and have somewhat resiled from that degree of extremism I must concede that my younger self had a point. Here's why: Consensus is boring. If you want to be creative in your examination of issues and ideas, do not be content with looking at both sides of the coin. You will also need to turn it on its side, cut it in half, dye it blue, and compare it with similar coins, learn its history, and, ..., you get the idea.

In the end you may come back to a fairly uncontroversial consensus, but you will have done so with a thorough understanding of the available options. You will have learned interesting stuff, and have acquired an understanding rather than a pre-digested second-hand overview. This will enable you to make decisions or recommendations from a solid base.

Application to Software Design
A feature request comes in or -- more likely -- becomes top priority. You decide to implement it in its simplest form. Is it actually useful? Or is it simply the case that it could be useful? In the latter case this is a token feature. Maybe it could become useful with further work, maybe it should be left in for a while (to find out for sure).

If a feature turns out to be fairly unused and is not the subject of ongoing then surely it is a candidate for removal. Of course this will annoy the 2% of the user-base who do use it, so the usual practice is to baulk at this degree of ruthlessness, and leave it in, or merely deprecate it (i.e. "we plan to remove it, say in 20 years time"). If removal would break backward compatibility, we tend to be very reluctant to remove a feature.

So maybe we did introduce the feature to serve a genuine need, but have not yet gone far enough. Perhaps there is a Tipping Point where with sufficient integration and polishing a feature or feature-set suddenly becomes compelling.

So again it becomes a case of tinkering, polishing, experimenting and, reflecting to get there: maybe incrementally; maybe with a sudden jump.

This approach risks that you overshoot and pass the point of diminishing returns, or end up throwing good money after bad. But, your guts should tell you when to quit. I contend that, having committed to adding a feature, it is a greater danger to do a bit too little than to do too much.

In golfing terms: It is better to push a putt long rather than leave it short.

Practical exercise: Review your software and look for partially realised features. Mark them for removal or improvement.

Question: Given limited resources, is it better to have a smaller, thoroughly-realised feature-set, or a larger, partially-realised set?

Essays worth mapping

When I get some spare time -- ha! -- I plan to produce argument maps of some of the better essays (or excerpts thereof) that I can lay my hands on. Here is a list of a few that I came across recently:

• Knuth on Software Patents: An open letter to the Commissioner of Patents and Trademarks from one of the great originators of ideas about algorithms
  
• Henry Hazlitt, Economics in One Lesson: Most physical scientists assume that there isn't much to Economics, so let's get it out the way quickly!
• Stewart Brand, Environmental Heresies: A legendary environmentalist examines several issues that the environmental movement may well reverse its stance on in the next decade