Hot answers tagged buttons
I would consider two things here: Visual connection to action Common standard implementation To the first point - visual connection: If you see an arrow that points up, you expect something to happen in that direction. You will automatically look up, not down. So every action that goes to a different direction will feel alien, detached. So this argument ...
A button should show what will happen when it is next clicked - not point to something else. When the button above a closed menu is clicked, the content will drop down - so the should point down (to where the content will appear) When the button above an open menu is clicked, the content will move up into the button - so the arrow should point up.
Arrows pointing in our reading direction (right or down) point forwards. Buttons should indicate what happens when clicked. The arrow on a dropdown button should point right or down as it indicates new content will be visible once clicked. Once the dropdown has been opened, clicking the button again should close it. Therefore the arrow should point upwards ...
Since you're asking about the direction of the arrow, you might like to check out the Microsoft standards for glyphs and arrows. Scroll down from here, to the table that lists the different types of arrows and glyphs. It says things such as this: Chevrons point in the direction where the action will occur, to show the future state. Arrows point in the ...
You have a primary and secondary action. Details is the primary action, delete is the secondary action. What you could do is move the delete function into the window that contains edit/information. This has the added advantage of cleaning up your listing layout. This will only work if delete is a fairly uncommon function and the use case is something like ...
To give yourself some more information and possible ideas about how to solve this, take 5 to 10 minutes to scan the Microsoft Style Guide sections on Command links and Links. Even if you're not designing or coding for the Microsoft platform, there are some good concepts here. In particular, the Command links topic may reframe how much supplemental ...
Few thoughts: 1) Think about this - for editing something, you first need to be able to view it right? So there is no issue, in not worrying about telling user upfront about the edit. Progressive disclosure is better rather than trying to tell all at once. User will go the view page, and then a clear mention or hint that he can edit is sufficient. 2) In ...
"view" seems logical - but hard to call without knowing what else you can do on the page. Otherwise "details" or even "view details" would make sense.
Consider the options: It depends on design goals, but customizing the headers looks like secondary action for advanced users. Then you need no to make the control too prominent. And follow @digsrafik's recommendations, these are general, but you didn't specify the goals and context in your question.
There's no "right" in design. To propose a good solution: Make sure you comply to 10 usability heuristics by Nielsen. Make sure technical limitations won't change the final UI dramatically. Test the design with users. Let them complete a real task and see whether they can easily finish it.
Only top voted, non community-wiki answers of a minimum length are eligible