RFC: Navigation restructuring

Matt Wagner matt.wagner at redhat.com
Fri Nov 16 16:01:20 UTC 2012


On Fri, Nov 16, 2012 at 01:57:10AM +0100, Jaromír Coufal wrote:
                     ^^^^^^^^^^^^^

You really don't ever sleep, do you? ;)

> Good morning/afternoon/evening to all
> (you can choose your time-zone)
> 
> On our Aeolus Developer Conference I introduced new concept of
> Conductor UI. When I wanted to use versioning to distinguish it from
> current one, I realized that it would be better just to call it "new
> generation" :)
> 
> With this e-mail I would like to follow up with more details to the
> first stage of our change - navigation restructuring.

I think this navigation restructuring is quite important -- it's awfully
confusing today.

I don't disagree with anything you're saying, nor do you say anything
that contradicts this -- but just to repeat something that was discussed
during the conference, we're on our fourth or fifth UI overhaul in the
past 2 years. So I think we should make sure we take this one gradually,
and ensure it's the last, rather than adding more dramatic overhauls.
(But again, I think we are already taking a more gradual approach -- I
just wanted to note that it's something to keep in mind going forward.)

<snip>
> =====
> Solution
> =====
> -> Two level navigation
> * First tier = logical grouping of elements
> * Second tier = elements themselves in sections (all of them)
> 
> - User always knows where he is (always highlighted item in 1st and
> 2nd tier).
> - Just by 3 clicks (listing through 1st tier), user can overview all
> accessible sections.
> - It takes just 2 clicks to get to any full list of elements (e.g.
> list of Images)
> - It takes just 3 clicks to get to any detail of any element in the
> system. (e.g. detail of an Image)
> - If user looks for some section, he knows he can always find it in
> 2nd tier (nowhere else).

+1

FWIW, this is pretty consistent with how Katello handles navigation.
(Though they sometimes have drop-downs for a third level.) Since we're
semi-related projects, I think a consistent navigation pattern is an
added bonus.

> ======
> Structure
> ======
> *Cloud Environments*
> (everything related to active content)
>     - Overview
>     - Cloud Environments
>     - Resource Zones
>     - AppForms

This makes sense, though it seems a little weird on the surface to have
a "Cloud Environments" tab under the "Cloud Environments" tab. I think
the approach actually makes sense, but I can see users finding it odd.

One solution (which I'm not 100% sure I agree with myself) would be to
try to find another term for "Cloud Environments" in the top-level tabs,
that's a little more generic, along the "Active content" lines.

> 
> *Catalog*
> (everything related to passive content)
>     - Catalogs
>     - AppForm Outlines
>     - Images
>     - Hardware Profiles
> 
> *Cloud providers*
>     - Cloud Providers
>     - Accounts
>     - Realms
>     - Provider Selection
>     - (Cost Estimates)
> 
> *Users*
>     - User groups
>     - Users
>     - Permissions

Ah, so _every_ top-level tab ends up having a second-level tab with the
same name -- Catalog has Catalogs, Cloud Providers has Cloud Providers,
and Users has Users.

I do think this is a logical grouping of items, it's just that it's
superficially confusing to repeat the name. I'm torn, though, on whether
finding slightly more-generic top-level names would help, or just add to
the confusion.

<snip>
> - *Dashboard* will not be part of navigation. It is specific page
> with purpose to inform user about current state of system and what
> happened when he was out. User will mostly work with this page just
> after logging in not during further use of our system. This means,
> that Dashboard will be a launch (home) page right after login. It is
> common and very widely used usability feature, that logo brings you
> to homepage; in our case it wouldn't be different, logo will bring
> you back to Dashboard.

I'm still chewing on this, I think. It seems slightly odd to have the
default login landing page be something not in the navigation flow. And
if we're saying it's just something users will see at login and won't
want to return to, I wonder if it actually serves much purpose. Plus,
Katello does have 'Dashboard' as their first top-level navigation item.

On the other hand, it feels like my argument is largely academic. And
it'll be pretty trivial to change this later on if we decide that it
does warrant a top-level tab, so maybe this doesn't matter a ton.

<snip>
> If you made it this far, I would be really thankful to any reaction -
> positive, negative, suggestions, if it makes sense to you, everything
> is really welcome.

Overall, I think this is a good idea. I also like that it does away with
the concept of an explicit "Administer" section.

Will we hide top-level (and second-level) navigation items that the user
doesn't have permission to see? I think we should.

-- Matt



More information about the aeolus-devel mailing list