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.
==== Goals ==== - Make user oriented in the system - Allow user to quick navigate through the system - Show to user as much as possible within at least steps as possible (but don't overwhelm him) - Don't get user lost (at least not easily) - If user gets lost recover him fast
===== 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).
====== Structure ====== *Cloud Environments* (everything related to active content) - Overview - Cloud Environments - Resource Zones - AppForms
*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
===== Concept ===== - *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.
- Under each item from the second tier is list of all its elements in table view
- There is one exception - first page of Cloud Environemnts = Overview (currently will be substituted by Monitor page)
========== Implementation ========== Currently we are missing following table views: - Cloud Environments - Resource Zones - AppForms - AppForm Outlines - Provider Accounts - Provider Selection
Other views are already implemented, so we can just relocate them with very small adjustments. (Details in link below Summary section)
====== Summary ======
Here is summary of the whole restructuring: http://conductor.jaromircoufal.cz/new_conductor-ui_navigation-restructuring....
Here is image for preview of the structure: http://conductor.jaromircoufal.cz/conductor_overview.png
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.
Looking forward to hearing from you -- Jarda
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
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
On 11/15/2012 07:57 PM, Jaromír Coufal wrote:
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.
==== Goals ====
- Make user oriented in the system
- Allow user to quick navigate through the system
- Show to user as much as possible within at least steps as possible
(but don't overwhelm him)
- Don't get user lost (at least not easily)
- If user gets lost recover him fast
This is good stuff Jaromir. My only concern, as you alluded to, is it's a bit of a "start from scratch" approach. If we can do that, wonderful! But if it's too big a hill to climb then could we make these changes more iteratively?
I recently posted some possible approaches[1]. The concepts are much less specific than yours. (I'm not a designer!) 1. Is it really a navigation problem or rather not taking advantage of our table widget model? It seems we don't display enough information so we end up with many page views, therefore confusing the user. Your solution addresses this nicely and my proposal is to apply this throughout the site. 2. Clean up and consolidate permissions management 3. Remove monitoring redundancy 4. Clean up UI antipatterns
Regarding the "skin", could we not just update the design of how the current tabs are displayed and achieve the same results? For example, under Users we have tabs Users, User Groups and Permissions.
-Aaron [1] http://blog.aeolusproject.org/rethinking-the-ui-part-1-actions-table/
===== 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).
====== Structure ====== *Cloud Environments* (everything related to active content) - Overview - Cloud Environments - Resource Zones - AppForms
*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
===== Concept =====
- *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.
- Under each item from the second tier is list of all its elements in
table view
- There is one exception - first page of Cloud Environemnts = Overview
(currently will be substituted by Monitor page)
========== Implementation ========== Currently we are missing following table views:
- Cloud Environments
- Resource Zones
- AppForms
- AppForm Outlines
- Provider Accounts
- Provider Selection
Other views are already implemented, so we can just relocate them with very small adjustments. (Details in link below Summary section)
====== Summary ======
Here is summary of the whole restructuring: http://conductor.jaromircoufal.cz/new_conductor-ui_navigation-restructuring....
Here is image for preview of the structure: http://conductor.jaromircoufal.cz/conductor_overview.png
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.
Looking forward to hearing from you -- Jarda
On 11/15/2012 07:57 PM, Jaromír Coufal wrote:
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.
==== Goals ====
- Make user oriented in the system
- Allow user to quick navigate through the system
- Show to user as much as possible within at least steps as
possible (but don't overwhelm him)
- Don't get user lost (at least not easily)
- If user gets lost recover him fast
This is good stuff Jaromir. My only concern, as you alluded to, is it's a bit of a "start from scratch" approach. If we can do that, wonderful! But if it's too big a hill to climb then could we make these changes more iteratively?
I recently posted some possible approaches[1]. The concepts are much less specific than yours. (I'm not a designer!)
- Is it really a navigation problem or rather not taking advantage
of our table widget model? It seems we don't display enough information so we end up with many page views, therefore confusing the user. Your solution addresses this nicely and my proposal is to apply this throughout the site.
Just to address this particular question - in my opinion, it is absolutely a navigation problem. I agree that the table widget is nice, but that fixes specific pages. Jaromir's point (which I agree with) is that it's hard to even navigate to that specific page right now. If a first time user started up Conductor, he'd have no instinctive way to know where to manage providers.
Mainn
On 12/04/2012 10:27 AM, Tzu-Mainn Chen wrote:
Just to address this particular question - in my opinion, it is absolutely a navigation problem. I agree that the table widget is nice, but that fixes specific pages. Jaromir's point (which I agree with) is that it's hard to even navigate to that specific page right now. If a first time user started up Conductor, he'd have no instinctive way to know where to manage providers.
Mainn
Yes, navigation is broken, but just fixing the site map is not a very difficult problem. Jaromír's wireframes address a deeper issue which is solved by leveraging a widget model (soon to be part of Converge-ui/Alchemy?[1]). Along the way, as my post suggests, we're able to simplify navigation.
-Aaron [1] https://fedorahosted.org/katello/wiki/Server%20Containers https://fedorahosted.org/katello/wiki/Organization
From: "Aaron Weitekamp" aweiteka@redhat.com To: "Tzu-Mainn Chen" tzumainn@redhat.com Cc: "aeolus-devel" aeolus-devel@lists.fedorahosted.org, "Jaromír Coufal" jcoufal@redhat.com Sent: Tuesday, December 4, 2012 11:05:08 AM Subject: Re: RFC: Navigation restructuring
On 12/04/2012 10:27 AM, Tzu-Mainn Chen wrote:
Just to address this particular question - in my opinion, it is absolutely a navigation problem. I agree that the table widget is nice, but that fixes specific pages. Jaromir's point (which I agree with) is that it's hard to even navigate to that specific page right now. If a first time user started up Conductor, he'd have no instinctive way to know where to manage providers.
Mainn
Yes, navigation is broken, but just fixing the site map is not a very difficult problem. Jaromír's wireframes address a deeper issue which is solved by leveraging a widget model (soon to be part of Converge-ui/Alchemy?[1]). Along the way, as my post suggests, we're able to simplify navigation.
We might just be arguing over approach here. I'm no usability expert, but I think that taking a step back and asking: "how does a user want to use Conductor?" makes sense. And when asking that question, I think it makes sense to start with site navigation and clearly define how it should work. The page content is definitely an issue as well, but I don't think it's a deeper issue than our navigation.
Mainn
-Aaron [1] https://fedorahosted.org/katello/wiki/Server%20Containers https://fedorahosted.org/katello/wiki/Organization
On 12/04/2012 11:30 AM, Tzu-Mainn Chen wrote:
From: "Aaron Weitekamp" aweiteka@redhat.com To: "Tzu-Mainn Chen" tzumainn@redhat.com Cc: "aeolus-devel" aeolus-devel@lists.fedorahosted.org, "Jaromír Coufal" jcoufal@redhat.com Sent: Tuesday, December 4, 2012 11:05:08 AM Subject: Re: RFC: Navigation restructuring
On 12/04/2012 10:27 AM, Tzu-Mainn Chen wrote:
Just to address this particular question - in my opinion, it is absolutely a navigation problem. I agree that the table widget is nice, but that fixes specific pages. Jaromir's point (which I agree with) is that it's hard to even navigate to that specific page right now. If a first time user started up Conductor, he'd have no instinctive way to know where to manage providers.
Mainn
Yes, navigation is broken, but just fixing the site map is not a very difficult problem. Jaromír's wireframes address a deeper issue which is solved by leveraging a widget model (soon to be part of Converge-ui/Alchemy?[1]). Along the way, as my post suggests, we're able to simplify navigation.
We might just be arguing over approach here. I'm no usability expert, but I think that taking a step back and asking: "how does a user want to use Conductor?" makes sense. And when asking that question, I think it makes sense to start with site navigation and clearly define how it should work. The page content is definitely an issue as well, but I don't think it's a deeper issue than our navigation.
Mainn
I think you're right. And you make a great point about first considering use cases: defining workflows and modeling our UI against that. Personas -> use cases -> wireframes/nav
-Aaron
-Aaron [1] https://fedorahosted.org/katello/wiki/Server%20Containers https://fedorahosted.org/katello/wiki/Organization
On 4.12.2012 17:30, Tzu-Mainn Chen wrote:
[snip]
We might just be arguing over approach here. I'm no usability expert, but I think that taking a step back and asking: "how does a user want to use Conductor?" makes sense. And when asking that question, I think it makes sense to start with site navigation and clearly define how it should work. The page content is definitely an issue as well, but I don't think it's a deeper issue than our navigation.
Agree. As I described earlier, site content is next step of the whole concept change. First is to make user oriented in our application and then give him such views, so he can expect functionalities on the same obvious places.
-- Jarda
Mainn
On 12/05/2012 05:34 AM, Jaromír Coufal wrote:
On 4.12.2012 17:30, Tzu-Mainn Chen wrote:
[snip]
We might just be arguing over approach here. I'm no usability expert, but I think that taking a step back and asking: "how does a user want to use Conductor?" makes sense. And when asking that question, I think it makes sense to start with site navigation and clearly define how it should work. The page content is definitely an issue as well, but I don't think it's a deeper issue than our navigation.
Agree. As I described earlier, site content is next step of the whole concept change. First is to make user oriented in our application and then give him such views, so he can expect functionalities on the same obvious places.
-- Jarda
Jaromír, thanks for your responses. It's difficult to get a sense of the "UI roadmap" since I wasn't at the the developer conference and missed your presentation. I gather that "2.0" is going to be very different. I'm trying to understand where priorities are short-term, (<6 months?). Do you have a document, wiki page or presentation that might help me?
-Aaron
Mainn
Hello Aaron
here are presentations from the conference: https://redmine.aeolusproject.org/redmine/projects/aeolus/wiki/Presentations.
Roadmap and priorities are following: 1) create missing views 2) apply new navigation 3) unify views (tables, details) 4) two-pane concept
We are currently at the stage 1.
-- Jarda
On 6.12.2012 15:28, Aaron Weitekamp wrote:
On 12/05/2012 05:34 AM, Jaromír Coufal wrote:
On 4.12.2012 17:30, Tzu-Mainn Chen wrote:
[snip]
We might just be arguing over approach here. I'm no usability expert, but I think that taking a step back and asking: "how does a user want to use Conductor?" makes sense. And when asking that question, I think it makes sense to start with site navigation and clearly define how it should work. The page content is definitely an issue as well, but I don't think it's a deeper issue than our navigation.
Agree. As I described earlier, site content is next step of the whole concept change. First is to make user oriented in our application and then give him such views, so he can expect functionalities on the same obvious places.
-- Jarda
Jaromír, thanks for your responses. It's difficult to get a sense of the "UI roadmap" since I wasn't at the the developer conference and missed your presentation. I gather that "2.0" is going to be very different. I'm trying to understand where priorities are short-term, (<6 months?). Do you have a document, wiki page or presentation that might help me?
-Aaron
Mainn
On 4.12.2012 17:05, Aaron Weitekamp wrote:
On 12/04/2012 10:27 AM, Tzu-Mainn Chen wrote:
Just to address this particular question - in my opinion, it is absolutely a navigation problem. I agree that the table widget is nice, but that fixes specific pages. Jaromir's point (which I agree with) is that it's hard to even navigate to that specific page right now. If a first time user started up Conductor, he'd have no instinctive way to know where to manage providers.
Mainn
Yes, navigation is broken, but just fixing the site map is not a very difficult problem.
I have to disagree, It is really huge problem. Once you change sitemap, you need to have unified views all across the app. We even don't have views for each and every item from the new navigation map. And even more it is not easy do decide, how should the navigation look like and what concept to keep to make it as easy as possible for the most user types (personas).
Jaromír's wireframes address a deeper issue which is solved by leveraging a widget model (soon to be part of Converge-ui/Alchemy?[1]).
Whole table concepts should be part of Alchemy in the future. The goal is to have one concept specified in the library and use it all across the app, not to repeat ourselves and not to give opportunity to implement each view differently. But what Katello does is not coordinated with Aeolus right now and partly it is little bit different from what will we need in the future. But this is longer term goal.
Along the way, as my post suggests, we're able to simplify navigation.
By "action table" you can simplify navigation. It might help with some use cases, but they are not significantly important as others right now and furthermore in many cases we even can't use batch functions in many cases. Anyway it's not a problem to add them to the concept I suggested.
-Aaron [1] https://fedorahosted.org/katello/wiki/Server%20Containers https://fedorahosted.org/katello/wiki/Organization
-- Jarda
Exactly Mainn, thank you for pointing this out. It is real problem even for developers who are working with the app everyday. Can you imagine user coming to the application for the first time?
-- Jarda
On 4.12.2012 16:27, Tzu-Mainn Chen wrote:
[snip]
Just to address this particular question - in my opinion, it is absolutely a navigation problem. I agree that the table widget is nice, but that fixes specific pages. Jaromir's point (which I agree with) is that it's hard to even navigate to that specific page right now. If a first time user started up Conductor, he'd have no instinctive way to know where to manage providers.
Mainn
Hey Aaron,
thank you for you response.
On 4.12.2012 16:14, Aaron Weitekamp wrote:
This is good stuff Jaromir. My only concern, as you alluded to, is it's a bit of a "start from scratch" approach. If we can do that, wonderful! But if it's too big a hill to climb then could we make these changes more iteratively?
If you look over all the discussions, this is longterm concept, what to achieve in the future, what could help us to serve better UX. It is partly start from the scratch, but I tried to align it with concepts we have now. In other mails, it is described, that there are about 4 steps, which we need to take one-by-one to end with this solution. It's not possible to achieve it in one big step.
1) Create missing views 2) Navigation restructuring 3) Unify detailed views 4) Two pane layout
I recently posted some possible approaches[1]. The concepts are much less specific than yours. (I'm not a designer!)
- Is it really a navigation problem or rather not taking advantage of
our table widget model? It seems we don't display enough information so we end up with many page views, therefore confusing the user. Your solution addresses this nicely and my proposal is to apply this throughout the site.
The biggest problem is really a navigation problem which corresponds also with workflows.
- Clean up and consolidate permissions management
Under process - Jeremy is working on UI around permissions, my concept of navigation restructuring addresses this as well (hiding unused parts)
- Remove monitoring redundancy
Monitor will work only as monitor - no management there. We need an overview and monitor is good way how to show this to user. But it will be little bit differently taken than now.
- Clean up UI antipatterns
Depends what you need with this, but this is mostly what we are trying to solve through the time. Unify views and use patterns all across the application.
Regarding the "skin", could we not just update the design of how the current tabs are displayed and achieve the same results? For example, under Users we have tabs Users, User Groups and Permissions.
I never addressed skin. The look is secondary in this moment.
-Aaron [1] http://blog.aeolusproject.org/rethinking-the-ui-part-1-actions-table/
One more time, thanks for comments, they are really valuable. This is great conversation, maybe just not very well suitable for blog posts, but more for mailing lists, like this one.
-- Jarda
aeolus-devel@lists.fedorahosted.org
-
Aaron Weitekamp -
Jaromir Coufal -
Matt Wagner -
Tzu-Mainn Chen