Tag Info

Hot answers tagged

14

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


4

An important factor to consider is the audience of the application (or website). It seems that typically, many younger audiences (or those familiar with touch devices) are used to swiping across carousels. If you look core applications of iOS (and I'm assuming Android as well), you'll find that carousels support swiping to switch to the next image. However, ...


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


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

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


3

Indicator dots below them. Part of the next image peaking in from the sides. Left / Right arrows. On load have the first image slide in from the right. Or just use a picture of John Stamos, it fixes everything.


3

In physics this would be a case of 'dry friction'. The velocity should decrease linear in time. The linear factor is the coefficient of kinetic friction. I suppose you want to experiment with different values there. If velocity is linear in time, then scroll position is quadratic.


3

Changing chapter is a major operation, which should be handled with care. A swiping motion changing chapter is in a way careless, since users who accidentally makes the swiping action will be completely lost. Therefore I thing your best option is to use a standard hamburger menu containing the chapters and possibly subchapters as well. download bmml ...


3

I suppose the first point to make is that you shouldn't depend on invisible interactions to accomplish anything. The example made in virtualnobi's comment of iOS's swipe-to-delete gesture is a good example; Mail items etc. can be deleted the long way by choosing Edit, then checking the items you wish to delete, then choosing "Trash"/"Archive" at the bottom ...


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

I would: cut off the last column of thumbnails as mervinj suggests it, to show that there is more to see make the grid of thumbnails slightly slide from right to left when page is loaded, to indicate the user what part of the screen moves when swiping.


2

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


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

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

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

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

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

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

Why not a separate button or a press and hold to show the main menu? Are they two left swipes close to each other? If so, it might be easy for the user to trigger the wrong one. You have to remember that touch gestures need a very big margin of error.


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

Just say swipe. No one ever looks up for information. Think about the worst case scenario- fraction of a second lost if they make the wrong choice.


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



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