Google New Experimental Search Features

Google have come up with a set of experimental new search features aimed at improving the search experience. I’ve been playing with them and have to admit they are really cool!

The first is the ability to view search results on a timeline or on a map. Google do this by extracting dates and locations from the search results so that the information can be viewed in a different way.

For example a search for Olympics, and specifying a map view plots the locations the event has been held in on a map. Whilst searching for information on the civil rights movement, and specifying a timeline view will highlight key dates and events on a timeline.

The next new feature, is the enabling of keyboard shortcuts to navigate around search results. After initially using this, I can’t stop! A small arrow is rendered next to a search result, pressing the ‘J’ key moves to the next results, whilst pressing ‘K’ moves to the previous. You can open a search result by pressing ‘O’ or just hitting enter. You can also press ‘/’ to have the cursor jumpt to the search box, whilst ‘ESC’ moves the cursor out of the search box. Try it for yourselves here, it’s really easy to use and if your like and means you dont need to use a mouse at all to navigate around search results.

Another new feature is the addition of facets to search results, ( which Google oddly refer to as left hand navigation? ). Basically the left hand pane lists a set of groupings, for example content type, patents, products, news etc. The left hand pane also list’s a set of related searches. Together both these bits of information allow you to narrow your search, in order to find whatever it is your looking for, hopefully, quicker. This feature is also available on the right hand side of the screen.

It’s encouraging to see that Google are trying very hard to improve search, not only by providing mechanisms that should enable ordinary users to get to the content they are interested in faster, but they are also thinking about how to improve the experience. The keyboard shortcuts, whilst on the face of it might look simple, actually increases your productivity because you don’t need to interact with a mouse at all.

I’m impressed.

100 Web Apps for everything you’ll ever need?

Came across this earlier, its a list of the 100 web apps for everything you will ever need. When I consider some of the recent things I’ve written about this idea that applications are moving away from the desktop and delivered primarily over the web, then this list serves to illustrate how wide ranging web based applications are becoming.

The list organises the applications into a set of categories

  • Organisational
  • Calendars and to-do Lists
  • Your Money
  • Project Management & Productivity
  • Storage
  • Writing and Design Tools
  • Security and Privacy
  • Mobility and Contact
  • Meeting and Networking
  • Business and Legal
  • Client Contact and Feedback
  • Website tools
  • Printing and Packaging
  • Tools to give and take
  • Miscellaneous

In addition to the examples on this list there’s other pretty useful applications out there. I’ve been playing around with SnipShot, which allows you to upload images and edit, adjust them online. It doesn’t provide the full functionality of PhotoShop, but it is very simple to use and integrates with Flickr making it far more valuable as a tool than if it worked in isolation.

That’s the real strength of Web based applications? The ever increasing ease with which they can be integrated and used together?

Google Tech Talk: Away with applications: The death of the desktop

The computer desktop metaphor is ubiquitous, but how much work do we get done there? None! … all Time is entirely wasted navigating or shuffling content to the application in which we can finally work. What lessons can we learn from designing interfaces without the desktop and without applications? Is it even possible? And how does this apply to the Web? Currently, Web applications are often more usable than their desktop-based counterparts because each one does one thing and does it well.

Aza Raskin gives this excellent talk which is really about human computer interaction and usability. For those who don’t know Aza is the son of Jeff Raskin the guy who started the Macintosh project at Apple.

Aza’s offers some very useful views on User interface design, he touches on GOMS Models, Cognetics, Habituation in a wonderfully easy to follow manner. In this talk he outlines how we can get rid of the application centric model which comes from the desktop design paradigm in order to free functionality that can be made accessible using a ZUI along with a universal method for accessing functionality.

Applications are like walled cities that hoard their functionality, but we need to give that functionality away so others can use it wherever they are. But to facilitate this Aza argues that we need a universal access interface. Web services give you a separation between the UI and the Data but up until now services are really available to developers, they’re not really intended for end users but can we expose them through CLI’s?. He proposes a synthesis between GUI’s and CLI’s and from what he says they’re having a great success some of the examples he shows are compelling. I for one can see the value of this. In fact we’ve already put it into practise about six months ago.

You see this was something Rob and I thought about when we developed Project Cenote, one of the features of the user interface is that the browser’s URL line is an interface in its own right. For example if you type this into the url line:

And the application will perform a search for all items that were authored by “gemmell”. So if your like me and you just want to get to the content your interested in you can use this as opposed to navigating around the site and entering search terms into a search box. It is basically a Command Line Interface, and I think this is a wonderful way of giving end users access to content without necessarily forcing them to always use a GUI.

I was amused when one Aza paraphrased Asimov’s Three laws of Robotics into Raskins Rules of Interfaces:
1. An interface shall not harm your content or, through inaction, allow your content to come to harm.
2. An interface shall not waste your time or require you to do more work than is strictly necessary.
3. An interface shall not allow itself to get into a state where it cannot manipulate content.

This is a great talk to listen to and full of some very useful tips.

Information Software and the Graphical Interface

I came across a very interesting paper by Bret Victor a couple of week ago- “Magic Ink: Information Software and the Graphical Interface“. Here’s an extract from the abstract :

The ubiquity of frustrating, unhelpful software interfaces has motivated decades of research into “Human-Computer Interaction.” In this paper, I suggest that the long-standing focus on “interaction” may be misguided. For a majority subset of software, called “information software,” I argue that interactivity is actually a curse for users and a crutch for designers, and users’ goals can be better satisfied through other means.

The paper echoes some of the views Alan Cooper discussed in The inmates are running the asylum – another text that I think anyone interested in HCI / User Interface Design / Interaction Design should definitely read!

The author goes to great lengths to try demonstrate why information software design should be seen as the design of context sensitive information graphics. He goes to great length to explain and demonstrate what he feels is the importance of information graphic design:

A well-designed information graphic can almost compel the viewer to ask and answer questions, make comparisons, and draw conclusions. It does so by exploiting the capabilities of the human eye: instantaneous and effortless movement, high bandwidth and capacity for parallel processing, intrinsic pattern recognition and correlation, a macro/micro duality that can skim a whole page or focus on the tiniest detail. Meanwhile, a graphic sidesteps human shortcomings: the one-dimensional, uncontrollable auditory system, the relatively sluggish motor system, the mind’s limited capacity to comprehend hidden mechanisms. A graphic presents no mechanisms to comprehend or manipulate—it plugs directly into the mind’s spatial reasoning centers.

On the face of it this sounds reasonable – a picture speaks a thousand words. How we present information to our users has to be the most important question software designers should be asking themselves. So why don’t they? Well I wrote a piece offering my views on that question a while ago: programmers are generally bad at user interface design. So as you might imagine I find myself agreeing with what Bret writes here:

Compared to excellent ink-and-paper designs, most current software communicates deplorably. This is a problem of surface, but not a superficial problem. The main cause, I believe, is that many software designers feel they are designing a machine. Their foremost concern is behavior—what the software does. They start by asking: What functions must the software perform? What commands must it accept? What parameters can be adjusted? (In the case of websites: What pages must there be? How are they linked together? What are the dynamic features?) These designers start by specifying functionality, but the essence of information software is the presentation.

I believe there is a great deal of merit in the argument that Bret makes, and the examples he uses such as his BART project are indeed compelling. However its important to note that they are relatively small software projects. BART is a small desktop widget that provides train schedules so you can plan journeys around the San Francisco bay area. It’s a great example of providing users with information that is important to them and providing interactions that are intuitive but not distracting. It feels even more compelling when he compares his widget to the official bay area trip planning tool – which presents information to user in html tables full of text.

Unfortunatly highly graphical user interfaces aren’t normally very accessible to people with disabilities, for example visual impairments. When I look at the BART widget, as a user I love it, its simple presents a wealth of information that I can take in, in a glance – but that’s because I don’t have any disabilities. If I take a screenshot of it, then using photoshop turn it into a grey scale image – its suddenly much harder to use. It’s one of the reasons many DDA standards require that you cannot use colour alone to signify meaning. I could go all the way and ask how a blind user might use the widget. The answer is, they wouldn’t be able to. There’s a wider question of course of whether they’d want to or need to use it 😉 .

The accessibility issue aside, I think software designers should reflect on what Bret has written, and others before him, like Alan Cooper. I know I struggle with some of the ideas he’s presenting here, but I can’t help but feel that too many software projects descend far too quickly into the delivery of “functionality”, without any significant effort or thought placed into whether the software is presenting the user with the information he/she wants as effectively, and efficiently as possible from the point of view of the user. Far too often the very interactions and flows through an application can be a product of the framework the developers have chosen to use, for example JSF – forces certain patterns of behaviour that the user in turn is forced to adopt by proxy.

I’m not sure if there’s a right or wrong answer, but Bret’s paper has given me plenty of food for thought, you should definitly read it!

Pimpin’ your product’s.

Amy’s written another excellent article over on her blog Slash7, on how to go about pimpin’ your products. As with all Amy’s writing she makes some excellent points in her wonderfully unique style. She’s definitely given me food for thought, and I suggest that anyone who has a product to promote on the web should read her article.

What resonates the most is that whilst her advice appears simple it’s amazing how easily we overlook things that seem so obvious, and I’m kicking myself because I can see that I’ve made some the mistakes she mentions.

How technical writing sucks: The five sins

I was commenting to my friend Rob recently that I think one of the things I need to really improve at is my technical writing. It’s something I think Rob is quite good at as are Ian and Justin and it really is kind of cool having those guys around to learn from. I do find myself reading a lot of their work … not surprising given that we work together…

It does frustrate me when I read something they’ve written, or others outside of work like Alan, and I wonder whether I could have made the same point as succinctly or eloquently or even as effectively. Now, rather mischievously, I could just say that those guys are way older than me and have had far more practice and experience at it … but I think that would be … disingenuous at best … a lame excuse for not trying harder myself … but hey I’m definitely younger and better looking than them 😉 I just know that I’m not as a good at writing. I think it’s because, just with any skill, you have to work at it, you have to practise at it in order to get better, and I haven’t really been doing that.

I’ve been having a relaxed weekend so far and have been catching on some reading. Came across this wonderful little article by Amy Hoy, whose blog I’ve been following for a while. Amy very succinctly describes herself as a designer-turned-interface-developer, which rather belies how good I think she is at it. Amy has a wonderfully engaging style of writing and whilst I don’t always agree with what she says (sorry!) whatever she writes is almost always great food for thought! 😉 She often makes me laugh, for example when I read here blog entry entitled “Are writers better women?

Her article about the five sins, is a fun read but I think what she identifies as the sins [losing the reader, making the reader feel stupid, failing to stick , being a total bore and not providing much needed context] are all indicative of some of the kinds of problems my own technical writing often suffers from. Anyway I think it provides a useful set of criteria for me to try to assess my work with, I think I’m going to try and use it like that to see if it begins to help me evolve my own style … one that I feel more comfortable with. If its an area you think you need to improve at then do read her article, who knows you might find it useful too.

Why software sucks

Over on slashdot theres an excellent little article and debate around the issue of why software sucks. The slashdot article points to this news story on the Fox News Network. that discusses the book by David Platt entitled “Why software sucks …. and what you can do about it“. I haven’t read the book yet but I’ve added it to my things to read list. The debate on slashdot though is actually quite interesting and worth reading in its own right. What interests me is how some of the sentiments echoed in the articles and discussions resonate around my earlier views that programmers arent usability experts, and until we start developing software centred around the user … software will continue to suck. – Usability in Movies — Top 10 Bloopers

Had sweet little christmas lunch in the hospital visiting M with our little gang. Its been a nice day so far, hope your all having a great christmas?

Anyway, didnt get round to posting this up last night so here goes …

Jakob Nielsen posted up his list of top 10 usability bloopers in movies. Its actually a fascinating read, and does make me smile. However science fiction has provided the inspiration for many technological advancements, take a look at this demo of a Minority Report like gesture based interface being developed over at Microsoft Research.