Swiping the screen mimic the same action as reading from an actual newspaper. Which is something I like. But not too sure with mobile chrome.
–
SimonTeoJul 31 '13 at 10:45

This is very actual question for me. My boss wants to make a site with swipe for navigation pages. And vertically and horizontally.
–
egor7Jul 31 '13 at 12:26

Like Revolt said, both seems like a good idea. You can detect mobile chrome users and serve them the traditional button version. Although I'm not certain you'd want vertical swipes at all as thats how people scroll.
–
jmathewJul 31 '13 at 20:22

Is it possible for users to access the other articles in any other way? I'm considering whether there are accessibility limitations for users with restricted motor skills
–
micapAug 1 '13 at 9:26

7 Answers
7

I'm a casual mobile browser. I'm in front of a computer 99.9% of the time, so I'm really only mobile browsing when I don't have access to a computer and I absolutely need to do something online.

Only one time have I used a website where I had to swipe across to get to the next 'section' and it drove me absolutely crazy. A good rule of thumb: don't make me think! I understand mobile devices are much more dynamic than a desktop environment, but the closer you can make my mobile phone experience to a desktop one, the shorter the learning curve and the better experience I will have.

Besides, if you need directions to explain how to swipe when in reality you could just use a button, keep it simple and just use the button. The website I referred to earlier had to explain how to use the website in big letter: "Swipe to the left to view the answer to your question." In a situation like this, a button which said "show answer" or better yet was on the same screen as the question would have been ten times better.

Firstly, you don't want to do anything that interferes with the browser's native touch events. If a browser relies on the user swiping from the edge of the screen to change tabs (as per more recent Android browsers), your functionality could potentially clash. Users who try to do the one will end up doing the other, and it could be hard for users to keep track of whether they're moving between tabs or moving between articles. Gestures like this typically work on an application level - by adding your own, you could be creating interaction problems further down the line.

Secondly, this isn't common behaviour on the web, so you'd have to signpost it. This means using up space and drawing attention to something on the page, which is obviously something you want to ration as far as possible.

Thirdly, is this even useful? Is there actually a logically defined 'set' of articles to be traversed through in order? If they're of different topics or categories, swiping blindly is pointless. If they do make sense read in order, why not present them on scroll rather than rely on a UI neologism?

Swiping to view another article is a great way to use the web. I absolutely hate clicking tiny buttons to switch to another article, when swiping would be much more appropriate. But for browsers that swipe does something else, you could always account for that and have buttons if it's that browser, or have buttons either way but also swiping available.

I often browse websites from my phone - as so many of my friends, usually picture sites, and clicking on a button is very annoying, when you can accidentally click the picture and open it up bigger. A lot of people that I know feel the same way.

The use of gestures on mobile is not a new thing, but as you mentioned, gestures on a site can clash with the browser or the app loading that site. Reaching the end of the news and scrolling down for "More" in order to move on to the next piece of news might be a good alternative, but only if the user actually reads the whole piece of news (and if you don't have other article suggestions and/or comments, ads, etc at the bottom).

In that respect, and, if the news are not particularly linked to one another, I wouldn't recommend adding the page-turning feature with a swipe (at least not without a button explaining where they'll go next). Another option is to display a button with "Next up:" as Forbes does whenever the user stops for a certain amount of time or reaches the end of the article.

Although gestures in this fashion are sometimes used, they are more so on native apps, opposed to a site. This is because not only is performance sometimes an issue, but as you rightly pointed out, web browser often come with their own navigation gestures. Not only does chrome use swipe, but safari in iOS7 also uses swipe to navigate back and forward. Because of this I would avoid any horizontal swipe gestures on a mobile website.

Also, swiping in a webpage isn't exactly common, and thus not really in the users mental model, this might just be seen as a gimmick, and not an efficient method of navigation. You would have to tell your users to swipe.

This combined with the 1st point would suggest to reserve swipe for use in a native app.

Adding a swipe functionality is useful in a native app, but not entirely so on a mobile site in my experience. By adding a swipe functionality on the web where your site is viewed within another app (in this case, a browser), you don't have full control over how it will work.

I would add sticky prev/next buttons somewhere visible, but not in a place that could be accidentally clicked. Related articles could be placed at the bottom of the screen when the user is done reading the article and a prominent "home" could cover the use case of someone wanting to just reset the state of the site.

As a user, I abhor the swipe-to-change-articles pattern that has been emerging on websites. It's cute, it's clever, and it conflicts with typical touch interactions. I've had it conflict with a less than perfectly vertical scroll gesture, which translated to a page load.

In an app, this is less of an issue as it's simple enough to swipe to go back - but on web sites this translates to un unintentional page load, wait time, back button or swipe back, and frustration. It's an attempt to replicate native app interactions while lacking the grace and speed that apps offer and results in a poor experience.