Are you a Jupiter user? If so, I'd like to hear from you.
There are a several features in Jupiter that I'm considering retiring. Most of them involve a lot of difficult-to-maintain code, in exchange for functionality that, for all I know, no one is actually using. But I don't want to remove a feature that will cause multiple users to open their veins and bleed out on their keyboards. I am not without empathy, in spite of what you may have heard.
Here's the current hit list:
"First image" and "Last image" navigation. Why would a visitor want to go instantly to the last image in a slide set? And if he wants to start with the first image again, he can go back to the thumbnail page and click the first thumbnail. So, two clicks instead of one.Removed.
The numbered link list on index pages. My reaction is that visitors won't know what page they want to go to. And if you're creating that many index pages on a given level, maybe you should consider using a folder structure to organize your material, rather than spreading it out over a large number of index pages.Safe because some people are using it, and among skins, it's just about the last of its species.
Overlays on the thumbstrip thumbnails (as opposed to the regular index page thumbnails) for video, audio, "new," star, and custom. Is a site visitor actually going to decide whether or not to click on a thumbstrip thumbnail based on what kind of slide page it's going to take him to?Removed.
The thumbstrip itself. Because Jupiter is a fairly simple "slide page" skin, the thumbstrip isn't a fancy, sliding affair. It's pretty rudimentary. Do site visitors actually use this, or is it just screen clutter? It adds a lot of overhead to the album generation, and the amount of code involved is surprisingly large.Removed.
The "star" overlays on thumbnails. An interesting idea - use the jAlbum colored "flags" to convey some information to the visitor. A blue star indicates a Democratic image, and a red star will take you to Trumpland. But is anyone actually using this in a real album?Removed.
Displaying the video/audio length in the thumbnail caption. I'm not passionate about killing this one, but I wonder whether it's used. Do your site visitors decide whether or not to go to the slide page for a video based on how long the video is?Safe because some users want it.
The option to disable "on-image navigation." Does anyone ever want to turn off the ability to click on the left or right side on an image to navigate? If so, why?Removed.
Double and beveled borders on thumbnails and/or slide images. They look kind of interesting, but is anyone using them?
Do your site visitors decide whether or not to go to the slide page for a video based on how long the video is?
I'm not a Jupiter user, but when I am offered a video in a news site, the length of the video does matter. E.g. "A condensed history of the second world war" in 51 secs is not worth opening. If it is 12 hours long, I don't have time for it. If it is 10 minutes long, I will look at it.
There is one thing that lazy loading (LL) definitely succeeds in doing. It saves bandwidth. Images that aren't viewed don't get downloaded. So, for a visitor with a metered connection, it will make a difference. But that usually applies only to mobile users, and they're not your target audience, anyway.
Does it make your page faster? Well, yes and no.
If you measure the page loading time for a non-LL page, it might be 2 seconds. For the same LL page, it might be 0.6 seconds. So yes, it's "faster." But this is what I call "coding for bots." Of course it's faster, because it hasn't actually loaded the entire page. It's loaded maybe a third of the page and then proudly announced, "I'm finished!" All it's doing is fooling a page speed bot into thinking that it's faster.
But does that translate into a better user experience (UX)? I don't think it does.
But on the non-LL page, while your visitor is gazing upon your wonderful thumbnails, the browser continues to download the rest of them in the background. When the visitor quickly scrolls down, he sees the images immediately, because they've already been downloaded. On the LL page, the fast-scrolling visitor (and even a slow-scrolling visitor, depending upon the LL implementation) will often see placeholders for the images, instead, because they haven't been downloaded yet. So, the UX is actually worse. The visitor has to wait for content every time he scrolls down.
This page in particular as it's the one with the most thumbnails:
Here's quick test for non-lazy and lazy loading:
An interesting real-world comparison. The LL page declares itself "finished" in 0.7s, rather than 1.2s. But of course, the subsequent thumbnails haven't been fetched yet. But I can't really beat it to the punch by, for example, jumping to the bottom of the page. Then again, the loading is so fast on my machine, I probably wouldn't be able to detect the difference anyway.
But what happens when you try the LL page? Clear the cache, load the page, and then, without scrolling down, hit CTRL-END to jump to the bottom. Is there a visible lag?
I might just take an agnostic approach and offer it as an option in my skins (only when it won't collide with something else that's going on with the page layout). I'd leave it disabled by default and tell people, "use it if you want to, but don't complain to me if you don't like the result!"
ETA: Upon further testing, it turns out that, as I originally suspected, from a fast server with a fast connection, lazy loading is slightly faster, without producing any unwanted side effects. But on a slower (or more distant) server, lazy loading is much, much worse, with terrible lags when the visitor scrolls down. So, it's OK when you don't need help, and detrimental when you do need help. Therefore, no current plans to add it to my skins.