Tbh I don't really see any use for the "forgot password" button/link, unless the user put in a wrong password before.
Let me try to paint a picture to explain why the comment above is a huge oversight.
Imagine a scenario where the users come to your application after a while and they don't remember the password. It means, they already know that an account ...
It's a very bad idea to not show the link. You should always give the user the option, even if they are likely to try a few passwords first.
How about an example - what if you have a password manager, and your credentials for this site is somehow lost/missing from your password manager?
You have no idea what the password is, as it will likely be some ...
Rob E's excellent answer covers the case where the application can (and the user wants to) mark specific passages of text.
If you also have (or want to offer) a simple "bookmark this page" option, without the user needing to mark a specific passage, then I think you should store the "location" of the paragraph at the top of the current page. When returning ...
If you're working in html/css, the effect is really quite simple to set up: CSS can take care of both the alternating row color and the transition effect on a row-removal.
A Fiddle demonstrating the working effect.
The CSS establishes a 'base' green colour for each table cell, but then sets the cell background of every 2nd row (tr:nth-child( 2n )) to red - ...
This is an excellent question for which there is an excellent answer. Allow me to start with two examples.
Colour and meaning
Consider you are using a system and wish to delete a record (and you do wish to delete the record). The interface presents the following dialog to you:
download bmml source – Wireframes created with Balsamiq Mockups
Globally Consistent Convention Versus Design "Wants"
There is always weight towards convention in user experience/interface design for numerous reasons, but crucial systems where there is a safety/security element are ones where that should be given even higher than normal priority.
In my current project we need as much space as possible
Your reason for ...
You could add a highlight text function then once the user highlights the text they have the option to bookmark the text.
That way regardless of how zoomed in/out they are, they are still able to get back to the right spot and continue reading merrily.
The blogging webpage Medium does this in quite a nice way:
I've always gone with the following rules to make this determination:
If any action on the current screen/page/window will change the availability of the field, it should be disabled/enabled as the values/inputs change.
If no action on the current screen/page/window will cause the field to be available, then the field should be hidden.
If the information in ...
For the most part the pros/cons of this come back to the classic Adaptive vs Adaptable interface argument, where Adaptive interfaces automatically adjust based on user interaction, and adaptable interfaces allow users to manually tweak them.
A problem with this in particular is that text size is an accessibility issue. Not everyone has the same eyes, so ...
Cutting of the text with an ellipsis would be my first idea as well. Alternatively you could make the text "disappear" in the background by placing a transparancy gradient on top of it, i.e. so that the text fades away. It's basically the same idea but a little more elegant from a design point of view.
Adding a tooltip that displays the full text could be a ...
The problem with dynamic interface elements is that it prevents the user from learning where things are. As they alter and adjust over time, the user is prevented from gaining mastery of the gui, as their learned behaviors become obsolete. Consistency is far more important than incremental improvements based on Fitts' Law.
Some elements are consistently ...
In my opinion, dynamic examples based on the first characters user have entered may help users to enter correct values (validation is still needed, thought):
Examples will not only suggest the way phone number can be entered, but also limit ways of validating this numbers (since there may be a lot of different schemes, so choosing one or two depending on ...
Smallhacker - Do you need the zebra striping to begin with? If it's to help the user scan across a wide row, maybe another design pattern would work? You could try "highlight row on hover".
A list apart has two interesting articles about whether zebra striping is useful:
Jessica Enders, “Zebra Striping: Does it Really Help?” at A List Apart, May 6, 2008
I love data visualisation and information experience design questions. Choosing an interactive visualisation to showcase your data is definitely a step in the right direction. We as humans, remember a lot from sight... visual and immersive content helps us understand or make sense of data we normally cannot digest.
So should you really impress your ...
As a user, I would often find it unnerving if the UI behaved in unexpected ways. Instead of having the new alarms pushed on top, you could consider one of the following:
Show the items beyond the current scroll (I'm assuming the modal window has a scroll?) out of the view of the user; he can then scroll up to see the new alarms. The top border could light ...
I'd recommend getting rid of zebra striping. It's often considered chart junk more than it's considered helpful.
If you need to group rows, do it with a visual divider line:
Using User Action Driven Scroll Might Help
If I have understood correctly, you have a global scroll (applied to the complete page) and another scroll inside a particular card. Now, while scrolling vertically, the nested-scroll is causing the irritation, because the behavior is going against the user's intended action/mental model.
An approach which you can ...
You should give the user control over refreshing the data, give them a notification that new data is available (or that data has changed) and tell them that they can refresh the view by pulling.
You already mentioned the big con of updating it without user interaction.
But, as always, it depends on the use-case. If you have data that changes every 2-3 ...
I would keep the users place. The user will return to the application expecting it to be where they left it rather than having had it move arbitrarily up. You should notify them that more things have happened but keep the viewport focused on the last place they left it.
this the way facebook do it with their activity stream on mobile, it keeps it's position ...
If your strips and your text aren't linked with some animation you could remove the annoyance. I guess it's even possible to work without uniform height if you wait for the text animation to finish before changing the stripes heights.
Combination of Last Use and Time-based Scoring System
(a.k.a "Last Used, and Most Used Most Recently")
Assuming your users aren't most likely to use a different box every time, then showing the last used item is something that's at least worth testing with users. You can get around the disruptive effect you correctly anticipated and described, by ...
If someone forgets their password they will first look for a forget password so this would just waste the user's time, annoying them causing them to want to leave. Also some people will use the change password to find out a username that they have forgotten so this would force then to try and remember it, annoying them. Finally some users will use the ...
There is some inconsistency in you mockup. The groupbox' title reads "Locations", yet you only show 1 location's details.
There should be an overview of all locations, where you can see all locations, which should have a button to add, delete and edit locations.
Both the add end edit buttons should show your mockup, but instead of "Locations" it should ...
"add location" should be displayed below form (footer). It's more covinient - user completing the form, from top to bottom... and then can decide to add new location,
"remove location" should be displayed as header of each location - on the level of current "add location". additionaly remove button should be similar to "add ...".
in addition ...
I haven't heard of a golden rule unfortunately; it would be great if anyone knows of a study. A couple of thoughts and my experiences:
Is the user interested in simply accessing the "child" field without going through a parent field that enables/shows it? If yes, than hiding the field might make it more challenging for the user to know that the option is ...
Do your best to rethink the grouping to slim down from 12 tabs to a smaller number, if possible.
Is this part of a stepped process ? (like setup, creating a profile, etc)
If so, I think 3 is the magic number in terms of the total number of steps. To slim down to 3, ask yourself 'do I really need this data ?' or 'do I really need this data now (can I ask ...
In option 1, they have to waste time by seeing options that are not related to the items whenever they want to manipulate an item, which results in slower scanning speeds.
In option 2, you are repeating yourself and forcing customers to scan options that they aren't interested in when they want to navigate away. Once again slower scanning.
Option 3 is ...
Users don't think in RESTful terms like this (Edit object, new object, delete object, etc.), developers do. So I'm not crazy about this interface in general. The better option would be to show the appropriate action on the "object" at just the right time in the workflow. But that's not your question :)
Here is how I would handle it. I would put the Edit, ...