We have a client that wants to use a pop-over to view, upload, or delete a related file.

When the pop-over is activated and there isn't yet a related record, is the best practice to hide the buttons to view and delete, or apply conditional formatting to subdue (grey text instead of black) the text on the button?

The advantage of the subdued text is that items that are expected from the user don't disappear, but their state indicates "not available." The disadvantage is that this would have a performance impact as it would be applied over the theme style.

The advantage of hiding the buttons is that the user doesn't even have the option to see them, and only option would be to upload a file. The disadvantage would be the blank space on the pop-over (though it isn't big) and that expected items would appear or disappear depending on the file status.

I'd like to think that someone out there with more experience than I in UI/UX would have an answer or at least a best practice for this situation.

Subdued buttons are good for when you want the user to know that there's an option not usable right now. I tend to ask myself "Is the user going to wonder where this option is, if they can't tell it's just disabled right now?".

They're also useful, as you've noted, for just keeping your bank of buttons consistent and nicely aligned. I try, though ("try" being a key word) to design layouts such that I don't have to lovingly handcraft the addition or removal of a button or two. Being a custom developer, I expect that no matter how clear the requirements are today, details like that are going to be fluid after, and even during, initial development.

If the disabled option is rare one, it's probably more distracting than useful to show the subdued button, so I'd hide that. F'rinstance, if you were using a plugin and had an "unzip" button that only appeared for .zip files, it probably wouldn't be useful to see it disabled when looking at .jpg or .pdf files, and it would just take up space.

If it's readily apparent why a button would be disabled, I tend to favor hiding over disabling, but I think that's more of a preference, and an aesthetic choice. For example, if you have back and forward buttons and one or the other disables because there's nothing in that direction, or up and down arrows where the up button disables when you're on the first record, and the down disables when you're on the last. This could work just as well with conditional formatting or hiding. I'd recommend selecting a default answer to these "gray areas" at the outset, though, to maintain some consistency to the "feel" of the solution.

Modern design principles tend towards "only show the user what he needs and can act on at that moment". The reasons are:

1) If only what is actionable is present, then the user doesn't have to figure out what's available and what isn't. Reduces confusion.

2) The fact that our visual capabilities notice change. The more obvious the change, the more easily it's noticed. Hence, when an action becomes available, if the interface element to perform that action suddenly appears, then the user gets an immediate visual cue that says, "Oh, look what I can do now."

3) The fact that the human brain can only maintain attention on a limited number of facts or elements at a single time. (Someone once posited the maximum number was 7. Don't know if that's true.) It's like a buffer; if there are more elements visible than the brain can retain in the buffer, something gets shoved out of the active space off to the side.

So, as a general principle, you would hide a button (or other interface element) that can't currently be used. It wouldn't be a disadvantage at all; it's an advantage. Of course, that would be tempered by the actual needs of the solution and by proper attention to grids, available space, and so forth.

One useful trick is to use a single button for two purposes, or layer multiple buttons that are exclusive in the same space to avoid "dead" spaces in the interface. You can also use slide panels to effect a change in the interface (using Go to Object and turning off the animation effect) to get multiple uses out of the same screen real estate.

Always bearing in mind, of course, that you can get carried away and end up requiring too many actions to perform a simple task.

Another consideration is the consistency of the design and the normal state of the application. You can easily test whether a related record is present or not and then present the user with a different UI based on that information. However, the way in which you do this will be influenced by the function of the system.

If the normal behaviour is that a user will interact with the record often to view records and upload often then the normal state of the UI should include the ability to view, upload and delete. The exception is that on the first interaction, there is nothing to delete or to view and you may want to use conditional formatting to provide feedback.

If the normal behaviour is that the user interacts with the record only once or twice to store documents then the normal interaction is to upload and that can be prioritised.

Thanks Mike. I like your suggestion of a slide panel. When MS Word added the ribbon, I can remember all of the frustration of something being there one minute, and gone the next. Most menus seem to keep the list of actions, but grey out those that are not relevant or possible in the current context. So much for standards.

I don't think it is such a bad comparison. When you see the "occupied" flag on a public toilet, you understand why you can't open the door, and it's obvious what to do about it. If instead the doorknob were missing, you'd be confused. Is the door broken? Is the toilet actually somewhere else? Is this some newfangled knob-less door that I have to gesture at with the secret handshake to open? So it can be with disappearing buttons.

Calling consistency (on the one hand) and progressive disclosure (on the other hand) "principles" of good user interface design is to oversell both of them. They're guidelines to think about, not recipes for consistent results. What is a principle that trumps both is testing: try both, and see what happens.

Hm. I can see where you're coming from, Jeremy, but I'm not sure I agree. Here's why:

You've laid out why it would be confusing for a doorknob to be missing. That's because we expect a doorknob to be present on a door. It's part of an established pattern. Say, for example, we were teleported to a distant alien planet where doors only had knobs when they were unlocked. We'd certainly be confused, but the aliens who lived there would think it perfectly natural. It's not part of our experience, but it's normal for them.

Extend it a bit further. Say one of those aliens were teleported here. He'd yank on every doorknob he saw, expecting the door to open, because that would be normal in his experience. He'd be the one thinking this approach is, to use your term, "newfangled". (Which I love, BTW.)

Now, move the metaphor to software. For years, it's been normal to have "ghosted" text on buttons that aren't currently available. This matches the doorknob metaphor ... sort of. IOW, people who are used to that pattern expect it, especially if it's been used in the current application for a while. (I do a LOT of upgrades of existing applications, so this is a common experience for me.) But if someone is new to the application, they wouldn't think it unusual at all to see progressive revelation - to see interface elements only when they're available. It'd be new to them, so it wouldn't be disruptive at all.

So "consistency" is not merely a matter of "this element always appears on the interface". It's also a matter of the experience of the user.

It can also include consistency across time, which is where I think the ghosted button falls down. How many times have you inadvertently yanked on the door of an airplane lavatory without noticing the "occupied" indicator? I know I have. You yank, it won't open, then you look at the door and go, "Oh, phooey. It's occupied." Users can and do click on a button they've clicked on many times, even if it's ghosted, because they've developed a pattern of clicking on that button. The fact that it doesn't work can be disruptive. OTOH, if the button isn't there, they can't click it. That means it's "consistent" in time - it always works when it's clicked, because it only appears when it's available.

So to say that the only approach to "consistency" is to leave a data element in place all the time and use other visual indicators to define its availability is, IMHO, not really a complete definition.

All else being equal, I still believe the progressive approach still has clear advantages. (Which is probably why the industry is moving that way.) However, things are not always equal, and sometimes, you have to be constrained by user pattern recognition and stick to an older approach, especially for an existing user base with an existing application.

Now, move the metaphor to software. For years, it's been normal to have "ghosted" text on buttons that aren't currently available. This matches the doorknob metaphor ... sort of. IOW, people who are used to that pattern expect it, especially if it's been used in the current application for a while. (I do a LOT of upgrades of existing applications, so this is a common experience for me.) But if someone is new to the application, they wouldn't think it unusual at all to see progressive revelation - to see interface elements only when they're available. It'd be new to them, so it wouldn't be disruptive at all.

I actually find that progressive disclosure is least disruptive to experienced users, and most disruptive to infrequent users. Experienced users learn where things are when, and when they can and can't do what. For absolute first-experience new users, progressive disclosure is great because they don't know what they don't know. For less experienced repeat users, changing what options are visible when creates a navigation problem because it isn't obvious that the same interface should look so different at different times. For this experience to be less disruptive, it needs to be easy to discover why the options are different. Leaving a button in a disabled state presents opportunities for this that hiding the button doesn't.

This raises an issue that I think doesn't get discussed enough in interface design: casual and professional users (and users in between) often have very different needs. The overwhelming majority of interface design literature is focused on casual and first-contact users. That scenario is certainly much easier to research than acclimating users to an interface before measuring anything. Most FileMaker applications spend most of their lives being used mostly by users who have used the application before, and many (not all!) of those include users who can be expected to achieve some fluency in working with their applications. The difference is worth being conscious of.