Hot answers tagged

9

While space is an obvious part of the equation, it's not the main one, you could simply have a sliding physical keyboard just as previous generations of smartphones and be a happy camper. However, physical keyboards had several issues: smaller keys that on screen keys structural weakness short lifetime (the flex connector and pieces of sliding keyboards ...


8

What creates confusion i.m.o. is the back and the close button being on the same level in the visual hierarchy where as they act on different levels. Wouldn't it be more clear when the close button is visually more separated from the back button? I would not recommend moving the previous/back button and replace it with a close button, because now the user ...


8

What caused this decline in the use of physical keyboards? The iPhone What is the impact on the UX of mobile devices? This is a pretty deep question and is tough to answer objectively. I would argue that dropping the physical keyboard was a net gain. That the benefits it brought far outweighed the usefulness of the physical keyboard. As others have ...


7

Forget mobile breakpoints, there's no phone and tablet sizes outside marketing. Breakpoints should follow the content, not the screen size. As a simple example, let's consider the menu: Home | Products | Contacts Do you think you should ever provide a mobile menu? Do you really want to stick three elements in a hamburger menu? They can probably fit ...


7

I would encourage you to consider whether a cancel button is truly necessary in this situation. What is the likelihood that the user will wish to cancel their entire submission? Is it more likely that the user would wish to change pieces of the submission more easily accessible using the back navigation rather than the entire submission? Will other ...


6

I find the second version confusing. I think that the same button should be placed at the same place in the different screens. But I have to say that I find the first option confusing as well. To me, the button on the left should go back and the button on the right should go forward. Maybe it is a good idea to give us some more information of the rest of ...


5

Here is a good article that explains the problem and give some tips on how to solve it. Making Hit Areas Sufficiently Distinct Also there is a good read by nngroup Beyond Blue Links: Making Clickable Elements Recognizable About this problem in the desktop platform, there you can find some more tips on how to approach this issue. TL;DR Use some kind ...


5

The good and bad of bottom nav Bottom nav was a great idea when Apple first came out with it. Steve was laser-focused on one-handed usability. The bottom nav was designed to accommodate fast and convenient view switching where the mobile use case seemed to demand it. Unfortunately, bottom nav is a hierarchy nightmare when used for an app's main info ...


5

Short Answer: After the sign up (You always want the user to first get on board with the application, Rest come later!) Long Answer: Simplest thing to do is observe how already established and successful applications do it. For example, Pinterest, Twitter asks user to select "area of interest" after signing up with the application. If user is on-board ...


4

Generally you want to reduce any initial friction, especially in B2C apps. So you ask for as little as possible at the start and make sure the user gets to experience the core value as quickly as possible. Said that, there's one important consideration. Sometimes you need a bit of extra information at the start to deliver great value and experience. For ...


4

Question 1: Back button is totally needed! There is a few reasons for this. With a back button, you ensure consistancy accross devices and browsers. Each browser could have the button in different places, different shapes or even hidden in a submenu. Essentially, you maintain control of the experience. Not all user uses the back button in browser, myself ...


3

If it was me, I would just have it as an option in the settings. The user can choose the time of day they'd like to be reminded, or whether they want it to be random between some set hours. After all, the user already knows that the Abusive Gym Reminder app is, well, going to annoy them with reminders, so why not empower them to choose when? This would ...


3

I suppose there are 2 routes to approach this: Generic Approach - Work out the most common times people go Gym and use that Custom Approach - Ask or work out the users PERSONAL routine Generic Approach - This is the simplest approach, but will be tough to define as it would need to be a one size fits all. For example, I have the new version of ...


3

I think you should reconsider the bottom navigation: Bottom navigation is very well established in mobile apps, far more so than top navigation, and there is good reason for this. In most cases i disagree with your point about incorrect information hierarchy - the content takes prime visual position in the interface, and the navigation is simply a tool for ...


3

Good UX would be to use the guidelines for Android apps, which would be to NOT have a close button. But instead using all the app management solutions provided by Android OS. Android apps generally do not have close buttons. But instead have a designed interface that developers can use which makes the apps appear integrated in to the operating system and ...


3

That sounds like 6 different apps to me. My mental model of an "app" is more focused than the use case you describe. Pretending I'm the target audience you mention in the comment on your post, I would likely think "I need to open my photo app to annotate this image" or "I need to log my hours and check-in to my work site on my timesheet app." Folders on my ...


2

The fact that this is an audio stream makes a difference to the user. If the sound is suddenly unwanted then you want to allow the user to kill it as quickly as possible, and the [X] is the most likely option to be used in this scenario. [X] is definitely a close / remove action, so it won't be a surprise that it immediately stops the stream.


2

When the item is being dragged, the panel could hide itself or move out of the way. Check out these demos from Codrops for inspiration. (Your interaction would be the opposite of most of these, but the principle is there.) Or, the panel could be on the top or bottom on mobile, instead of the side. This might be even more effective if the content is ...


2

One line answer to this is the Usability of choosing that position. When you hold your mobile in hand, your thumb immediately gets into action and the bottom position is easily accessible to it than the top. In the era of large screen devices it's difficult to hold the phone in hand and access the navigation placed on top. Which is why Apple has changed ...


2

There is little evidence of any specific apps or design features on mobile devices designed to reduce the risk of RSI. However there may be features that reduce the risk without that specific intent. There's a nice article in a medical journal from a few years ago interviewing an industrial designer at RIM (remember them?) which goes through some of the ...


2

It's all in the convenience. Having everything in on place can arguably be considered more secure (Example: 1Password), but mainly, it's so you're not limited by the physical constraints of carrying everything. An extension of the Mobile Wallet are the apps that collect and store all your card numbers (like Air Miles, Grocery Points, Movie Points, etc). I ...


2

Bootstrap, a very popular framework, uses 4 breakpoints, as below: /* Extra small devices (phones, less than 768px) / / No media query since this is the default in Bootstrap */ /* Small devices (tablets, 768px and up) */ @media (min-width: @screen-sm-min) { ... } /* Medium devices (desktops, 992px and up) */ @media (min-width: ...


2

It's best to ask for the info you require from your users to access and start using the app. The user shouldn't be blocked by an unnecessary question at any point during use of the app. Remember mobile, with slow connections and small screens and consider the impact of complex forms in this context. There are a couple of ways you can do this: Ask for ...


2

I'd recommend against using a table in this instance. First, it's a mobile version which makes the horizontal space restrictive: there'll be lots of wrapping occurring inside the cells. Second, it seems like comparison of tasks (rows) is not your main goal so it's not necessary to make it all that compact. I'd suggest you use a list of cards, each ...


2

In general, it is useful to have shortcuts on desktops because you are use the keyboard anyway. On a smartphone or tablet on the other hand, you are not continuously using a keyboard. Therefore, you would need to open the keyboard, to be able to do certain actions, which would simply result in an extra step for the user in the process (opening the keyboard, ...


2

A keyboard has obvious costs: Increased device size. Reduced space for a screen. Mechanical complexity/manufacturing costs. The need to localize the keyboard to different languages. On the other hand, the main benefit of a keyboard was easier data entry. At one point, a keyboard was worth it despite the costs, for this reason. However, improvements in ...


1

My answer only applies to Android, as I am lacking any long term usage experience with iOS. Add step forward and backward buttons on the bottom (if this is a wizard like screen), Add the familiar "steps" dots on the bottom too. Provide swipe gestures to go forwards and backwards too. Please do not attempt to create a general solution for Android and iOS! ...


1

I think it's very confuse having the back and cancel button in the same bar. I would suggest to add a bottom bar to navigate along the next/previous, so you can have a cancel button on the top consistently along the whole process.


1

Yes, the tester has a point. He is thinking from end-user's perspective. So when user usually clicks some animation/click effect should be shown so as to show user that the click was successful. Imagine if the click effect is not there, user will click multiple times by mistake resulting in some weird operation maybe. Remember one of the golden rules of ...


1

Before answering the usability question, I want to make this note: The non-IOS functionality here would be correct, according to your code. There's no css:hover or css:active loadout. I don't know if it's a loading issue related to white flashes, or if it's an intentional change by iOS. But your site/element as is shouldn't be flashing. Can after-effects ...



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