Mobile-Friendly Portfolio Galleries in WordPress: The Thought Process

Slide shows are a common design pattern that I frequently need to implement, most often as photo galleries or portfolios. They involve loading a set of images with titles and/or captions, and cycling through them with some kind of fade or sliding transition using Javascript. The slide show script I currently use is WooThemes’ Flexslider.

Unfortunately, slide shows can raise serious performance concerns for mobile devices. Loading a bunch of large images for display on a small screen is wasteful and can slow the page load to a crawl. Additionally, some older devices don’t support Javascript, and markup written with a slide show script in mind may not give the nicest experience for them.

This is where the concept of progressive enhancement comes into play: we give the full slide show experience to the devices that can handle it, and an appropriately scaled-back experience to those that can’t.

It’s very difficult to make progressive enhancement work perfectly for every aspect of every site. There are always assumptions made and edge cases that get lost in the shuffle, but it’s the right mindset for approaching any feature and even a little bit of thought and effort can go a long way towards making our content more widely accessible.

In the case of our slide shows, there are a few things we can do to address image sizes and Javascript dependency in an attempt to serve appropriate content to each device.

Think it through

There are three basic “views” that I consider for every new layout or feature:

  1. Devices with no Javascript
  2. Small-screen devices with Javascript
  3. Large-screen devices with Javascript

Devices without javascript can be any size. Sometimes people disable Javascript on desktop computers for their own reasons, though it’s pretty rare these days. But I picture an older phone that doesn’t support Javascript at all, has a small screen, low processing power and low bandwidth. An assumption, but one that takes care of the most people.

Small-screen and large-screen are arbitrary distinctions. What counts as small? Once again I’m picturing a phone, but as we know, new phones come out every day with different screen sizes. 480 pixels is a dividing line based on iPhones of old, and it’s as good a starting point as any, though the final large/small boundary is often a little larger to include more of the newer models, and is strongly influenced by the design and what looks good at different window sizes.

Case #1 – A list of projects

This corresponds with the portfolio galleries for the Design and Illustration sections of this site. Our primary goal is to share a collection of links to pages that each have their own set of visuals, as opposed to sharing the images themselves.

No Javascript: In this case, it is a completely acceptable experience to just provide a list of links without images to devices without Javascript. This nicely keeps the no-Javascript view extremely light weight for a quick load in low-power/low-bandwidth situations.

Techniques for implementation:

Small screens with Javascript: There are a couple of different approaches to the small-screen view.

In some cases, it might work to load an image only for the first few projects in the list, with the remainder of the links as text (an approach I used in this portfolio site for a stained glass studio).

Other times, it feels better for the design to go ahead offer the slide show functionality to any size of device as long as it runs Javascript, as in the Design and Illustration galleries on this site.

There is a trade-off between page weight and nice-to-have design features here. The first approach with fewer images will load faster, while the second approach sacrifices some of that speed to be a bit more fancy. The number of items likely to be added to the gallery can help make the decision for me: if we have to load a dozen images before the slide show begins, the first approach is probably better.

The most important thing for both of these approaches is that we load in images that are sized appropriately for the screen size.

Techniques for implementation:

Large screens with Javascript: These guys get the full slide show experience with larger images appropriate to the wide-screen page layout.

Here I use the same techniques as for small screens with Javascript, but include a larger image size in my WordPress loop.

Case #2 – A gallery of images

This corresponds with the project galleries on this site, such as the Botanical Illustration or City of Alpine Tourism Promotion project pages.

The only significant difference in this case is for the “no Javascript” user. A list of titles and links is not very helpful for an image gallery, so we need to find a way to get images into the no-javascript view.

Here we have to undertake a balancing act, trying to accommodate all of our users with a minimum of negative impact on any of them.

If we load thumbnail images for our users without Javascript and then proceed to hide them and use AJAX to load larger images for the slide show, we are adding unnecessary http requests and file weight to our users with Javascript.

Another option is to provide our no-Javascript users with introductory text for the gallery and a link to an additional Javascript-optional page with static thumbnails of all the images. This puts an extra click and page load between them and the images they are looking for, which is not an ideal user experience. It does work, though, and since non-Javascript users are a tiny minority it seems better to slightly inconvenience them than to inconvenience the much larger group of users with Javascript available.

The small-screen and larger-screen Javascript views would be approached exactly as described above.

Conclusion

Any feature like this will require a similar thought process, weighing the performance implications for each set of users. It is always an exercise in trade-offs and we just do our best to responsibly serve our users with the constraints we are given.