Warning: Spoiler for Ender’s game by Orson Scott Card.*
After posting my comments on the Maiana interface, in my posting Maiana February Release, I fully intended to post a suggested alternative interface.
But, comparing end results to end results isn’t going to get us much further than: “I like mine better than yours,” sort of reasoning.
It has been my experience in the topic maps community that isn’t terribly helpful or productive.
I want to use Ender’s Game to explore criteria for a successful topic map interface.
I think discussing principles of interfaces, which could be expressed any number of ways, is a useful step before simply dashing off interfaces.
Have all the children or anyone who needs to read Ender’s Game left at this point?
Good.
I certainly wasn’t a child or even young adult when I first read Ender’s Game but it was a deeply impressive piece of work.
Last warning: Spoiler immediately follows!
As you may have surmised by this point, the main character in the story is name Ender. No real surprise there.
The plot line is a familiar one, Earth is threatened by evil aliens (are there any other kind?) and is fighting a desperate war to avoid utter destruction.
Ender is selected for training at Battle School as are a number of other, very bright children. A succession of extreme situations follow, all of which Ender eventually wins, due in part to his tactical genius.
What is unknown to the reader and to Ender until after the final battle, Ender’s skills and tactics have been simultaneously used as tactics in real space battles.
Ender has been used to exterminate the alien race.
That’s what I would call a successful interface on a number of levels.
Ender’s environment wasn’t designed (at least from his view) as an actual war command center.
That is to say that it didn’t have gauges, switches, tactical displays, etc. Or at least the same information was being given to Ender, in analogous forms.
Forms that a child could understand.
First principle for topic map interfaces: Information must be delivered in a form the user will understand.
You or I may be comfortable with all the topic map machinery talk-talk but I suspect that most users aren’t.
Here’s a test of that suspicion. Go up to anyone outside of your IT department and ask the to explain how FaceBook works. Just in general terms, not the details. I’ll wait. 😉
OK, now are you satisfied that most users aren’t likely to be comfortable with topic map machinery talk-talk?
Second principle for topic map interfaces: Do not present information to all users the same way.
The military types and Ender were presented the same information in completely different ways.
Now, you may object that is just a story but I suggest that you turn on the evening news and listen to 30 minutes of Fox News and then 30 minutes of National Public Radio (A US specific example but I don’t know the nut case media in Europe.).
Same stories, one assumes the same basic facts, but you would think one or both of them had over heard an emu speaking in whispered Urdu in a crowed bus terminal.
It isn’t enough to simply avoid topic map lingo but a successful topic map interface will be designed for particular user communities.
In that regard, I think we have been mis-lead by the success or at least non-failure of interfaces for word processors, spreadsheets, etc.
The range of those applications is so limited and the utility of them for narrow purposes is so great, that they have succeeded in spite of their poor design.
So, at this point I have two principles for topic map interface design:
- Information must be delivered in a form the user will understand.
- Do not present information to all users the same way.
I know, Benjamin Bock, among others, is going to say this is all too theoretical, blah, blah.
Well, it is theoretical but then so is math but banking, which is fairly “practical,” would break down without math.
😉
Actually I have an idea for an interface design that at least touches on these two principles for a topic map interface.
Set your watches for 12:00 (Eastern Time US) 28 February 2010 for a mockup of such an interface.
*****
*(Wikipedia has a somewhat longer summary, Ender’s Game.)
PS: More posts on principles of topic map interfaces to follow. Along with more mockups, etc. of interfaces.
How useful any of the mockups prove to be, I leave to your judgment.
Patrick, this is all too theoretical, blah, blah.
Oh, wait! That’s a trap.
You’re actually making a good point here – but with different conclusions. We all know that Maiana isn’t a tool for the general public but for Topic Mappers. The Maiana goal is to be able to load *any* topic map and have it represented in a reasonable and understandable way without any further information.
Unfortunately, a TMDM topic map doesn’t have enough information on how to display a topic map in a user-friendly or context-specific way.
Of course more could be done to make it more end-user-friendly, e.g. instead of listing the topic types in one list, one could have a list types and their instances¹ directly below them, so one item in the outer list would be “People” (which is easily pluralized from “Person”²) and then list all instances. This would be much more like what you intended in another post when you wrote about the “list of individuals”. Unfortunately, this doesn’t help understanding a generic map, it makes things less understandable and less clear in many cases.
There are things which could help displaying things in a good way, e.g. a TMCL model, maybe with more annotations to hint the UI generator etc.
I’m looking forward to try your interface and I’ll definitely find a generic Topic Map of which your interface leaves out important information. But wait, it’s just a mockup – how could I try?
¹ I can smell a Barta-comment coming up here (-;
² If the language is known or can be detected and there’s a pluralizer available.
Comment by Benjamin Bock — February 25, 2011 @ 3:29 am
Benjamin,
Sorry, I don’t think I was clear about the goals for the mockup interface exploration I promised. Or at least its non-goals.
Non-Goal #1: Be a generic interface for any particular topic map syntax. (To call Maiana a topic map browser is a category error. It is a topic map syntax browser. Not the same thing.)
What I want to explore are interfaces more generally, what have we seen that works and as part of that discussion, what would it look like to apply such principles as we can discern to the display of topic maps.
To jump to things like “…listing the topic types in one list…” reflects a mis-understanding of the issue I am attempting to address. Yes, we can always ask programmers what syntax interface they like and get a non-marketable product. I got that part. We have a long history of that in topic maps.
I am asking different questions: What interfaces have been proven to work for users? What are the characteristics of those interfaces? How (if at all) can we use those characteristics in developing a topic map interface or principles for topic map interfaces? (note the plurals).
The sort of questions that are researched and discussed in “media” departments around the globe.
Personally I think work on interfaces will involve a great deal of experimentation (hence the mockups), test versions, surveys of users, etc.
I appreciate your focus on the “practical” aspects of delivering a result but if we have no idea what a useful result would look like, that focus seems a bit premature.
Comment by Patrick Durusau — February 25, 2011 @ 5:59 am