I ran across Top Three Drivers of Solr Adoption and thought it might offer some lessons for driving topic map adoption.
From a survey of customers, these were the following drivers:
- Vendor Fatigue
- Flexibility
- Stability
Having a “cute” name didn’t make the list. So much for all the various debates and recriminations over what to call products. Useful products, even with bad names, survive and possible thrive. Useless products, well-named or not, don’t.
Vendor Fatigue referred to the needless complex and sometimes over-reaching vendor agreements that seek to guarantee only particular levels of usage, etc. You really need to see the Dlibert cartoon at the post.
Very large vendors, ahem, I pass over without naming names, can rely on repeat business “just because.” Small vendors, on the other hand, should concentrate on delivering results and no so much on trying to trap customers in agreements. (You will also have lower legal fees.)
Good results = repeat business.
Flexibility referred to the ease with which Solr can be adapted to particular needs both for input and output. Topic maps have that in spades.
Stablity I think what the author meant was complexity. That is Lucene is for more complex than Solr, which makes it more difficult to maintain. Solr, like any other abstraction (compare editing with ex to vi), makes common tasks easier.
Topic maps can be as complex as need be.
But, in terms of user interfaces, successful topic map applications are going to be domain/task specific.
I say that because our views of editing/reading are so shaped by our communities, that departures from those, even if equally capable of some task, feel “unnatural.”
Shaping topic map interfaces in conversation with actual users, a fairly well documented technique, is more likely to produce a successful interface than developers guessing for days what they think is an “intuitive” interface.