On 2/6/12 3:00 PM, Irakli Nadareishvili wrote:
1. Adaptive images:
To optimize user-experience on smart-phones (most of which have relatively
small screens, and are on slow connections most of the time) we need to send
lower-resolution or resized versions of high-resolution images that would be
sent to desktop clients. The best way to do it is if markup referred to an
image resource with single URL and server, depending on header information,
sent different crop or resolution of the image to different classes of devices.
OK, so just to make sure I understand:
1) You want to use device class as a proxy for connection speed.
2) You want to use device class as a proxy for "size the user will be
able to see the image at". Users who zoom, or save your page to a PDF
for later viewing or printing, screw them, right?
The two underline assumptions here are: it's much easier to detect device type
than quality of network connection.
If you sufficiently restrict your definition of "device type", perhaps.
It's also more correct because small-screen devices do not need high-def images
even if they can download them fast.
Why not? Every single such device allows users to zoom. Many allow the
user to send the image on to other media (external monitors, PDFs, etc)
where they may well want high-def images.
I think that you're assuming particular usage patterns for these devices
which may even be true today but that we don't necessarily want to lock
into the architecture of the web.
Most websites use CSS/JS aggregation. Different devices need special CSS/JS
code. For instance, touch-screen devices need all kinds of libraries like
jqueryMobile. Likewise, Desktop experience may need large javascript libraries
that are not needed on smart-phones. If server could easily detect device
type/capabilities it would have the ability to tailor aggregated js/css files
to a class of a device, thus providing greatly improved experience.
I agree this is a use case worth addressing.
Please tell me which device class your server would like to put
http://www.lenovo.com/products/us/desktop/ideacentre/a-series/a700?cid=us|disp|badg|pcmag|display_dr|21620&dfaid=1
and why (summary for those not wanting to read the specs: it's a desktop
system with a 23" touchscreen running at 1920x1080, with the system
itself built into the base of the screen; similar to modern iMacs, but
with a touchscreen). Which JS libraries would you send or not send to
this device based on its screen size and the fact that it's obviously a
"desktop"?
It seems to me, honestly, that given the current state of the market the
main effect of guessing about device classes and sending them different
content, as opposed to directly detecting the device capabilities you
really care about one way or another, will just lead to you sending the
wrong content to devices as the lines between "device classes" blur more
and more.
I do think there are classifications that are worth making between
devices so as to adapt your content to them, but the primary one I care
about ("is this device running on a battery right now?") is not one I've
even heard anyone mention... and has nothing to do with device class,
except insofar as tablets and phones are almost always doing that while
desktops (but not laptops) are almost never doing that.
I am sure there are other use-cases that could benefit from improved device
type/capability detection. After all, that's exactly why people have put
enormous effort in projects like WURFL.
Quite honestly, as far as I can tell a major reason people have put a
lot of effort into things like WURFL because so many phones shipped with
completely broken browsers for so long... So you needed a big database
just to figure out how the browser was going to screw up your content....
This is clearly not a concern for new proposals, right?
Again, I agree that exposing device capabilities would be useful. I
think that if people are going to infer things like "device class" from
screen size and things like "level of support for touch interfaces" from
"device class", then exposing the capabilities would actually be worse
for users because sites would get things wrong so often.
-Boris
