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:
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.
Uta Schulze and Michael Prilop report:
Today, the Maiana team released the first 2011 version of Maiana. After forgoing the January release because of open issues we are now presenting Maiana in a partly new design – including pagination and catchy boxes. Most important: Maiana switched to TMQL4J v. 3.1.0-SNAPSHOT supporting the draft of 2008.
- New design: Check out our fresh new design to present data in a topic map (e.g. the Opera Topic Map). Do you like it? We also extended the ‘Overview’ box to summarize every action available to the topic map. Last but not least, we added pagination to avoid long load time and vertical scrolling.
- New TMQL4J version: We now run on TMQL4J v. 3.1.0-SNAPSHOT (see TMQL4J 3.0.0 Release News for more information). Currently, only queries compliant to the TMQL draft of 2008 are supported.
- Donating queries: TMQL and SPARQL queries which until now could only be used privately may now be set public. Thus enabling sharing of queries or simply promoting a interesting query result. An overview of queries may be found on the users corresponding profile page.
- Syntax Highlighting of TMQL Queries: And because reading queries is difficult as it is we now use syntax highlighting displaying queries and even some autocompletion (try typing “FOR”)
- “More about this subject”: To enhance the browsing experience we now look up additional information whilst visiting a topic page. This expands our use of the Semantic Search to also show topics available in visible maps on Maiana and even providing similarity information (Opera).
- Maiana Search Provider: Do you like using your browsers search field? Try adding Maiana as a search provider and find more, faster!
The new Maiana homepage, http://maiana.topicmapslab.de/.
With Opera, http://maiana.topicmapslab.de/u/lmaicher/tm/opera.
Comments on the new interface?
I think the color scheme makes it more readable, something I appreciate more and more the older I get. 😉
Beyond that…, well, I have to confess the topic map navigation interface doesn’t do a lot for me.
I think because it seems to me, personal opinion, to emphasize the machinery of the topic map at the expense of the content.
Hmmm, think of it this way, what if you had the display of an ODF based document and it listed:
<h> elements
….
3 Document Structure
3.1 Document Representation
3.1.1 General
….
<text:p> elements
….
<draw:object> elements
….
It would still be readable (sorta) but not exactly an enjoyable experience.
Let me leave you to think about the machinery-in-front approach versus what you would suggest as an alternative.
I have a suggested approach that I will be posting tomorrow.
(Hint: It is more of a pull than push information model for the interface. That maybe what is bothering me about the default topic map interface, that it is a push model.)
DSPL: Dataset Publishing Language
From the website:
DSPL is the Dataset Publishing Language, a representation language for the data and metadata of datasets. Datasets described in this format can be processed by Google and visualized in the Google Public Data Explorer.
Features:
- Use existing data: Just add an XML metadata file to your existing CSV data files
- Powerful visualizations: Unleash the full capabilities of the Google Public Data Explorer, including the animated bar chart, motion chart, and map visualization
- Linkable concepts: Link to concepts in other datasets or create your own that others can use
- Multi-language: Create datasets with metadata in any combination of languages
- Geo-enabled: Make your data mappable by adding latitude and longitude data to your concept definitions. For even easier mapping, link to Google’s canonical geographic concepts.
- Fully open: Freely use the DSPL format in your own applications
For the details:
A couple quick observations:
Geared towards data that can be captured in csv files, which are considerable and interesting data sets, but only a slice of all data.
Did not appear on a quick scan of the tutorial or developer guide to provide a way to specify properties for topics.
Did not appear to provide a way to specify when (or why) topic could be merged with one another.
Plus marks for enabling navigation by topics, but that is like complimenting a nautical map for having the compass directions isn’t it?
I think this could be a very good tool for investigating data or even showing, but if you had a topic map, sort of illustrations to clients.
Moving up in the stack, both virtual as well as actual, of reading materials on my desk.
Free Encyclopedia of Interactive Design, Usability and User Experience
A resource like this will not make non-design types (ask me about the cover on my first book some time) into designers.
It may give you a greater appreciation for design issues and the ability to at least sense when something is wrong.
So you will know when to ask designers for their assistance.
Interfaces that are intuitive and inviting will go a long way towards selling a paradigm.
Building Interfaces for Data Engines is a summary by Matthew Hurst of six data engines that provide access to data released by others.
If you are a data user, definitely worth a visit to learn about current data engines.
If you are a data developer, definitely worth a visit to glean where we might be going next.
If it is any consolation, the art of book design, that is the layout of text and images on a page remains more art than science.
Research on that topic, layout of print and images, has been underway for approximately 2,000 years, with no signs of slacking off now.
User interfaces face a similar path in my estimation.
Hubs and Connectors: Understanding Networks Through Data Visualization
I have been shying away from the rash of LinkedIn graph visualizations but then I ran across this one by Whitney Hess at her Pleasure + Pain: Improving the human experience one day at a time blog.
The title alone made me take a double take. 😉
This post merits your reading as an introduction to network analysis, albeit presented in an easy to understand way with eye-candy along the way.
While you are there, check out her archives and other posts as well.
Such as: 10 Most Common Misconceptions About User Experience Design
If I could get topic map project managers to read one article, it would be that one.
Workshop on Human-Computer Interaction and Information Retrieval
From the website:
Human-computer Information Retrieval (HCIR) combines research from the fields of human-computer interaction (HCI) and information retrieval (IR), placing an emphasis on human involvement in search activities.
The HCIR workshop has run annually since 2007. The workshop unites academic researchers and industrial practitioners working at the intersection of HCI and IR to develop more sophisticated models, tools, and evaluation metrics to support activities such as interactive information retrieval and exploratory search. It provides an opportunity for attendees to informally share ideas via posters, small group discussions and selected short talks.
Workshop participants present interfaces (including mockups, prototypes, and other early-stage designs), research results from user studies of interfaces, and system demonstrations related to the intersection of Human Computer Interaction (HCI) and Information Retrieval (IR). The intent of the workshop is not archival publication, but rather to provide a forum to build community and to stimulate discussion, new insight, and experimentation on search interface design.
Proceedings from 2007 to date are available.
I would point to the workshops separately or even some of the papers but the site helpfully returns its base URL for all resources.
Good weekend or even weekday reading!
Watzlawick1 recounts the following experiment:
That there is no necessary connection between fact and explanation was illustrated in a recent experiment by Bavelas (20): Each subject was told he was participating in an experimental investigation of “concept formation” and was given the same gray, pebbly card about which he was to “formulate concepts.” Of every pair of subjects (seen separately but concurrently) one was told eight out of ten times at random that what he said about the card was correct; the other was told five out of ten times at random what he said about the card was correct. The ideas of the subject who was “rewarded” with a frequency of 80 per cent remained on a simple level, which the subject who was “rewarded” only at a frequency of 50 per cent evolved complex, subtle, and abstruse theories about the card, taking into consideration the tiniest detail of the card’s composition. When the two subjects were brought together and asked to discuss their findings, the subject with the simpler ideas immediately succumbed to the “brilliance” of the other’s concepts and agreed the other had analyzed the card correctly.
I repeat this account because it illustrates the impact that “reward” systems can have on results.
Whether the “rewards” are members of a crowd or experts.
Questions:
This study does raise the interesting question of whether conferences should track and randomly reject authors to encourage innovation.
1. Watzlawick, Paul, Janet Beavin Bavelas, and Don D. Jackson. 1967. Pragmatics of human communication; a study of interactional patterns, pathologies, and paradoxes. New York: Norton.
Dan Russell of Google, notes in Why is search sometimes easy and sometimes hard? Understanding serendipity and expertise in the mind of the searcher, teaching someone to use Control-F to search for text on a page, out performs 16 other changes they made to a search interface. An improvement of 12% in time-to-result measure.
Now for the sad news:
Two questions:
*****
PS: This is a great presentation. I have other comments on it but wanted to single this one out for your attention.
Dark Patterns: User Interfaces Designed to Trick People
I found this site from the blog posting Anti-Patterns and Dark Patterns at Endeca.
The term dark patterns is used to refer to patterns in user interfaces that by design try to serve their own purposes and not those of users.
Such as making canceling a subscription very difficult.
There are a host of other examples at this site.
One legitimate use of such examples would be as contrast to your topic map interface, which is designed to assist users.
Or in the preparation of such a demonstration to alert you that your interface isn’t as helpful as you thought.
Moving Forward is a blog I discovered via alls things cataloged.
From the Forward blog:
Forward is a Resource Discovery experiment that builds a unified search interface for library data.
Today Forward is 100% of the UW System Library catalogs and two UW digital collections. The project also experiments with additional search contextualization by using web service APIs.
Forward can be accessed at the URL:
http://forward.library.wisconsin.edu/.
Sounds like a great opportunity for topic map fans with an interest in library interfaces to make a contribution.
Barriers to Entry in Search Getting Smaller
Jeff Dalton, Jeff’s Search Engine Caffè, makes a good argument that the barriers to entering the search market are getting smaller.
Jeff observes that blekko can succeed with a small number of servers only because its search demand is low.
True, but how many intra-company or litigation search engines are going to have web-sized user demands?
Start-ups need not try to match Google in its own space, but can carve out interesting and economically rewarding niches of their own.
Particularly if those niches involve mapping semantically diverse resources into useful search results for their users.
For example, biomedical researchers probably have little interest in catalog entries that happen to match gene names. Or any of the other common mis-matches offered by entire web search services.
In some ways, search the entire web services have created their own problem and then attempted to solve it.
My research interests are in information retrieval broadly defined so a search engine limited to library schools, CS programs (their faculty and students), the usual suspects for CS collections, library/CS/engineering organizations, with semantic mapping, would suit me just find.
Noting that the semantic mis-match problem persists even with a narrowing of resources, but the benefit of each mapping is incrementally greater.
Questions:
United States of Autocomplete also via Flowing Data
Deeply amusing visualization of autocompletion of search terms by the Google search engine.
Most data manipulation/visualization focuses on some data set.
What if those techniques were turned inward?
That is to say what if data manipulation/visualization choices were visualized? Either in terms of the choices they make or the processes they use?
I suspect that is a largely unexplored area of visualization and one where given the differences in terminology, topic map could be helpful.
Questions:
PS: One additional thought. What if we had a data set and compared two techniques, manipulation or visualization, on the basis of how they treated the data? What data was lost or not included by one technique but was by another? And does it vary by the nature of the data set?
Could be useful for topic map engineers trying to decide on the best tools for a particular job. I am sure that sort of information is generally available in data mining books or in stories about data mining exercises, but being able to visualize the same could be quite useful.
Flowing Data reports on Similarities Between PhD Dissertations
From Flowing Data:
Certain fields of study tend to cover many of the same topics. Many times, the two fields go hand-in-hand. Electrical engineering, for example, ties tightly with computer science. Same thing between education and sociology. Daniel Ramage and Jason Chuang of Stanford University explore these similarities through the language used in their school’s dissertations.
Topic distance is explored between departments from 1993 to 2008. Select a department and it goes to the middle of the circle. Departments with dissertations that were similar for the year are highlighted and near closer. The closer to the center, the more similar. Alternatively, you should also be able to find departments who are fairly different from the rest.
You can also use the time slider on the bottom to check out how some departments grow closer to another over time.
Questions:
Data Visualization Practices at the New York Times
Amanda Cox of the New York Times’ graphics department recently gave a great presentation to the New Media Days conference in Copenhagen and described how the Times uses data visualizations to reveal patterns, provide context, describe relationships, and even create a sense of wonder about the world.
Great post!
I was amused to read:
At a high-level, CXML can be thought of as a set of property/value pairings. Facets are like property values on an item, and facet categories are groups of facets. For example: if a collection had a facet category called “U.S. State,” then “Georgia” could be a facet in that category. Depending on authoring choices, these facets may be displayed as filters in the PivotViewer collection experience, or included in the details of an item. Collection XML Schema
Sounds a lot like the Topic Maps Reference Model.
Or, the game of twenty questions.
That is the subject you are identifying is broader or narrower depending upon the number of key/value pairs you specify.
The Pivotviewer allows you to go from a very broad subject to a very narrow, even a specific one by, adding on key/value pairs.
Legends enable users to arrive at the same broad or narrow subject, even if they have different key/value pairs for that subject.
Hey, that is rather neat and practical isn’t it? (Take note Lars. He knows which one.)
Will have to investigate how to combine collection XML schemas to make that point.
More to follow on this topic (sorry) anon.
Andrew Townley has suggested Gary Flake: is Pivot a turning point for web exploration? as an example of “wow” factor.
From a search on Pivot I found: Silverlight Pivotviewer is no longer experimental.
On the issue of “wow” factor, I have to agree. This is truly awesome.
I am sure there are corner cases and bugs, but I think kudos are due to the developers of Silverlight Pivotviewer.
Now the question is what do “we,” as in the topic maps community, do with this nice shiny tool?
Questions:
Computational Information Design by Ben Fry develops what is required for information visualization.
Particularly relevant given the developer-driven designs/presentations I have seen.
I am sure the developers in question found them very intuitive.
Or at least I hope they did.
It be really sad to have an interface no one found intuitive.
Questions:
First noticed on Alex Popescu’s blog.
Text a phone number and then it appears as an entry on a map.
I have an uneasy feeling this may be important.
Not this particular application but the ease of putting content from dispersed correspondents together into a single map.
I wonder if instead of distance the correspondents could be dispersed over time? Say as users of a document archive?*
Questions:
*Or for those seeking more real-time applications, imagine GPS coordinates + status updates from cellphones on a more detailed map. Useful for any number of purposes.
8 Keys to Findability mentions in closing:
The average number of search terms is about 1.7 words, which is not a lot when searching across millions of documents. Therefore, a conversation type of experience where users can get feedback from the results and refine their search makes for the most effective search results.
I have a different take on that factoid.
The average user needs only 1.7 words to identify a subject of interest to them.
Why the gap between 1.7 words and the number of words required for “effective search results?”
Why ask?
Returning millions of “hits” is on 1.7 words is meaningless.
Returning the ten most relevant “hits” on 1.7 words is a G***** killer.
Powered by WordPress