Revealing functionality (tabs) as the user enters more data

Question

Assume that we have an application where the user can add his/her events. The application has 4 main functions (represented as horizontal tabs when the user logs in):

• calendar view
• list view
• graph view
• import events

Tab #2 (list view) doesn't present anything useful unless at least 1 event has been entered.
Tab #3 (graph view) doesn't do anything useful as well unless at least 4 events have been entered.

My 2 options:

1. All 4 tabs are visible even when the user is new and has no events entered in the system. A helpful message on tab #2 and #3 will inform the user that there are not enough events (data) for these panels/functionalities to display anything useful.
2. Dynamically reveal tab #2 when the user enters his/her 1st event and reveal tab #3 when the user enters his/her 4th event. Revealing of tabs (functionalities actually) will be done with an appropriate message of the form "List View enabled!".

Which one should I choose?

I'm not sure which path to choose because I'm afraid that:

• path 1 will confuse the very very new users (who have just registered) who will not know where to start from (even if the default tab is #1 and on tabs #2 and #3 there is message explaining the situtation)
• path 2 will make the application look very empty for users who have just registered. Could it be that it would confuse them as well because of the new tabs poping up injected between tabs #1 and #4?

Answer 1

I agree with you. Both approaches have pros and cons.

I would advise mocking them up, or developing a quick prototype, and testing it with a couple people, see what they think! (testing, testing, testing should be your mantra, when developing UI's :P )

But, in my experience, i'd advise you to keep the menus static, to avoid possible confusion on users: "why did the menu change when i inputted my Xth event?", "why did it go away when i deleted an event?". The inner workings you described seem pretty simple/straightforward, but i see no advantage in hiding 2 of 4 options to avoid confusion, when this already introduces some confusion :)

I'd go with option 1 being the less confusing, probably. But your best specialist opinion comes from users you test.

Do you want links for mr Krug's books? or have you read mr Nielsen's website? You should!

Answer 2

Option 1, static tabs with helpful messages, should do just fine. Remember, your users aren't stupid. When they get instructed what the situation is (they should have more events for a certain tab to be useful), they understand it a lot better than the confusion created by tabs appearing and disappearing while they don't have a clear reason why that happens.

And I totally second José's comment about testing with mockups! You can get the most accurate feedback from the actual end-users of the software. Just don't rely only on their opinions or comments, see for yourself how they use the system (or mockup in the early development).

You don't necessarily need to have massive user arsenal for constant testing - if you have coworkers you can utilitize every now and then, hallway usability testing can be your friend and timesaver.

Answer 3

It's #1 clearly. A simple

No events were entered. Create new event

should help with all novice users.

---

Progressive disclosure isn't bad, it beats "novice only" interfaces (like wizards) that don't provide a smooth transition to "expert mode". However, you have to balance it against a stable top level navigation structure.

• Don't move items around. Adding tabs at the end is better than inserting them in the middle. This also helps support ("select the second tab").

• Make dependencies obvious: Controls that affect each other should be on the same page. When Checkbox [C] enables List [L], the checkbox must be available when the user goes looking fdor the list, and the list should show/hide when the user toggles the checkbox.

• Keep a logical flow: in LTR cultures, a control should affect only what is directly right or below it.

Answer 4

UE data considerations should always provide a clear path from the 'empty' case to the 'one data item' case and then to the 'more than one' data item case.

In addition, don't be afraid to include documentation in the GUI! E.g. for the empty case, have an action to create an item, but also show an illustration of what it might look like, with a picture or video illustrating the point.