Another Word For It Patrick Durusau on Topic Maps and Semantic Diversity

November 14, 2011

SearcherLifetimeManager prevents a broken search user experience

Filed under: Interface Research/Design,Lucene,Searching — Patrick Durusau @ 7:16 pm

SearcherLifetimeManager prevents a broken search user experience

From the post:

In the past, search indices were usually very static: you built them once, called optimize at the end and shipped them off, and didn’t change them very often.

But these days it’s just the opposite: most applications have very dynamic indices, constantly being updated with a stream of changes, and you never call optimize anymore.

Lucene’s near-real-time search, especially with recent improvements including manager classes to handle the tricky complexities of sharing searchers across threads, offers very fast search turnaround on index changes.

But there is a serious yet often overlooked problem with this approach. To see it, you have to put yourself in the shoes of a user. Imagine Alice comes to your site, runs a search, and is looking through the search results. Not satisfied, after a few seconds she decides to refine that first search. Perhaps she drills down on one of the nice facets you presented, or maybe she clicks to the next page, or picks a different sort criteria (any follow-on action will do). So a new search request is sent back to your server, including the first search plus the requested change (drill down, next page, change sort field, etc.).

How do you handle this follow-on search request? Just pull the latest and greatest searcher from your SearcherManager or NRTManager and search away, right?

Wrong!

Read at the post why that’s wrong (it involves getting different searchers for the same search) but consider your topic map.

Does it have the same issue?

A C-Suite users queries your topic map and gets one answer. Several minutes later, a non-C-Suite user does the same query and gets an updated answer. One that isn’t consistent with the information given the C-Suite user. Obviously the non-C-Suite user is wrong as is your software, should push come to shove.

How do you avoid a “broken search user experience” with your topic map? Or do you just hope information isn’t updated often enough for anyone to notice?

A Simple News Exploration Interface

Filed under: Filters,Interface Research/Design,News — Patrick Durusau @ 7:14 pm

A Simple News Exploration Interface

Matthew Hurst writes:

I’ve just pushed out the next version of the hapax page. I’ve changed the interface to allow for dynamic filtering of the news stories presented. You can now type in filter terms (such as ‘bbc’ or ‘greece’) and the page will only display those stories that are related to those terms.

Very cool!

November 7, 2011

Save the Pies for Dessert

Filed under: Graphics,Interface Research/Design — Patrick Durusau @ 7:28 pm

Save the Pies for Dessert by Stephen Few.

A paper on pie charts and why they are mis-leading.

I encountered this quite by accident but it is quite good. It illustrated quite well why pie charts should not be your first choice if you want to communicate effectively.

Something I assume to be a goal of all topic map interface designers, that is to communicated effectively.

From the paper:

Not long ago I received an email from a colleague who keeps watch on business intelligence vendors and rates their products. She was puzzled that a particular product that I happen to like did not support pie charts, a feature that she assumed was basic and indispensable. Because of previous discussions between us, when I pointed out ineffective graphing practices that are popular in many BI products, she wondered if there might also be a problem with pie charts. Could this vendor’s omission of pie charts be intentional and justified? I explained that this was indeed the case, and praised the vendor’s design team for their good sense.

After reading the paper I think you will pause before including pie charts capabilities in your topic map interface.

When Gamers Innovate

Filed under: Authoring Semantics,Authoring Topic Maps,Bioinformatics,Biomedical,Games,Interface Research/Design — Patrick Durusau @ 9:32 am

When Gamers Innovate

The problem (partially):

Typically, proteins have only one correct configuration. Trying to virtually simulate all of them to find the right one would require enormous computational resources and time.

On top of that there are factors concerning translational-regulation. As the protein chain is produced in a step-wise fashion on the ribosome, one end of a protein might start folding quicker and dictate how the opposite end should fold. Other factors to consider are chaperones (proteins which guide its misfolded partner into the right shape) and post-translation modifications (bits and pieces removed and/or added to the amino acids), which all make protein prediction even harder. That is why homology modelling or “machine learning” techniques tend to be more accurate. However, they all require similar proteins to be already analysed and cracked in the first place.

The solution:

Rather than locking another group of structural shamans in a basement to perform their biophysical black magic, the “Fold It” team created a game. It uses human brainpower, which is fuelled by high-octane logic and catalysed by giving it a competitive edge. Players challenge their three-dimensional problem-solving skills by trying to: 1) pack the protein 2) hide the hydrophobics and 3) clear the clashes.

Read the post or jump to the Foldit site.

Seems to me there are a lot of subject identity and relationship (association) issues that are a lot less complex that protein folding. Not that topic mappers should shy away from protein folding but we should be more imaginative about our authoring interfaces. Yes?

November 6, 2011

Clive Thompson on Why Kids Can’t Search (Wired)

Filed under: Interface Research/Design,Marketing,Searching — Patrick Durusau @ 5:44 pm

Clive Thompson on Why Kids Can’t Search (Wired)

From the post:

We’re often told that young people tend to be the most tech-savvy among us. But just how savvy are they? A group of researchers led by College of Charleston business professor Bing Pan tried to find out. Specifically, Pan wanted to know how skillful young folks are at online search. His team gathered a group of college students and asked them to look up the answers to a handful of questions. Perhaps not surprisingly, the students generally relied on the web pages at the top of Google’s results list.

But Pan pulled a trick: He changed the order of the results for some students. More often than not, those kids went for the bait and also used the (falsely) top-ranked pages. Pan grimly concluded that students aren’t assessing information sources on their own merit—they’re putting too much trust in the machine.

I agree with the conclusion but would add it illustrates a market for topic maps.

A market to deliver critically assessed information as opposed to teaching people to critically assess information. Critical assessment of information, like tensor calculus, can be taught, but how many people are capable of learning/applying it?

Take a practical example (US centric) of the evening news. Every night, for an hour, the news is mostly about murders, fatal accidents, crimes of other sorts, etc. So much so that personal security is a concern for most Americans and they want leaders who are tough on crime, terrorism, etc. Err, but crime rates, including violent crime have been falling for the last decade. They are approaching all time lows.

As far as terrorism, well, that is just a bogeyman for security and military budgets. Yes, 9/11, but 9/11 isn’t anything like having monthly or weekly suicide bombers is it? American are in more danger from the annual flu, medical malpractice, drunk drivers, heart disease, and a host of other causes more than terrorism. The insurance companies admit to 100,000 deaths a year to medical “misadventure.” How many Americans died from terrorist attacks last year in the U.S.? That would be the “naught” or “0” as I was taught.

I suppose my last point, about terrorism, brings up another point about “critical assessment” of information for topic maps. Depends on what your client thinks is “critical assessment.” If you are doing a topic map for the terror defense industry, I would suggest skipping my comparisons with medical malpractice. Legislative auditors, on the other hand, might appreciate a map of expenditures and results, which for the US Department of Homeland Security, would have a naught in the results column. Local police and the FBI, traditional law enforcement agencies, have been responsible for the few terrorist arrests since 9/11.

I read somewhere a long time ago that advertisers think of us as: “Insecure, sex-starved neurotics with attention spans of about 15 seconds.” I am not sure how to codify that as rules for content and interface design but it is a starting point.

I say all that to illustrate that critical assessment of information isn’t a strong point for the general population (or some of its leaders for that matter). Not just kids but their parents, grandparents, etc.

We may as well ask: Why people can’t critically assess information?

I don’t know the answer to that but I think the evidence indicates it is a rare talent, statistically speaking. And probably varies by domain. People who are capable of critical assessment in one domain may not be capable of it in another.

So, if it is a rare talent, statistically speaking, like hitting home runs, let’s market the ability to critically assess information.

November 5, 2011

Does GE Think We’re Stupid?

Filed under: Graphs,Interface Research/Design — Patrick Durusau @ 6:45 pm

Does GE Think We’re Stupid?

A gem from Stephen Few:

The series of interactive data visualizations that have appeared on GE’s website over the last two years has provided a growing pool of silly examples. They attempt to give the superficial impression that GE cares about data while in fact providing almost useless content. They look fun, but communicate little. As such, they suggest that GE does not in fact care about the information and has little respect for the intelligence and interests of its audience. This is a shame, because the stories contained in these data sets are important.

(graphic omitted)

Most of the visualizations were developed by Ben Fry (including the colorful pie that Homer is drooling over above); someone who is able to design effective data visualizations, but shows no signs of this in the work that he’s done for GE. The latest visualization was designed by David McCandless, who has to my knowledge never produced an effective data visualization. In other words, GE has gone from bad to worse.

Before you decide this is over the top criticism, go read the original post and view the graphics.

The question I would raise, I suppose all those years in law not being wasted, is whether the GE graphics were intended to inform or confuse?

If the latter, made to make the public feel that these are issues beyond their ken and best left to experts, then these maybe very successful graphics.

Even if not sinister in purpose, I think we need to attend very closely to what we assume about ourselves and graphics (and other interfaces). It may be, even often may be, that it isn’t us but the interface that is incorrect.

If you encounter a graphic you don’t understand, don’t assume it is you. If in writing, investigate further; if in class, ask for a better explanation; if in a meeting, ask for and follow up on the actual details.

November 4, 2011

Confidence Bias: Evidence from Crowdsourcing

Filed under: Bias,Confidence Bias,Crowd Sourcing,Interface Research/Design — Patrick Durusau @ 6:10 pm

Confidence Bias: Evidence from Crowdsourcing Crowdflower

From the post:

Evidence in experimental psychology suggests that most people overestimate their own ability to complete objective tasks accurately. This phenomenon, often called confidence bias, refers to “a systematic error of judgment made by individuals when they assess the correctness of their responses to questions related to intellectual or perceptual problems.” 1 But does this hold up in crowdsourcing?

We ran an experiment to test for a persistent difference between people’s perceptions of their own accuracy and their actual objective accuracy. We used a set of standardized questions, focusing on the Verbal and Math sections of a common standardized test. For the 829 individuals who answered more than 10 of these questions, we asked for the correct answer as well as an indication of how confident they were of the answer they supplied.

We didn’t use any Gold in this experiment. Instead, we incentivized performance by rewarding those finishing in the top 10%, based on objective accuracy.

I am not sure why crowdsourcing would make a difference on the question of overestimation of ability but now the answer is in, N0. But do read the post for the details, I think you will find it useful when doing user studies.

For example, when you ask a user if some task is too complex as designed, are they likely to overestimate their ability to complete it, either to avoid being embarrassed in front of others or admitting that they really didn’t follow your explanation?

My suspicion is yes and so in addition to simply asking users if they understand particular search or other functions with an interface, you need to also film them using the interface with no help from you (or others).

You will remember in Size Really Does Matter… that Blair and Maron reported that lawyers over estimated their accuracy in document retrieval by 55%. Of course, the question of retrieval is harder to evaluate than those in the Crowdflower experiment but it is a bias you need to keep in mind.

A Taxonomy of Enterprise Search and Discovery

Filed under: Information Retrieval,Interface Research/Design,Search Behavior,Search Interface,Searching,Users — Patrick Durusau @ 6:08 pm

A Taxonomy of Enterprise Search and Discovery by Tony Russell-Rose.

Abstract:

Classic IR (information retrieval) is predicated on the notion of users searching for information in order to satisfy a particular “information need”. However, it is now accepted that much of what we recognize as search behaviour is often not informational per se. Broder (2002) has shown that the need underlying a given web search could in fact be navigational (e.g. to find a particular site) or transactional (e.g. through online shopping, social media, etc.). Similarly, Rose & Levinson (2004) have identified the consumption of online resources as a further common category of search behaviour.

In this paper, we extend this work to the enterprise context, examining the needs and behaviours of individuals across a range of search and discovery scenarios within various types of enterprise. We present an initial taxonomy of “discovery modes”, and discuss some initial implications for the design of more effective search and discovery platforms and tools.

If you are flogging software/interfaces for search/discovery in an enterprise context, you really need to read this paper. In part because of their initial findings but in part to establish the legitimacy of evaluating how users search before designing an interface for them to search with. They may not be able to articulate all their search behaviors which means you will have to do some observation to establish what may be the elements that make a difference in a successful interface and one that is less so. (No one wants to be the next Virtual Case Management project at the FBI.)

Read the various types of searching as rough guides to what you may find true for your users. When in doubt, trust your observations of and feedback from your users. Otherwise you will have an interface that fits an abstract description in a paper but not your users. I leave it for you to judge which one results in repeat business.

Don’t take that as a criticism of the paper, I think it is one of the best I have read lately. My concern is that the evaluation of user needs/behaviour be an ongoing process and not prematurely fixed or obscured by categories or typologies of how users “ought” to act.

The paper is also available in PDF format.

November 3, 2011

Introducing DocDiver

Filed under: Authoring Topic Maps,Data Mining,Document Classification,Document Management,Interface Research/Design,Topic Maps — Patrick Durusau @ 7:22 pm

Introducing DocDiver by Al Shaw. The ProPublica Nerd Blog

From the post:

Today [4 Oct. 2011] we’re launching a new feature that lets readers work alongside ProPublica reporters—and each other—to identify key bits of information in documents, and to share what they’ve found. We call it DocDiver [1].

Here’s how it works:

DocDiver is built on top of DocumentViewer [2] from DocumentCloud [3]. It frames the DocumentViewer embed and adds a new right-hand sidebar with options for readers to browse findings and to add their own. The “overview” tab shows, at a glance, who is talking about this document and “key findings”—ones that our editors find especially illuminating or noteworthy. The “findings” tab shows all reader findings to the right of each page near where readers found interesting bits.

Graham Moore (Networkedplanet) mentioned early today that the topic map working group should look for technologies and projects where topic maps can make a real difference for a minimal amount of effort. (I’m paraphrasing so if I got it wrong, blame me, not Graham.)

This looks like a case where an application is very close to having topic map capabilities but not quite. The project already has users, developers and I suspect would be interested in anything that would improve their software, without starting over. That would be the critical part, to leverage existing software an imbue it with subject identity as we understand the concept, to the benefit of current users of the software.

Trello

Filed under: Interface Research/Design — Patrick Durusau @ 7:18 pm

Trello – Organize anything, together

From the site:

Trello is a collaboration tool that organizes your projects into boards. In one glance, Trello tells you what’s being worked on, who’s working on what, and where something is in a process.

Trello requires a free account to use the tool. I am not suggesting that you need an online task management tool, this one or another.

I mention it because of the simplicity of the interface.

Boards

A board is a just a collection of lists (and lists hold the cards). You’ll probably want a board for each project you’re working on. You can add and start using a new board in seconds. You can glance at a board and get a handle on the status of any project.

Lists

Lists can be just simple lists, but they are most powerful when they represent a stage in a process. Simply drag your lists into place to represent your workflow. Move a card from one list to the next to show your progress.

Cards

Cards are tasks. You make a card to track something you or your team needs to get done. You can add attachments, embed video, assign users, add due dates, make checklists, or you can just add your card to a board with no fuss and no overhead, and know exactly what work needs to get done.

My question is: Is this enough? For the average project? There is software project software like JIRA but the interface is far more complex.

  1. What about Trello makes the interface easy? Not asking you to describe the interface, this post already does that. What is it about board/list/card that is familiar? What other contexts do we use or see such arrangements?
  2. What other ways of visually organizing data seem common to you?
  3. What is it about other methods of organizing data that makes it “work” for you?

A Protovis Primer, Part 1

Filed under: Graphics,Interface Research/Design,Protovis,Visualization — Patrick Durusau @ 7:16 pm

A Protovis Primer, Part 1

From the post:

Protovis is a very powerful visualization toolkit. Part of what makes it special is that it is written in JavaScript and runs in the browser without the need for any plugins. Its clever use of JavaScript’s language features makes it very elegant, but it can also be confusing to people who are not familiar with functional programming concepts and the finer points of JavaScript. This multi-part tutorial shows how to create a visualization (my interactive Presidents Chart) in Protovis, and explains the concepts that are involved along the way.

This introduction is based on my experiences with using Protovis in my Visualization and Visual Communication class earlier this spring. While the concepts involved are really not that difficult, they are rather foreign to students who have not been exposed to functional programming. And since that is also the case for a lot of hobbyists and people wanting to do visualization who do not have a computer science background, I imagine they run into the same problems.

This has grown from being a single article into several parts (and is still expanding). Let me know if there are things that you don’t understand or that you think need to be covered in more detail, so I can tailor the next parts accordingly.

Protovis requires a modern browser, which means any recent version of Safari, Chrome, FireFox, or Opera. Internet Explorer does not work, because it does not support the HTML5 Canvas element. The visualizations in this article are all Protovis drawings (check out the source code!), with a fall-back to images for RSS readers and IE users. There is no real difference at this point, but once we get to interaction, you will want to read this in a supported browser.

See the comments as well for pointers.

A Protovis Primer, Part 2 – If you are interested in earthquakes, this is the tutorial for you! Plus really nifty bar chart techniques.

A Protovis Primer, Part 3 – Lives and office terms of US presidents. OK, so not every data set is a winner. 😉 Still, the techniques are applicable to other, more interesting data sets.

October 27, 2011

HTML5 web dev reading list

Filed under: HTML,Interface Research/Design — Patrick Durusau @ 4:45 pm

HTML5 web dev reading list

I am sure there are more of these than can be easily counted.

Suggestions on others that will be particularly useful for people developing topic map interfaces? (Should not be different from effective interfaces in general.)

Thanks!

October 22, 2011

Edelweiss

Filed under: Interface Research/Design,Ontology,Semantic Web — Patrick Durusau @ 3:17 pm

Edelweiss

From the website:

The research team Edelweiss aims at offering models, methods and techniques for supporting knowledge management and collaboration in virtual communities interacting with information resources through the Web. This research will result in an ergonomic graph-based and ontology-based platform.

This research will result in an ergonomic graph-based and ontology-based platform. Activity Report 2010
Located at INRIA Sophia Antipolis-Méditerranée, Edelweiss was previously known as Acacia.
Edelweiss stands for…

  • Exchanges : communication, diffusion, knowledge capitalization, reuse, learning.
  • Documents : texts, multimedia, XML.
  • Extraction : semi-automated information extraction from documents.
  • Languages : graphs, semantic web languages, logics.
  • Webs : architectures, diffusion, implementation.
  • Ergonomics : user interfaces, scenarios.
  • Interactions : interaction design, protocols, collaboration.
  • Semantics : ontologies, semantic annotations, formalisms, reasoning.
  • Servers : distributed services, distributed data, applications.

Good lists of projects, software, literature, etc.

Anyone care to share any longer acronyms in actual use at projects?

October 21, 2011

Towards georeferencing archival collections

Filed under: Archives,EADitor,Encoded Archival Description (EAD),Geographic Data,Geographic Information Retrieval,Interface Research/Design,Library,Library software — Patrick Durusau @ 7:28 pm

Towards georeferencing archival collections

From the post:

One of the most effective ways to associate objects in archival collections with related objects is with controlled access terms: personal, corporate, and family names; places; subjects. These associations are meaningless if chosen arbitrarily. With respect to machine processing, Thomas Jefferson and Jefferson, Thomas are not seen as the same individual when judging by the textual string alone. While EADitor has incorporated authorized headings from LCSH and local vocabulary (scraped from terms found in EAD files currently in the eXist database) almost since its inception, it has not until recently interacted with other controlled vocabulary services. Interacting with EAC-CPF and geographical services is high on the development priority list.

geonames.org

Over the last week, I have been working on incorporating geonames.org queries into the XForms application. Geonames provides stable URIs for more than 7.5 million place names internationally. XML representations of each place are accessible through various REST APIs. These XML datastreams also include the latitude and longitude, which will make it possible to georeference archival collections as a whole or individual items within collections (an item-level indexing strategy will be offered in EADitor as an alternative to traditional, collection-based indexing soon).

This looks very interesting.

Details:

EADitor project site (Google Code): http://code.google.com/p/eaditor/
Installation instructions (specific for Ubuntu but broadly applies to all Unix-based systems): http://code.google.com/p/eaditor/wiki/UbuntuInstallation
Google Group: http://groups.google.com/group/eaditor

October 20, 2011

AutoComplete with Suggestion Groups

Filed under: AutoComplete,Clustering,Interface Research/Design — Patrick Durusau @ 6:41 pm

AutoComplete with Suggestion Groups from Sematext.

From the post:

While Otis is talking about our new Search Analytics (it’s open and free now!) and Scalable Performance Monitoring (it’s also open and free now!) services at Lucene Eurocon in Barcelona Pascal, one of the new members of our multinational team at Sematext, is working on making improvements to our search-lucene.com and search-hadoop.com sites. One of the recent improvements is on the AutoComplete functionality we have there. If you’ve used these sites before, you may have noticed that the AutoComplete there now groups suggestions. In the screen capture below you can see several suggestion groups divided with pink lines. Suggestions can be grouped by any criterion, and here we have them grouped by the source of suggestions. The very first suggestion is from “mail # general”, which is our name for the “general” mailing list that some of the projects we index have. The next two suggestions are from “mail # user”, followed by two suggestions from “mail # dev”, and so on. On the left side of each suggestion you can see icons that signify the type of suggestion and help people more quickly focus on types of suggestions they are after.

Very nice!

Curious how you would distinguish “grouping suggestions” from faceted navigation? (I have a distinction in mind but curious about yours.)

October 15, 2011

Open Net – What a site!

Filed under: Interface Research/Design,Search Interface,Searching — Patrick Durusau @ 4:26 pm

Open Net – What a site!

From the post:

I was doing some poking around to find out about OpenNet (which the Department of State uses), and I came across a DOE implementation of it (they apparently helped invent it.) Clicking the author link works really well! The site is clean and crisp. Very professional looking.

The “Document Categories” list on the Advanced Search page gave me pause.

There are about 70 categories listed, in no discernible order, except for occasional apparent groupings of consecutive listings. One of those groupings, strangely enough, is “Laser Isotope Separation” and “Other Isotope Separation Information”, while “Isotope Separation” is the first category in the entire list. “Other Weapon Topics” is near the end; various weapon categories are sprinkled throughout the list. I guess you have to go through the whole list to see if your weapon of choice is “other”.

Read on. There is discussion of a DOE thesaurus and other analysis that I think you will find useful.

I had to grin at the option under “Declassification Status” that reads Never. Maybe I should not pick that one for any searches that I do. Probably just accessing the site has set off alarm bells at the local FBI office. 😉 BTW, have you seen my tin hat? (Actually “never” means never classified.)

Seriously, this interface is deeply troubled. In part for the reasons cited in the post but also from an interface design perspective. For example, assuming accession number means what it means in most libraries (probably a bad assumption), means that you know the number a particular copy of a document was assigned when it was cataloged in a particular library.

If you know that, why the hell are you “searching” for it? Can’t get much more specific than an accession number, which is unique to a particular library.

Someone did devote a fair amount of time to a help file that makes the interface a little less mystic.

Extra credit: How would you change the interface? Just sketch it out in broad strokes. Say 2-3 pages, no citations.

October 13, 2011

Predicting What People Want

Filed under: Interface Research/Design,Marketing — Patrick Durusau @ 6:56 pm

If you haven’t see Steve Yegge’s rant about Google, which was meant to be internal for Google, you can read about it (with the full text) at: Google Engineer Accidentally Posts Rant About Google+.

Todd Wasserman reports:

Yegge went on to write, “Our Google+ team took a look at the aftermarket and said: ‘Gosh, it looks like we need some games. Let’s go contract someone to, um, write some games for us.’ Do you begin to see how incredibly wrong that thinking is now? The problem is that we are trying to predict what people want and deliver it for them.” (emphasis added)

That’s doable, the history of marketing in the 20th century has made that very clear. See Selling Blue Elephants.

What doesn’t work is for very talented programmers, academics, do-gooders, etc., to sit around in conference rooms to plan what other people ought to want.

What or should I say who is missing from the conference room?

Oh, yeah, the people we want to use or even pay for the service. Opps!

You may have guessed/predicted where this is going: The same is true for interfaces, computer or otherwise.

Successful interfaces happen by:

  1. Dumb luck
  2. Management/developers decide on presentation/features
  3. Testing with users and management/developers decide on presentation/features
  4. Testing with users and user feedback determines presentation/features

Care to guess which one I suspect Google used? If you picked door #3, you would be correct! (Sorry, no prize.)

True enough, management/developers also being users they won’t be wrong everytime.

Question: Would you go see a doctor who wasn’t wrong everytime?

I never thought I would recommend that anyone read marketing/advertising texts but I guess there is a time and place for everything. I would rather see you doing that than to see more interfaces that hide your hard and valuable work from users.

OK, this is a bit over long, let me summarize the rule for developing both programs (in terms of capabilities) and interfaces (in terms of features):

Don’t predict what people want! Go ask them!

October 7, 2011

HaptiMap toolkit beta release

Filed under: Interface Research/Design,Software — Patrick Durusau @ 6:20 pm

HaptiMap toolkit beta release

From the HapiMap homepage:

HaptiMap toolkit beta release. The HaptiMap toolkit which provides a simple cross-platform API that abstracts the complexities of

  • dealing with haptic / audio / visual input and output on a cross-platform basis
  • retrieving, storing and manipulating geographic data

behind a simple interface, leaving user interface developers free to concentrate on maximizing the usability and accessibility of their applications.

Hmmm, a new interface for your topic map?

October 3, 2011

Scala – [Java – *] Documentation – Marketing Topic Maps

Filed under: Interface Research/Design,Marketing,Scala,Topic Maps — Patrick Durusau @ 7:06 pm

Scala Documentation

As usual, when I am pursuing one lead to interesting material for or on topic maps, another pops up!

The Scala Days 2011 wiki had the following note:

Please note that the Scala wikis are in a state of flux. We strongly encourage you to add content but avoid creating permanent links. URLs will frequently change. For our long-term plans see this post by the doc czar.

A post that was followed by the usual comments about re-inventing the wheel, documentation being produced but not known to many, etc.

I mentioned topic maps as a method to improve program documentation to a very skilled Java/Topic Maps programmer, who responded: How would that be an improvement over Javadoc?

How indeed?

Hmmm, well, for starters the API documentation would not be limited to a particular program. That is to say for common code the API documentation for say a package could be included across several independent programs so that when the package documentation is improved for one, it is improved for all.

Second, it is possible, although certainly not required, to maintain API documentation as “active” documentation, that is to say it has a “fixed” representation such as HTML, only because we have chosen to render it that way. Topic maps can reach out and incorporate content from any source as part of API documentation.

Third, this does not require any change in current documentation systems, which is fortunate because that would require the re-invention of the wheel in all documentation systems for source code/programming documentation. A wheel that continues to be re-invented with every new source repository and programming language.

So long as the content is addressable (hard to think of content that is non-addressable, do you have a counter-example?), topic maps can envelope and incorporate that content with other content in a meaningful way. Granting that incorporating some content requires more efforts that other content. (Pointer “Go ask Bill with a street address” would be unusual but not unusable.)

The real question is, as always, is it worth the effort in a particular context to create such a topic map? Answers to that are going to vary depending upon your requirements and interests.

Comments?

PS: For extra points, how would you handle the pointer “Go ask Bill + street address” so that the pointer and its results can be used in an TMDM instance for merging purposes? It is possible. The result of any identifier can be respresented as an IRI. That much TBL got right. It was failing to realize that it is necessary to distinguish between use of an address as an identifer versus a locator that has cause so much wasted effort in the SW project.

Well, that an identifier imperialism that requires every identifier be transposed into IRI syntax. Given all the extant identifiers, with new ones being invented every day, let’s just that that replacing all extant identifiers comes under the “fairy tales we tell children” label where they all live happily ever after.

September 23, 2011

5 misconceptions about visualization

Filed under: Interface Research/Design,Virtualization — Patrick Durusau @ 6:28 pm

From the post:

Last month, I had the pleasure of spending a week at the Census Bureau as a “visiting scholar.” They’re looking to boost their visualization efforts across all departments, and I put in my two cents on how to go about doing it. For being a place where there is so much data, the visual side of things is still in the early stages, generally speaking.

During all the meetings, there were recurring themes about what visualization is and what it is used for. Some people really got it, but others were new to the subject, and we ran into a few misconceptions that I think are worth repeating.

Here we go, in no particular order.

Yeah, I moved the link.

Before you see Nathan’s list, take a piece of paper and write down why you have used visualization of data.

Got that? Now for the link:

5 misconceptions about visualization by Nathan Yau

Any to add to Nathan’s list? Perhaps from your own?

Top JavaScript Dynamic Table Libraries

Filed under: Interface Research/Design,Javascript — Patrick Durusau @ 6:26 pm

Top JavaScript Dynamic Table Libraries from Sematext.

From the post:

Since @sematext focuses on Search, Data and Text Analytics, and similar areas that typically involve exclusively backend, server-side work, we rarely publish anything that deals with UI, UX, with JavaScript, front ends, and do on. However, our Search Analytics and Scalable Performance Monitoring services/products do have rich, data-driven UIs (think reports, graphs, charts, tables), so we are increasingly thinking (obsessing?) about usability, intuitive and clean interfaces, visual data representations, etc. (in fact, we have an opening for a UI/UX designer and developer). Recently, we decided to upgrade a group of Search Analytics reports that, until now, used a quickly-thrown-together HTML table that, as much as we loved its simplicity, needed a replacement. So we set out to look for something better, more functional and elegant. In the process we identified a number of JavaScript libraries for rendering and browsing tabular data. Eventually we narrowed our selection to 6 JavaScript libraries whose characteristics we analyzed. In the spirit of sharing and helping others, please find their feature matrix below.

I suppose there is a time in everyone’s life when they finally have to show their front end. This will help you with yours. 😉

September 15, 2011

Explorer for Apache Solr

Filed under: Interface Research/Design,Solr — Patrick Durusau @ 7:50 pm

Explorer for Apache Solr

From the webpage:

One of our products is the Explorer for Apache Solr, a powerful generic Apache Solr client developed by JTeam. Based on Google Web Toolkit and the GWToolbox framework, this powerful explorer is able to connect to several Solr instances/cores and provides a meaningful UI for some of the more advanced featured offered by Solr.

With this Explorer for Apache Solr you can:

  • Perform simple term based search
  • Configure highlighting of search terms
  • Configure spellchecking (“Did you mean…” functionality)
  • Explore search facets (field and query facets)
  • View the search request and raw search response
  • Browse the Solr Schema
  • Configure different search result sortings
  • And more…

Do you really have the time to develop a UI from scratch?

September 11, 2011

Solr and Autocomplete

Filed under: Interface Research/Design,Solr — Patrick Durusau @ 7:16 pm

Rafał Kuć has a multi-part series on Solr and its autocomplete feature:

Solr and autocomplete (part 1)

Solr and autocomplete (part 2)

Solr and autocomplete (part 3)

Part 4 to appear.

Autocompletion is common enough that I suspect it has or will shortly become a user expectation for search interfaces.

Customizing the dictionary (in part 3) will help you provide better guidance to users than seen in general search engines.

September 10, 2011

TV Tropes

Filed under: Authoring Topic Maps,Data,Interface Research/Design — Patrick Durusau @ 6:06 pm

TV Tropes

Sam Hunting forwarded this to my attention.

From the homepage:

What is this about? This wiki is a catalog of the tricks of the trade for writing fiction.

Tropes are devices and conventions that a writer can reasonably rely on as being present in the audience members’ minds and expectations. On the whole, tropes are not clichés. The word clichéd means “stereotyped and trite.” In other words, dull and uninteresting. We are not looking for dull and uninteresting entries. We are here to recognize tropes and play with them, not to make fun of them.

The wiki is called “TV Tropes” because TV is where we started. Over the course of a few years, our scope has crept out to include other media. Tropes transcend television. They reflect life. Since a lot of art, especially the popular arts, does its best to reflect life, tropes are likely to show up everywhere.

We are not a stuffy encyclopedic wiki. We’re a buttload more informal. We encourage breezy language and original thought. There Is No Such Thing As Notability, and no citations are needed. If your entry cannot gather any evidence by the Wiki Magic, it will just wither and die. Until then, though, it will be available through the Main Tropes Index.

I rather like the definition of trope as “devices and conventions that a writer can reasonably rely on as present in the audience members’ minds and expecations.” I would guess under some circumstances we could call those “subjects” which we can include in a topic map. And then, for example, map the occurrences of those subjects in TV shows, for example.

As the site points out, it is called TV Tropes because it started with TV, but tropes have a much larger range than TV.

Being aware of and able to invoke (favorable) tropes in the minds of your users is one part of selling your topic map solution.

September 9, 2011

Why “Second Chance” Tweets Matter:…

Filed under: Interface Research/Design — Patrick Durusau @ 7:08 pm

Why “Second Chance” Tweets Matter: After 3 Hours, Few Care About Socially Shared Links

From the post:

There have been various studies suggesting that if someone doesn’t see a tweet or a Facebook post within a few hours, they’ll never see it at all. Now link shortening service Bit.ly is out with another. After three hours, Bit.ly has found, links have sent about all the traffic they’re going to send. So start thinking about doing “second chance” tweets, as I call them.

What I found interesting was the chart comparing the “half-life” of Facebook, Twitter, YouTube and direct. Or if you prefer the numbers:

  • Twitter: 2.8 hours
  • Facebook: 3.2 hours
  • YouTube: 7.4 hours

I suspect the true explanation is simply that volume pushes tweets and/or Facebook postings “below the fold” as it were and most people don’t look further than the current screen for content.

That may be an important lesson for topic map interfaces, if at all possible, keep content to a single screen. Just as in the “olden print days,” readers don’t look below the “fold.”

Another aspect that needs investigation is the “stickyness” of your presentation. The long half-life on YouTube is the slower rate of posts but I suspect there is more to it. If the presentation captures your imagination, there is at least some likelihood it will capture the imagination of others.

I suspect that some data sets lend themselves to “sticky” explanations more than others but that is why you need graphic artists (not CS majors), focus groups (not CS majors), professional marketers (not CS majors) to design your interfaces and delivery mechanisms. What “works” for insiders is likely to be the worst candidate for the general public. (Don’t ask me either. I am interested in recursive information structures for annotation of biblical texts. I am not a “good” candidate for user studies.)

September 1, 2011

TEX line breaking algorithm in JavaScript

Filed under: Interface Research/Design,Typography — Patrick Durusau @ 6:07 pm

TEX line breaking algorithm in JavaScript by Bram Stein.

From the post:

This is an implementation of the Knuth and Plass line breaking algorithm using JavaScript and the HTML5 canvas element. The goal of this implementation is to optimally set justified text in the new HTML5 canvas element, and ultimately provide a library for various line breaking algorithms in JavaScript.

This is very impressive and will reassure your topic map clients that you pay attention to details. Work remains to be done here and elsewhere on browser displays.

This was forwarded to me by Sam Hunting.

August 29, 2011

Hyperwords

Filed under: Authoring Topic Maps,Interface Research/Design — Patrick Durusau @ 6:29 pm

Hyperwords

From the website:

Every word becomes a link to the most powerful services on the internet – Google, Wikipedia, translations, conversions and much more.

Is available as a plugin for Firefox, Chrome and Safari web browsers. A beta version is being tested for IE, Office and PDFs.

You can select a single word or a group of words or numbers.

It can also be licensed for use with a website and that enables you to customize the user’s experience.

Very high marks for a user friendly interface. Even casual users know how to select text, although want to do with it next may prove to be a big step. Still, “click on the icon” should be as easy to remember as “use the force Luke!,” at least with enough repetition.

I am curious about the degree of customization that is possible with a licensed copy for a website. Quite obviously thinking about using words on a website or some known set of website as keys into a topic map backend.

This could prove to be a major step forward for all semantic-based services.

Very much a watch this space service.

August 24, 2011

How Browsers Work:…

Filed under: Interface Research/Design,Search Interface,Web Applications — Patrick Durusau @ 6:56 pm

How Browsers Work: Behind the Scenes of Modern Web Browsers by Tali Garsiel.

If you are delivering topic map content to web browsers, ;-), you will probably find something in this article that is useful.

Enjoy.

August 6, 2011

Real-time Streaming Analysis for Hadoop and Flume

Filed under: Flume,Hadoop,Interface Research/Design — Patrick Durusau @ 6:52 pm

Real-time Streaming Analysis for Hadoop and Flume

From the description:

This talk introduces an open-source SQL-based system for continuous or ad-hoc analysis of streaming data built on top of the Flume data collection platform for Hadoop.

Big data analytics based on Hadoop often require aggregating data in a large data store like HDFS or HBase, and then running periodic MapReduce processes over this data set. Getting “near real time” results requires running MapReduce jobs more frequently over smaller data sets, which has a practical frequency limit based on the size of the data and complexity of the analytics; the lower bound on analysis latency is on the order of minutes. This has spawned a trend of building custom analytics directly into the data ingestion pipeline, enabling some streaming operations such as early alerting, index generation, or real-time tuning of ad systems before performing less time-sensitive (but more comprehensive) analysis in MapReduce.

We present an open-source tool which extends the Flume data collection platform with a SQL-like language for analysis over streaming event-based data sets. We will discuss the motivation for the system, its architecture and interaction with Flume, potential applications, and examples of its usage.

Deeply awesome! Just wish I had been present to see the demo!

Makes me think of topic map creation from data streams with the ability to test different subject identity merging conditions, in real time. Rather than repetitive stories about a helicopter being downed, you get a summary report and a listing by location and time of publication of repetitive reports. Say one screen full of content and access to the noise. Better use of your time?

May 27, 2011

GAMIFY – SETI Contest

Filed under: Crowd Sourcing,Interface Research/Design — Patrick Durusau @ 12:33 pm

GAMIFY – SETI Contest

From the webpage:

Are you a gamification expert[1] or interested in becoming one? Want to help solve a problem of epic proportions that could have a major impact on the world?

The SETI Institute and Gamify[2] together have created an EPIC Contest to explore possible ways to gamify SETI. We’re asking the most brilliant Earthlings to come up with ideas on how to apply gamification[3] to increase participation in the SETI program.

The primary goal of this social/scientific challenge is to help SETI empower global citizens to participate in the search for cosmic company and to help SETI become financially sustainable so it can live long and prosper. This article explains our problem and what we are looking to accomplish. We invite everyone to answer the question, “How would you gamify SETI?”.

To be more specific:

  • Can we create a fun and compelling app or set of apps that allow people to aid us in identifying signals?
  • Do you have any ideas to make this process a fun game, while also solving our problem, by applying game mechanics and game-thinking?
  • Can we incorporate sharing and social interaction between players?
  • Is monetization possible through virtual goods, “status short-cuts” or other methods popularized by social games?
  • Are there any angles of looking at the problem and gamifying that we have not thought of?

The scientific principles involved in this field of science can be very complicated. A conscious attempt has been made to explain the challenge we face with a minimum of scientific explanation or jargon. We wish to be able to clearly explain our unique problems and desired outcomes to the scientific and non-scientific audience.

….

  1. http://gamify.com/experts
  2. http://gamify.com
  3. http://gamification.org

You will see from the presentations at Web 2.0 Expo SF 2011 that gamification is a growing theme in UI development.

I mention this because:

  1. Gamification has the potential to ease the authoring and use(?) of topic maps.
  2. SETI is an complex and important project and so a good proving ground for gamification.
  3. Insights found here maybe applicable to more complex data, like texts.
« Newer Posts — Older Posts »

Powered by WordPress