The physical mute and volume buttons affect all other apps too. It's better to have a mute button in your app because as a user I may only want to mute the notifications from your app and not others. For example, there's a chance I want to mute Facebook notifications but not those from Twitter. So for that I'd need a mute button in Facebook because the ...
TL;DR: An app forcing me to use the global mute would be uninstalled in the blink of an eye. So they better have a mute function if they want to use audio at all.
EDIT: The previous was a bit too short for an answer, here's an explanation:
Audio is in essence quite intrusive, that is, you can hardly block it out. That's different from vision - you can ...
Just a small extra consideration but I'll make it an answer anyway. I tend to listen to the radio via an app whilst playing casual games so need to be able to choose which app's volume to control. If I had to use the volume control for all apps I wouldn't be able to complete half of my objective (as I want to do both). This goes beyond the other answers that ...
I would say a wizard 'stepped' process, with a progress tracker, is perfectly viable on a tablet. The full screen format should lend itself nicely to tapping through a form.
Some related points to bear in mind
keep amount of steps relatively low but…
don't make each step too long
clearly indicate on the progress tracker which step the user is on
No, it's not always necessary. System-defined screens are not obligatory, and there is no need to reproduce clone pages/elements with minor changes. Alternatives to hi-fi prototypes are lo-fi wireframes, user journey maps, PRDs.
Yes, paper sketches/prototypes are legitimate prototypes if they are detailed enough and capture/highlight on all important parts.
Mobile OSes usually have broad scoped sound controls instead of app specific ones. Android (AOSP) sound volume has three separated controls: one for general effects and notifications, another one for multimedia apps and the last one for alarms. But those are system-wide, so adding sound controls into the app you can control the app specific sound volume ...
I recently had a project with a similar challenge. I was charged with rebuilding an application that relied heavily on hover text for help. With the updates focus on tablet and devices I had to figure out a new way to present this information. As a result, I relied on a lot of tap to expand interaction.
After looking at your example. I am very glad the ...
I'm not sure usage heat maps are all that useful, as users tend to interact with the regions where the most important controls are - regardless if they are in the optimum location or not.
There are some optimal thumb range heat maps in an article about thumb reachability for different sized iPhones. It might be used with tablets as well by mirroring the ...
Web or Mobile?
This sounds like a really useful native mobile application as I'm guessing it will be notification-centric that will alert the user when action is required. Things to consider before diving into native mobile development:
Will this be OS-agnostic (i.e. will it run on iOS, Android, and possibly even Windows devices)
Will it be a universal ...
I haven’t seen any stats on the issue but I have a suggestion that might help narrow things down to allow you to conduct testing:
Aggregate and prioritise game controls :
Start by aggregating controls into logical entities and prioritise them inline of how you think the game should be played.
Test and refine design and layout:
Test and refine to distil ...
I think your answer lies in your question, also it may only be 5% of traffic, but who are those users? I would find that out before ignoring them.
My employer's main traffic comes from desktops due to the nature of what it publishes online (large documents). However the site is designed to be mobile responsive for ease of use on such a platform. Although ...
Implementing a wizard, or a stepped process should be no problem for tablets. Apps use this often in walkthroughs, and also registration/sign up processes, purchases and content creation.
These are essentially slides describing your app's functionality with a progress tracker to know what step you're on. Often accompanied with animations.
My only experience comes from what i have learned at school and experienced myself. So here comes my humble opinion on the topic.
First of all there are different types but i don't know if there are better names than these:
if the page can scroll vertical, and a certain field on the page can also scroll vertical
if the page can ...
Well, the simplest solution to this would be to have two different login portals, I suppose. However, if that is not an option, you could look in to the following options:
Which type of user uses the page the most? If user type A requires it more than type B, you could keep the user A login page as default with a link/button that redirects to type B.
I'll give two ideas.
(1) More direct
When the user selects a node, show a callout with all the possible actions. It is direct, which is important as you are working with a NUI. Also, if it is possible, I believe you should lock the node in its position until the user takes action.
(2) Less direct
If things moves around and if you think it will be hard to ...
Adding a tap would require extra efforts from the user. Why make user to take such steps.
Scrolling is synonymous to exploring without causing the pain.
Plus when I look at other Ecommerce apps, scroll is used almost everywhere. Have a look at some of these Images:
Just to add to the other answers, you should actually avoid making the mocks look finished until the functionality is also finished.
To quote Joel Spolsky:
If you show a nonprogrammer a screen which has a user interface which is 100% beautiful, they will think the program is almost done.
To this, I would add that even people who aren't non-...
I see no reason why not.
Provided the following holds true.
No impact on normal user operation
This are advance user actions. As such, they may not be easily discoverable to every user. It may not be intended for a normal user to perform those operations. In any case, there should not be any impact on normal operation of the user. The usability and trust ...
Regarding designing a longer form
The problem with two columns forms is users would be confused by the two column layout and interact differently needing them to more time to get the task done. To quote this article
One of the problems with form fields in multiple columns is that your
users are likely to interpret the fields inconsistently.
The iPad Air 2's front camera has 1.2MP resolution, or 1280x960 pixels. Let's make some assumptions:
The horizontal field of view is 60°
Users hold their tablets about 450mm from their eyes
Eyeballs are about 24mm in diameter
So, at the distance of a user's eyeball, one pixel covers (450mm * tan(60 / 1280))mm = 0.37mm. Let's see how much an eyeball ...
No. Floating Action Buttons or FAB represents the promary action of the screen, and therefore you'll have only one FAB since you can have only one Primary Action .
From Floating action button
Only one floating action button is recommended per screen to increase
its prominence. It should represent only the most common action.
However, you can use the ...
If these are strictly dependent on each other, perhaps expand the first unselected category automatically so that the user doesn't have to click into it, scroll to their item, and select it.
After selection1, that element can be collapsed into a single select menu as you currently have in your design. The collapsed select menu can still be modified if the ...
Tailoring for a specific orientation in a phone web-app is going to cause problems for some sub-set of your users that are forced to use the other mode.
Here are a couple of examples showing situations which require a user to use their phone in one orientation or the other, regardless of the way the app thinks it should be used. This list is non-exhaustive, ...
First, you can add padding between rows to make them easier to click. As for the size of the buttons, you are always trading space for easier to click buttons.
A way to approach this would be to have a simple text field that opens a small bubble with large + and - buttons next to the control. This would reduce the chance of errors without using up space. ...
Some suggestions to make input more easy and less error prone on a tablet:
place – and + signs into the input control and increase responsive area
increase space between controls to eliminate missing while tapping
To reduce information overload you could try accordion-style navigation with folding sections.
While building an application for another type of device within the same family, you should do your best to preserve consistency between these. But do it wisely:
first, do not port directly, but use the same patterns and improve them - simply scaling up is a bad idea
second, if it's necessary, improve your mobile phone application instead of making your ...
I don't think this is very easy when it comes to design for limited screen estate.
Is there a reason to have it all show at once? You may be inundating the user with too much raw data.
You could allow the user to choose what they wish to focus on by:
allowing "freeze frames" functionality or just freeze the ones that makes sense. This maintains user ...
I have been using something called BrowserStack for a couple of weeks now:
You have to pay for it, but you can get a 3 month free trial via this microsoft site: http://www.modern.ie/en-us/virtualization-tools
It has some emulators for mobile devices that you can use (including iOS), and also has a feature that allows you to ...