[ACCEPTED]-Static UI vs Dynamic UI-user-interface
In my opinion, a static GUI with disabled 3 controls is preferable.
When some options 2 are not visible, the user will not know 1 they exist.
Both of those styles have their uses. Remember 27 that you should always use the right tool 26 for the job and that there are (almost) no 25 absolutes in creating software.
A static 24 UI with grayed out elements is preferable 23 in most cases. By providing a simple non-obtrusive 22 message (don't show a modal message box 21 for instance) when the user clicks or tries 20 to interact with the grayed out elements, you 19 can train your users.
What really happens 18 in most cases is that there is a grayed 17 out menu and your users are left wondering 16 what they need to fix to be able to click 15 on that element. This is bad UI design.
A 14 dynamic UI is also relevant if you have 13 an extensive administration section that 12 the logged in user should NEVER be able 11 to use. By hiding the administration section, you 10 avoid confusion and interface "overload" for 9 users who will NEVER interact with the hidden 8 interface elements.
A dynamic UI is required 7 in applications like Adobe Photoshop. There 6 are literally thousands of commands and 5 menu items possible in Adobe Photoshop. The 4 only way that any user could comprehend 3 the interface is by hiding and showing user 2 interface elements depending on the state 1 of the application.
I always recommended a UI that is as unchanging 1 as possible:
- Don't surprise users
I don't think there is a right or wrong 11 answer to this question, I think it is just 10 a matter of opinion/preference.
Personally, I 9 would expose all functionality to the user 8 and just grey it out when it is not accessible. However, there 7 are some situations where I would consider 6 removing the buttons from view e.g.
- Administrative options (probably don't want to expose this to users with lower priveledges)
- RunOnce functionality (activating product/registering)
Reasons 5 for this is there is no point in exposing 4 functionality when the user is not meant 3 to access them or if the functionality is 2 just going to sit there greyed out forever...
Hope 1 that helps.
If an action is not available because the 7 profile of the user forbids its use do not 6 show it at all
If an action is not available 5 only because another action must first be completed 4 either :
Grey it out or
Leave it activated 3 but on execution display a message with 2 a clear explanation of why it cannot be 1 executed
Make the action unavailable (by hiding, disabling, or 49 using an error message) only if the action 48 is logically impossible for the current 47 state of the task, or to encode organizational 46 rules on the actions certain users are permitted 45 to do (e.g., privileges/permissions). Whenever 44 possible make the user actions always available:
Use 43 status indicators to discourage unnecessary 42 actions, but allow them anyway.
Use verification 41 and undo to prevent permanent damage from 40 unadvisable actions, rather than disallowing 39 the actions. Users may need to do something 38 some day that is usually “unadvisable.”
Alter 37 app design to make actions always possible 36 in some way. For example, if a field needs 35 to be filled out before an action can be 34 done, prompt the user for the field, rather 33 than disallowing the action.
Control user 32 behavior through organizational policy, not 31 software. Policies are easier to change 30 when the business rules change or when there’s 29 an exception or emergency.
Use disabling 28 when:
The user can do something in the app 27 to make the action available.
Availability 26 is achieved through controls in the same 25 window or its parent.
The user can easily 24 figure out which control does this.
Use 23 toggling controls rather than disabling 22 for turning processes on and off.
Use read-only 21 text boxes rather than disabled text boxes 20 for data that is applicable for the current 19 state unchangeable by the user.
Use hiding 18 (“dynamic UI”):
For actions that are never 17 available to the user in his or her current 16 job.
For indicating different virtual places 15 or things (e.g,. pages on a tab control, where 14 each “tab” is a different place or thing). Make 13 sure visual design is compatible with this: if 12 you are representing different places, then 11 make it look like different places (e.g., the 10 way tabs do)
For swapping large numbers of controls 9 with alternative controls.
Use layout, symbols, and 8 text to explain unavailability, especially 7 disabling. For example, mark your required 6 fields; use tooltips to say why a button 5 is disabled.
Use error messages rather than 4 disabling or hiding when there no other 3 means to indicate graphically or textually 2 how to make an action available.
Further 1 details and rationale at http://www.zuschlogin.com/?p=40.
I nearly always keep the UI static and simply 5 disable (grey out) components that aren't 4 applicable at this moment in time. It can 3 be jarring to the user and confusing if 2 components move around as you show/hiden 1 them as the state changes.
I have seen good examples of both, and bad 4 examples of both.
Your primary goal should 3 be in making sure that your UI design (whatever 2 route you choose) makes the entire process 1 logically sensible to your intended audience.
dynamic is better if you don't want to frustrate 1 your users
Well, that's the idea behind the latest 25 MS Office, right? Controls that are around 24 based on context. That, versus older versions 23 with lots of grayed-out menus and toolbar 22 buttons.
I worked for a number of years on 21 control systems and in those environments, we 20 mimicked the hardware controls (toggles, dials, buttons) that 19 were, of course, static though not always 18 usable. This was a customer requirement 17 and their position was that the operator 16 using the system expected button X to always 15 in the same place. But from the designer 14 and developer standpoint, I was frustrated 13 by the cluttered UI and didn't like it when 12 95% of the buttons on a screen were grayed 11 out.
I think that it will depend on your 10 audience and the domain and customer requirements. In 9 my shop, I make things dynamic and offer 8 controls that make sense based on context. Typically, we 7 don't show grayed out buttons or menu options 6 that aren't available in the current context. Once 5 the users recognize that they follow certain 4 workflows and those involve particular UI 3 elements when appropriate, they have no 2 problems with (and probably prefer) a dynamic 1 UI.
Less is better.
Why not do both and let the A/B testing tell you what 1 your users prefer?
I think it's better to focus on the user 14 productivity and on the business the software 13 is implementing.
To show operations that 12 does not make sense for a specific user 11 or in a specific moment will not help, disabled 10 or not.
For example, if you have a software 9 that is used in several departments of an 8 organization, each user/department will 7 only be interested in the part of the software 6 that implements the part of the business 5 he is involved to. Anything else is useless 4 for him and only will make the software 3 experience worst. The same applies for a 2 screen that is usefull for a user but shows 1 useless options.
I'd suggest prototyping both and asking 2 your users (or a representative sample) which 1 they prefer and why.
A modal UI introduces mode errors. Always.
You 18 currently seem to want to choose between 17 two different ways of presenting a modal 16 UI. From those I'd say the first one is 15 superior (unless you really have many possible 14 commands, see the Office 2007 UI for a good 13 example how to handle this, but it's not 12 common to have that many).
If you have the 11 space and you haven't too many controls 10 then I'd really go with disabled controls 9 as it shows th user what is possible. Furthermore 8 you might want to make it really clear which 7 mode the UI is in (not just from the buttons 6 that are enabled). I've seen user interfaces 5 where you had disabled buttons but the user 4 couldn't figure out what he has to do to 3 enable them.
In any event be sure to do usability 2 testing to find out what way is less error-prone 1 on behalf of your users.
Just to re-iterate what Mitch Wheat said 11 really.
If you make buttons disappear and 10 reappear depending on user actions then 9 there is the danger that the user might 8 think that they've done something that's 7 broken the application.
You are also hiding 6 actions from the user, so it will be harder 5 for them to discover what it can do.
Disabling 4 buttons is a well known paradigm and users 3 will be able to see everything that your 2 application can do and will experiment to 1 see how to enable them.
I think it depends on what users you want 11 to hide design for but in general I would 10 opt for the static version. Don't forget 9 that a user interface doesn't only provide 8 functionality but also information. If you 7 grey out a button you inform the user about 6 it's state (by what he can do and what not) more 5 clearly than removing buttons.
The remove 4 button aproach can work for users that in 3 general have good understanding of the system 2 like admins. But I think you should use 1 this with causion
Grayed out buttons are better, because then 10 the user will know that under some situation 9 such a function is available (and depending 8 on the context the user might be able to 7 guess when it is enabled), and the visual 6 cue of being grayed out will signal to the 5 user that the button can not be clicked, so 4 the user will not try to click it (the problem 3 with a message after clicking is that it 2 comes too late - the user already made a 1 mistake).
Whatever you choose, use constant positions 2 of the buttons. Users often are not read 1 text on the buttons.
Depends. But a clear and compact GUI is 13 a nice thing to have. Why bother with 10 12 fields/controls you cannot change or use 11 at all. For example on stackoverflow you 10 have a reduced UI if you only have a low 9 reputation, because it doesn't matter at 8 all to the user, that one day he might be 7 able to use them. Another thing is that 6 controls (with borders) usual take more 5 space than just text. If you have information, that 4 currently cannot be changed, I would present 3 them in a very compact text field/label. Depending 2 on the information it even could be placed 1 outside or far way from the form.
According to Joel - neither :-)
Both can make sense, as long as you use 3 paradigms the users are familiar with.
The 2 tab control is basically a dynamic UI that 1 changes depending on the state.
Consistency is probably the most important 7 thing when designing an UI. If buttons pop 6 in and out, they are seen as a visual stimulus, and 5 the user will "spend" attention looking 4 at them.
A subtle, but clearly disabled button 3 (not disappearing) is my preffered choice 2 for designing UI....
.. So I guess that's 1 option 1 :)
A combination of the two.
If a function is 15 not applicable in the current state, disable 14 the button but also place an icon next to the 13 button and associate a tooltip with the 12 icon. The tooltip should explain why the 11 user can't use the button right now.
Attaching 10 the tooltip directly to the button doesn't 9 work so well. Most users won't even hover 8 over the button as they won't expect it 7 to do anything.
And avoid exclamation mark 6 icons. They suggest the user has entered 5 an invalid value (unless they actually have.)
I'd 4 like to say I always do this, but unfortunately 3 it does take significantly more coding time, and 2 clients aren't always willing to pay for 1 that.
I like to keep all advanced options hidden 8 under a "More >>"/"Less <<" button, or 7 "Advanced Mode" checkbox, depending on the 6 context and application.
Once clicked/checked, the 5 window expands to reveal more options.
In 4 terms of action availability though (like 3 a Wizard featuring Next/Previous buttons) I 2 always show them, and enable/disable them 1 according to what functionality is possible.
The dynamic UI is done like the UI may keep 14 changing. The fields may keep changing. So 13 depending upon that the information of the 12 field fetched from internet the ui is designed. Rembr! all 11 the similar fields have same design so u 10 can keep changing the UI design and hence 9 the application. without uploading the newer 8 version of the application to the cloud 7 or play store you can change the design 6 of the UI. As a example the UI pattern 5 and fields are filled in the excel sheet 4 and uploaded to cloud and the app has the 3 access to download the excel sheet.
the above 2 explanation holds good for an android dynamic 1 app development
More Related questions