Tag Info

Though the left and right icons would give information that you can continue scrolling, another option is use a layout where only part of the images are visible and the user will have to scroll to the right to see them as given below: Another approach which I am not a fan of would be to use a horizontal scrollbar at the bottom which informs the user that ...

You could try something like this: Note the line breaks at left and right as well as the cut off text. Omit the left line breaks if nothing to swipe to at left. Even the line breaks alone would be a very simple cue that would be better than nothing if the cut off text is a problem to implement:

One of my favourite soluion for this is pulse's: on first run, display an overlay with help: you can show this once, and never worry about it again. Of course it has downsides as well: user forget it quickly, or ... But you should thick to the Android 4.x design conventions, section swiping between tabs. Also a good idea would be something like the ...

This isn't a new design pattern. It's a carousel. But, as you say, it does seem to be more popular on mobile as of late. The main benefit is that it keeps the user on the page while giving them the ability to browse more content. Does it work? Sure, if you want to browse through some more secondary information in a small space. That said, there will be a ...

You should use neither of them. When you are referring to vertical content, you should say "scroll up" or "scroll down". Vertical content movement has been used for decades now, and there is no good reason to change the terminology. Yes, you are swiping, but you shouldn't refer to how it is done, just what you want to achieve. We say "click on X" not ...

Yes. Apple use the terms "swipe up and swipe down: http://www.apple.com/iphone/iphone-5/tips/ The Apple HCI Guidelines may be of use here in conveying defined actions: On avoiding redefining gestures: ...

Don't create a dead zone Assuming you allow both horizontal and vertical swipes and only horizontal and vertical swipes then I see no reason not to simply say that if your swipe is within 45° of horizontal treat as a horizontal swipe and within 45° of vertical, treat it as a vertical swipe. I'm not sure there a need for a dead zone on the middle where it ...

The biggest risk with these isn't that they won't figure out to swipe, it's that they won't realize there are other images. Use a generic page count bubble, and trust them to figure out the rest. download bmml source – Wireframes created with Balsamiq Mockups

Horizontal scrolling has become cumbersome in comparison to vertical scrolling. With mouse input horizontal scrolling is often better supported by the hardware (scroll wheels). With touch UIs horizontal scrolling is just as easy as vertical scrolling but mixing the 2 is problematic when it's not clear that part scrolls which way (could sure use some visual ...

From a user experience point of view inputting information would be easiest, if the most used keys are in close proximity, and common keyboard combinations are next to each other. While the DVORAK layout is efficient for typing with ten fingers that lay on the home key row and thus have fast access to the most commonly used letters, the same logic does not ...

I'm a massive Swype user in 2 languages (Hebrew & English), and I just completed an article that will be published soon on UXBooth about the challenges of typing for people who lack the use of an arm or hand. The thing with Swype is that it works on memory more than anything else. That's why the QWERTY is the only real solution...theoretically there ...

The first sentence in your question is incorrect. QWERTY was designed to avoid conflicts between the arms on a typewriter, by making the keys used alternate mostly between the keys on the left and right sides. And all newer keyboard layouts use this, as it makes typing faster than say an alphabetic layout. But the swipe keyboard which is a continuous ...

It is never wrong to give users cues on what you can do on any device. However, it could be annoying if they are present at all times. I would make the arrows visible when you first access the gallery, and then dimed out after two seconds. The user knows that there are controls if they want to use them. If the user swipes images, the arrows wouldn’t appear ...

Android by convention now uses Scrollable Tabs for this. Scrolling tab controls can contain a larger number of items than a standard tab control. To navigate to the next/previous view, swipe left or right.

Is there a way you could indicate this without displaying a specific image? One option is to position the content partially off the screen so that the users understand there is content to be scrolled to. Another approach would be to build it into your content/visuals. So you could introduce the concept to the user and then they will be aware to swipe ...

I guess you could overlay icon representing the gesture, e.g., those of P.J. Onori: The overlay should fade away whenever the user swipes.

I would say limiting the range to be ±20° from horizontal or vertical would be a good starting point. I'd then run some tests to see if they work most of the time. Much less than this and you'll be rejecting too many swipes all together, much more than this and you'll be mistaking too many (vertical for horizontal & vice versa). One way of implementing ...