Tag Info

Hot answers tagged

13

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 ...


9

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:


5

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 ...


3

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 ...


3

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 ...


3

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: ...


2

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 ...


2

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


2

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 ...


2

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 ...


2

I don't think showing the buttons for a short time and then moving them is a good idea. You might put these (unlikely) options in the menu (always available in the menu) but have the buttons completely gone once an allergy is specified. But it seems to me logically inconsistent to allow an allergy to be specified and be able to specify "No Known Allergies" ...


2

The first left swipe (activates right menu) can be set to start from the edge of the screen. like the side menu in facebook. The seocnd left swipe (Activates actions on an item) can be set to start from anywhere EXCEPT the edge of the screen. Just like when you're moving about a zoomed in page in a browser


2

Vertical scrolling is the "natural" way to see additional content in the same document. Making horizontal swipe go to another page in the same document would be confusing for most users. Perhaps the most straightforward option is to use nested lists. First the user chooses a team, then the user chooses a document, and finally the user sees the viewer. ...


2

You'd need some sort if indicator saying that the bar is swipe-able to begin with, for example indicator dots below, or having the red/green peeking in from the left/right. See this discussion: best image to indicate swipe left right. With that indicator in place I would personally just use more paper prototypes to display the different states But to answer ...


2

Basing your apps functionality on what the user tells you they need is considered a wrong approach. In UX it's widely believed best practice to observe your users' behavior and base functionalities on that. Users don't want what they tell you they want, but want what they don't know they want. As for swipe gesture or just buttons, there isn't a clear ...


1

Please make sure there is a signifier that shows the user that such a feature exists. I used a favorite app of mine for years before I accidentally discovered there was a side-bar menu available with a swipe gesture. I think the jury is still out over the effectiveness these menus, especially on small mobile devices, since horizontal space is at a premium. ...


1

The advantage that I can think of with the swipe is that it's easier to get to when using one hand (either hand). A button needs a more precise and more specific tap that may be a bit more awkward on some devices in some situations. But you of course have to weight that against the con you found with it opening when a user intended to use a different ...


1

You can use a sliding bit of paper to model the swiping behavior. Once the user has begun the swipe, pause the prototype (i.e., say "hang on a sec") and put whatever you want "under" the sliding bit of paper. Make sure the background behind the swipe paper has a bit of green on the right and a bit of red on the left, just enough for the user to notice when ...


1

You could move any actions that are performed frequently/infrequently up into the action bar, for example adding a + button next to the overflow when you are on the allergies tab. Anything you don't use often can be shifted to the overflow. I would leave the No Known button where it is, but move the Unknown to the action bar too to allow for quick sorting ...


1

This probably isn't as good an idea as it sounds. 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 ...


1

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 ...


1

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 ...


1

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 ...


1

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 ...


1

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.


1

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 ...


1

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.


1

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 ...



Only top voted, non community-wiki answers of a minimum length are eligible