Arguments against responsive/adaptive web design

No. http://adaptive-images.com/

Not if you attach your scripts immediately before the </body> tag where they belong.

Not if you attach your scripts immediately before the </body> tag where they belong.

Believe me, I tried that too. By the time the call to jQuery went out, the page was already loaded and there was no load event for the library to see.

Where to place scripts is purely a personal decision. I hear a lot of people arguing with much fury and passion over it. Let them.

The way I see it is that responsive web design is simply the next step from fluid web design but i see them both as flawed . The reason why is say this is because both are to depended on the client side processing . We have extremely powerful servers on our disposal and yet we use them only to run apache . This is a crime that our user won’t forget .

IMHO we should let the back end do far more of the workload . For example we can use the back end to find out the user’s resolution and serve content accordingly therefore saving bandwidth and sparing it’s micro CPU from computing complex CSS and unnecessary JS .

For example we can use the back end to find out the user’s resolution

how? user agents lie. a lot.

So far as I know, client-side javascript or media queries (which are not universally supported!) are required to find the users’ screen sizes/resolutions. Meaning the answer you get is 100% dependent on how retarded (or not) the users’ browsers are. There are still a lot of retarded browsers out there.

There are also many users with thuper-dooper thmart phones who don’t want empty featureless mobile sites (this is getting better, but for a long time the “mobile version” was little better than the “text-only for accessibility” nonsense many sites employed) who would deliberately change their user-agent strings so they could get to the “desktop” versions. I remember back when Facebook would send the mobile version of their crappy site to my DESKTOP copy of Konqueror.

Browser-sniffing: a bad habit, even though sometimes it’s our only recourse for some things.

Waiting for that page to load… waiting… Go for coffee… waiting. Great, web advice from a page that’s 3 megabytes in 185 separate files. RIGHT.

Now, no offense, but that article linked to by the OP is some of the most chuckle headed nonsense I’ve ever heard, and likely stems from people who make websites that are miserable accessibility FAILURES – like say that entire site it’s hosted on with the illegible color contrasts, px metric fonts in an absurdly small size, and crappy fixed width layout that doesn’t even seem to line up properly.

The article itself is chock full of the types of half truths and card stacking I’ve come to expect from the PSD jockeys who repeatedly piss all over the mere CONCEPT of accessibility. So let’s go down their list of lies.

  1. Image resizing – The entire first sentence, “This is a major issue considering that every good designer must rely on images to illustrate its concepts” is your typical PSD jockey bull. “concepts” in this sense is your typical marketspeak idiocy; the CONTENT should be relaying your concepts, NOT the goofy graphics you hang on it. As to the “full size images” bit, if you’re talking layout images, they’re not content – they don’t go in the HTML, so just DON’T SHOW THEM ON MOBILE! If it’s a content image then you should probably have this tiny image called a thumbnail and then SHOCK let the user open it NORMALLY (without any of that lightbox asshattery) – end of problem. What the HELL he’s rambling on about with the table of images and sizes is beyond me.

  2. resizing images cpu/memory. – sure, that’s true, which is why you shouldn’t be resizing images in the first damned place unless you’re showing JUST one image – in which case let the bloody UA handle it. Anything else should be a thumbnail and a launch… The only thing I can figure is they’re talking about giant idiotic banner image bull; Things that IMHO shouldn’t even be considered web deployable in the first place!

  3. Image downloads – because some nimrod thought monstrous images on the main page of their site was a good idea. The problem isn’t mobile downloading it, again it’s some photoshop junkie going “hey, lets make a fat bloated useless website nobody actually wants to visit!”

  4. Mobile speed vs. Desktop Speed – The old bandwidth arguement – there will always be slow smaller devices; and frankly this isn’t just a “desktops are fast” issue given less than 10% of my neighbors likely have connections faster than 768kbps… I go 50 miles north, and everyone up there who wants internet access is stuck paying through the nose for that hughesnet garbage, or dailup as a long distance phone call.

As to the speed of the devices – when todays browsers are FASTER than older browsers, and we used to browse the internet JUST FINE on sub 100mhz Pentiums and 486’s – that’s 100% horse manure. Again, that’s like the idiots who say tables render slower – or to be specific slow enough for it to even matter. When a 386/33 running IE 4 on windows 3.1 can render a table in a acceptable amount of time, claims that it makes a difference when your average smartphone is now pushing 1ghz – RIGHT.

Of course that the section has a nice illegible “infographic” to send people attempting to make sense of the article off into glazed-over land…

  1. Hiding background images – Not a problem with Opera mini or Opera Mobile; and frankly if the browser is too stupid to check CSS overloads before it starts rendering on a low capabilities device, the blame shouldn’t be put on the developer it should be put on the Browser maker… but of course since IE isn’t the media darling webkit and gecko are, we can’t actually say that without the floss fanboys shouting you down no matter how badly either browser handles things.

Of course, if you optimize those background images and/or use CSS3 INSTEAD… and maybe, I don’t know – set page size limits of say… 70k in 16 files as an ideal target and 140k in 32 files as your maximum allowable page size :smiley:

  1. More code – Lame excuse #7. A WELL CODED website should have NO extra HTML for mobile apart from MAYBE an extra DIV or two – and usually less than 2k of CSS for the media target. Of course 99% of what people vomit up any old way resulting in websites with their HTML to content ratios of 20:1 and code to content ratios of 200:1, that entire section ends up more FUD than fact. See my opening statement. For them to complain about code size when the page it’s on wastes 233k of HTML to deliver 48k of plaintext? Uhm… no.

  2. “unneccessary code removal” – If your targeting smartphones, whatever scripts you’re running should be good enough to work in Opera mini/mobile, Safari for iPhone, Chrome on Droid… or… uhm… who else supports media queries again? Oh wait, that’s right! NOBODY. Since said code SHOULD work in those browsers and/or be smart enough to adjust to it, just where’s the problem? Oh wait, SHOULD be smart enough, but with everyone doing copypasta of jquery idiocy without even bothering to understand how any of it works…

  3. Bad choice for multiple devices – REALLY? Again, the only things that accept media queries are… browses that support scripting. In this case the article is referring to old/outdated cheap phones that DON’T SUPPORT MEDIA QUERIES IN THE FIRST PLACE! Specifically, devices we can only hope will exit the marketplace soon as more people move to real smartphones and the prices start to get cutthroat (thanks Google! There’s a reason Apple’s afraid)

  4. “never ported” – The example used is typical of the mentality of people who do not craft their content properly. If you have to “spend time scrolling around” on mobile, the site is probably a navigational mess on desktop TOO. There’s this tendency to just slap content in the page any old way; If you build incrementally, which is to say use “progressive enhancement” – coding the HTML to be clean and presentable and functionally present ALL of the content and navigation, then ENHANCE it with CSS to make the layout, and then last and ONLY last start up the goof assed paint program to hang images on the layout – you’ll have graceful degradation for all those lesser devices!

But of course, most people sleaze out a picture that’s non-viable for web deployment in photoshop first, vomit up the HTML any old way slapping the content into it willy-nilly, don’t even BOTHER with things like semantic markup or separation of presentation from content, load up on jquery and other idiotic “frameworks” to bloat out the page into a useless train wreck – then wonder why they spend weeks debugging and end up having their site tank inside 6 months… with it NEVER working right…

  1. “needs” – The only “need” you should be thinking is navigation and content. ANYTHING else is bull. As such if you write your page with navigation and content in mind, you’ll be golden on all of them. THAT’S THE POINT OF HTML!!!

  2. “Mobile instead of responsive” – Complains about more code, then says “make two separate sites instead”? RIGHT. I’d buy that for a dollar. Of course, this section is card stacking because it’s comparing two unlike things, without figuring out if the destkop versions are even well coded compared to their mobile counterparts – here’s a tip; they aren’t. They’re chock full of decade out of date and half-assed coding practices, and that INCLUDES wikipedia. It also fails to list the URL’s tested. Is that the home page? A sample sub-page?

Let’s use the wikipedia home page as an example. The use of middot’s encoded in the markup means even the plaintext total can be called into question – but it’s 4.23k of plaintext. Even with the hundred or so anchors there is NO EXCUSE for the 46k of html – idiotic HTML with using STYLE to apply margin top, total lack of headings, static style and javascript inlined in the markup, meta’s nobody gives a flying fig about (author, copyright, publisher), LINK elements nobody has probably ever even VISITED (copyright and license for example), IE conditionals when NONE of their pages are complex enough to warrant their use…

You want proof of idiotic half-assed markup, HERE IT IS:


<div style="margin: 1em 0 0.3em 0; text-align: center; font-size: 30px; line-height: 110%; font-family: 'Linux Libertine', 'Hoefler Text', Georgia, 'Times New Roman', Times, serif; padding: 10px 0;">
<img src="http://upload.wikimedia.org/wikipedia/commons/thumb/b/bb/Wikipedia_wordmark.svg/174px-Wikipedia_wordmark.svg.png" width="174" height="30" alt="WikipediA" title="Wikipedia" style="font-variant: small-caps;"/>
</div>

BTW, if you don’t know what’s wrong with the above code, you have no business coding websites!

… and that’s without even talking about the APO train wreck, lack of proper use of heading tags on any page – it’s why I do consider Wikipedia one of the WORST websites out there from an accessibility standpoint…

Then it uses Yahoo and Youtube as examples as well? Have you SEEN their code? You end up wanting to slap them with a wet trout and then sign them up for classes – assuming you can find any educators who have a clue. (yeah, RIGHT)

Bottom line - the first few items ***** about image use/abuse that shouldn’t even be done on websites for ANY target in the first blasted place… The rest of it reeks of your typical “fixed width photoshop junkie” nonsense that just heaps onto my existing disgust with the current web development industry as a whole.

Really it sounds like the same bull you hear from the people who defend fixed width layouts to cover up their ineptitude. Next thing you know you’ll have your percenters chiming in with “this is only 1%, who cares” repeated for 100 different groups… do the math.

Though at least the article was good for a hearty laugh – particularly the bits that don’t apply to browsers that can use media queries in the first place.

  1. Bad choice for multiple devices – REALLY? Again, the only things that accept media queries are… browses that support scripting. In this case the article is referring to old/outdated cheap phones that DON’T SUPPORT MEDIA QUERIES IN THE FIRST PLACE! Specifically, devices we can only hope will exit the marketplace soon as more people move to real smartphones and the prices start to get cutthroat (thanks Google! There’s a reason Apple’s afraid)

This. Here. Is the reason we are stupid to build large sprawling “desktop” web sites and then think “oh, I’m going to add some media queries to make this ‘responsive’ to ‘mobile’.” Fail.

If you start out with your structured content, and style it fluid and basic, you will likely do just fine on ALL mobile devices (so long as they at least can deal with CSS2). Yes, this means your best shot is starting thinking about mouse-turd screens, crappy bandwidth and no cursor/pointer or fat greasy fingers at the beginning, and I’m not going to call that a luxury. It is likely a necessity, meaning if an existing and ginormous “desktop” site like Wikipedia wants to go mobile well, it probably needs to be re-written from the beginning. Since that would cost a lot of existing sites a lot of money, this is why they go for the “separate mobile site” idea.

Most desktop browsers (IE being the big exception) understand media queries just fine: so use those to set styles for desktop browsers, with larger screens, call in scripts, start downloading larger images.

I’ll disagree with crusty about lots of large images: if the site in question has large content images, and the site needs to work on mobile, someone’s going to have to decide if they are going to be cropped, shrunk, substituted, or something else. Example: e-commerce site with product images; personnel page with headshots (maybe not big, but lots of them); sites with diagrams, charts and tables; anything smelling like a photo gallery.

But you can’t start without them when they are part of the content like that. You’ll have to find a solution to the bandwidth and screensize issue first.

Easy enough. As long as Javascript is supported, the browser need only download a suitably sized version of an image rather than resize a large image. (See my previous comment).

So long as it’s a light and fast script (which, with vanilla JS, it should be, but I wonder if it impacts loading times horribly, if there are lots of images).

Again, though, it can be the other way around: hard-code the small content images. Users of desktops who also happen to have JS enabled can call the larger images instead. And the world won’t end for those of us who surf w/o scripts, we just don’t get the “nicer/larger” images. Mobiles don’t notice a thing, and don’t run any scripts for this. No browser/device sniffing necessary.

You’d need… imagemagick or similar who resizes your images not on the fly, but at the beginning (or you could do it by hand yourself if you want and there aren’t so many). Javascript runs that checks either screen size or whether the desktop.css is being called, whichever you prefer. If true, find document.images and dynamically change the src urls (to the larger ones you already made, sitting on the server).

That actually sounds like something fun to try for getting my JS skills up. It sounds incredibly simple, except for maybe I dunno, in order for the js to look for document.images, the document would have to be loaded, which means there were already calls to teh server for those images. So that would give desktop-users more HTTP requests than necessary…

It’s just one line of JS and, yes, the small image is displayed if any part of the process doesn’t work. Apart from the JS and a cookie (for caching the screen-size), it’s all done in PHP and htaccess. Speed-wise, it seems fine, but I suppose that it will vary from one server to another and one usage case to another.

  1. “never ported” – The example used is typical of the mentality of people who do not craft their content properly. If you have to “spend time scrolling around” on mobile, the site is probably a navigational mess on desktop TOO. There’s this tendency to just slap content in the page any old way; If you build incrementally, which is to say use “progressive enhancement” – coding the HTML to be clean and presentable and functionally present ALL of the content and navigation, then ENHANCE it with CSS to make the layout, and then last and ONLY last start up the goof assed paint program to hang images on the layout – you’ll have graceful degradation for all those lesser devices!

But of course, most people sleaze out a picture that’s non-viable for web deployment in photoshop first, vomit up the HTML any old way slapping the content into it willy-nilly, don’t even BOTHER with things like semantic markup or separation of presentation from content, load up on jquery and other idiotic “frameworks” to bloat out the page into a useless train wreck – then wonder why they spend weeks debugging and end up having their site tank inside 6 months… with it NEVER working right…

I really liked reading your post deathshadow60. I confess I’m one of those Photoshop junkies. That’s how I learned to design websites back in the early 90’s. Design it all in Photoshop, cut up the graphics, use a table to put it all into an HTML fixed-width layout. Then later on when I learned CSS I started trying to use CSS more to add style, yet I was still using tables. Then I started reading about semantic markup and how tables shouldn’t be used for layout but were meant for data and everything regarding the design of the site should be used with CSS, etc. etc. So I started to relearn how I designed websites again and did away with the table layouts. But I was still using fixed-width layouts beginning in Photoshop. So now that I’ve been reading up on Responsive Web Design and Progressive Enhancement and Mobile First…I’m realizing I need to relearn just about everything I’ve learned and rethink the way I’ve been designing websites for so many years.

I totally agree with the whole concept of mobile first because then we really rethink and focus on what really needs to be in a website as a whole. So many sites out there have so much on them just because there’s lots of space on the desktop. At least one of my strengths I would say throughout my web design career is that I’ve always designed with simplicity. My sites are usually clean looking and simple, not over cluttered or flashy. I always appreciate simple, clean, concise and to the point websites, yet that are visually appealing. But now I just need to relearn how to go about designing a site.

My thoughts have been should I just merely start out with just an outline of just the information and structure it in a meaningful way so it makes sense for example in a Word doc file. Then using that outline go to the drawing board and sketch some designs. I’m thinking I will still use Photoshop as a guideline of how I want the site to look, begin with the mobile size layout first, 320px and then move up from there and figure out how I want everything to resize and reflow as the viewport gets larger. But since I’m starting with mobile first I know my images cannot be too memory intensive and I need to plan my navigation out carefully since I only have limited screen space.

That’s kind of how I’m thinking I should begin to approach this whole new way of designing for THE WEB (meaning desktop and mobile). I’d like to see how others go about beginning the process of designing a responsible responsive web site with progressive enhancement. :slight_smile:

And deathshadow60 or anyone else, what is your opinion on the need for a separate mobile version of a web site. Do you think there is a place for some sites to have a mobile version? Or maybe a website should just be for the One Web which is really how we’ve been designing sites all along before the web was available on mobile devices. We didn’t or shouldn’t have had an IE version and any other browser version, or a Large screen version and a small screen version. Maybe if there’s some need for something particular on mobile devices should it just be built as a mobile app?

  1. resizing images cpu/memory. – sure, that’s true, which is why you shouldn’t be resizing images in the first damned place unless you’re showing JUST one image – in which case let the bloody UA handle it. Anything else should be a thumbnail and a launch… The only thing I can figure is they’re talking about giant idiotic banner image bull; Things that IMHO shouldn’t even be considered web deployable in the first place!
  1. Image downloads – because some nimrod thought monstrous images on the main page of their site was a good idea. The problem isn’t mobile downloading it, again it’s some photoshop junkie going “hey, lets make a fat bloated useless website nobody actually wants to visit!”

From what I gathered from the website, the author is talking about “liquid images” where you load big images and let the browser scale them down, processor power, like this: Rock On, Rock ON! : The Art of Rock Balancing

That is something I would avoid, since you can’t even resize viewports in mobile anyway, so you force the mobile user to download huge images and size them down, rather than just serving smaller images to mobile users or, if desired viewing at larger size, using the thumbnail convention.

  1. Hiding background images – Not a problem with Opera mini or Opera Mobile; and frankly if the browser is too stupid to check CSS overloads before it starts rendering on a low capabilities device, the blame shouldn’t be put on the developer it should be put on the Browser maker…

Yeah but blaming the browser maker doesn’t help the end user who is forced to use that browser. The article just points out the problem, if you are using big background images, or even just any old background image, that you are not showing to mobile, hiding it does not mean it will not download. So using media queries will not solve the problem of downloading the large image. We can argue whether or not designers SHOULD use large backgrounds, but if they do, they should know they will be downloaded even with media queries.

And deathshadow60 or anyone else, what is your opinion on the need for a separate mobile version of a web site.

It depends on what you want. I am on the fence with the adaptive thing. It’s a cool trick, but has its problems depending on what you are serving up to desktops. But a dedicated mobile site does allow you more content control. For example, you may want GPS capabilities on a mobile site, which you do not want on a desktop site. A dedicated mobile site allows you to not litter your code for desktop sites for something you only want for the mobile site etc.

Yeah but blaming the browser maker doesn’t help the end user who is forced to use that browser. The article just points out the problem, if you are using big background images, or even just any old background image, that you are not showing to mobile, hiding it does not mean it will not download. So using media queries will not solve the problem of downloading the large image. We can argue whether or not designers SHOULD use large backgrounds, but if they do, they should know they will be downloaded even with media queries.

But the whole argument that the author is making about hiding things using display:none implies to me, that they are still thinking desktop first. In the last chapter of Ethan Marcotte’s book on Responsive Web Design he makes the point that we need to rethink and design for mobile first. Begin thinking mobile first and then progressively enhance the site for the desktop user. Then we shouldn’t have to “hide” large images, correct? Am I understanding that correctly?

What the HELL he’s rambling on about with the table of images and sizes is beyond me.

He is talking about this: Fluid Images — Unstoppable Robot Ninja
In the article he is referring to this example page using that flexible image technique: A Flexible Grid

You will notice that when the browser is resized, the images are resized by the browser.
The table with images and sizes, that you are referring to, is comparing the size savings of simply sizing down the images in an image editor and serving them to mobile devices rather than forcing the mobile user to download the bigger images. The table demonstrates that the average size savings is around 60-70% which is alot.

He says: Using CSS media queries isn’t very bad to handle images and one might think hiding background images is a better idea than using labels. Well, the display:none won’t stop a background image to be downloaded on a mobile device. Other part to consider is that if you use CSS media query to replace the background image with a mobile version; in some cases it would actually download both images.

I don’t think his solution to that is making the argument that you shouldn’t think mobile first, but that you should create mobile dedicated sites. I am not taking that position per se, as I think depends on what you are trying to achieve.

In other words something I wouldn’t even SUGGEST trying to do on a website in the first place – unless you switched to a vector format to build that. Likely explains why said layout it broken (only showing half the menu elements) here at my normal DESKTOP screen width. “Non-viable for web deployment” images.

EXACTLY why the author of said article “doesn’t get it” – you hit it on the head they are thinking desktop layout FIRST and not content first. It’s the only explanation for the conclusions drawn which means they fail to grasp the POINT of HTML, or how to make fluid/semi-fluid/variable/responsive layouts in the first place.

Which makes it SOUND like the typical lame excueses used by the fixed width photoshop jockeys who honestly have little business designing websites in the first place… Not that their pretty pictures have ANYTHING to do with practical web development and quite often fly completely in the face of accessibility, compatibility, flexibility, and maintainability – Basically alien concepts to anyone who thinks a PSD is where you should start. Be fun when CSS3 support is complete and makes them obsolete and/or redundant.

I am honestly confused as to where the author of the article is promoting either a mobile first website method or reverse. The title of the section is “Hiding background images is a bad idea.”

The problem he is addressing is the tendency to use display:none to hide images WHILE thinking that means the image will not download, when it will. Some people who use the responsive technique DO think desktop first. In fact, the “think mobile first” only works if you have the luxury of building a site from the ground up in the first place.

A client might be very happy with their desktop version and bring you on board to design the mobile site. In fact, in the introduction of responsive design to the world, the ALA tutorial explains how to do that! It takes a desktop solution and makes it work for mobile.

Apart from the JS and a cookie (for caching the screen-size), it’s all done in PHP and htaccess.

Since I use neither of those (we’d either have Python or Perl running back here, and we like the speed of the actual httpd.config than .htaccess), I’d be interested in a pure JS solution where possible.

Or would JS simply be calling a whole new document with new src urls instead of manually changing image src urls?

The cookie’s a good idea. While I personally surf without them enabled most of the time, most people let them in.

And deathshadow60 or anyone else, what is your opinion on the need for a separate mobile version of a web site. Do you think there is a place for some sites to have a mobile version?

I can think of two scenarios for apart mobile sites:

  1. You’re a huge company with a ginormous steaming pile of garbage website that you spent bazillions over 5 years building. You’re not going to scrap it and start over just to fit on the mouse-turd screens

  2. Your web “page” is really a web “application” and the way it “works” on mobile on-the-go whatever makes little sense to how someone sitting behind a computer at a desk in a quiet area with a full keyboard would use it.
    …or, maybe there is no reason to have a “desktop” version at all, because it’s heavily involved in GPS and the user moving about. Like the live-action get-in-shape role-playing escape-from-zombies game we’ve been thinking about. The phone/whatever shows you a (google?) map of where you are and where the zombies are. You have to run to stay away from them. Literally run.

In fact, the “think mobile first” only works if you have the luxury of building a site from the ground up in the first place.

Indeed. In those cases I might push more towards “separate mobile site” rather than throwing a steaming pile of bandwidth-eating gremlins at poor innocent mobile users : )

Really, I’m constantly surprised how large wikipedia is. What I see on my screen doesn’t appear to need much (editing capabilities aside). A shame.

I look back at stuff I did just two or three years ago, and go “what was I thinking” – you’ll always have the lame excuses of “I have deadlines”, but if you don’t keep your skills sets up to date, deadlines will be the least of your problems. Tehcnical fields are fast moving and always changing. As my grandfather used to say, the day you think there’s nothing new to learn, is the day the rest of the world leaves you behind.

See, I disagree with the notion of ANY “target device” first… as that’s not what HTML is for; and CSS is only as good as the HTML it’s applied to. HTML is for saying what things are so the user agent can best determine how to show it. CSS is for targeting specific devices with appearance enhancements… and was SUPPOSED to do so all along with the MEDIA attributes – see ‘handheld’.

But handheld makers didn’t pay any attention to that because people were still just vomiting up ‘for screen’ without even bothering to use media attributes properly. You don’t get the people making sites doing it there’s no reason for niche browser makers to even look at it. In many ways media queries are just a trick to get browser makers and site makers to actually get off their duff’s and finally start targeting devices by capability.

This is very VERY true – people love slapping more and more stuff into pages until it reaches the point you can’t find anything. Concepts like “information overload” going right over many developers (and owners) heads.

See the opposite problem of the client who doesn’t know what they want on a page – clients who want everything possible stuffed into the home page… in all things there must be balance.

See, to me that’s a flawed approach – because you’re still designing to a visual target instead of making the site progressively. Semantic markup, layouts in CSS, THEN start up the paint program to make the graphics you’ll hang on it.

I could see rare cases where customizing for a specific device like mobile has advantages – I just have a hard time believing it’s worth the extra hassle of basically maintaining two copies of the same site… or three copies… four copies, five copies – when the next flavor of the month for mobile comes along. I mean, WML, HTML+CSS3 for iPhone, HTML+CSS3 for droid… HTML+CSS2 for non-droid non-apple phones that aren’t WML capable… where do you draw the line?

… and if I’ve learned anything the past decade of doing websites, the more vague your targets the better things tend to work out in the long haul. Media queries by width are perfect for that – media queries detecting flaws in the queries to target specific devices and dicking around with javascript? Not so much.

It depends on the website.

And that isn’t just a trite way of avoiding the question.

There are some websites that have particular features that are likely to be wanted by people on the move. A website giving train or flight times, for example, can have a huge range of information and capabilities, but what people who are accessing the site on their mobiles really want to know is … when is my train/flight due? When is the next one to (wherever I’m going)? So you can sensibly have a cut-down mobile version of the site that isn’t just a reformat of the full desktop site, but genuinely is a mobile version, just giving the few options that people on mobiles are most likely to need, giving them a very fast and user-friendly browsing experience. Of course, you need to give a link to the full site, and not force them to use the mobile site (yes, Facebook, I’m talking to you) so that those with cleverer phones who do want to access other parts of the site can do so.

Other websites won’t have such a clear-cut divide. It’s hard to see how a news site, for example, would differentiate between content for mobile browsers and desktop browsers – news is news, and it doesn’t matter so much whether you’re sat at a desk or on a bus. You might want to offer a mobile stylesheet, or some server-side wizardry that gives a slimmed-down page without all the cruft and fancy-pants scripting and artwork, but a lot of that will depend on the resources available and the typical traffic levels, as to whether it justifies the additional development time.

As for mobile apps – I’m not a fan. Sure, there are a few that are really good, but most of the time they don’t offer anything much that a decent mobile version of the website couldn’t offer, and they create all sorts of headaches. Which handsets/OSs do you support? There’s an awful lot of coding and learning to be done there, and at the end of it, you’ll still be locking out a large number of phones that could access the content perfectly easily if it was on a website. My phone is a pretty decent device from a mainstream manufacturer, and when paired up with Opera Mobile can cope with most things, but there are a lot of apps out there that are just not available for it.