The Timeline Development Blog

When I’ve had a minute in between essays, I’ve been working on making Timeline’s internal URLs simpler. For example, here is an old-style Timeline URL:

gettimeline.net/viewer.php?imageID=100&view=album

The problem here is that the readability of the URL is low, both for humans and for search engines. With some remapping of parameters in the server’s configuration, we can configure a URL such as the following to redirect internally to the URL above:

gettimeline.net/view/100/album

This  gives a much more professional and user-friendly appearance to URLs, as well as helping Timeline URLs to rank more highly in search engines.

One further step is that usernames are now accepted in profile URLs. This means that the following old URL

gettimeline.net/profile.php/userID=1

becomes:

gettimeline.net/profile/mattus

Each user thus has their own profile URL which is easy to remember.

Earlier, I waxed lyrical about the wonderful sidebar implementation which I’d cobbled together to allow the logged-in user to navigate Timeline.

Predictably, last week, I wiped out all the code for it and started again.

As is often the case, continued use of the sidebar had drawn my attention to its shortcomings. The first was that the amount of information it could display was sorely limited. It was adequate for switching between functions – but I began to think about incorporating lists of recently-viewed pages as well as quick links to other useful Timeline pages, and it soon became clear that there was no way to fit all of this information into the vertical format without making for a horribly confusing user experience.

The second problem was the the sidebar provided no visual cues as to which page the user was on when in its contracted state. Nobody is going to know the structure of Timeline as intimately as I do, and I sensed that this absence of navigational aids had the potential to scare off new users.

The biggest problem, though, was that the vertical format just didn’t feel natural. Almost everybody is used to using a horizontal taskbar to switch between programs, whether they use Windows, Mac OS or Linux – where was the benefit in forcing people to adapt to a new navigation paradigm? Furthermore, the sidebar combined with the navigational bar which is fixed at the top of every logged-in Timeline page, and created an effect which looked unbalanced and just awkward. I grew to hate it.

The new taskbar is drastically different.

In its contracted state, the simple design wastes minimal screen space and allows the user to switch easily between Timeline’s basic functions whilst providing a clear indication of which function is active.

Mousing over the taskbar reveals the expanded form, after a short delay. The top part of the extension conveys further information on the user’s current actions; when it’s finished, the lower part will ‘intelligently’ suggest links to Timeline pages and functions based upon the user’s history. I see the new taskbar as a significant step in the development of Timeline from a purely personal project to something suitable for a wider audience.

After some time away from the computer enjoying the summer, I’ve been spending some more time in dark rooms (!) working on the Timeline project. There have been far more developments and changes in the last couple of months than could be discussed in a single post, and thus I’ll begin with the most visible: the latest changes to the homepage.

You may recall that this is where we left off:

This version of the homepage was a great improvement on the initial rendering, in terms of  appearance and usability. The chief remaining flaw was that it didn’t permit a simple method of navigation; the three links at the bottom of the page did their job satisfactorily but left no room for expansion. Knowing from experience that confusing and illogical navigation structures are one of the principal turn-offs when visiting a web page for the first time, I also knew that this alone necessitated a rethink of some elements of the homepage. I was looking for some kind of navigation bar – but how to insert one without crowding the page and compromising the simplicity that has always been a key goal of Timeline?

Here is the Timeline homepage, incarnation three.

The eagle-eyed amongst you will notice plenty of alterations alongside the bottom navigation bar which was the impetus for the changes:

• I’ve worked to make the divisions between the header, the footer and the page content much clearer. Since space is of the essence, the distinction between the black and the grey background serves as a visual trick, allowing me to cram more information onto one ’screenful’ than would otherwise be feasible.
• The canvas background has gone. I always considered it a bit tacky. It’s been replaced by a reasonably bland grey background image with faint swirls on it. Bland is good when you’re trying to draw attention to your content – nevertheless, I suspect that it may be replaced again one day.
• The featured images now have reflections! They’re created by a bit of (some would say unnecessary) JavaScript which I borrowed and adapted a little. Trying out lots of combinations of height and opacity for the reflections provided a perfect outlet for my perfectionist tendencies; I think the resulting effect adds a touch of Apple-like finesse, though there’s always time for me to get bored of it. For now, it’s only 5kb of code which doesn’t seem to cause a slowdown on any popular browsers (my major concern), so it’s staying.
• Finally, the elephant in the room – the appearance of the search function. But that’s for another post – scroll down to find it.

When the idea of Timeline came into my head, a comprehensive and intuitive search function was already central to it. I’d done no work on this aspect of the project before now, partly because there were certain aspects of the site and database structure which had to be set out first, and partly because it was the kind of thing which needed to evolve and be fully-formed in my mind before I started coding it.

Searching, to state the mildly obvious, is how the user of Timeline discovers new stuff. The search function needs to allow the user to discover if people whom he or she knows are on Timeline, which necessitates a sensible way to find members.  It also needs to work well when the user is searching for keywords and expecting to find relevant images and timelines. The search is the portal to all of Timeline’s content; the search is a big part of what keeps people engaged. So it has to be engaging.

The search can be accessed whether you’re logged in or not, both from the front page (what I call the ‘public search’) and from the ‘find timelines’ section once logged in. At the moment, these two methods present the same results; in the future, search results will probably be tailored to a user’s wishes when he or she is logged in. Image data and timeline data are searched, as well as members’ usernames and actual names.

Here is how image results are presented (the timeline and user searches aren’t finished yet):

(Two important things that we’re still missing are pagination and the ability to sort results by name and popularity.  Those are coming soon.)

Like many aspects of the site, developing the search was all about finding a way to present information in a clean and attractive manner. I spent a disproportionate amount of time figuring out how to give the preview images curved edges in a way that worked across all browsers. After that, I set about organising the information on display. The search results use a similar colour scheme to that employed on the home page; specifically, the eye-catching colour which I call ‘Timeline orange’ is used for titles (the most important information), with blue for user names and slightly less important information and grey for auxilary information. The fonts got a lot of attention too. Georgia, the serif font employed for titles, conveys a suitable sense of authority and grandeur; usernames are displayed in the softer and more personable Calibri (reverting to the similar Tahoma when that’s not available.) And all other information is in Tahoma, because it’s readable at small sizes.

We also have coloured highlights when an image is moused over, accomplished through the wonderful JQuery, and view counts, which called for a bit of background work so that Timeline would track this information. And don’t miss the list of popular searches, which is perpetually updated and displayed on the main search page and when a query returns no results. There’s more to come.

If your appetite for August Timeline updates is not yet sated, scroll down for more.

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: