Matt, thank you for looking at this and writing down your ideas, each
input is really valuable.
There are some notes in the text:
On 16.11.2012 17:01, Matt Wagner wrote:
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.)
I am
aware of this, Matt, and I am glad you pointed this out, because I
also think that it is really important issue. Actually this is the
reason, why I presented changes at the conference and trying to get as
much feedback as possible from all of you - to make it as much
bulletproof as possible.
<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.
Exactly, it is one of my goals - to get these two projects as close as
possible. Not necessarily blindly steal what Katello has, but find the
way and concepts from which we both can benefit and which fit us. I am
in touch with guys working on Katello's designs so we make sure to head
the same way.
> ======
> 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.
Yes,
your thoughts make sense. Background for this is below next paragraph.
> *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.
Well I was looking for the best representative which would describe
the
whole section. I didn't want to look for some artificial terms. In top
level I wanted to use such terms, which describes the most of what
Conductor can do.
- Cloud environments = management of active content
- Catalog - pre-prepared set of launchable elements
- Cloud providers - speak for themselves
- Users - the same, speak for themselves
From my point of view, I would find it odd, to search for some
artificial name describing Users, User Groups and Permissions if
everything from there is related to the User. The same is for Cloud
providers, etc.
But I understand your point. I would like to hear from others if this is
confusing for them as well?
<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.
I
know Katello has it as the first tab. I would disagree with one point
- I would say that Dashboard definitely is valuable - that's why it is a
landing page right after accessing the app. My intention was to not
necessarily show the user section, which is the most important for him
mainly at the very beginning. He still can access it through logolink
anytime. Anyway, this is nothing what I am standing 100% behind,
actually it was almost 50-50 and I chose what I felt that might worth to
try and work. Honestly, I would sleep well even if it would be placed as
the first tab in main navigation :)
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.
Agree on
this, it would be no deal to change in the future (adding one
more tab to current number of top level navigation is no problem at all).
<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.
I am happy that it makes
sense for you as well :)
Will we hide top-level (and second-level) navigation items that the
user
doesn't have permission to see? I think we should.
Exactly, you are right. You
can see idea how it might work here (user
roles):
http://conductor.jaromircoufal.cz/conductor_navigation_user-roles.pdf
-- Matt
-- Jarda
--
Jaromír Coufal
Interaction Designer
Red Hat Czech s.r.o.
Mobile: +420 724 595 508
E-mail: jcoufal(a)redhat.com
IRC: jcoufal at #cloudforms-ui, #aeolus, #brno