Half a croissant, on a plate, with a sign in front of it saying '50c'
h a l f b a k e r y
(Serving suggestion.)

idea: add, search, annotate, link, view, overview, recent, by name, random

meta: news, help, about, links, report a problem

account: browse anonymously, or get an account and write.

user:
pass:
register,


     

UI Buttons That Know Whether They’re Coming Or Going

Best Practice shape convention
  (+3)
(+3)
  [vote for,
against]

I suggest that there should be two distinctly but slightly different shapes for on-screen soft buttons based on whether the action behind it is putting information into a system, for example, storing a setting, or for retrieving information back out of a system, for example, making a predetermined action happen.

Whatever is decided the most appropriate visual clueing arrangement should be widely adopted (i.e. as widely adopted and understood as the FF/Stop/Play/Rewind icons of tape transports of olde were).

The initiative for this idea came from using the Blackmagic Design ATEM controller software, where there is a pair of buttons to set the DVE at a certain size and position (A and B positions) and just below it, a pair of buttons to make the DVE move to position A and B. The top pair say ['set A] and [set B] or something like that, and the buttons that make the DVE go there are [A] and [B], but it’s too easy to hit the set buttons, which are look the same and are too nearby. If you do that, you’re screwed, as you’ve lost the settings for the DVE position, the new position is where it happened to be when you pressed the set button.

It’s partly a UI flaw in that those buttons should not be so near each other, but it occurred to me that in general, buttons like this are basically either inputs or outputs and therefore need not look the same — the rectangles with gently rounded corners — we have the opportunity to make buttons that demonstrate whether they’re to put information in, or grasp information out, of a system, by their shape.

Ian Tindale, Jun 26 2015

[link]






       Sounds like bad design in the software you're using, mostly. But this reminded me of how often the same buttons in real life are "output" or recall buttons, but when pressed and held, become set buttons. Example: The radio station buttons on your car radio.   

       Maybe we should adopt this more readily in software design. I'm imagining a Photoshop tool palette where pressing the brush button gives me a brush, while holding it down opens up the brush manager. Pushing a layer brings me to that layer, while holding it down could pop open the properties for that layer. An interesting idea but could conflict with drag/drop functionality in places.
napoleonbag, Jun 26 2015
  

       Interesting. But, I'm seeing buttons going away as a UX concept.   

       With mobile UX, we're seeing a growing use of swipes, auto- saves, and other invisible UI elements that are a frustrating mystery before you discover them, but elegant once discovered.   

       For desktop UX, where buttons will still reside, it does make sense to separate "save/edit/transform" buttons visually from those that are "open/view/expand tools" type.
sophocles, Jun 27 2015
  
      
[annotate]
  


 

back: main index

business  computer  culture  fashion  food  halfbakery  home  other  product  public  science  sport  vehicle