Improving Wolfram|Alpha's User Experience

Wolfram|Alpha is a new type of tool: a computational knowledge engine (CKE.) Sadly, while the engine itself is brilliant, it is a struggle to use. Wolfram's team tried hard to make it feel just like a search engine. This has caused lots of confusion and ultimately limits the system's potential. By understanding a few fundamental ways in how W|A differs from a classical search engine (CSE), several UI changes fall out naturally that will greatly improve the experience of using W|A.

The W|A query model

A CSE like Google has a very simple query model. Users think of what they want, and type it into a box. They hit enter or click a button, and a new page loads showing them the results. They can page through these results, or do another search right there on the results page. It's simple, and obviously works.

As many have noticed, this model breaks down when misapplied to a CKE like W|A. A better UI can emerge by exploiting the differences between the two models, instead of ignoring them:

• Invalid Queries - Of the entire set of possible free-form queries, a CKE is unable to produce a result for a vast majority of them. There are many reasons why a query may be invalid, but for now let's consider all invalid queries the same.

• Intrinsic Query Value - CKE queries themselves are intrinsically valuable. Unlike CSE queries, they:
  - often compute new information that didn't exist before.
  - can be complex and challenging to construct.
  - can provide instructive guidance for new users.
  - provide a live taxonomy of system capabilities.

• Compact Results - CKE result pages generally fit on one or two pages and have a compact UI to explore the computed results.
  

Alleviating Invalid Query Pain

The most common W|A complaint seen is the prevalence of the "Wolfram Alpha isn't sure what to do with your input" page. This has become the BSOD of W|A. Sadly, there is no reason for it to even exist.

Many free-form queries are going to be invalid, particularly for new users. The way to address this is to prevent users from submitting invalid queries. Here's what I'd do for the first two iterations of improving this:

• When hitting enter, perform an AJAX request that checks if the query is valid. If not, show the "Wolfram doesn't know..." message under the search bar. Otherwise, go through to the results. This will eliminate a large part of the pain.

• Next, provide a visual indicator icon that can be in three states: red, yellow, green. The indicator is yellow as the user is typing. It is red when the current text in the search box is an invalid query. It is green when the query is valid. AJAX can be used to continually parse the query on the server. When the user hits enter, if the indicator is green then results appear. Otherwise, we fall back on the behavior above.
  

Note that the AJAX request for query validation does not need to compute a full result - it simply needs to determine if a result will be computable. (This should alleveate performance concerns.)

Exploiting query value

Valid queries are valuable. They compute new information, can be challenging to construct, and can help guide new users. By exploiting the stream of valid queries, the W|A experience can be improved dramatically.

There are countless ways to do so. For example:

• Above the search bar could be a series of high level categories such as Biology, Physics, and Mathematics. Mousing over these would provide a dense and dynamic view of a large number of queries relevant to that category. Unlike the current documentation, these queries should be chosen by the system based upon the live stream. Specifically, they could be chosen based upon popularity, relevance, and even Digg-like community voting.

• A "Google-Suggest on steroids" approach. When typing a query, dynamically showing similar relevant queries and perhaps compacted results right below the search bar would be an effective way to quickly explore the engine.

• Users should be able to name, parameterize, and share their queries. For example, if I create a query that computes the cost of a trip via gas mileage (this example was shared via Twitter a few days ago,) I should be able to share that query in a useful manner.
  

Exploiting result page structure

The W|A results page is often short and to the point. SEO issues aside, it makes you wonder, why bother with a results page at all?

I'd propose that once a the UI above is in place for exploring and using the engine, it would make sense to simply avoid transitioning between any pages at all. I envision a UI where the user quickly can find a query that works using the techniques above, and by hitting enter, the results are computed and appear on screen instantly via AJAX. Subsequent searches simply replace the previous results, and a query history is maintained to easily navigate between previous results.

Final points

I think if all these changes are implemented, using W|A will be a much smoother and satisfying experience. There would no longer be any place for the user to feel like they've made a mistake, and quickly digging into the capabilities of the system would be more natural and intuitive. The W|A engine is begging for a more intuitive, rich, and fun exploratory interface. The exciting part is that a lot of these things can be implemented by anyone once a search API is available, so I hope we'll be seeing improvements like this soon!