Honestly, if the images are ‘too big’ for mobile in the first place, they’re probably too big all-around… after all theres a reason I wouldn’t ever use thumbnails larger than 180px wide; and if it’s not a thumbnail, WTF is it doing on a normal page.
Unless you’re pissing all over accessibility like the useless train wrecks of garbage websites that most auto makers seem to waste money on… the banner-type and full-page images thrown onto those piles of dung being poster-children for everything wrong with the web today – AND not being what I’d actually call content either.
Again, if they’re too big for mobile, they’re probably buggy slow rubbish on the desktop too. Visit a pile like say… www.nissanusa.com for an example of that idiocy in action… where to be frank those types of sites are likely more of an expense than an investment.
The obvious answer would be lighter pages, both for desktop and mobile. Instead of 20 car pictures, 5 car pictures per page. And better filtering options. Make it easier for the user and content: help the user limit the set of cars. And the car image should be a thumbnail first.
But how far do take that thinking?
Do you make content optimised for an iPad resolution? Do you serve extra content for extra large desktop screens?
I said in my post that a separate version is sometimes justified, in my opinion most of the time it’s not though - adjusting the content with media queries is a great simple solution that keeps one page to maintain.
Similar to what Jason was saying,
Honestly, if the images are ‘too big’ for mobile in the first place, they’re probably too big all-around…
If the content is too complex for mobile, it’s probably too complex all-around.
Though, the way people use mobile and desktop applications are certainly different, you don’t always have the users full attention on mobile as they are often used on the run. Web applications don’t always make sense on mobile, and mobile applications don’t always make sense on the desktop.
If we’re just talking about web sites that are serving static content though, separate versions is unnecessary overhead.
It seems acceptable enough to have separate desktop and mobile presences. I don’t really think tablet needs much more thought than using either desktop or mobile but could very well have a dedicated appearance and/or work flow. Now whether those presences are using responsive, dedicated mobile or combination of the two (RESS) depends on circumstance.
I think RESS is the best solution considering any server-side components can be removed instead of merely hidden client-side.
Disagree. fact of the matter is there is much more screen real-estate to work with on desktop than mobile. How many sites have sidebars out there. Of those sites how many show sidebars on mobile. The answer is probably none. So should the processes necessary to generate sidebar data still be carried out even though sidebar content is not shown on mobile devices. Should sidebars just be eliminated because they are unnecessary for mobile.
Regardless of anything the fact is that any website that is optimized server-side will be more efficient than anything that can just be done clients-side. CSS can’t stop server-side processes from occurring it can only hide the results which means that the end-user is still paying the cost to generate that data even though they won’t see it.
The only way to do so in CSS would be to use regions with media queries. Of course it wouldn’t work on any devices currently but perhaps a mere few. Still with this approach would come the extra load of additional requests and bootstrapping cost of most dynamic content management systems. So I think the middle ground, RESS is the *best of both worlds.
It seems acceptable enough to have separate desktop and mobile presences. I don’t really think tablet needs much more thought than using either desktop or mobile but could very well have a dedicated appearance and/or work flow. Now whether those presences are using responsive, dedicated mobile or combination of the two (RESS) depends on circumstance.
I agree it depends on circumstance but as a first step I’d always opt for one site to maintain.
67 million = Macs sold in 24 years = iPods in 5 years = iPhones in 3 years = iPads in 2 years.
Tablets are increasingly popular so their resolutions is important to consider.
Disagree. fact of the matter is there is much more screen real-estate to work with on desktop than mobile. How many sites have sidebars out there. Of those sites how many show sidebars on mobile. The answer is probably none. So should the processes necessary to generate sidebar data still be carried out even though sidebar content is not shown on mobile devices. Should sidebars just be eliminated because they are unnecessary for mobile.
If the sidebar contains anything important it should still be available on mobile. It should never be a case of just deleting stuff that doesn’t fit. http://twitter.github.com/bootstrap/index.html is a great example that re-formats quite a lot of information really nicely.
Regardless of anything the fact is that any website that is optimized server-side will be more efficient than anything that can just be done clients-side. CSS can’t stop server-side processes from occurring it can only hide the results which means that the end-user is still paying the cost to generate that data even though they won’t see it.
Again, this is just a misunderstanding that what I am promoting is to hide elements.