@CHRFRENNING

UI Libraries and Application Look (Read: Office Look)

Why do UI libraries “always” implement application style looks?

All good UI libraries, for any platform, seem to impose a strict style, copying ideas and functionality from desktop applications. Theoretically stylable, but only through very hard work.

We don’t want all applications to look alike - and especially not on the web. Model your look after your users and the tasks they’re doing on your site, and innovate. Stop copying stuff designed in a different era.

A close, but imperfect copy of something users are familiar with, for example Microsoft Office, is rather repulsive than good, and causes more frustration than happiness.

After all, the web isn’t a native application and never will be. Never should be. We’ve moved on. UI library vendors should too.

Speed up loading of JavaScript, CSS, and graphics

Speed is essential for all websites, but especially for sites where users spend much time and navigate through many pages. Reducing the traffic will improve the user’s experience and lower your traffic costs.

Your web server is already using eTags and Last-Modified headers to help browsers validate the items in their cache. This ensures you don’t transfer data twice (as long as it is cached), and the cache is immediately updated when an item changes on your web server. These techniques already do a reasonably good job for you.

However, these still require a browser to make a call to the server to validate each item. Although this is a minimal request, it still requires server resources, bandwidth, and most essentially: time. With many items, as any non-trivial website or webapp will have, it adds up and affects your performance and your users.

I’ll explain an alternative strategy for your most common resources which will help you speed up your site. Using this will help you make the most of existing internet architecture, such as browser caches, proxy servers, front-end caches and content delivery networks. It is not a solution for every file on your website, but you should use this for all content that is used across many pages of your site and changes infrequently.

Today’s solution

Most web developers will store their documents in a structure that looks somewhat like this today:

/index.htm
/css/common.css
/js/common.js
/gfx/sitelogo.png
/gfx/background.png
… etc …

When you make a change to e.g. sitelogo.png, you update that file, and voila - all your users see that change. Also, each time a page is loaded, their web browsers will tell your server what version of sitelogo.png it has, and download the data if changed.

Your next solution

By using the Cache-Control or Expires headers, you can instruct your clients to keep an item in the cache for a certain time period. It is easiest to use the Cache-Control header in most web servers. The header below allows clients to cache an item for 30 days:

Cache-Control: public; max-age: 2592000

Create a folder, e.g. /commonres, and ask your server administrator to enable the header above for this directory structure.

Then, create a version folder below this each time you push an update to your server. The folder structure now looks something like this:

/index.htm
/commonres/1.0/css/common.css
/commonres/1.0/js/common.js
/commonres/1.0/gfx/sitelogo.png

You can now push new files into this structure, and they will be correctly downloaded by clients. However, if you change any of these files you must rename the version part of the path and update all your references to point to this new location.

When making major changes to your site, copy the folder 1.0 to 1.1, and push to your website:

/index.htm
/commonres/1.1/css/common.css
/commonres/1.1/js/common.js
/commonres/1.1/gfx/sitelogo.png

Automating the updates

Obviously, if you have many manually crafted pages on your site, using Search/Replace to update all the version numbers can become tedious.

I therefore strongly recommend that you have some kind of global variable which is set by you in one place, and then use this variable to create the resource URLs. This will work in absolutely all scripting languages.

Wrapping up

This technique requires you to think about versioning of your site, but will make a big impact on performance in the long run.

Another benefit is that by thinking about which content you put where, you are well prepared for introducing a content delivery network in the future.

Getting the ‘application feeling’ in a browser

In our work with the FotoWare Digital Asset Management system, we’re now focusing all our efforts on a specific user group among our users: professional picture editors.

These are people that work professionally with images, spending hours each day browsing through and searching in collections that grow with many thousands of photos each day. Their task is to find the best picture(s) for their stories, or even creating stories based on pictures they find.

This kind of focused effort requires tools that are extremely effective - every wasted mouse or keyboard operation will be an irritation for the user. This blog post is about the lessons we’ve learned.

In our work we have come across some design considerations that make the difference between an average and a wonderful application:

Infinite scrolling is a requirement in lists. The typical paging approach used by web sites is not acceptable for users any more. You may not want to load elements in the background, but you may want to hint to your server that you’ll soon come to get them so that it can prepare stuff for you.
Screen estate / control size. The oversized controls made popular lately makes you run out of space quickly. Users love these, but you cannot afford to use them everywhere. Think about every pixel. When done well, you do not have to give up on beauty, but you will need to work hard to get it.
Speed. Predict what the user wants to do next and load it before he does, or at least hint to the server that you’ll soon need the data so that it can prepare. Servers are cheap.
Animate transitions. You can make load times less visible (read: boring) by carefully choosing and timing animations. But never let them get in the way of performance - speed up or kill the animation as soon as you’re ready to present more data.
Widescreen monitors. We used to design for 4:3, now 16:9 is more and more common. Use this knowledge wisely and you’ll get good results.
Horizontal scrolling is bad. You can’t use your mouse wheel, which makes it inaccessible for most users. Users seem to have problems with horizontal scroll bars. If you need to scroll, let the user scroll vertically.
Drag’n’drop is difficult to discover for users. They are not used to it in web applications yet, so they are not looking for it. But… they like the concept when you tell them, so use UI hints to teach users it is there.
Hitting small stuff with your mouse is more difficult than you think. The most important buttons and links must be so large that you can press them on an iPad without zooming. That way they’ll also work for most users. Size buttons and controls according to importance and frequency of use.
Keyboard shortcuts. Common operations must be accessible through keyboard shortcuts - mouse operations are too slow. Choose keys wisely - avoid frequent movement across the entire keyboard. Keeping keyboard shortcuts accessible for the left hand lets you use your right hand to control the mouse (you should also think of left-handed users).
First and foremost, it must be easy to use. Users must instinctively understand what to do without reading documentation. But, if you can save them large amounts of time, they will invest time and effort in learning tricks, such as keyboard shortcuts, mouse gestures, or other smart features.
Learn from Twitter’s blue whale. It is your fault when a user gets an error, not their. Don’t scare them with error messages, try to be friendly and helpful.

Today it is so easy to put up a user interface on the web, but it is not easy to make a really effective and user friendly interface.

I think the most important lesson to learn here is that you must invest a lot of time and effort into your primary interfaces if you want to make your users truly happy.

When making a web application that users will work with for long periods of time, you won’t necessarily spend less time designing the user interface on the web than in a thick application.

About Me

I’m currently working in FotoWare, a software development company specializing in image workflow and digital asset management. We’re managing millions of important images, videos, audio, and documents for thousands of customers world-wide through our software products.

A lot of what we do is related to working with metadata, which is data describing an object, such as a document or an image. Metadata is so far the only viable way of finding stuff in large collections of images, but our hopes are high on face recognition and visual search for images, which may make life easier for our customers.

I am the CTO of FotoWare, which means I’m leading the product development in the company, trying to work with our customers and partners and fulfill their needs related to our products and technology. Also, we’re working on exciting new products which we hope will make life even better for our customers (and help us get new customers). My teams consist of awesome people working with the latest in web, mobile and cloud technology, with the added complexity of putting all of these powerful tools into installers that anybody can run on their local servers to get a DAM system up and running in minutes.

I myself specialize in server architecture, cannot give up C++ for its raw power, and spend quite a lot of time with our customers to learn what their current challenges are.

At home, I live with my wife Kathrine, and Julia and Jacob, our two kids. My main past-time passion is mountain biking, and I really enjoy the gnarly trails available just five minutes from my home.