I’ve created an add-in that consist of a ribbon and three tabs.
Background to build:
The ribbon is built using designer and not xml. The primary use of these is to allow quick opening of various email templates.
Tab0 adds a couple buttons to the built in TabMail
Tab1 is a new custom tab with various buttons that do various things.
Tab2 is a reduced version of Tab1 for use by users of our subsidiary company but pointing to alternatively branded templates.
In the coding, Tab1 and Tab2’s visibility is set based on user AD group membership on ribbon load event. This has been tested and works.
Tab0 always is merged with the built in Home tab shows as expected.
Developers and template admins like me should see all tabs. This also works using same methods.
Current issue:
Recently and I think after a certain office 365 update (but not 100% which), Tab1 no longer shows for anyone that should see it on load. However the tab has loaded somewhere. The reason I know this is because to fix this bug all I have to do is minimise the ribbon the re-maximise. Both additional tabs are instantly visible.
Please note, I do not have to disable and the re-enable the actual add-in.
I can also confirm that the Ribbon Type is set correctly (Microsoft.Outlook.Explorer) so please, no reply along those lines either.
I have trawled the web and cannot seem to find an explanation or fix for this behaviour. I'm hoping someone has seen this before and might point me in the right direction.
To replicate, I've seen it happen by just creating a new simple ribbon project and creating a new custom tab. Then create a second tab by copying the first, giving it a diff ID.
e.g.
Ribbon on App Launch/Load - Tab01 Missing
Ribbon on minimise - Tab01 Appears
Ribbon on maximised- Tab01 still visible
Still have no idea why this happens but i have found a work around for those that have experiences the same issue.
The issue seems to affect the first custom tab only. So if you add a new blank custom tab and set its visibility to false, this inherits this bug allowing the other to function properly.
Its a bit of a dirty fix but work well.
Would still be interested in an actual fix if anyone knows one though.
This happens because you had added control to your ribbon perhaps a property to the Control which you should not.
An example is when you add a Ribbon Gallery control to your Ribbon and change its "PositionType" property from Default to another value.
This results in the Ribbon not showing.
Or perhaps you should check the last code you added to your project
I am trying to build a new add-in command (button) to add to the Home tab in the Outlook ribbon. This is easy enough to do, but my organization also wants to target the button based on properties in one's Active Directory profile (specifically department). Is this possible? Thank you so much!
This is pretty straightforward with desktop office add-ins (like VSTO). All you need to do is basically to get information about the currently logged in user organizational unit from the active directory, and then show/hide/modify buttons depending on this information.
From the tags on your question, it looks like this is NOT what you are looking for (please correct me if I am wrong)? The fact that you added "office365", probably means that you are interested in javascript (cloud/browser/store) solution?
For javascript-based add-ins, the part where you get the user department from its profile was impossible until recently. Now you may check out the Single-Sign-On API (added last year). It provides you information from user's Azure active directory profile, meaning that your organization is supposed to be part of it.
Another difficulty could be, dynamic display of the related buttons (showing/hiding/enabling/disabling) (I may be wrong, but it looks like it is still not supported for javascript). You can try to create a workaround for that by building a custom task pane instead (you can do whatever you want on your task pane)
--- update ---
In case of .NET VSTO add-in, you can get user groups using:
UserPrincipal.Current.GetAuthorizationGroups()
Then you can control which buttons/controls to show/hide by providing callback function(s) in your code and in your ribbon interface definition file (you need to define Ribbon using XML, not with UI designer). There are callbacks available like getVisible, getLabel, etc.
My partner and I created a custom task form to be used in Outlook using the developer mode to do that, and we published it to the Organization Forms Library for anyone to open. We're running into issues that I personally can't seem to find on how to resolve:
Custom forms aren't syncing correctly.
When I complete out the custom form, and I assign it to someone else they might be missing details like the dates I picked from the date picker, and text within the text box are gone too. It's very odd that sometimes some would get all the details that an end-user would input but that's like a 1/8 chance. I feel like there's a disconnect where it just won't behave like any other task. Cache mode or no cache mode doesn't matter it seems. When the person assigns it back with changes made on their end, those changes aren't seen on my side. I just have the same original details that I made when I first made it. We're on Exchange Server 2010.
Looks like a custom form was not published correctly to others in the organization. Try to create a new Outlook item on other machines with your custom forms to make sure they were deployed correctly.
Note, message forms default to separate layouts for composing and reading. Many people find their first message form doesn't look right when they receive an item created with it. That's simply because they forgot to click the Edit Read Page button and customize the Read layout!
You may find the Customizing Outlook Message Forms article helpful.
I would like to be able to include a screenshot of a control inside my code, this way making control identification easier for new members on my team, is such a thing possible?
Maybe even the ability to just have the image on a network share with the path in a comment, and then have a plugin that when hovering over the link brings up the image?
EDIT (More detail):
I'm creating a test project, the application under test has over 1000 controls, some of them are similar in name and purpose, this can make it difficult at times for developers to reuse the API I am creating because the control name is simply not enough for quick identification of the control in use.
I use the word API very loosely too, none of this stuff will be consumed in web services, and it will always be white box with developers including a project reference and have direct access to the source code.
For every form in my application (The test one), I have a controls.cs file where all the controls for that form in the application under test are listed - This is where I want the hover to screenshot ability in the control definitions.
Another sure factor is that all developers will be using VS2013 (For now the base version), later this could be update 1 or 2.
As the initial author and senior developer on this project, these hover / image references (in the code) will be as useful to me personally as any 3rd party developers, or any later developers to join the initiative.
Thanks again, and I added a bounty!
I believe you can use Whole Tomato's free SourceLinks Visual Studio extension to do what you want - or at least get pretty close to it.
Built-in Functionality:
Out of the box, the extension allows you to specify comment patterns you want users to be able to take an action on. Once the patterns are specified, SourceLinks will highlight any occurrences of those patterns in the text editor. You will be able to double click the highlighted items and perform a pre-configured action (such as opening a link in an internal/external browser, or launching an executable).
You can see an example in the SourceLinks configuration dialog shown below:
(source: wholetomato.com)
So you could use this feature pretty painlessly to define a keyword such as Control Image and then put comments like the following in your code:
// Control Image: my_smart_list.jpg
SourceLinks would allow you double click this text, and you could have that configured to launch the image (using a file:// or http:// url depending on how and where your images are stored) either inside Visual Studio in it's internal browser, or in an external browser.
Custom Tooltips!
Now, if you want to put in some more effort into this and actually write some code, then SourceLinks allows you to create API Extensions to display custom tooltips when the user hovers over the marked text in the editor. The default installation of SourceLinks comes with sample API extensions that you can copy to create your own. See the article linked at the very top of the answer for more details on these samples.
This post in the SourceLinks forum informs us that SourceLinks expects the custom API Extension to return the tooltip value as FlowDocument XAML text. This is awesome news for us, because a FlowDocument can contain many types of elements, including formatted text, hyperlinks, and images.
Imanges in a Flow document can be specified both inline as well as externally.
Hope this helps!
I would use doxygen -- create the images somewhere in the source tree and use doxygen comments. You can embed the \image command in source comments (see docs) and doxygen will generate all the HTML documentation from there. I think doxygen is a great tool for documenting a codebase as you can generate the documentation directly from comments in the source and distribute or host the HTML separately.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
In some application with UI, what is better (easy, friendly, etc.) to a user:
UI is static (don't depends on user state). E.g user see some button, but it's grayed out or when it's clicked, a message, that this action is not applicable right now, is shown.
or
UI is dynamic (depend on user state). E.g. user don't see buttons, that are not applicable right now. But after some action, buttons may appear/disappear.
Sorry for my French:)
In my opinion, a static GUI with disabled controls is preferable.
When some options are not visible, the user will not know they exist.
Both of those styles have their uses. Remember that you should always use the right tool for the job and that there are (almost) no absolutes in creating software.
A static UI with grayed out elements is preferable in most cases. By providing a simple non-obtrusive message (don't show a modal message box for instance) when the user clicks or tries to interact with the grayed out elements, you can train your users.
What really happens in most cases is that there is a grayed out menu and your users are left wondering what they need to fix to be able to click on that element. This is bad UI design.
A dynamic UI is also relevant if you have an extensive administration section that the logged in user should NEVER be able to use. By hiding the administration section, you avoid confusion and interface "overload" for users who will NEVER interact with the hidden interface elements.
A dynamic UI is required in applications like Adobe Photoshop. There are literally thousands of commands and menu items possible in Adobe Photoshop. The only way that any user could comprehend the interface is by hiding and showing user interface elements depending on the state of the application.
I always recommended a UI that is as unchanging as possible:
Don't surprise users
I don't think there is a right or wrong answer to this question, I think it is just a matter of opinion/preference.
Personally, I would expose all functionality to the user and just grey it out when it is not accessible. However, there are some situations where I would consider 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 for this is there is no point in exposing functionality when the user is not meant to access them or if the functionality is just going to sit there greyed out forever...
Hope that helps.
If an action is not available
because the profile of the user
forbids its use do not show it at
all
If an action is not available only
because another action must first be
completed either :
Grey it out or
Leave it activated but on execution display a
message with a clear explanation of
why it cannot be executed
Make the action unavailable (by hiding, disabling, or using an error message) only if the action is logically impossible for the current state of the task, or to encode organizational rules on the actions certain users are permitted to do (e.g., privileges/permissions). Whenever possible make the user actions always available:
Use status indicators to discourage unnecessary actions, but allow them anyway.
Use verification and undo to prevent permanent damage from unadvisable actions, rather than disallowing the actions. Users may need to do something some day that is usually “unadvisable.”
Alter app design to make actions always possible in some way. For example, if a field needs to be filled out before an action can be done, prompt the user for the field, rather than disallowing the action.
Control user behavior through organizational policy, not software. Policies are easier to change when the business rules change or when there’s an exception or emergency.
Use disabling when:
The user can do something in the app to make the action available.
Availability is achieved through controls in the same window or its parent.
The user can easily figure out which control does this.
Use toggling controls rather than disabling for turning processes on and off.
Use read-only text boxes rather than disabled text boxes for data that is applicable for the current state unchangeable by the user.
Use hiding (“dynamic UI”):
For actions that are never available to the user in his or her current job.
For indicating different virtual places or things (e.g,. pages on a tab control, where each “tab” is a different place or thing). Make sure visual design is compatible with this: if you are representing different places, then make it look like different places (e.g., the way tabs do)
For swapping large numbers of controls with alternative controls.
Use layout, symbols, and text to explain unavailability, especially disabling. For example, mark your required fields; use tooltips to say why a button is disabled.
Use error messages rather than disabling or hiding when there no other means to indicate graphically or textually how to make an action available.
Further details and rationale at http://www.zuschlogin.com/?p=40.
I nearly always keep the UI static and simply disable (grey out) components that aren't applicable at this moment in time. It can be jarring to the user and confusing if components move around as you show/hiden them as the state changes.
I have seen good examples of both, and bad examples of both.
Your primary goal should be in making sure that your UI design (whatever route you choose) makes the entire process logically sensible to your intended audience.
dynamic is better if you don't want to frustrate your users
Well, that's the idea behind the latest MS Office, right? Controls that are around based on context. That, versus older versions with lots of grayed-out menus and toolbar buttons.
I worked for a number of years on control systems and in those environments, we mimicked the hardware controls (toggles, dials, buttons) that were, of course, static though not always usable. This was a customer requirement and their position was that the operator using the system expected button X to always in the same place. But from the designer and developer standpoint, I was frustrated by the cluttered UI and didn't like it when 95% of the buttons on a screen were grayed out.
I think that it will depend on your audience and the domain and customer requirements. In my shop, I make things dynamic and offer controls that make sense based on context. Typically, we don't show grayed out buttons or menu options that aren't available in the current context. Once the users recognize that they follow certain workflows and those involve particular UI elements when appropriate, they have no problems with (and probably prefer) a dynamic UI.
Less is better.
Why not do both and let the A/B testing tell you what your users prefer?
I think it's better to focus on the user productivity and on the business the software is implementing.
To show operations that does not make sense for a specific user or in a specific moment will not help, disabled or not.
For example, if you have a software that is used in several departments of an organization, each user/department will only be interested in the part of the software that implements the part of the business he is involved to. Anything else is useless for him and only will make the software experience worst. The same applies for a screen that is usefull for a user but shows useless options.
I'd suggest prototyping both and asking your users (or a representative sample) which they prefer and why.
Just to re-iterate what Mitch Wheat said really.
If you make buttons disappear and reappear depending on user actions then there is the danger that the user might think that they've done something that's broken the application.
You are also hiding actions from the user, so it will be harder for them to discover what it can do.
Disabling buttons is a well known paradigm and users will be able to see everything that your application can do and will experiment to see how to enable them.
I think it depends on what users you want to hide design for but in general I would opt for the static version. Don't forget that a user interface doesn't only provide functionality but also information. If you grey out a button you inform the user about it's state (by what he can do and what not) more clearly than removing buttons.
The remove button aproach can work for users that in general have good understanding of the system like admins. But I think you should use this with causion
Grayed out buttons are better, because then the user will know that under some situation such a function is available (and depending on the context the user might be able to guess when it is enabled), and the visual cue of being grayed out will signal to the user that the button can not be clicked, so the user will not try to click it (the problem with a message after clicking is that it comes too late - the user already made a mistake).
Whatever you choose, use constant positions of the buttons. Users often are not read text on the buttons.
Depends. But a clear and compact GUI is a nice thing to have. Why bother with 10 fields/controls you cannot change or use at all. For example on stackoverflow you have a reduced UI if you only have a low reputation, because it doesn't matter at all to the user, that one day he might be able to use them. Another thing is that controls (with borders) usual take more space than just text. If you have information, that currently cannot be changed, I would present them in a very compact text field/label. Depending on the information it even could be placed outside or far way from the form.
According to Joel - neither :-)
Both can make sense, as long as you use paradigms the users are familiar with.
The tab control is basically a dynamic UI that changes depending on the state.
Consistency is probably the most important thing when designing an UI. If buttons pop in and out, they are seen as a visual stimulus, and the user will "spend" attention looking at them.
A subtle, but clearly disabled button (not disappearing) is my preffered choice for designing UI....
.. So I guess that's option 1 :)
A combination of the two.
If a function is not applicable in the current state, disable the button but also place an icon next to the button and associate a tooltip with the icon. The tooltip should explain why the user can't use the button right now.
Attaching the tooltip directly to the button doesn't work so well. Most users won't even hover over the button as they won't expect it to do anything.
And avoid exclamation mark icons. They suggest the user has entered an invalid value (unless they actually have.)
I'd like to say I always do this, but unfortunately it does take significantly more coding time, and clients aren't always willing to pay for that.
A modal UI introduces mode errors. Always.
You currently seem to want to choose between two different ways of presenting a modal UI. From those I'd say the first one is superior (unless you really have many possible commands, see the Office 2007 UI for a good example how to handle this, but it's not common to have that many).
If you have the space and you haven't too many controls then I'd really go with disabled controls as it shows th user what is possible. Furthermore you might want to make it really clear which mode the UI is in (not just from the buttons that are enabled). I've seen user interfaces where you had disabled buttons but the user couldn't figure out what he has to do to enable them.
In any event be sure to do usability testing to find out what way is less error-prone on behalf of your users.
I like to keep all advanced options hidden under a "More >>"/"Less <<" button, or "Advanced Mode" checkbox, depending on the context and application.
Once clicked/checked, the window expands to reveal more options.
In terms of action availability though (like a Wizard featuring Next/Previous buttons) I always show them, and enable/disable them according to what functionality is possible.
The dynamic UI is done like the UI may keep changing. The fields may keep changing. So depending upon that the information of the field fetched from internet the ui is designed.
Rembr! all the similar fields have same design so u can keep changing the UI design and hence the application. without uploading the newer version of the application to the cloud or play store you can change the design of the UI.
As a example the UI pattern and fields are filled in the excel sheet and uploaded to cloud and the app has the access to download the excel sheet.
the above explanation holds good for an android dynamic app development