Our website would like to use cookies to store information on your computer. You may delete and block all cookies from this site, but parts of the site will not work as a result. Find out more about how we use cookies.

Login or Register

Powered by
Powered by Novacaster
 
Let's get preloaded
by Bruce Ure at 11:15 10/10/07 (Forum::Technical Advice::General)
On the new mastermaster site (at mastermaster.org.uk/new3.php currently, but don't expect it to be working all the time as it's a 'live dev' environment) there's a link labelled 'random'.
Originally I wrote it so that when you click it a random master ID is chosen and the image displayed. Logical enough.

But then I got to thinking about image preload. Things like preload can make a huge difference to the 'usability' of a site, and it's the sort of thing I like to spend time getting right.

Preload is already incorporated into the next/back buttons, but random was going to be harder, because by definition your next image is random.

So I thought okay then, I'll put the id of the NEXT 'random' master as a parameter in the url of the 'random' link. So in fact it's predetermined but still essentially random.

Except that still doesn't preload the FIRST random image for the first time they click on 'random'.

So then I had a brainwave. Why not massively simplify it by generating the ID for the 'random' link every time the page is loaded, regardless of whether they clicked 'random' or one of the other links? That way I can easily preload the 'random' image in case someone clicks on the link, and the code is exactly the same as the normal 'detail' code, but with a predetermined random id, so the code is waaaaay simpler.

So I threw away my working-but-overly-complicated random code and just wrote it like that.

But then the horror dawned.

Now when you bookmark the 'random' link, you will always get the same image, because it's just a standard link to a detail page with a particular ID. It's passive. There's no randomisation when you click 'random': it's already decided and coded into the link.

So the question (which is what this has all been leading up to) is, is it MORE important that the random link is genuinely random if people bookmark it, than that the first random image is preloaded?

Personally I think it is, and I'm inclined to re-complicate my code again and try to cover all eventualities, but I wondered what (if anyone's still reading) the panel thought.

The ideal would be:

By default load the grid page, with a random image preloaded in case they click 'random'. If they refresh the grid page or go to a (non-random) detail page, that random image stays the same, until they click Random, at which point it displays that and chooses the next random image for preload.

Without using sessions and possibly cookies, I can't see a way of doing this. The best case scenario is, I think, that there will be an inevitable delay the first time they click 'random' because the image will not be preloaded. All subsequent ones will, though, by dint of choosing the next one when the first is loaded.

And all because people may want to bookmark the 'random' link.

--

<< 3Ware SATA Raid 9550SX Perform... Weird Mac LANishness >>
View Comments (Threaded Mode) Printer Version
Let's get preloaded Bruce Ure - 11:15 10/10/07
Re: Let's get preloaded Simon - 12:48 10/10/07
Why not have your random link pick one of ten predetermined images, and preload all ten on the previous page.

You could recalculate which ten are the random set on a daily basis.

I might do it by daily creating a set of 10 symlinks to the actual randomly-chosen images in the /random/ directory, with the names of the symlinks being random1, random2 etc. The links would then stay the same, but the images underneath them would change daily.
--
simon

Re: Let's get preloaded Bruce Ure - 09:49 13/10/07
Cunning, thanks.

--

Re: Let's get preloaded Graham Freeman - 03:05 11/10/07
Check the referring page. If it's from your site, they clicked a link, so show the image that's pre-loaded.

If the referring page is not from your site then they used a bookmark, so show a random image without going through the pre-load stuff.
--
gfreeman

Re: Let's get preloaded Bruce Ure - 09:51 13/10/07
Doubly cunning... thanks.

--

Re: Let's get preloaded Steve - 02:19 16/10/07
Out of curiosity, how much time does preloading save versus actually loading the image as needed?

--
stevepa

Re: Let's get preloaded Bruce Ure - 08:39 16/10/07
In practice a second or two at the most in this case as they are only 60-100k files.

But it's more to do with how excellently 'snappy' a site feels when the next image is preloaded, along with how crappy it feels if you have to watch it paint. Try http://www.mastermaster.org.uk/new3.php and check the dfference between flicking through really fast (into uncached images!) and waiting for the next one to preload.

If you don't preload, your connection speed becomes [a negative] part of the presentation experience. Whereas presentation should be as far divorced from the delivery medium as possible, I feel. I haven't explained that well but I expect YSWIM.

I reckon if the site developer knows what image is coming next it's sloppy not to preload it.

--

Re: Let's get preloaded Steve - 15:01 16/10/07
I agree. In the case of Random, I think that second or two might be forgiveable unless Random was the only or the most common navigation option. But then engineering is all about going over and beyond what would be practical and squeezing that bit extra.

--
stevepa

Re: Let's get preloaded Bruce Ure - 21:33 02/05/08
We now have:

- Caching of next/back images

- Caching of the next 'random' master when you click "random" on the site repeatedly

- Genuine random master when a bookmarked link is clicked instead of the 'predetermined' random if you click the random link on the site.

So, thanks for the suggestion Mr freeman!

Come and see the randomness inherent in the system!

(There are some other additions as well--comments always welcome--and a total of well over 300 masters now).

--