Hello everyone,
I asked a question at the European Squiz user conference a few months back, and a couple of the London Squiz team did come up with some suggestions/answers on how to best serve responsive images using Matrix … but I bearly understood it at the time and its completely left me now.
So - what can Matrix do to help with truely responsive images?
Background images are a piece of cake - just use your media queries to bring in different image varieties for your differnt viewpoints. That one I can get my head around.
Content images - things like header images, images that authors put in via the WYSIWYG, images that semantically should be <img> in the html, not background images, because they are part of the content. What can we do with these?
I can get Matrix to fire off triggers to generate as many differnet size varieties as I like - but how do I get the big files only being sent to users with wide screen views, and the smaller images only sent to users on tiny screen views? Yes, you can use CSS to 'hide' the big images, but it still means that there is an html call to the big image and its still clogging up the bandwidth, it just doesn't get shown.
So, is there a way to get truely responsive images, so that big images don't ever get called for a small screen view? jQuery, some kind of server-side script action, something else?
All ideas and suggestions welcome!
thanks,
Charlie.
Responsive images - best practice in Matrix?
Best Practices for Managing Large Asset Counts in Squiz Matrix
Are you building a new website, or modifying an existing one?
I wouldn't worry about the extra bandwidth of loading up the full-size images while on a mobile. What I would do is just use CSS media queries to scale those same images that are shown on the desktop site. I really would not go through the trouble of trying to create smaller resolution images for mobile, especially with many high resolution mobiles that could use those extra pixels.
[quote]
Are you building a new website, or modifying an existing one?
[/quote]
A bit of both actaully. Totally new designs, so new base html and css, new Design files and paint layouts in Matrix, but then applying all of that over existing content and pages that have content images in them.
I've been reading about the new proposals for new kinds of <img> tags with interest, but in the few years it will take til those are implemented wanted to know what other people are doing for responsive images.
Thanks for your advice - maybe I'm worrying about those few extra KB a bit too much!
C.
I fiddled around with responsive image variety solutions a little as a proof of concept:
https://github.com/ironikart/responsive-image-varieties
It works, but there are a few problems with the approach:
- Requires extra markup for each responsive image
[*]Currently detecting of screen width. This might not seem like much of an issue, but if you start using ems for your media query width measurements then you can end up with images being out of step with the breakpoints. There are other methods you can use like $('element:visible') in jQuery to detect whether you are at a certain breakpoint.
[*]Can be flaky if you aren't consistent with varieties on images
Bandwidth is becoming less of an issue, but here in Aus we have relatively low bandwidth plans for mobile carriers and extra data is a little more expensive. Additionally, the more kb you put in a page the longer it takes to download. If you can find a solution to trim the size I think it's best to follow it, even if you are only saving a few kb there are people who would appreciate it.
There are a few other solutions you could use that use user agent detection, but these are unreliable with the number of devices currently on the market, and also the number of emerging devices. They are also hard to manage, no one wants to have to keep up with all the potential new user agent strings. JavaScript seems to be the best overall solution for conditionally loading those images, the only problem with it will be devices that report to support JavaScript but don't properly (eg, older Blackberry devices).
[quote]
(eg, older Blackberry devices).
[/quote]
People still use Blackberry?! 
On the other end of this debate is retina graphics.
We are starting to add 2x version of our news images as an image variety called 2x. That way we can work to be future proof when all display are high res. For now, it just looks nice when I load them up in our Pacific Union College iOS app.
[quote]
On the other end of this debate is retina graphics.
We are starting to add 2x version of our news images as an image variety called 2x. That way we can work to be future proof when all display are high res. For now, it just looks nice when I load them up in our Pacific Union College iOS app.
[/quote]
This requires you to use the background-size property to normalize those images for non-retina displays doesn't it?
http://caniuse.com/#search=background-size (no IE 8 support of course)
The retina displays are nice, but I think browser usage and bandwidth limitations will hold us back for some time.
[quote]
This requires you to use the background-size property to normalize those images for non-retina displays doesn't it?
[/quote]
Yes it would.
We have not currently deployed them on puc.edu, and I am not sure when we will. But I have just added it to our workflow so that we get used to doing it, and because we pull that same content into our iOS app, which does use the 2x versions.
[quote]
I wouldn't worry about the extra bandwidth of loading up the full-size images while on a mobile.
[/quote]
I'm not sure that some of the ideas about best practice for mobile design, responsive design or improving page speed necessarily agree with that.
Consider http://de.slideshare.net/sevenval/mobile-web-performance for example which calls out (on slide 55) image resizing and image quality as one step that can be taken to address the issue of slow page loading on mobile devices.
While retina displays and the like make viewing and zooming on graphics that you wish to study useful, I'd argue there's always value in considering what you can do to improve the performance of the page - and particularly on mobile.
At the risk of starting an all out war (hehe) I'm in both boats with a swing towards Nic's side of the fence.
So much focus is placed on trying to provide multiple flavours for different devices that the end result can easily become a nightmare for the end user to manage and maintain, one or two specialists become the fail points in the scenario, and it costs a flat out fortune for the client and takes forever to implement. It's a rare platform/solution/product that can do all of it in the one neat package and getting it right requires multiple external components and the right people involved.
I'm also a firm believer that the world and its technology changes so rapidly now that placing too much focus on trying to provide multiple falvours would be wasteful, unless of course your situation calls for it i.e. your business is dependant on revenue generated from mobile traffic and keeping those customers happy is your first concern. Which happens alot, and of course makes sense.
At the end of the day (at the moment) you still gotta plug your phone in to charge it every few hours if you have all the good stuff turned on, even if you havnt been surfing the web, and the majority of frequent web users have adjusted their data plans to accomodate their regular patterns of use. Technology is fast catching up, driven by the consumer. In the not too distant future most of what forces us to provide mutiple flavours for these situations won't matter, we'll be too worried about the next wave of web stuff we have to scramble to accomodate, like web 4.0 / Skynet
I highly prioritize user experience. And if I can provide a user (in this case a student that might come to our College) a superior user experience and have to use more bandwidth to do it, that is just the risk I am going to have to take.
[quote]
While retina displays and the like make viewing and zooming on graphics that you wish to study useful, I'd argue there's always value in considering what you can do to improve the performance of the page - and particularly on mobile.
[/quote]
It isn't just that. It is providing the user with an excellent experience.
Now that many many of our mobile users are used to retina graphics, they visit a website without them or an app, and it IS noticeable. They will start to perceive that product as inferior or low quality because it isn't looking as sharp and snazzy on their screen as other things they see.
At least in higher education, things like this matter for the perception of our brand to prospective students.
I think that's really the distillment of the issue - User Experience and their expectations.
Images are the core part of our 'brand', and as National Parks we're lucky to have some pretty stunning photos to use. I agree with Nic that users on devices that support hi-res images will expect them, and supplying them will help enhance our brand and our message.
But, we also have users who may be using their devices on patchy 3G reception, without hi-res supported devices, and having a responsive design to taylor the layout to their screen size is great, but they'll have a bad experience if they can't download that beautifully laid out content because we're sending them our normal 15 header images and then using javascript to hide those, or using css to resize them.
I'd prefer a way of being able to send them one smaller image at a smaller file size.
And yes, that means that people viewing the site on a small screen size, but using kick-ass fast WiFi will get a less picturesque experience than their wider-screened friends, but in my case, I think the needs of users who are actually out in the Parks on 3G trumps that.
Its a shame that we have media queries to detect screen width but nothing to detect bandwidth speed and respond to that!
Charlie.
[quote]
Its a shame that we have media queries to detect screen width but nothing to detect bandwidth speed and respond to that!
[/quote]
I think the issue with this, especially on mobile, is the speed could fluctuate. But I guess you would reevaluate that on each page…if it was possible.