Turning MS Office into a game

There's now a plugin to Microsoft Office, Ribbon Hero, that adds simple game dynamics to encourage users to better learn how to drive the darn thing, betwixt coffee breaks.

Informative article, here.  Excellent slides:

Beats the hell out of reading the manual.

Non-functional requirements

There's a lot of unglamorous stuff in software that is just "expected", and accounts for some of the project cost that you will miss when imagining two guys in a garage (or cafe) knocking out a quickie project.  Here's a handy list: Non-functional requirements: Minimal checklist.

To Customize is Cool

It's cool to customize! It practically has the word "customer" in it, so what's not to love?

Seriously: When prospective customers see the Qualify tool -- part of Austhink's bSelling add-on to Salesforce crm ...


they say two things:

1. Wow!
2. Can I customize it?

The "Wow!" reaction is because here is a tool that really helps the salesperson with a vital but difficult task -- sales qualification -- in a fun way. It provides useful feedback -- an overall percentage, and sensible concrete ways to boost the score. Ok: Most of the wow is because of the fun factor and groovy way it plays (like flipping through photos on a Mac).

The second reaction -- the wish for customization -- is natural. Although at Austhink we believe that the out-of-the-box system is quite generic, sales teams do of course vary in their terminology, types of customers, and overall slant sales.

So, I recommend a suck it before you salt it approach:

1. Try out the generic version (that comes with the free version of bSelling) on a few opportunities to get the feel for the process. Just pick a neutral "card" if a factor doesn't seem to apply.
   
2. Make notes about where the terminology needs revision, which "factors" don't apply, and which (if any) are missing.
3. Upgrade to the premium version of bSelling and make use of our soon-to-be-released customize feature.
4. If you need extra help, we can arrange consultation!
   

The customize feature allows your company to change the wording, options, factors, and weightings -- i.e. everything -- of the Qualify tool to tailor it to fit your unique situation. Just like the tool itself, it looks great, is fun-to-use and it has a game-like feel. Here's a sneak peak:


Each line represents a deck of cards in the tool, and each block represents a single card. The length of each line represents the weight of each factor. You just click on a box to edit some wording (shown), or click on an end box to stretch or squash a line (to make a factor more or less important compared to the others). Other operations are similarly simple.

By the way: If you think of the Qualify tool as a level in a game, the customization tool is like the level-designer that allows an obsessed user to design new game levels for their friends to play. In this case, the customization tool allows the sales-manager to tweak (or totally revamp) the qualification process to fit local conditions, and better monitor (and mentor) the sales team.

We are about to trial the customization tool with a select group of beta-testers -- email me at dan@austhink.com if you want to give it a whirl -- and the first version should be available in the next week or so.

First web-based product released: bSelling

Last week we -- Austhink Software -- released our first web-based product, bSelling Opportunity Management, an add-on application to the web-based Salesforce CRM.

Yay team!

Here are some brief notes about the product (a visual tool to enhance the performance of sales teams), its placement (as an add-on to Salesforce CRM available through salesforce.com's AppExchange), and the development experience (using Adobe Flex + Django talking to Salesforce).

The Product
The best way to get a taste for this add-on, which helps the salesperson to better Qualify (i.e. estimate the percentage chance of closing the deal) , better understand the customer's pain(s), and ultimately pitch more effectively to the customer's needs -- is to check out the 2 minute (approx.) introductory video:

bSelling video

For non-sales people, here's my distillation of Solution Selling, one of a family of consultative approaches to sales -- along with SPIN, Strategic and Consultative Selling -- that bSelling is intended to support.

The Placement
Austhink's Softwares previous products, bCisive and Rationale were PC-based and intended to create new markets: Rationale for improving Critical Thinking in education, and bCisive for applying Visual Thinking to business.

For our first web-offering we decided to pick a more targeted application -- consultative selling -- and apply our visual approach more narrowly. This enabled us to go from "let's port bCisive to the web" (a daunting undertaking on account of the size of the pre-existing product) to "let's port the bits of bCisive that will help with consultative selling" (a smaller and more customer-centric) undertaking.

We aimed from the outset to put the resulting application on Salesforce.com's AppExchange, as a way to make bSelling visible to our chosen market segment, and to offer easy integration with the leading web-based CRM.

Development Experience
We accomplished this with a team of 3 in just over two months, admittedly making use of some initial work on a web-port from last year, plus our accumulated experience from bCisive, Rationale and some earlier non-commercial web-based projects, most notably Aaron's side-project, Path of a Hero.

We found that Adobe Flex / AS3 gave us the graphic power (and portability across browsers) that we wanted for the front-end, with our architecture hanging off a slightly souped-up version of the PureMVC framework. We use Django / Python / MySQL for the back-end and use AMF3 / PyAMF to get fast communication between the back and front-ends.

The big unknown for us was integration with Salesforce CRM. It turns out that their APIs and docs are pretty good, and we were able to embed our app as a web-page in their S-Control.

Now, it is possible to build apps entirely on their force.com platform, but we chose not to because:

• It required a steeper learning curve
• We had a pre-existing technology investment
• It would couple us completely to their platform

On the negative side this meant that we had to subject ourselves to a nerve-wracking security review. This involved submitting our organization's written policies plus go under attack from their review team. It was certainly "an experience", a bit liking going back to University for another exam, but their liaison was helpful in guiding us through the process, and we achieved a provisional pass first time (much relief).

One note for start-ups: There is normally a $US5000 application fee for the review (annual!). The two ways to waive this are to develop directly on the force.com platform (i.e. inside the Salesforce sandbox), or to supply a free version of your app. We went with the free version.

Compared to the security review, the final review was less demanding.

The Future
We are putting the finishing touches on an "export to PowerPoint" feature for the paid version, so that a salesperson can grab some snappy visual slides to supplement customer presentations.

Naturally getting the word out is paramount -- thanks to AppExchange we've already had some people checking out the video and installing bSelling-- and we look forward to responding to customer feedback with further refinements. To this end we have set-up UserVoice to help out with this. The AppExchange infrastructure requires people to leave details, so we will also follow up (selectively and politely) with some of the early adopters to find out worked and what didn't.

Beyond bSelling on Salesforce we are also look at integrating it with other online platforms (SugarCRM is an obvious candidate).

And beyond that lie other applications in Sales and other business verticals. We aim to apply our skills and technology to create other "Enterprise 2.0" apps, but in these -- ahem -- challenging times we need to be strategic about picking off targets.

Software Product Design and the Collaboration Process

In the last few months my team and I at Austhink software have had a wonderful graphic designer -- David Urbinder -- consult on our products. Much more than design icons and images, collaborating with David has led to improvements in overall visual design, and more deeply into dynamic behavior (interaction design) and consequently the overall usability and appeal of our products.

Working with someone from a complementary design background helps to trigger creative sparks. David has pointed me to this article by Nate Fortin about the non-separability of design into different disciplines in Cooper Journal. Cooper Journal is hosted by Cooper Design, whose principal Alan "Father of Visual Basic" Cooper wrote the influential book About Face, and the provocative and important The Inmates are Running the Asylum, both of which I also highly recommend.

One of the issues that we are grappling with is how best to engage expert outside design consultants like David. At the moment we are doing a blend of some consulting time, plus directed tasks, spread out over time. The benefit of the spreading out is that we get the benefit of David's creative input early, when it can have a formative effect, and guidance at later stages too as the product becomes more "locked down". Coordinating our schedules is a "fun" part of this approach, and is of course more challenging than just employing him for confined blocks.

Finally, if you want to commission David, I would love to link to his web-site, but I believe that it is not ready for public consumption just yet (hint, hint ;-). In the meantime, David can be contacted on email at urbinder@gmail.com.

Inspiration

Bob Franklin, who programmed up the first electronic spreadsheet, VisiCalc, in 1978 working with Dan Bricklin -- whose idea it was -- has been writing up the history. I found the following inspirational and salutory. How to build a software product:

Design Principles

VisiCalc was a product, not a program. Decisions were made with the product in mind and, to the extent possible the programming was towards this end. In practice it was more complicated as we were designing against the limitations of the personal computers, price point and, most important, what the user could understand.

The goal was to give the user a conceptual model which was unsurprising -- it was called the principle of least surprise. We were illusionists synthesizing an experience. Our model was the spreadsheet -- a simple paper grid that would be laid out on a table. The paper grid provided an organizing metaphor for a working with series of numbers. While the spreadsheet is organized we also had the back-of-envelope model which treated any surface as a scratch pad for working out ideas. Since we were used to working with powerful computers without worry about the clock running, we already had the experience of focusing on the users needs rather than the computers needs.

The ability for Dan and I to work as a team was crucial. While he could've written the program, the fact that he wasn't gave him the freedom to focus on what the program should do rather than how to do it. I could appreciate his reasons and would eventually accept that I had to change code that I had labored over. We were able to find ways to take advantage of the limited space available for the program in deciding what features to include or not include.

The original version put the entry area at the bottom of the screen. By playing with this simple prototype Dan found that it was better to put the entry area at the top of the screen and I made the change to the evolving program.

In addition to prototyping, Dan put together a reference card for users. If we couldn't figure out how to explain a feature on the reference card we would change the program. The original method for copying formulas was too complicated so we just changed the design rather than try to explain it.

The more things change, the more they stay the same.

Laws of Logins

Privacy issues aside, when it comes to logins, I want convenience.

When using a web-page that provides a service, I want it to:

1. Allow me to try or taste the service without entering a username and password (or I won't it use it).
2. Never supply username and password if the service is once only (or I won't use it).
   
3. Allow me to login and use a nice administrative interface if it is a site that allows me to create content. For this, I not only accept having to supply login details; I want to be able to login.
   

Of course having to remember multiple logins for multiple sites (point 3) is a PITA. Can OpenID help with this?

Order-dependence of design decisions

When the proggit community was asked for their best piece of Best piece of insight for computer programming/software engineering? some excellent responses were elicited, including this one from hamsterboy:

The quality of the design of a piece of software depends on the order in which you make the design decisions. 5 years from now, the earliest decisions will have the most far-reaching consequences, and will be the most difficult to re-think.

This can be taken incorrectly as an indictment of incremental approaches or, more acutely, as justification for periodic re-design.

Recently I have been working on a port /re-design of a 2.5 year-old product and it has been an absolute pleasure to be able to take advantage of the insights learned the first time round.

Signs of Good Design

It is a good sign when something you design solves problems not originally envisaged. This indicates depth and robustness.

Another good sign is when a third party of high standing makes a recommendation.

Both these signs are apparent in the increasing adoption of the Erlang language and libraries for distributed computing problems. Originally designed for telecommunications software, Erlang is now being used by Amazon, Facebook, and others as part of their infrastructure.

Also, Steve Vinoski, an authority on CORBA, an older technology for distributed computing, has been singing the praises of Erlang for largely "getting it right". In response Joe Armstrong (inventor of Erlang) has thanked Steve for going down the wrong path and living to tell the tale. Here's Joe on Steve, and Steve on Joe.

I hope that everyone working in distributed computing can take note of the lessons that Steve (and Joe) learned the hard way, without necessarily repeating all the hard yards.

Remember: It is always a good time to learn from other people's mistakes (and your own).

Fred Brookes on Online Collaboration

DL Weinreb, one of the co-creators of Common Lisp, took some notes at the OOPSLA 2007 conference. One of the talks was by given by Fred Brooks:

Fredrick Brooks Jr., author of the classic book “The Mythical Man-Month”, talked about telecollaboration. Most of the talk was about collaboration itself, and under what circumstances it’s a good thing: not always! His main point is that collaboration is great for determining system requirements and brainstorming about possible approaches, but that you really need a single system architect in order to achive conceptual integrity. The system architect can delegate parts of the architecture to others (e.g. the user interface czar), but he distinguishes sharply between delegating design (OK) and sharing design (not OK).

Readers of The MMM, will not be surprised by Brooks's reiteration of the need for a single designer to ensure a unified vision, but it's nice to have strong position brought to light in a new context.

For me, Brooks's pronouncement raises a couple of questions:

• To what extent does his advice apply to non-software enterprises?
• To what extent should collaborative software endeavour to encourage "good practice" through constraining its users?
  

Algorithms vs Architecture

There are many facets to software design. Some, like user-interface design, are apparent to the end user. Others take place almost entirely under the hood. These are the bones on which the software is built.

Two significant under-the-hood aspects are algorithms and software architecture.

Algorithms form a major strand of computer science. They are concerned with
the nitty-gritty of getting the computer to do stuff. The major aspects of an
algorithm include: what it does, its domain of valid inputs, and its time- and
space-efficiency.

Software architecture, on the other hand, is concerned with the high-level structure and conventions of a software system, and is more of a topic for industry than academia. Good architectural choices contribute to the overall performance, resilience, and extensibility of a system.

We need both! And interestingly, you neglect either one at your peril.

For example, recently when we noticed a significant slow-down in performance the issue turned out to be an architecture-algorithm interaction. While the algorithm was O(n^2) in time, an imperfection in the architecture led to it being executed as each item was added to the structure, making it effectively O(n^3), and correspondingly sluggish.

As usual, when the problem is tricky to track down, it is often due to the interaction of two separate-seeming factors.

Cross-ferretization

Cross-ferretization, n. The art of stealing ferreting out ideas from other fields and applying them to one's own.

In programming, there are many generic job descriptions:

• programmer
• software developer
  
• software engineer
• software architect
• computer scientist
• hacker
• etc.
  

Each of these has its own connotations, some overlapping, some contradictory.

Recently I have been delving back into (physical) architecture, and finding out a bit more about that field.

(Physical) architects are the generalists in a once-unified field that has splintered into civil engineers, draughtsmen, builders, interior designers, etc. Consequently their training delves into many fields, and in practice they work with many specialists, especially on large projects.

So it seems reasonable that there is a role for (software) architects in the (virtual) world, although such titles seem to be largely self-bestowed and not really as well-defined as (physical) architects.

Another reason for the interest in architecture in software development is the influence of Christopher Alexander and his notions of patterns and pattern languages on programming. This gave rise, largely via the famous Gang-of-Four book, to the notion of patterns in software (although the notion of pattern languages) was not as widely imported.

For what it is worth, Alexander's original writings have always resonated with me in a way that the Gang-of-Four's have not. So the other day when I spied an attractively packaged little book aimed at (physical) architects and students of architecture, entitled 101 Things I Learned in Architecture School by Matthew Frederick, I purchased it with little hesitation.

Quick review: "101" is not just a book for architects, but for anyone with an interest in any kind of design. Many of the "things" are of general applicability-- I especially like #29, about the importance of being process- rather than product-oriented, and #45, which contrasts simplicity with complexity and informed-simplicity. Such of the ideas are really very general. Others are specific to architecture, either practical points or theoretical tidbits, often admitting useful analogies. Each thing is accompanied by an illustration.

Every field needs a book like this.

Parsimony in Design

William Clinger writes in the introduction to the revisions to the Scheme programming language standards (my emphasis):

Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary. Scheme demonstrates that a very small number of rules for forming expressions, with no restrictions on how they are composed, suffice to form a practical and efficient programming language that is flexible enough to support most of the major programming paradigms in use today.

It would be great to be able to similarly say:

Applications should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary. Rationale demonstrates that a small number of rules for forming structures, with minimal restrictions on how they are employed, suffice to form a practical and efficient application that is flexible enough to support most of the major decision-making paradigms in use today.

Step 2: Make it so!

The Medical Model of User Feedback

From a Business Week interview with Clayton Christensen, author of The Innovator's Dilemma:

In The Innovator's Dilemma you warn that the maxim "staying close to your customers" can lead you astray. Wouldn't a cursory reading of the book say "don't listen to your customers?"

You're exactly right. The cursory reading is "don't listen." The deep reading is you have to be careful which customers you listen to, and then you need to watch what they do, not listen to what they say.

The last part of this -- watch what they do / don't listen to what they say -- while perhaps superficially disrespectful is a key part of what I call the Medical Model of User Feedback.

Symptoms and Signs
When a (medical) doctor examines a patient she will usually ask for symptoms -- what is the patient's experience? -- and look for signs -- her own observations.

Generally signs are regarded as the more significant, since the patient is typically neither particularly well-trained at interpretation nor unbiased. This is why watching people is invaluable when tuning software features.

By all means listen to User Feedback and requests, but consider it an early step towards revision and improvement, not the last word.

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.

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?