This is a slightly longer post than normal, and goes into some mildly technical software stuff. Hence if you don’t care about any of that, and/or don’t know the difference between Javscript and HTML, I’m providing a choice of the short or long version.
The Short Version
I have a custom home page I made for searching with on my iPhone. It’s efficient, user friendly, and I’m proud of it. If you like, you can use it too: www.simoncoronel.com/isearch. (It also works on Android.)
While you can use it on a desktop browser, it’s optimised for a small touchscreen interface.
There we go; we’re done. Unless you want a long semi-technical saga, you’re excused. Go and watch some films or something. I’ll understand.
The Longer Version
This is essentially a story about user interface design, and gradually developing your own version of something when the default options aren’t good enough. It’s also a story about how making something apparently simple can be far more complex than you’d think.
Back in about 2004, Wikipedia was rapidly becoming my favourite website. However, it was annoying to search. If I wanted to learn more about, say, Michel Gondry, I’d have to type “wikipedia.org” in a browser address bar, wait for the page to load, then click on the “English” version, and THEN type in my actual search string. When you’re hungry for knowlege several times a day, that can get irritating quite quickly.
The other option was to use Google and search for “site:wikipedia.org michel gondry”, but that was a whole extra 18 keystrokes every time I wanted to search, and while “wikipedia michel gondry” or even “wiki michel gondry” would often get the right result, it was far from 100% reliable. Similarly, I’d often be using browsers at work or university that couldn’t be set to Google search from the address bar, so in addition to the extra Wikipedia characters, I’d often have to type “google.com” into the address bar, hit enter, and wait for the page to load before typing in my long Wikipedia search string.
I also found that I was frequently searching Snopes.com and Urbandictionary.com, and since I was at university I was frequently making use of Dictionary.com and its less authoritative but much faster and more charismatic cousin Ninjawords.com.
So one day I sat down, quickly reverse engineered the search interfaces of each of those sites, and made the following page of HTML forms to use as a home page. It looked like this:
Reverse engineering the search interfaces was actually quite a fun challenge. To an experienced software developer it would be relatively trivial, but at the time I was still getting used to how this whole HTML thing worked.
I also coded all the buttons to open the search results in new windows, so that the search page would sit there constantly making my life easer. I even started reverse engineering the search interfaces of other sites I used semi regularly, though many of them were less “important” than the previous sites:
So, for a long time that page worked wonderfully. But, as often happens with user interfaces, a design that seems perfect at first turns out to have some issues that are only apparent once you’ve been using it for a while.
In this case there were two main problems:
1) If you typed something into one of the text boxes and searched it, the text would still be there next time you came back to the page. Hence for each subsequent search you’d have to manually delete the existing text. Not a big deal, but it becomes annoying when you have to do it multiple times per day.
2) If you searched for something on, say, Wikipedia and no results came up, you’d then have to either copy and paste the search string from the Wikipedia box into whichever other box you were going to try next (eg: Urbandictionary for phrases, Dictionary.com for normal words, Google for everything else, etc). Or you could type it in again. Either way, fiddly and mildly annoying.
Neither problem was a deal-breaker though, and back then I couldn’t see any efficient way to solve them. Hence the page stayed pretty much as-is for the next several years, until in 2009 I bought an iPhone 3GS. All of a sudden my beloved search page was glaringly non smartphone friendly. Wonderful though the pinch-and-zoom browsing technology is, it just wasn’t enough to make the page convenient on a tiny screen.
So I sat down with a text editor and the source code from a bunch of iPhone-friendly websites and came up with the single-textbox layout that you saw at the start of this article. I was really happy with it. It was simple, clean, immediately intuitive, and way more useful to me than any other iPhone searching interface I’d seen at the time.
Eg, for the Flickr Creative Commons search:
The other benefit of moving to the single textbox layout was that it solves Problem #2 from above – if you search for a term on one website and nothing comes up, it’s trivial to come back to the page (where the text will still be sitting in the search box) and hit a button to search for the same string on a different site.
I finally figured out a way to have the best of both words by adding the innocuous red “delete” button next to the search field. It may not look like much, but it’s the single element of the UI that I like the most. It’s simple, unobtrusive, and gives the best balance of functionality without cluttering up the layout.
So, that’s the long complex story behind a relatively simple page. Those of you in software development and/or UI design will know exactly what I’m talking about. For everyone else, keep in mind that keeping something simple is usually much much harder than letting it get complicated.