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

May 17, 2012

Designing Search (part 4): Displaying results

Filed under: Interface Research/Design,Search Behavior,Search Interface,Searching — Patrick Durusau @ 3:41 pm

Designing Search (part 4): Displaying results

Tony Russell-Rose writes:

In an earlier post we reviewed the various ways in which an information need may be articulated, focusing on its expression via some form of query. In this post we consider ways in which the response can be articulated, focusing on its expression as a set of search results. Together, these two elements lie at the heart of the search experience, defining and shaping much of the information seeking dialogue. We begin therefore by examining the most universal of elements within that response: the search result.

As usual, Tony does a great job of illustrating your choices and trade-offs in presentation of search results. Highly recommended.

I am curious since Tony refers to it as an “information seeking dialogue,” has anyone mapped reference interview approaches to search interfaces? I suspect that is just my ignorance of the literature on that subject so would appreciate any pointers you can throw my way.

I would update Tony’s bibliography:

Marti Hearst (2009) Search User Interfaces. Cambridge University Press

Online as full text: http://searchuserinterfaces.com/

March 28, 2012

Designing User Experiences for Imperfect Data

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

Designing User Experiences for Imperfect Data by Matthew Hurst.

Matthew writes:

Any system that uses some sort of inference to generate user value is at the mercy of the quality of the input data and the accuracy of the inference mechanism. As neither of these can be guaranteed to by perfect, users of the system will inevitably come across incorrect results.

In web search we see this all the time with irrelevant pages being surfaced. In the context of track // microsoft, I see this in the form of either articles that are incorrectly added to the wrong cluster, or articles that are incorrectly assigned to no cluster, becoming orphans.

It is important, therefore, to take these imperfections into account when building the interface. This is not necessarily a matter of pretending that they don’t exist, or tricking the user. Rather it is a problem of eliciting an appropriate reaction to error. The average user is not conversant in error margins and the like, and thus tends to over-weight errors leading to the perception of poorer quality in the good stuff.

I am not real sure how Matthew finds imperfect data but I guess I will just have to take his word for it. šŸ˜‰

Seriously, I think he is spot on in observing that expecting users to hunt-n-peck through search results is wearing a bit thin. That is going to be particularly so when better search systems make the hidden cost of hunt-n-peck visible.

Do take the time to visit his track // microsoft site.

Now imagine your own subject specific and dynamic website. Or even search engine. Could be that search engines for “everything” are the modern day dinosaurs. Big, clumsy, fairly crude.

March 20, 2012

Designing Search (part 3): Keeping on track

Filed under: Interface Research/Design,Search Behavior,Search Interface,Searching — Patrick Durusau @ 3:52 pm

Designing Search (part 3): Keeping on track by Tony Russell-Rose

From the post:

In the previous post we looked at techniques to help us create and articulate more effective queries. From auto-complete for lookup tasks to auto-suggest for exploratory search, these simple techniques can often make the difference between success and failure.

But occasionally things do go wrong. Sometimes our information journey is more complex than weā€™d anticipated, and we find ourselves straying off the ideal course. Worse still, in our determination to pursue our original goal, we may overlook other, more productive directions, leaving us endlessly finessing a flawed strategy. Sometimes we are in too deep to turn around and start again.

(graphic omitted)

Conversely, there are times when we may consciously decide to take a detour and explore the path less trodden. As we saw earlier, what we find along the way can change what we seek. Sometimes we find the most valuable discoveries in the most unlikely places.

However, thereā€™s a fine line between these two outcomes: one personā€™s journey of serendipitous discovery can be anotherā€™s descent into confusion and disorientation. And thereā€™s the challenge: how can we support the former, while unobtrusively repairing the latter? In this post, weā€™ll look at four techniques that help us keep to the right path on our information journey.

Whether you are writing a search interface or simply want to know more about what factors to consider in evaluating a search interface, this series by Tony Russell-Rose is well worth your time.

If you are writing a topic map, you already have as a goal the collection of information for some purpose. It would be sad if the information you collect isn’t findable due to poor interface design.

March 5, 2012

Bad vs Good Search Experience

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

Bad vs Good Search Experience by Emir Dizdarevic.

From the post:

The Problem

This article will show how a bad search solution can be improved. We will demonstrate how to build an enterprise search solution relatively easy using Apache Lucene/SOLR.

We took a local ad site as an example of a bad search experience.

We crawled the ad site with Apache Nutch, using a couple of home grown plugins to fetch only the data we want and not the whole site. Stay tuned for a separate article on this topic.

ā€˜BADā€™ search is based on real search results from the ad site i.e. how the website search currently works. ā€˜GOOD ā€˜ search is based on same data but indexed with Apache Lucene/Solr (inverted index).

BAD Search: We assume that itā€™s based on exact match criteria or something similar to ā€˜%like%ā€™ database statement. To simulate this behavior we used content field that it tokenized by whitespace, lowercased and used phrase queries every time. This is the closest we could get to existing ad site search solution, but even this bad it was performing better.

An excellent post in part because of the detailed example but also to show that improving search results is an iterative process.

Enjoy!

January 28, 2012

YapMap: Breckā€™s Fun New Project to Improve Search

Filed under: Interface Research/Design,Search Interface,Searching — Patrick Durusau @ 7:32 pm

YapMap: Breckā€™s Fun New Project to Improve Search

From the post:

What I like about the user interface is that threads can be browsed easilyā€“I have spent hours on remote controlled airplane forums reading every post because it is quite difficult to find relevant information within a thread. The color coding and summary views are quite helpful in eliminating irrelevant posts.

My first job is to get query spell checking rolling. Next is search optimized for the challenges of thread based postings. The fact that relevance of a post to a query is a function of a thread is very interesting. I will hopefully get to do some discourse analysis as well.

I will continue to run Alias-i/LingPipe. The YapMap involvement is just too fun a project to pass up given that I get to build a fancy search and discovery tool.

What do you think about the thread browsing capabilities?

I am sympathetic to the “reading every post” problem but I am not sure threading helps, at least not completely.

Doesn’t help with posters like myself who may make “off-thread” comments that may be the one you are looking for.

Comments about the interface?

January 19, 2012

Designing Search (part 1): Entering the query

Filed under: HCIR,Search Behavior,Search Interface,Searching — Patrick Durusau @ 7:40 pm

Designing Search (part 1): Entering the query by Tony Russell-Rose.

From the post:

In an earlier post we reviewed models of information seeking, from an early focus on documents and queries through to a more nuanced understanding of search as an information journey driven by dynamic information needs. While each model emphasizes different aspects of the search process, what they share is the principle that search begins with an information need which is articulated in some form of query. What follows below is the first in a mini-series of articles exploring the process of query formulation, starting with the most ubiquitous of design elements: the search box.

If you are designing or using search interfaces, you will benefit from reading this post.

Suggestion: Don’t jump to the summary and best practices. Tony’s analysis is just as informative as the conclusions he reaches.

December 17, 2011

Google; almost 50 functions & resources killed in 2011

Filed under: Search Interface,Searching,Semantic Diversity — Patrick Durusau @ 6:32 am

Google; almost 50 functions & resources killed in 2011 by Phil Bradley.

Just in case you want to think of other potential projects over the holidays! šŸ˜‰

For my topic maps class:

  1. Pick one function or resource
  2. Outline how semantic integration could support or enhance such a function or resource. (3-5 pages, no cites)
  3. Bonus points: What resources would you want to integrate for such a function or resource? (1-2 pages)

Google removes more search functionality

Filed under: Advertising,Search Engines,Search Interface,Searching — Patrick Durusau @ 6:32 am

Google removes more search functionality by Phil Bradley.

From the post:

In Google’s apparently lemming like attempt to throw as much search functionality away as they can, they have now revamped their advanced search page. Regular readers will recall that I wrote about Google making it harder to find, and now they’re reducing the available options. The screen is now following the usual grey/white/read design, but to refresh your memory, this is what it used to look like:

Just in case you are looking for search opportunities in the near future.

The smart money says to not try to be everything to everybody. Pick off a popular (read advertising supporting) subpart of all content and work up really well. Offer users for that area what seem like useful defaults for that area. The defaults for television/movie types are likely to be different from the Guns & Ammo crowd. As would the advertising you would sell.

Remind me to write about using topic maps to create pull-model advertising. So that viewers pre-qualify themselves and you can charge more for “hits” on ads.

December 14, 2011

A Task-based Model of Search

Filed under: Modeling,Search Behavior,Search Interface,Searching — Patrick Durusau @ 7:46 pm

A Task-based Model of Search by Tony Russell-Rose.

From the post:

A little while ago I posted an article called Findability is just So Last Year, in which I argued that the current focus (dare I say fixation) of the search community on findability was somewhat limiting, and that in my experience (of enterprise search, at least), there are a great many other types of information-seeking behaviour that arenā€™t adequately accommodated by the ā€˜search as findabilityā€™ model. Iā€™m talking here about things like analysis, sensemaking, and other problem-solving oriented behaviours.

Now, Iā€™m not the first person to have made this observation (and I doubt Iā€™ll be the last), but it occurs to me that one of the reasons the debate exists in the first place is that the community lacks a shared vocabulary for defining these concepts, and when we each talk about ā€œsearch tasksā€ we may actually be referring to quite different things. So to clarify how I see the landscape, Iā€™ve put together the short piece below. More importantly, Iā€™ve tried to connect the conceptual (aka academic) material to current design practice, so that we can see what difference it might make if we had a shared perspective on these things. As always, comments & feedback welcome.

High marks for a start on what complex and intertwined issues.

Not so much that we will reach a common vocabulary but so we can be clearer about where we get confused when moving from one paradigm to another.

December 13, 2011

Which search engine when?

Filed under: Search Engines,Search Interface,Searching — Patrick Durusau @ 9:51 pm

Which search engine when?

A listing of search engines in the following categories:

  • keyword search
  • index or directory based
  • multi or meta search engines
  • visual results
  • category
  • blended results

There are fifty-three (53) entries so plenty to choose from if you are bored with your current search “experience.”

Not to mention learning about different ways to present search results to users.

BTW, if you run across a blog mentioning that AllPlus was listed in two separate categories, like this one, realize that SearchLion was also listed in two separate categories.

Search engines are an important topic for topic mappers because it is one of the places where semantic impedance and the lack of useful organization of information is a major time sink for all users.

Getting 400,000 “hits” is just a curiosity, getting 402 “hits,” in a document archive like I did this morning, is a considerable amount of content but a manageable one.

No, it wasn’t a topic map that I was searching but the results may well find themselves into a topic map.

November 10, 2011

Take the struggle out of search

Filed under: Findability,Search Interface,Searching — Patrick Durusau @ 6:42 pm

Take the struggle out of search

John Moore writes in Federal Computer Week:

Consistency is generally a good thing, but the Food Safety and Inspection Serviceā€™s website established a pattern for its search function no organization wants to own: It was consistently bad.

The agency used a combination of Web analytics and more detailed survey questions to zero in on the problem and discovered what was frustrating some site visitors: They were searching for information that couldnā€™t be found on the site. FSISā€™ food safety purview covers meat, poultry and eggs, but some users were searching for information on vegetable and seafood recalls. Those alerts fall under the Food and Drug Administration.

The problem was solved here by directing visitors off-site to find the appropriate information.

Question: What do you do when visitors ask for information you don’t have?

Say they search for a game title that is by a competing manufacturer? Or a book title from another publisher? Or some other product by “the competition.”

Do you simply return a null result? (Tip for the day – when all else fails, return a useful result)

The article provides the details of and possible solutions to: (not unique to government, survey says half of all commercial businesses lack findability goals, 2008 but I would be willing to bet that hasn’t improved):

  • Problem 1: Poor information architecture
  • Problem 2: Not enough people or expertise
  • Problem 3: Too many government websites
  • Problem 4: Little or no SEO

Is this another data point in the continuing saga of why semantic solutions, including topic maps, face slow uptake?

That most organizations, commercial/governmental/non-profit/etc., lack basic information storage/retrieval skills. Have some very highly skilled people but not enough to do everything. Most of the rest are very willing but lack the skills to make a difference.

Which makes offering advanced information technologies like offering a grade school science fair participant use of the Large Hadron Collider in place of their lost radium sample for a Wilson cloud chamber. May some day be useful to them, but not today.

Suggestion: Use advanced techniques (I would inveigh for topic maps) to create “better” search capabilities for part of an agency website. Can’t really repair poor architecture remotely but probably can minimize its impact. Create a noticeably more useful search experience, such that even agency staff turn to it for some resources. Gives you a calling card with validation to back it up. (You probably also need to hire that recently retired section chief but doing a good job helps as well.)

PS: Just so you know, the first example of antimatter, a positive electron was discovered with a cloud chamber. Stray cosmic ray with enough power for the decay pattern to include a positron. Cloud chamber plans. The start of your education to be able to talk to the folks at the CERN in their own terms.

November 4, 2011

A Taxonomy of Enterprise Search and Discovery

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.

October 26, 2011

Google removes plus (+) operator

Filed under: Search Engines,Search Interface,Searching — Patrick Durusau @ 6:58 pm

Google removes plus (+) operator

From the post:

The ā€œ+ā€ operator used to mean ā€œrequiredā€ to Google, I think. But it also meant ā€œand exactly that word is required, not an alternate form.ā€ I think? Maybe it always was just a synonym for double quotes, and never meant ā€˜requiredā€™? Or maybe double quotes mean ā€˜requiredā€™ too?

At any rate, the plus operator is gone now.

Iā€™m not entirely sure that the quotes will actually insist on the quoted word being present in the page? Can anyone find a counter-example?

I had actually noticed a while ago that the google advanced search page had stopped providing any fields that resulted in ā€œ+ā€, and was suggesting double quotes for ā€œexactly this form of wordā€ (not variants), rather than ā€œphraseā€. Exactly what given operators (and bare searches) do has continually evolved over time, and isnā€™t always documented or reflected in the ā€œsearch tipsā€ page or ā€œadvanced searchā€ screen.

The post is a good example of using the Internet Archive to research the prior state of the web.

BTW, the comments and discussion on this were quite amusing. “Kelly Fee,” a Google employee had these responses to questions about removal of the “+” operator:

We’ve made the ways you can tell Google exactly what you want more consistent by expanding the functionality of the quotation marks operator. In addition to using this operator to search for an exact phrase, you can now add quotation marks around a single word to tell Google to match that word precisely. So, if in the past you would have searched for [magazine +latina], you should now search for [magazine “latina”].

We’re constantly making changes to Google Search – adding new features, tweaking the look and feel, running experiments, – all to get you the information you need as quickly and as easily as possible. This recent change is another step toward simplifying the search experience to get you to the info you want.

If you read the comments, having a simple search experience wasn’t the goal of most users. Finding relevant information was.

Kelly reassures users they are being heard, but ignored:

Thanks for sharing your thoughts. I especially appreciate everyone’s passion for search operators (if only every Google Search user were aware of these tools like you are…).

One thing I’d like to add to my original post is that, as with any change we make to our search engine, we put a lot of thought into this modification, but we’re always interested in user feedback.

I hope that you’ll continue to give us feedback in the future so that we can make your experience on Google more enjoyable.

After a number of posts on the lost of function by elimination of the “+” operator, Kelly creatively mis-hears the questions and comes up with an example that works.

I just tested out the quotes operator to make sure that it still works for phrases and it does. I searched for [from her eyes] and then [“from her eyes”] and got different results. I also tried [from her “eye”] and [from her eye] and got different results for each query, which is how it is intended to work.

Many people understand that putting quotes around a phrase tells a search engine to search for that exact phrase. This change applies that same idea to a specific word.

Would it help to know that Kelly Fee was a gymnast?

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.

August 29, 2011

Building Search App for Public Mailing Lists

Filed under: ElasticSearch,Search Engines,Search Interface,Searching — Patrick Durusau @ 6:25 pm

Building Search App for Public Mailing Lists in 15 Minutes with ElasticSearch by LukĆ”Å” Vlček.

You will need the slides to follow the presentation: Building Search App for Public Mailing Lists.

Very cool if fast presentation on building an email search application with ElasticSearch.

BTW, the link to BigDesk (A tiny monitoring tool for ElasticSearch clusters) is incorrect. Try: https://github.com/lukas-vlcek/bigdesk.

August 24, 2011

Do You CTRL+F?

Filed under: Marketing,Search Interface,Searching,Topic Maps — Patrick Durusau @ 7:00 pm

College students stumped by search engines

This link was forwarded to me by Sam Hunting.

That college students can’t do adequate searching isn’t a surprise.

What did surprise me was the finding: “…90 percent of American Google users do not know how to use CTRL or Command+F to find a word on a page.”

That finding was reported in: Crazy: 90 Percent of People Don’t Know How to Use CTRL+F.

Or as it appears in the article:

This week, I talked with Dan Russell, a search anthropologist at Google, about the time he spends with random people studying how they search for stuff. One statistic blew my mind. 90 percent of people in their studies don’t know how to use CTRL/Command + F to find a word in a document or web page! I probably use that trick 20 times per day and yet the vast majority of people don’t use it at all.

“90 percent of the US Internet population does not know that. This is on a sample size of thousands,” Russell said. “I do these field studies and I can’t tell you how many hours I’ve sat in somebody’s house as they’ve read through a long document trying to find the result they’re looking for. At the end I’ll say to them, ‘Let me show one little trick here,’ and very often people will say, ‘I can’t believe I’ve been wasting my life!'”

How should this finding influence subject identity tests and/or user interfaces for topic maps?

Should this push us towards topic map based data products, as data products, not topic maps?

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.

July 22, 2011

Designing Faceted Searches

Filed under: Facets,Search Interface,Searching — Patrick Durusau @ 6:09 pm

Tony Russell-Rose has been doing a series of posts on faceted searches.

Since topic maps capture information that can be presented as facets, I thought it would be helpful to gather up the links to Tony’s posts for your review.

Interaction Models for Faceted Search

Where am I? Techniques for wayfinding and navigation in faceted search

Designing Faceted Search: Getting the basics right (part 1)

Designing Faceted Search: Getting the basics right (part 2)

Designing Faceted Search: Getting the basics right (part 3)

And a couple of related goodies:

A Taxonomy of Search Strategies and their Design Implications

From Search to Discovery: Information Search Strategies and Design Solutions

Word of warning: You can easily lose hours if not days chasing down design insights that remain just out of reach. Have fun!

July 15, 2011

Cloudant Search

Filed under: Search Engines,Search Interface,Searching — Patrick Durusau @ 6:49 pm

Cloudant Search

Tim Anglade writes:

Iā€™ve always strongly felt that using NOSQL wasnā€™t so much a choice as a necessity. That most successful NOSQL deployments start with the intimate knowledge that your set of requirements ā€” from speed & availability to operational considerations and budget ā€” cannot be met with a relational database, coupled with a deep understanding of the tradeoffs you are making. Among those, perhaps no tradeoff has been felt more deeply by NOSQL users worldwide, than the eponymous loss of a natural, instantaneous way of accessing your data through a structured query language. We all came up with our own remedies; more often than not, that substitute was based on MapReduce: Googleā€™s novel, elegant way of explicitly parallelizing computation over distributed, unstructured data. But as the joke goes, itā€™s always been a non-starter for the more novice users out there, and where suits & ties are involved.

CouchDB Views (as our brand of MapReduce is called) come with additional concerns, as they are pre-computed and written to disk. While this is fine ā€” and actually, extremely useful ā€” for the use-cases and small scales a lot of Apache CouchDB deployments reside at (single instances working off a limited dataset), this behavior is somewhere North of nagging and South of suicidal for the data sizes & use-cases most Cloudant customers have to deal with. Part of the promise of our industry is ā€” or should be, anyway ā€” to make your life & business easier, no matter how much data you have. And so, while CouchDB Views have been, and will undoubtedly remain, an essential tool to index, filter & transform your data, once you know what to do with it; and while its various weaknesses (explicitly parallelized syntax, lengthy computation, heavy disk usage) are also the source of its most meaningful strengths (distributed processing, high performance on repeated queries, persistent transformations), we at Cloudant saw a clear opportunity to offer a novel, complementary way to interact with your data.

A way that would allow you to interact with your data instantaneously; wouldnā€™t force you to mess around with MapReduce jobs or complex languages; a way that would not require you to set up a third-party, financially or operationally expensive solution.

We call this way Cloudant Search. And today, weā€™re proud to announce its immediate availability, as a public beta.

Well, there goes the weekend!

May 19, 2011

Designing faceted search: Getting the basics right (part 1)

Filed under: Facets,Interface Research/Design,Search Interface,Searching — Patrick Durusau @ 3:27 pm

Designing faceted search: Getting the basics right (part 1)

Tony Russell-Rose says:

Over the last couple of weeks weā€™ve looked at some of the more advanced design issues in faceted search, including the strengths and weaknesses of various interaction models and techniques for wayfinding and navigation. In this post, weā€™ll complement that material with a look at some of the other fundamental design considerations such as layout (i.e. where to place the faceted navigation menus) and default state (e.g. open, closed, or a hybrid). In so doing, Iā€™d like to acknowledge the work of James Kalbach, and in particular his tutorial on faceted search design, which provides an excellent framework for many of the key principles outlined below.

To write or improve a faceted search interface, start with this series of posts.

Search Your Gmail Messages with ElasticSearch and Ruby

Filed under: Dataset,ElasticSearch,Search Data,Search Engines,Search Interface — Patrick Durusau @ 3:26 pm

Search Your Gmail Messages with ElasticSearch and Ruby

From the website:

If youā€™d like to check out ElasticSearch, thereā€™s already lots of options where to get the data to feed it with. You can use a Twitter or Wikipedia river to fill it with gigabytes of public data, or you can feed it very quickly with some RSS feeds.

But, letā€™s get a bit personal, shall we? Letā€™s feed it with your own e-mail, imported from your own Gmail account.

A useful way to teach basic searching.

After all, a search of Wikipedia or Twitter may return impressive results, but are they correct results?

Hard for a user to say because both Wikipedia and Twitter are large enough that verification (other than by other programs) of search results isn’t possible.

Assuming your Gmail inbox is smaller than Wikipedia you should be able to recognize what results are “correct” and which ones look “off.”

And you may learn some Ruby in the bargain.

Not a bad day’s work. šŸ˜‰


PS: You may want to try the links on mining Twitter, Wikipedia and RSS feeds with ElasticSearch.

May 12, 2011

Beyond the Polar Bear

Filed under: Interface Research/Design,Search Interface — Patrick Durusau @ 7:55 am

Beyond the Polar Bear

Webinar:

Date: Thursday, May 26, 2011, 11:30am-12:30pm (EDT)

From the post:

The BBCā€™s new Food site (bbc.co.uk/food) is completely rebuilt using principles of domain and data modeling. Domain-driven design breaks down complex subjects into the things people usually think about. With food, itā€™s stuff like ā€˜dishesā€™, ā€˜ingredientsā€™ and ā€˜chefsā€™. The parts of the model inter-relate far more organically than a traditional top-down hierarchy.

A logical domain model makes site navigation mirror the way people explore knowledge. By intersecting across subjects, links themselves become facts, allowing humans and machines to learn through undirected user journeys. This paradigm shift from labeling boxes to taming rich data is a vital skill for the modern IA.

In this webinar, we’ll explore how to design for a semantic ā€˜web of dataā€™, using case studies from the BBCā€™s Food and Natural History products. Youā€™ll learn how to unlock the potential of your content, create scalable navigation patterns, achieve simply fabulous SEO and step confidently into the world of open linked data.

Not cheap: ASIS&T Members: $25 Non-Members: $59

I need to check on my ASIS&T dues status.

This could well be worth the price of admission.

May 9, 2011

Google at CHI 2011

Google at CHI 2011

From the Google blog:

Google has an increasing presence at ACM CHI: Conference on Human Factors in Computing Systems, which is the premiere conference for Human Computer Interaction research. Eight Google papers will appear at the conference. These papers not only touch on our core areas such as Search, Chrome and Android but also demonstrate our growing effort in new areas where HCI is essential, such as new search user interfaces, gesture-based interfaces and cross-device interaction. They showcase our efforts to address user experiences in diverse situations. Googlers are playing active roles in the conference in many other ways too: participating in conference committees, hosting panels, organizing workshops and teaching courses, as well as running demos and 1:1 sessions at Google’s booth.

The post also has a complete set of links to papers from Google and other materials.

I remember reading something recently about modulating the amount of information sent to a user based on their current activity level. That is a person who was engaged in a task requiring immediate attention (does watching American Idol count?) is sent less information than a person doing something less important (watching a presidential address).

Is merging affected by my activity level or just delivery of less than all the results?

April 15, 2011

Interaction Models for Faceted Search

Filed under: Facets,Interface Research/Design,Search Interface — Patrick Durusau @ 6:29 am

Interaction Models for Faceted Search

Tony Russell-Rose on models for faceted search:

Faceted search offers tremendous potential for transforming search experiences. It provides a flexible framework by which users can satisfy a wide variety of information needs, ranging from simple lookup and fact retrieval to complex exploratory search and discovery scenarios. In recognition of this, UX designers are now starting to embrace its potential and have published many excellent articles on a variety of design issues, covering topics such as facet structure, layout & display, selection paradigm, and many more.

The purpose of this article is to explore one aspect that has received somewhat less attention than most: the interactive behaviour of the facets themselves, i.e. how they should respond and update when selected. Surprisingly, the design choices at this level of detail can make a remarkable difference to the overall user experience: the wrong choices can make an application feel disjointed and obstructive, and (in some cases) increase the likelihood of returning zero results. In this post, weā€™ll examine the key design options and provide some recommendations.

Highly recommended.

That your topic map has the right answer somewhere isn’t going to help a user who can’t find it.

March 2, 2011

Collaborative Web Search (Haystack)

Filed under: Search Engines,Search Interface — Patrick Durusau @ 1:00 pm

Jeff Dalton reports the launch of Haystack, a collaborative web search startup.

I suspect that while useful within small groups, as shared search results propagate outwards, they will encounter the same semantic dissonance as tagging.

WhistlePig: A minimalist real-time search engine

Filed under: Search Engines,Search Interface — Patrick Durusau @ 12:39 pm

WhistlePig: A minimalist real-time search engine.

From Jeff Dalton’s blog:

William Morgan recently announced the release of Whistlepig, a real-time search engine written in C with Ruby bindings. It is now up to release 0.4. Whistlepig is a minimalist in memory search system with ranking by reverse date. You can read William’s blog post for his motivations for writing it.

Of particular interest (at least to me):

  • A full query language and parser with conjunctions, disjunctions, phrases, negations, grouping, and nesting.
  • Labels: arbitrary tokens which can be added to and removed from documents at any point, and incorporated into search queries.

February 28, 2011

From Search to Discovery

Filed under: Interface Research/Design,Navigation,Search Interface — Patrick Durusau @ 9:04 am

From Search to Discovery by Tony Russell-Rose.

Abstract:

The landscape of the search industry is undergoing fundamental change. In particular, there is a growing realisation that the true value of search is best realised by embedding it a wider discovery context, so that in addition to facilitating basic lookup tasks such as known-item search and fact retrieval, support is also provided for more complex exploratory tasks such as comparison, aggregation, analysis, synthesis, evaluation, and so on. Clearly, for these sorts of activity a much richer kind of interaction or dialogue between system and end user is required. This talk examines what forms this interactivity might take and discusses a number of principles and approaches for designing effective search and discovery experiences.

Topic map projects looking to develop successful interfaces would do well to heed this presentation.

February 26, 2011

Experiencing Information – Blog

Filed under: Interface Research/Design,Navigation,Search Interface — Patrick Durusau @ 7:12 am

Experiencing Information is a blog by James Kalbach.

Kalbach authored Designing Web Navigation and a number of other publications on information delivery.

I will be mentioning posts by Kalbach that seem to me to be particularly useful for topic map interfaces but commend the blog to you in general.

January 21, 2011

Workshop on Human-Computer Interaction and Information Retrieval

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!

January 20, 2011

80-50 Rule?

Filed under: Crowd Sourcing,Interface Research/Design,Search Interface,Uncategorized — Patrick Durusau @ 6:18 am

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:

  1. Should you randomly reject searches in training to search for subjects?
  2. What literature supports your conclusion in #1? (3-5 pages)

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.

« Newer PostsOlder Posts »

Powered by WordPress