Nav & Search

Agile Website Development

Web Development - June 20th, 2011

I’m a big proponent of agile development (although that’s a bit of an understatement, I’m huge fan), the problem with the most common methods (SCRUM, for example) is that they don’t work so well when the entire project is smaller than a single sprint and the development team can be counted on one or two fingers. This is the case for many fairly straight-forward websites which can be built by a single developer in under a month. So, I’ve been thinking about how to take some of the ideas that make SCRUM so efficient and apply them to small web projects.


Search Driven Websites

Web Development - May 6th, 2011

During a recent sales seminar for a search engine provider I saw a piece of statistic that said that 26% of all users start their interaction with a website by going straight for the search field and entering a query. That might sound like a big incentive to go for a search driven design and really optimize the internal search engine. For me, that single statistic says that a vast majority of users (74%) prefer to start by using the conventional navigational elements.

Furthermore, it doesn’t say why the users have turned to search for their first interaction. I believe many scan the navigational elements but don’t find a suitable entry since so many websites are way too bloated. So, the issue isn’t the traditional navigation (which most still prefer), it’s the amount of information and the information architecture.

Getting users to find the right information is most of all about reducing the amount of noise.

What we really can learn from the proponents of search driven websites is how they use dynamic search terms and suggestions. A common feature is to suggest popular searches and even display the most used search terms. This information should be used to constantly iterate the information and conventional navigation on the website!

Of course there are scenarios where you can’t or don’t want to reduce the amount of information or choices and in these cases search driven navigation can be the right way to go. It means though that the users have to know what they’re looking for and you have to be careful not to invent new ways of navigating just for the sake of it. Conventions are powerful and give a sense of security for the users, to deviate from them requires that the added value surpasses the threshold of not using the usual norms of navigation. However, always make sure to use the information from the internal search engine to see what the users really want to find.

Do you want to read more posts like this? I now blog about Web Development at

Mobile Web Versus Apps

Web Development - April 20th, 2011

Most vocal mobile development gurus I’ve heard claim that apps are faster and are the preferred choice for direct interaction on mobile devices over mobile web sites. In this logic, mobile web is the choice for indirect use, as a landing platform when someone clicks a link using a mobile device in twitter, facebook etc. However, the app market is getting crowded and I’m of a different view and belive that apps have a vastly more narrow use. Think about it, which is faster and requires the least amount of effort for the user:

  • Open the app store
  • Find the wanted app
  • Click install (or “Free” and then “Install”)
  • Click “Accept terms” (or enter the store password)
  • Waiting for the app to download and install
  • Find it somewhere on the device
  • Find the item to purchase or wanted information


  • Open the mobile browser (or tap a link on the homescreen, then jump to the last step below)
  • Enter the URL (or use a bookmark)
  • Find the item to purchase or the wanted information

Mobile apps can only be seen as direct communication when the user already have an established relationship with the company or service and have the app installed and regularly use it. For new relationships it’s a very time-consuming and energy-wasting detour. A problem also arises if the app is not up to par with the effort level of downloading it and figuring it out, more than 26% of iOS apps are only used once and then deleted (if they don’t just lie around on the device without ever being opened again). In this case a mobile website is much more appropriate, we don’t want to force our customers into downloading, installing something and then taking up screen real estate for a single interaction and for this the web is the appropriate medium.

I’m not saying that there’s no case where apps aren’t preferred over web, there are many of those (in-app purchases, advanced functionality, games etc). What I’m saying is that apps are only appropriate if they provide something more that isn’t available in a web app and the user already have a relation to the provider so they trust that the app and the content is worth the trouble.

Do you want to read more posts like this? I now blog about Web Development at

Creating a HTML 5 Web App for iPad – Part 2

Projects - March 16th, 2011

This is the second part of a two-part article mini-series (first part here) showing some basic techniques for creating a HTML 5 web app compatible or optimized for the iPad depending on how the techniques are used. It’s not the most exhaustive guide out there, but it’s basically what I now use to progressively enhance mobile versions of the websites I create. See it as a starting point for your own experimantation!


Creating a HTML 5 Web App for iPad – Part 1

Projects - December 7th, 2010

The iPad is (at least for now) the perfect device for consuming media (on the go) and for casual browsing and news consumption. In my point of view there’s no reason for most apps to live in the App Store, the majority would work equally well (if not better) as websites or web apps with the benefit that they would be accessible on all platforms, be free from Apple censorship and are easier to develop (just count the number of HTML vs. Objective C developers). There are a few instances were the speed and processing ability is needed (such as games and media players) but most apps are basically information presenters and the web is more than adequate of handling that.

However, there are some optimizations that can be done to most websites for optimal display and a few other issues that needs to be adressed to allow websites to feel as native apps on the iPad (and other mobile touch devices).


Lumebox 2.0

Projects - November 2nd, 2010

I’ve just released Lumebox 2.0 which has some major new features, the first is that it uses the Google Ajax Feed API to pull RSS-feeds (no need for local proxies for feeds on other domains), the second major new feature is that the next image in queue to be displayed is now preloaded. Lots of small improvements are also made, particularly in scaling, positioning and transforming the images.

Width and Height of Dynamically Loaded Images in Webkit

Projects - September 24th, 2010

Another day, another problem and (luckily) a new solution when developing the next version of Lumebox. It seems as if Webkit browsers sets the image height and width before the image file has been loaded which means that when using, for example, jQuery the .loaded()-event is fired when the height is still 0. Stackoverflow was kind enough to pin down the problem in these two Q&As, but the given solutions didn’t really fix the problem.


Googles Ajax APIs and jQuery Plugins

Projects - September 22nd, 2010

I’m working on a new version of the Lumebox that utilizes Googles AJAX Feed API instead of relying on a local proxy to fetch RSS-data. Only problem was that the Google AJAX APIs uses dynamic loading in the same way as jQuery does but there’s no obvious way to sync them, which means that you can’t use external jQuery plugins out of the box. The best (and only working) solution I found online used three separate functions and a manual timeout to let the DOM’s keep up with another, this doesn’t cut it for me so set out to find a better solution.



Engineering Ideas - September 9th, 2010

I recently read two interesting articles, one by Thomas Baekdal on how the digital renting model is fundamentally flawed and the other by Wired on Thomas Edisons failed attempt to hijack the movie industry in the early 20th century. What immediately struck me was the similarity between how the established media giants now work much in the same way that Edison did 100 years ago (in large part due to DRM, user crippling licenes etc) and how that leaves room for a startup that actually caters to the needs of the consumers. Since I already have too many projects going right now I’m going to give this one away for free. Here’s my vision of uniTunes.



Portfolio - August 20th, 2010


I like to capture the bride and groom on the way out of the church, during the march in they are usually very nervous but on the way out the are much more relaxed and are starting to enjoy their big day. I was just a guest during this wedding but couldn't help myself when I saw this photo coming to life and stepped out in the middle of the isle to get it.