Cancel might be too vague. I always like to be more descriptive when asking users to perform a quite destructive task. This often reduces any anxiety users might have.
download bmml source – Wireframes created with Balsamiq Mockups
As LightnessRacesinOrbit made me realise in the comments, mixing up buttons with links that act like buttons (or in ...
The problem with your buttons is that they are not raised above the background, so they don't seem clickable.
I highly recommend the Material Design for details on how to choose between flat buttons and raised buttons, with exhaustive do's and don'ts. http://www.google.com/design/spec/components/buttons.html#buttons-flat-raised-buttons
You're looking at the problem from the wrong angle. A user could also open a different browser, or use a second device, which means you can't rely on the idea of opening tabs(and preventing it), nor on IP address. Your solution needs to be server-side. Signing them out would just annoy them. Either make it so your website show them the same game no matter ...
Do what the Android browser does when you are trying to touch things too small to reliably resolve to a single location - zoom to confirm. On the first touch, zoom the area around the touch so that the individual seats are clearly separable, on the second touch select the seat you want within the zoomed area.
Because this is part of the normal browsing ...
Have you considered giving the user an undo button instead? It reduces the cognitive overhead because no choice actually has to be made in the normal case and reduces the input from always having to do two actions (click cancel and then confirm/other) to only a single action when the user actually wants to cancel:
Wireframes made in Pencil.
If you're on mobile and you feel you need traditional style breadcrumbs to navigate then something probably went wrong with designing your site for mobile use - ie it's too complex (too deeply nested) for the type of usage and environment that mobile provides.
Jared Spool wrote on ixda in response to a similar question
Can't speak specifically to mobile, ...
From the A/B Testing (based on the article posted by keiwes) we can infer the following:
download bmml source – Wireframes created with Balsamiq Mockups
There seems to be a correlation between correctly identifying the hamburguer icon functionality and the age of the users.
Hence from the usability perspective, you need to question yourself were is ...
Web design has always been about choosing an audience you care about. You could care about every single browser in use and either rely on the minimal set of common functionality or use progressive-enhancement/graceful-degradation techniques to take advantage of modern functionality where it's available. The later approach takes much resources.
You can check book my show app they give the small window to show the overall seating and then the maximised view on the main screen which you can zoom in zoom out and select multiple seats by just one click.
I have opted to use a pointer element (similar to the text range selection brackets in the iOS and Android) that allows to select a group of seats.
Visually, it looks like this:
Pointer refers to the starting position of the seat selection, i.e. if user is buying 3 tickets, then the pointer will select 3 seats starting with the seat which the seat pointer ...
Personally I'm a supporter of sites with a mix of the two.
Fonts should keep the same size both in landscape and portrait. It should merely be distributed differently depending on the current screen width. As you've also showed in the mockup for A.
I feel that also scaling the text is like surrendering to a notion that "-ok, we know the text is very small ...
James Foster of Exis Web did an interesting A/B test on the hamburger icon:
Tests on mobile showed a difference, though not all that significant, when the icon was used with a border (so it looks like a button):
Perhaps more interestingly, the A/B test seemed to more clearly indicate that desktop users don't understand the icon:
I tested 4 ...
Let me add a late answer: after the content has loaded, do not let rotations trigger breakpoints.
If the user rotates the device accidentally, their most immediate task is to reorient themselves and re-find the content they were viewing or reading at the time of rotation. But a breakpoint trigger, the user is suddenly presented with an interface they don't ...
How to display
I would not scatter your UI with i-icons or question marks. Instead, use a dotted underline to make it clear that the user can interact with the work but to set it apart from a link.
How to interact
Keep in mind that on cursor-devices the tooltip is hidden again on mouse-out. You can't do that on touch devices, so make sure the tooltips are ...
My company caters towards an older population, so we included text along with the hamburger icon. Here is an article that had similar results with the older population: http://mobile.smashingmagazine.com/2013/09/11/responsive-navigation-on-complex-websites/
Google defines a convention as "a way in which something is usually done, esp. within a particular ...
Showing a full page modal window on mobile devices means users may confusedly think they’ve been taken to a new page.
Modal windows are typically boxes which contain information relevant to the current page but which don’t require the user to leave the page they’re on to view that information.
Considering these facts, I think, it would be best if we ...
If you have a separate site for mobile and non-mobile then yes, most definitely yes, let them go to the full site to complete what they wish if it isn't offered on your mobile one.
Mobile doesn't just mean 'people sat in a coffee shop for 2 minutes looking at their iPhone'. These days Mobile means 'anything that isn't a laptop/desktop' (and even that line ...
Mobile first means that you start your design process off by designing for mobile. Once you have that done, you can easily modify the design for pc.
The main reasoning behind this is that if you voluntarily constrain yourself to mobile, you will be forced to make decisions about what is really important, and what you need to focus on. By doing that, you ...
The UK site GOV.UK published some initial test findings about how users on mobile devices use a DOB field they were testing against.
Initial reports suggested that having two dropdowns (one for day and one for month) followed by a text field for year was well received by users, although not exclusively. (emphasis mine).
...This tested much better, and ...
I would say that it depends on the site. You could categorise mobile websites into two categories:
A bespoke mobile website / app that is a stripped-down version of the
full site only offering the most appropriate content for mobile
A responsive website, or a desktop site rendered in a separate mobile 'template'.
With the first type of site then if ...
Mobile websites should not be mobile versions of desktop websites - they should be a service or product for mobile usage. That means that yes, if certain content isn't relevant 'on the road', or if its inclusion makes it harder to provide an interface that works better in a mobile context, you should consider chopping it.
And remember, if needs be, you can ...
The problem is it's not flat enough
Are they icons or buttons? This is a common problem with flat design (see other answers) but one possible solution I haven't seen here yet is to remove information until the only viable option is to click. Think tiles.
...And at this point it should also become obvious that </> never was a suitable icon.
Gracefully degrade your subnavigation or drop it by reiterating its contents on the index pages.
It's true. Just look at the evidence below. Two great examples of responsive web design are Smashing Magazine and The Boston Globe. Ethan Marcotte himself was involved in the Boston Globe redesign.
Smashing Magazine: Drop the Subnav
Note in these screenshots ...
This is delicate, and should be a sound judgment by the designer. There is no right or wrong, neither is there a convention (yet) to rely on. But there are a few things to consider, like zooming in just widening the page, which I feel is useless. If I want to zoom I can snap-in on the text getting it in a more readable form (both in Landscape and Portrait ...
Jakob Nilsen about "Return to Top" Links:
Yes, "return to top" can be avoided, because the exact same
functionality is provided by simply dragging the scrollbar to the top
of the page. It's almost always better to rely on a single, generic
interaction technique so that users don't have to ponder the choice
between two alternate interaction ...
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 ...
There are different approaches to device oriented design, and you can implement one of several design patterns to choose from. The first one that comes to mind is the fluid design, which (simply put) just reorganize the elements to a better view. Some, less important elements, are hidden as the screen width gets narrower and vice versa.
Next is the ...
I think the decision between a single responsive site vs. multiple sites targeting different devices comes down to whether or not you are following LukeW's Mantra of 'design for mobile first'.
If you're designing for mobile first, then it's almost trivial to reconfigure the layout/flow to also accommodate desktop use. There are many other advantage as well.....
Google hangout has the same requirement as your application. You cannot do two hangouts at the same time.
Yet Google does not shock the user by disconnecting the first call when a second call is attempted. Instead, you see an error message in the second call's window.
Why don't you try the same approach?