- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Mon, 06 Feb 2012 16:53:31 -0500
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
Received on Monday, 6 February 2012 13:53:31 UTC