The Timeline Development Blog

Over the last couple of days I’ve been busy making some substantial improvements to Timeline’s UI, and laying the groundwork for some more.

The first and most noticeable concerns the sidebar which allows the logged-in user to switch between Timeline’s functions. What I want to achieve with this is twofold:

• provide the means for the user to carry out more than one Timeline task at once, and to switch easily between them. When the user changes between functions, Timeline tries to remember the state of all the functions they’re using, giving the impression of (somewhat rudimentary) multitasking.
• to get out of the way when the user is involved with a task – i.e. not to waste screen space or to provide a distraction.

The previous sidebar was quite good at the first task (considering its stage of development), but not very good at the second. It remained on the screen all of the time, using up quite a lot of horizontal space and drawing attention away from Timeline’s content, especially when user was scrolling through a timeline.

I consider the solution I’ve implemented to be fairly elegant, although there may well still be some bugs (especially, as ever, in Internet Explorer, which required some browser-specific code for this even to work at all.) The sidebar displays as normal whilst the mouse is over it. When the mouse is removed, the sidebar slides outwards until it simply displays the Timeline emblem:

(Don’t take my word for it – have a go. I’m quite proud of the animation.)

The second major change is the start of a push to make Timeline a little more interactive. Previously, removing an image required the loading of a separate page, navigating the user away from his or her timeline and breaking the work flow. Now, images are deleted ‘in-place’ and without navigating away from the current page.

I intend to revise all of the editing functions to work like this, which is a rather more interesting technical challenge than it seems. Essentially the difficulty lies in contacting the server without opening a new page, and in modifying the current page dynamically with the results of the request. This is resolved with some clever JavaScript and results in a much more seamless experience for the user.

On top of this, there are some more minor changes. The timeline in ‘view’ mode now scrolls in response to the mouse wheel; translating a vertical scroll to a horizontal movement is annoyingly awkward to implement. And images in ‘create’ mode are now smaller by default, being enlarged when the user mouses over them.

I’d not been happy with the previous Timeline homepage for a while. It was an early effort, put together when my conception of where this project was going was rather more vague. Consequently, although it served its purpose, I knew it would have to be redesigned at some point before the project went live. The homepage forms the new visitor’s first impression of the site, and what they see there dictates to a large extent how strong their inclination to sign up will be.

Today, I stopped putting it off; I sat down, looked at the Timeline homepage and made a mental note of everything that was wrong with it:

• The page is too long. The average user with a fairly small monitor has to scroll a lot to gain an impression of what the site’s about, and that’s not good for maintaining interest. It was developed on my 22-inch desktop monitor, and it looks a lot worse on my 13-inch laptop.
• There’s too much white (or grey) space. Whilst some empty space helps the page to breathe, overusing it dilutes the site’s visual impact and actually makes it less usable.
• The page isn’t intelligently arranged. The most important elements of the page – the login boxes and the links to sign up – are at the bottom. This makes the homepage frustrating – perhaps even confusing – to view, particularly for the regular user who wants to access his or her account quickly.
• The slanted ‘timeline’ graphic doesn’t add anything to the page. Not only is it not an accurate visual representation of the site, but it doesn’t really help the user figure out what the site’s for.
• The ‘featured’ images are poor quality. This is a result of upscaling 320×240 thumbnails to 400×300 for use on the homepage.
• The column spacing looks really awkward, as if there’s an invisible man pushing the columns apart

After that, I went through something of an iterative process, gradually refining the homepage with the above points in mind. After hours fiddling around in Photoshop, dozens of CSS tweaks to get the alignment and spacing just right and dozens more to get it looking passable in Internet Explorer, I arrived at something I’m pretty happy with:

The new design addresses the flaws of the previous one:

• It’s wider than it is tall. So’s your monitor, so this makes for a more natural viewing experience. I can now see the entire page without scrolling on my 1280×800 laptop screen.
• It uses the space more intelligently. The header has a darker background color to achieve some separation from the rest of the page, despite there being more content crammed into a smaller space. The featured timeline and site description use the full width of the page, whilst the three-column layout stops them from looking lost.
• The most important stuff – the login and signup options – is right at the top of the page.
• The amateurish timeline graphic is gone, and the featured images are displayed at the correct size rather than being upscaled.
• The spacing is much more consistent.
• It links to this blog

I like it, and I hope you do as well. Next: more viewer improvements. Starting to get pretty enthusiastic about this project again.

Following the reduction in bandwidth utilisation gained for the viewer as detailed in the previous post, I’ve tried something similar for the Timeline front page. Quick load times here are essential as they affect the user’s first impression of the site.

Timeline centres on photographs. Creating a homepage which loads quickly and is visually appealing is difficult; there’s always a trade-off between appearance and load times. Fortunately, in this case, there was great room for improvement; the homepage code contained a couple of inefficiencies which were sending load time through the roof.

Firstly, the large preview images displayed on the homepage were called from the large (640×480) images; now the thumbnail (320×240) images are loaded instead. Secondly, the small images which sit underneath the main preview image now load from the new mini (160×120) files, as opposed to the 320×240 versions. Thirdly, the number of previews which are cycled on the homepage has been reduced from 10 to 6.

Through these changes the size of an average homepage has been reduced from an unacceptable 1,140k to a much more pleasant 416k. Optimising the page’s JavaScript should reduce this further. And in the future, each preview will load dynamically using AJAX techniques whilst the previous is displayed. This should make the Timeline homepage much faster and more reliable.

The pop-up Timeline image viewer loads a lot of images. In addition to the image which is being viewed, the ‘filmstrip’ section at the top of the window previews the five days prior to the displayed image, and the five days after it. If multiple images have been uploaded for these days, the filmstrip displays all these images in rotation. All these images make the viewer visually appealing, but they’ve tended to increase loading times.

Part of the problem was that Timeline stored uploaded images in three forms – the original image, the large version which is displayed in the viewer (640×480 resolution) and the thumbnail that is displayed in the timeline itself and in the management interface (320×240 resolution). The small images displayed in the ‘filmstrip’ were thus generated by loading the 320×240 thumbnail and resizing it in the browser – wasting a lot of bandwidth.

As of today, Timeline now saves each uploaded image in an extra form – a ‘miniature’ 160×120 version. These mini images are now loaded into the filmstrip instead of the bigger thumbnails, reducing the bandwidth used by the viewer significantly. The result: a typical instance of the viewer which I tested now downloads 233k on the inital load, compared to 464k previously. This means that it loads in half of the time, with no detrimental effects.

Before:

After: