This is somewhat to my annoyance, because I frequently find mobile-friendly pages less friendly on mobile than desktop pages.
Specifically, mobile-friendly typically disables zoom, so that zooming can't be used to choose text size or to scroll through the page at a higher rate. Instead, everything is reduced to a kind of very long ticker-tape, where if you're deep into the page, you need to scroll many, many times to get anywhere.
Alternatively, you get a page broken up into expandable sections, like mobile wikipedia, where it's very tedious to visually scan the page. Wikipedia is one of the best examples of a site where I prefer the desktop page on mobile.
Another issue is limited functionality. Sites with complex forms typically present a hobbled or otherwise limited, basic mobile experience.
That's just a stupid choice made by (so many) web developers. I checked a sampling of my own sites with Google's tool and they all passed as mobile friendly, but none of them disable zooming. (HN fails, of course.)
What's a good way to easily call up bookmarklets on mobile? I use short, unique bookmark names. If you know of any better method, I'd love to hear it :)
This is a well known and hard to fix bug that I've been following. It affects other websites too, typically forums and other pages with large tables and short paragraphs of text.
> That's just a stupid choice made by (so many) web developers.
Sometimes it's stupid, sometimes not. Disabling zoom removes the 300ms delay added to most interactions on mobile devices [1]. You can alternatively use fastclick.js [2] or swiftclick.js [3], but that's an extra lib/http request to load.
Which is just what I do. Disabling zoom is one of those nonsensical practices that spreads as web "developers" copy code from each other. I suppose there's a use case for it somewhere, but its main purpose is to remove choice and make sites harder to use.
EDIT: Actually I also include the initial-scale as in the comment below.
Huh. I only have the initial-scale entry, and I think that my sites always show up with page width matching device width as a result. Is there something important that the extra width specification does that I'm missing?
Why do you feel you need to prevent it? As a user I'm pretty sure I'd rather just zoom back out if I want to, or use a browser that didn't do this if it really bothered me. But not having the option to zoom is annoying.
As a user I find having to do this incredibly annoying.
Maybe my phone is just a little zealous with the zooming, but it loves to zoom into the top-left corner of the textarea. The first thing I do uses three pinches' worth to zoom back out, and if I ever have to move the cursor and thus touch into the textarea again, it zooms in again.
As a front-end dev, I'm really curious about this. If you're using a native mobile app, do you expect the UI to zoom in on text inputs as well? Is that a common UI behavior?
I've always been a fan of moving mobile web towards the standards and behaviors of native apps which generally did not require zooming to get tasks done.
Yes, it does happen on some text inputs, it tends to depend on relative size (for example, I recall zoom in landscape but not necessarily in portrait, etc.).
Generally I welcome it, because I can click on the teeeny input field and have it come "closer" to me for editing then get out of the way.
I disabled zoom on a web property i own because it played havoc with a `position:fixed` top header. When you zoom in, the top header scales up as well and covers the entire content.
This may not be within your power, but you should consider removing the fixed header instead. They take up precious screen real space on already small devices, usually in the name of branding.
I disagree. People needs to have fixed headers that auto hides on scroll down and auto shows when you start scrolling up.
Due to that low screen real estate there is an extreme amount of scrolling down, whenever you need that header to navigate you end up needing to scroll a long way to the top.
Links from the bottom are easily forgotten about when you're half or 80% of the way through an article. Likewise follow you around widgets are a painful annoyance 100% of the time.
I absolutely despise the fact that all sections are collapsed on load on mobile. That means "search in page" is broken and Wikipedia without search in page isn't Wikipedia at all.
It's iPhone's number 1 unknown feature. I've been using computers since I was two and it took me more than a year to find this: just type in the search term in the safari search bar, then scroll down in the autocomplete results (without hitting go or enter). It'll come up after autocomplete and history/bookmark matches - and it's been there since at least iOS 6.
Before this, when iOS had separate search and URL boxes, typing in the Google search box would offer a prompt to search in the page since ... maybe v3 was it? Hence why that moved to the URL box when the boxes merged. Yes, it sucks.
The other one in a similar vein is pulling the search results down (before typing anything) to get 'Request Desktop Site'. It took a while before I stopped having to pause to remember where that was each time I wanted it.
What mobile device is wikipedia designed for exactly? Its such a small and spartan design that it seems like the kind of thing you'd see on an early 2000's site when stuff like Palm and Windows Mobile came out.
Why aren't the sections already opened by default? Why aren't there any images? My phone out-performs desktops from just a few years back. I don't need this super-minimalist wikipedia. I just need something that's slightly more responsive because I don't have the horizontal space to handle all of its columns properly.
> Why aren't the sections already opened by default?
If sections are all expanded, one has to scroll an unknown distance to get to the section one is interested in. If sections were to expanded by default, it would probably be better to not make them collapsable at all and instead include in the mobile layout the table of contents found in the desktop layout. However the table of contents uses anchor links which may be less usable in a mobile context (easier to lose your sense of place, a user's desire to not click links that may load a new page for performance and/or bandwidth reasons).
I agree that an "expand all" option would be a useful addition, I didn't follow the link in another post that presumably explains why one isn't being added.
That's what anchor tags with an id tag are for, so it scrolls to the section you want. Which they use on the desktop but, wait for it, you can guess what's coming here, not on the mobile site...
How often have you been able to browse the content you want just by the section heading? They are somewhat informative, but I find it much much faster and easier to scroll through the sections skimming the text and images.
Collapsibility means requiring high-precision clicking, instead of low-precision sweeping of the finger.
I don't spend a lot of time looking at Wikipedia on my phone but I'd have to say I do like the collapsed section design. I rarely want to read an article top to bottom and having the collapsed sections makes it very quick to view just the section(s) with the most promising heading.
> a user's desire to not click links that may load a new page for performance and/or bandwidth reasons
I see your point in general, but even the average user browses Wikipedia often enough to realize they're always in-page links. If only by accident, I hit the wrong link often enough :)
Imo the Wikipedia app is much better, and addresses all those points. I think it's been getting the main development time lately, because the previous app was ancient/broken and so they tasked a team with redoing it. But now it's ahead of the mobile site, which was previously ahead. I'm not 100% sure why they actually need the app vs. just a good mobile site though.
I'd wager most people agree with you, despite the majority opinion you see on HN. User engagement levels have been higher on every mobile-optimised site I've worked on, when compared to mobile users looking at a desktop version.
This might be because any mobile-optimized site that tracks user engagement levels is more likely to be a good mobile site. People on HN don't say that all mobile sites are bad, just that a lot of bad ones are worse than desktop sites.
I'd really like to be able to collapse sections from the bottom of a section, rather than scrolling upwards frantically trying to find the header so I can re-collapse it.
Sometimes I use the mobile version of Wikipedia just so I can read text that's pleasantly formatted with limited line widths like almost every printed or post-1990's digital text. The wide-as-possible lines, which sometimes make me resort to putting my finger on the screen to keep track of what line I'm on, are a ridiculous legacy.
This. I can't believe Twitter actually does that; it's uber painful to browse photos in tweets, which unfortunately I needed to do quite often recently.
I think it has to do with a kind of counter-purpose development where the people who create the devices are trying to create a good experience on websites and the designers of websites keep moving the goalposts.
Perhaps it's time that web designers are subject (or subject themselves) to a similar set of human interface guidelines that app developers are subject to, for instance.
It's a shame the semantic web hasn't taken off. Yeah, it's neat what you can do with a webpage these days, but 99% of the time, "web design" today sucks to the point where I'm relieved when I end up on an old "black text, white background, underlined blue links" site.
I would love to replace web pages with an RSS reader type program that just displays content and navigation in a legible format.
But with all the fancy stuff that's being added on and on, it seems like the best we're going to get is browsers with a reading "try to unfuck the formatting" button once you've gotten to the content you want.
It's so odd that gopher sounds like a fresh solution to this over-proliferation of design. I wonder if there's potential for a modern version.
I guess the problem is our attention economy. As a designer your job is to hold attention, and this drives design trends so far from competitors that usability suffers.
Although we do see that people love the uniformity of the big social networks. I find Twitter's clean timeline much more helpful than visiting individual websites.
I wonder if we'll continue to see a trend of the web separated into app-level experiences & information silos. I'm thinking there's a big void in the market for something like squarespace meets tumblr.
The problem is that we use the internet for more than just sites, we use it for web applications now too. Making sure the site works without javascript is usually possible, but often much more work. For sites that are presenting information to me, or where I'm interacting in a minimal way, a well defined static interface is preferable. For complex applications, I would definitely prefer a more rich experience than is provided by HTML+CSS and HTTP (although with HTML5 it's not as bad as it used to be).
I recently realized how often web developers defending the status quo have internalized a circular reasoning regarding "what the Internet is for". So the Internet is for web applications now, so we need to have all that stupid crap in CSS and dump metric tons of JavaScript on everyone. But if you suggest that maybe we should then drop the content/layout "separation" and make CSS actually nice to work with, the same people will tell you that "web is for documents", so what we have now is good.
I'm beginning to wonder if we shouldn't split the Internet into two - one for cloud apps and another for content - and design the tech stacks accordingly.
I'm fairly sure you're just conflating two separate opinions from many, many different people, and using your personal biases to crap on that conflation, so that you can bolster a fairly weak point.
Definitely true. But I've noticed that web applications are usually not awful design offenders.
An unusable webapp frustrates users and drives them off, but an informational page trying to be some kind of 1920's prediction of a futuristic interactive magazine is annoying at most. I can always figure out how to read the text, so I just put up with the stupid design.
>In my opinion, all sites should be usable like this. Styles and scripts should merely be enhancements, not requirements.
As much as I agree, many sites are not usable like this :(
And there are aspects of CSS that I do want to keep, like making the navigation lists properly horizontal (and in some cases, nested with hovers). Without CSS, you sometimes have to scroll through several pages of expanded out header/navigation before you find the content.
I agree. I switch to the desktop version whenever I can. And if I can't, I tend to avoid the page. But the reason is mostly different: Often I know the desktop version and offering me the mobile one means that I need to relearn where stuff is. I guess, that is different for people who go online on a mobile device, only.
Older versions of iOS had a bug where zoom levels would mess up when device orientation was changed. For a while disabling zoom was a reasonable alternative but it's not justifiable anymore
On the other points I think it's because a lot of companies are still treat their mobile UX as an afterthought, even the ones who wouldn't like to admit it. It's a lot of work to handle all the variables well and few are willing to commit the resources in the right places early enough to implement a good mobile experience without awkward technical workarounds later.
I made my legacy web pages (one almost 20 years old and including an image map) mobile-friendly by google's standards simply by adding a viewport. This had no impact on the usability of the site on a desktop, and only slightly changed the formatting (for the better) on my iPhone. I don't think that what Google is mandating here is a separate, crippled site for mobile devices.
I find mobile sites are often tailored towards use cases that are very narrow and specific to what the site operators believe are the reasons a person would visit their site.
This sort of thinking leads to sites highly tailored for mobile that ignores a segment of their audience.
Specifically, mobile-friendly typically disables zoom, so that zooming can't be used to choose text size or to scroll through the page at a higher rate. Instead, everything is reduced to a kind of very long ticker-tape, where if you're deep into the page, you need to scroll many, many times to get anywhere.
Alternatively, you get a page broken up into expandable sections, like mobile wikipedia, where it's very tedious to visually scan the page. Wikipedia is one of the best examples of a site where I prefer the desktop page on mobile.
Another issue is limited functionality. Sites with complex forms typically present a hobbled or otherwise limited, basic mobile experience.