Hi,
I've recently outlined a proposal to add reports and statistical data to conductor. The link is below, but first here's a summary of the idea.
Conductor is currently very straightforward in what it does: it creates, modifies, and destroys entities of various types. These are the most important functions, of course, but now that they are somewhat established, I think it'd be useful to think a bit beyond that. To give an example: when you first start up and install conductor, you'll probably want to do a lot of configuration with, say, providers and provider accounts. However, after that initial work, your needs are likely to be much different. On the provider level, you might want to see things like utilization over the past week, or providers that have thrown errors, etc.
I've recently pushed a patch that provides such data to the provider index page. It should provide a good, working illustration of what I'm talking about (and it also re-creates a missing index page, so no toes were stepped on!) I'd like to start adding similar data to other pages, but I wanted to see other people's thoughts first.
A summarized goal list would be as follows:
a) create libraries to help with re-use of graph and statistics code b) add statistics and data to various index and show pages c) create a dashboard that pulls "key" information from around the website. For example, it might include the most utilized/error-prone provider accounts and deployables; overall utilization for the past week; etc.
https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Add_Targeted_Repo...
Thanks, Tzu-Mainn Chen
On 07/23/2012 09:48 PM, Tzu-Mainn Chen wrote:
Hi,
I've recently outlined a proposal to add reports and statistical data to conductor. The link is below, but first here's a summary of the idea.
Conductor is currently very straightforward in what it does: it creates, modifies, and destroys entities of various types. These are the most important functions, of course, but now that they are somewhat established, I think it'd be useful to think a bit beyond that. To give an example: when you first start up and install conductor, you'll probably want to do a lot of configuration with, say, providers and provider accounts. However, after that initial work, your needs are likely to be much different. On the provider level, you might want to see things like utilization over the past week, or providers that have thrown errors, etc.
I've recently pushed a patch that provides such data to the provider index page. It should provide a good, working illustration of what I'm talking about (and it also re-creates a missing index page, so no toes were stepped on!) I'd like to start adding similar data to other pages, but I wanted to see other people's thoughts first.
A summarized goal list would be as follows:
a) create libraries to help with re-use of graph and statistics code b) add statistics and data to various index and show pages c) create a dashboard that pulls "key" information from around the website. For example, it might include the most utilized/error-prone provider accounts and deployables; overall utilization for the past week; etc.
https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Add_Targeted_Repo...
Thanks, Tzu-Mainn Chen
Hi,
based on your providers patch, I like the idea of having statistical data available, but I think it is necessary not to forget to maintain the basic list of (users, pool_families, pools etc.) and possibility to filter and maintain this data. As a user I want to be able to see the list of providers (users etc.) and be able to filter this list, remove and add data to this list. This kind of conflicts with the provider statistics list as the filter there filters the data from the statistics point of view. So what I propose is to keep the current index views and add the "Statistics" tab that would contain the data and filters you propose. Othervise we might be loosing finctionality in spite of another finctionality.
Also Jaromir could have valuable input on how to display these data.
Jirka
----- Original Message -----
From: "Jirka Tomasek" jtomasek@redhat.com To: aeolus-devel@lists.fedorahosted.org Sent: Tuesday, July 24, 2012 4:12:56 AM Subject: Re: RFC: Adding Useful reports and Statistical Data
On 07/23/2012 09:48 PM, Tzu-Mainn Chen wrote:
Hi,
I've recently outlined a proposal to add reports and statistical data to conductor. The link is below, but first here's a summary of the idea.
Conductor is currently very straightforward in what it does: it creates, modifies, and destroys entities of various types. These are the most important functions, of course, but now that they are somewhat established, I think it'd be useful to think a bit beyond that. To give an example: when you first start up and install conductor, you'll probably want to do a lot of configuration with, say, providers and provider accounts. However, after that initial work, your needs are likely to be much different. On the provider level, you might want to see things like utilization over the past week, or providers that have thrown errors, etc.
I've recently pushed a patch that provides such data to the provider index page. It should provide a good, working illustration of what I'm talking about (and it also re-creates a missing index page, so no toes were stepped on!) I'd like to start adding similar data to other pages, but I wanted to see other people's thoughts first.
A summarized goal list would be as follows:
a) create libraries to help with re-use of graph and statistics code b) add statistics and data to various index and show pages c) create a dashboard that pulls "key" information from around the website. For example, it might include the most utilized/error-prone provider accounts and deployables; overall utilization for the past week; etc.
https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Add_Targeted_Repo...
Thanks, Tzu-Mainn Chen
Hi,
based on your providers patch, I like the idea of having statistical data available, but I think it is necessary not to forget to maintain the basic list of (users, pool_families, pools etc.) and possibility to filter and maintain this data. As a user I want to be able to see the list of providers (users etc.) and be able to filter this list, remove and add data to this list. This kind of conflicts with the provider statistics list as the filter there filters the data from the statistics point of view. So what I propose is to keep the current index views and add the "Statistics" tab that would contain the data and filters you propose. Othervise we might be loosing finctionality in spite of another finctionality.
Also Jaromir could have valuable input on how to display these data.
Jirka
Actually, I don't *think* I filter the providers list from a statistics point of view; I provide a date range filter that changes the statistics in the table, but it shouldn't change the actual list. My goal would be to keep both the current filter and add a date range filter. If it becomes overwhelming, I agree, separate tabs makes sense.
Generally speaking, my goal for 1.1 would be to make non-disruptive changes - additive, without taking current functionality away (that's why I started with the previous non-existent providers index page), while also building up a code library to ease future changes.
Mainn
On 07/24/2012 07:01 PM, Tzu-Mainn Chen wrote:
----- Original Message -----
From: "Jirka Tomasek" jtomasek@redhat.com To: aeolus-devel@lists.fedorahosted.org Sent: Tuesday, July 24, 2012 4:12:56 AM Subject: Re: RFC: Adding Useful reports and Statistical Data
On 07/23/2012 09:48 PM, Tzu-Mainn Chen wrote:
Hi,
I've recently outlined a proposal to add reports and statistical data to conductor. The link is below, but first here's a summary of the idea.
Conductor is currently very straightforward in what it does: it creates, modifies, and destroys entities of various types. These are the most important functions, of course, but now that they are somewhat established, I think it'd be useful to think a bit beyond that. To give an example: when you first start up and install conductor, you'll probably want to do a lot of configuration with, say, providers and provider accounts. However, after that initial work, your needs are likely to be much different. On the provider level, you might want to see things like utilization over the past week, or providers that have thrown errors, etc.
I've recently pushed a patch that provides such data to the provider index page. It should provide a good, working illustration of what I'm talking about (and it also re-creates a missing index page, so no toes were stepped on!) I'd like to start adding similar data to other pages, but I wanted to see other people's thoughts first.
A summarized goal list would be as follows:
a) create libraries to help with re-use of graph and statistics code b) add statistics and data to various index and show pages c) create a dashboard that pulls "key" information from around the website. For example, it might include the most utilized/error-prone provider accounts and deployables; overall utilization for the past week; etc.
https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Add_Targeted_Repo...
Thanks,
Tzu-Mainn Chen
Hi,
based on your providers patch, I like the idea of having statistical data available, but I think it is necessary not to forget to maintain the basic list of (users, pool_families, pools etc.) and possibility to filter and maintain this data. As a user I want to be able to see the list of providers (users etc.) and be able to filter this list, remove and add data to this list. This kind of conflicts with the provider statistics list as the filter there filters the data from the statistics point of view. So what I propose is to keep the current index views and add the "Statistics" tab that would contain the data and filters you propose. Othervise we might be loosing finctionality in spite of another finctionality.
Also Jaromir could have valuable input on how to display these data.
Jirka
Actually, I don't *think* I filter the providers list from a statistics point of view; I provide a date range filter that changes the statistics in the table, but it shouldn't change the actual list. My goal would be to keep both the current filter and add a date range filter. If it becomes overwhelming, I agree, separate tabs makes sense.
Generally speaking, my goal for 1.1 would be to make non-disruptive changes - additive, without taking current functionality away (that's why I started with the previous non-existent providers index page), while also building up a code library to ease future changes.
Mainn
Hi, agree with Jirka. I was just clicking in this section now and was little bit confused of amount of data on the page (however these data were interesting). Separate tab would be better.
Jan
On 24.7.2012 10:12, Jirka Tomasek wrote:
On 07/23/2012 09:48 PM, Tzu-Mainn Chen wrote:
Hi,
I've recently outlined a proposal to add reports and statistical data to conductor. The link is below, but first here's a summary of the idea.
Conductor is currently very straightforward in what it does: it creates, modifies, and destroys entities of various types. These are the most important functions, of course, but now that they are somewhat established, I think it'd be useful to think a bit beyond that. To give an example: when you first start up and install conductor, you'll probably want to do a lot of configuration with, say, providers and provider accounts. However, after that initial work, your needs are likely to be much different. On the provider level, you might want to see things like utilization over the past week, or providers that have thrown errors, etc.
I've recently pushed a patch that provides such data to the provider index page. It should provide a good, working illustration of what I'm talking about (and it also re-creates a missing index page, so no toes were stepped on!) I'd like to start adding similar data to other pages, but I wanted to see other people's thoughts first.
A summarized goal list would be as follows:
a) create libraries to help with re-use of graph and statistics code b) add statistics and data to various index and show pages c) create a dashboard that pulls "key" information from around the website. For example, it might include the most utilized/error-prone provider accounts and deployables; overall utilization for the past week; etc.
https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Add_Targeted_Repo...
Thanks, Tzu-Mainn Chen
Hi,
based on your providers patch, I like the idea of having statistical data available, but I think it is necessary not to forget to maintain the basic list of (users, pool_families, pools etc.) and possibility to filter and maintain this data. As a user I want to be able to see the list of providers (users etc.) and be able to filter this list, remove and add data to this list. This kind of conflicts with the provider statistics list as the filter there filters the data from the statistics point of view. So what I propose is to keep the current index views and add the "Statistics" tab that would contain the data and filters you propose. Othervise we might be loosing finctionality in spite of another finctionality.
Also Jaromir could have valuable input on how to display these data.
Jirka
Hi,
without any doubts statistical data are valuable and it is really good to have that in our system. But as Jirka mentioned, we need to be careful about main purpose of administration section. Right now, statistics are preventing us from main point of administrators - as for providers it is their and account management.
In current state, imagine that you are administrators and you want to add account. How will you do that? It looks like very simple step. Very likely you will go to Administrator section, to Cloud Providers and then? No edit, no options, just statistical data which you are not interested in because you want to add account which is your current task as an administrator. And it will take some time, when you realize that you need to click on specific provider in statistical list in order to edit his accounts.
To be honest, right now with statistical data we are implementing new function, new views, but in the first line we need to revise current workflows in order to do such big change in UI structure as Min is suggesting. I just want to prevent doing things twice. There is lot of work to do in main stream of the application and in my opinion, spending time on having statistical data perfect is secondary output right now.
Idea with keeping statistics in tabs is good and I like it. I suggest temporarily place statistical data as one of the tabs (not the first one) and after revising structure we will see where to place them and how to display them. In a short time I will start working on fix of providers section to release 1.1.
Jarda
-- Jaromír Coufal
Interaction Designer Red Hat Czech s.r.o.
Mobile: +420 724 595 508 E-mail:jcoufal@redhat.com IRC: jcoufal at #cloudforms-ui, #aeolus, #brno
----- Original Message -----
From: "Jaromír Coufal" jcoufal@redhat.com To: "aeolus-devel" aeolus-devel@lists.fedorahosted.org Sent: Wednesday, July 25, 2012 6:34:21 AM Subject: Re: RFC: Adding Useful reports and Statistical Data
snip
Hi,
without any doubts statistical data are valuable and it is really good to have that in our system. But as Jirka mentioned, we need to be careful about main purpose of administration section. Right now, statistics are preventing us from main point of administrators - as for providers it is their and account management.
In current state, imagine that you are administrators and you want to add account. How will you do that? It looks like very simple step. Very likely you will go to Administrator section, to Cloud Providers and then? No edit, no options, just statistical data which you are not interested in because you want to add account which is your current task as an administrator. And it will take some time, when you realize that you need to click on specific provider in statistical list in order to edit his accounts.
To be honest, right now with statistical data we are implementing new function, new views, but in the first line we need to revise current workflows in order to do such big change in UI structure as Min is suggesting. I just want to prevent doing things twice. There is lot of work to do in main stream of the application and in my opinion, spending time on having statistical data perfect is secondary output right now.
Idea with keeping statistics in tabs is good and I like it. I suggest temporarily place statistical data as one of the tabs (not the first one) and after revising structure we will see where to place them and how to display them. In a short time I will start working on fix of providers section to release 1.1.
Jarda
Jaromír Coufal
Interaction Designer Red Hat Czech s.r.o.
Mobile: +420 724 595 508 E-mail: jcoufal@redhat.com IRC: jcoufal at #cloudforms-ui, #aeolus, #brno
Hi,
I guess this is one area where I fundamentally disagree. Our UI is full of examples where entities are kept in lists, and the expectation is that the user/admin clicks on the name in order to edit. The only difference between that and the providers index page is that the latter also happens to provide statistics. Adding an [edit] link or icon to all of these lists would make more sense to me.
The other area where I disagree is this: in the long-run, I think that the administration section *will* be more about the statistics and reports, rather than adding/editing entities. I think that the former is more likely to be needed for day-to-day operations.
Thanks, Tzu-Mainn Chen
On 25.7.2012 15:26, Tzu-Mainn Chen wrote:
----- Original Message -----
From: "Jaromír Coufal" jcoufal@redhat.com To: "aeolus-devel" aeolus-devel@lists.fedorahosted.org Sent: Wednesday, July 25, 2012 6:34:21 AM Subject: Re: RFC: Adding Useful reports and Statistical Data
snip
Hi,
without any doubts statistical data are valuable and it is really good to have that in our system. But as Jirka mentioned, we need to be careful about main purpose of administration section. Right now, statistics are preventing us from main point of administrators - as for providers it is their and account management.
In current state, imagine that you are administrators and you want to add account. How will you do that? It looks like very simple step. Very likely you will go to Administrator section, to Cloud Providers and then? No edit, no options, just statistical data which you are not interested in because you want to add account which is your current task as an administrator. And it will take some time, when you realize that you need to click on specific provider in statistical list in order to edit his accounts.
To be honest, right now with statistical data we are implementing new function, new views, but in the first line we need to revise current workflows in order to do such big change in UI structure as Min is suggesting. I just want to prevent doing things twice. There is lot of work to do in main stream of the application and in my opinion, spending time on having statistical data perfect is secondary output right now.
Idea with keeping statistics in tabs is good and I like it. I suggest temporarily place statistical data as one of the tabs (not the first one) and after revising structure we will see where to place them and how to display them. In a short time I will start working on fix of providers section to release 1.1.
Jarda
Jaromír Coufal
Interaction Designer Red Hat Czech s.r.o.
Mobile: +420 724 595 508 E-mail: jcoufal@redhat.com IRC: jcoufal at #cloudforms-ui, #aeolus, #brno
Hi,
I guess this is one area where I fundamentally disagree. Our UI is full of examples where entities are kept in lists, and the expectation is that the user/admin clicks on the name in order to edit. The only difference between that and the providers index page is that the latter also happens to provide statistics. Adding an [edit] link or icon to all of these lists would make more sense to me.
Well, it is ok to go to detail through list (or item name in this list). But in this case it is statistical list and it has different purpose. You have some historical data there. And from the very first look for me it doesn't look like list of all providers (even it can be), because I expect that it is somehow filtered.
The other area where I disagree is this: in the long-run, I think that the administration section *will* be more about the statistics and reports, rather than adding/editing entities. I think that the former is more likely to be needed for day-to-day operations.
The question is about personas use-cases. Will be the administrator the one who is responsible for watching statistics? Or is it someone else who is responsible for that? I suppose that it won't be administrator, but I don't know, I might be wrong in this.
My thoughts were heading this way (just very first ideas): * have very separate tab "Statistics" (on the same level as Users, Settings,...) and keep all detailed statistics there * have sub-tab statistics in each section (on the same level as Connectivity, Accounts,... at Provider). We can also let user to "pin" specific page as his homepage (so he can start with statistics or index page or ...)
Thanks, Tzu-Mainn Chen
Jarda
On 07/25/2012 03:26 PM, Tzu-Mainn Chen wrote:
----- Original Message -----
From: "Jaromír Coufal" jcoufal@redhat.com To: "aeolus-devel" aeolus-devel@lists.fedorahosted.org Sent: Wednesday, July 25, 2012 6:34:21 AM Subject: Re: RFC: Adding Useful reports and Statistical Data
snip
Hi,
without any doubts statistical data are valuable and it is really good to have that in our system. But as Jirka mentioned, we need to be careful about main purpose of administration section. Right now, statistics are preventing us from main point of administrators - as for providers it is their and account management.
In current state, imagine that you are administrators and you want to add account. How will you do that? It looks like very simple step. Very likely you will go to Administrator section, to Cloud Providers and then? No edit, no options, just statistical data which you are not interested in because you want to add account which is your current task as an administrator. And it will take some time, when you realize that you need to click on specific provider in statistical list in order to edit his accounts.
To be honest, right now with statistical data we are implementing new function, new views, but in the first line we need to revise current workflows in order to do such big change in UI structure as Min is suggesting. I just want to prevent doing things twice. There is lot of work to do in main stream of the application and in my opinion, spending time on having statistical data perfect is secondary output right now.
Idea with keeping statistics in tabs is good and I like it. I suggest temporarily place statistical data as one of the tabs (not the first one) and after revising structure we will see where to place them and how to display them. In a short time I will start working on fix of providers section to release 1.1.
Jarda
Jaromír Coufal
Interaction Designer Red Hat Czech s.r.o.
Mobile: +420 724 595 508 E-mail: jcoufal@redhat.com IRC: jcoufal at #cloudforms-ui, #aeolus, #brno
Hi,
I guess this is one area where I fundamentally disagree. Our UI is full of examples where entities are kept in lists, and the expectation is that the user/admin clicks on the name in order to edit. The only difference between that and the providers index page is that the latter also happens to provide statistics. Adding an [edit] link or icon to all of these lists would make more sense to me.
The other area where I disagree is this: in the long-run, I think that the administration section *will* be more about the statistics and reports, rather than adding/editing entities. I think that the former is more likely to be needed for day-to-day operations.
Thanks, Tzu-Mainn Chen
Hi,
my concern is not really on which tab or data view should we present as default view. I see problem in mixing the data list and filter set used for CRUD manipulation and data list and filter set used for statistical reasons. I think having the table with check boxes, buttons for deleting and creating new data, filter set for filtering displayed list, filter set for statistics and statistics graph is just too much information in one place.
Jirka
----- Original Message -----
From: "Jirka Tomasek" jtomasek@redhat.com To: aeolus-devel@lists.fedorahosted.org Sent: Wednesday, July 25, 2012 9:45:48 AM Subject: Re: RFC: Adding Useful reports and Statistical Data
On 07/25/2012 03:26 PM, Tzu-Mainn Chen wrote:
----- Original Message -----
From: "Jaromír Coufal" jcoufal@redhat.com To: "aeolus-devel" aeolus-devel@lists.fedorahosted.org Sent: Wednesday, July 25, 2012 6:34:21 AM Subject: Re: RFC: Adding Useful reports and Statistical Data
snip
Hi,
without any doubts statistical data are valuable and it is really good to have that in our system. But as Jirka mentioned, we need to be careful about main purpose of administration section. Right now, statistics are preventing us from main point of administrators - as for providers it is their and account management.
In current state, imagine that you are administrators and you want to add account. How will you do that? It looks like very simple step. Very likely you will go to Administrator section, to Cloud Providers and then? No edit, no options, just statistical data which you are not interested in because you want to add account which is your current task as an administrator. And it will take some time, when you realize that you need to click on specific provider in statistical list in order to edit his accounts.
To be honest, right now with statistical data we are implementing new function, new views, but in the first line we need to revise current workflows in order to do such big change in UI structure as Min is suggesting. I just want to prevent doing things twice. There is lot of work to do in main stream of the application and in my opinion, spending time on having statistical data perfect is secondary output right now.
Idea with keeping statistics in tabs is good and I like it. I suggest temporarily place statistical data as one of the tabs (not the first one) and after revising structure we will see where to place them and how to display them. In a short time I will start working on fix of providers section to release 1.1.
Jarda
Jaromír Coufal
Interaction Designer Red Hat Czech s.r.o.
Mobile: +420 724 595 508 E-mail: jcoufal@redhat.com IRC: jcoufal at #cloudforms-ui, #aeolus, #brno
Hi,
I guess this is one area where I fundamentally disagree. Our UI is full of examples where entities are kept in lists, and the expectation is that the user/admin clicks on the name in order to edit. The only difference between that and the providers index page is that the latter also happens to provide statistics. Adding an [edit] link or icon to all of these lists would make more sense to me.
The other area where I disagree is this: in the long-run, I think that the administration section *will* be more about the statistics and reports, rather than adding/editing entities. I think that the former is more likely to be needed for day-to-day operations.
Thanks, Tzu-Mainn Chen
Hi,
my concern is not really on which tab or data view should we present as default view. I see problem in mixing the data list and filter set used for CRUD manipulation and data list and filter set used for statistical reasons. I think having the table with check boxes, buttons for deleting and creating new data, filter set for filtering displayed list, filter set for statistics and statistics graph is just too much information in one place.
Jirka
Hm, these are reasonable points (as are Jaromir's); I just don't fully agree, esp. given since the layout and combination of editing/statistics is essentially the same as the pool_families/ index page, which always seemed easy enough to navigate for me. On the other hand, the pool_families page is very "distinct" from all the other pages, so, well, I dunno :)
My personal preference would be to add an edit link to the providers index page and then wait for the overall UI discussion to make more severe changes. The truth is, until we discuss and develop a consensus on what we think the workflow for a given user should be, it's going to be hard to really plan out a UI.
Mainn
----- Original Message -----
From: "Jirka Tomasek" jtomasek@redhat.com To: aeolus-devel@lists.fedorahosted.org Sent: Wednesday, July 25, 2012 9:45:48 AM Subject: Re: RFC: Adding Useful reports and Statistical Data
On 07/25/2012 03:26 PM, Tzu-Mainn Chen wrote:
----- Original Message -----
From: "Jaromír Coufal" jcoufal@redhat.com To: "aeolus-devel" aeolus-devel@lists.fedorahosted.org Sent: Wednesday, July 25, 2012 6:34:21 AM Subject: Re: RFC: Adding Useful reports and Statistical Data
snip
Hi,
without any doubts statistical data are valuable and it is really good to have that in our system. But as Jirka mentioned, we need to be careful about main purpose of administration section. Right now, statistics are preventing us from main point of administrators - as for providers it is their and account management.
In current state, imagine that you are administrators and you want to add account. How will you do that? It looks like very simple step. Very likely you will go to Administrator section, to Cloud Providers and then? No edit, no options, just statistical data which you are not interested in because you want to add account which is your current task as an administrator. And it will take some time, when you realize that you need to click on specific provider in statistical list in order to edit his accounts.
To be honest, right now with statistical data we are implementing new function, new views, but in the first line we need to revise current workflows in order to do such big change in UI structure as Min is suggesting. I just want to prevent doing things twice. There is lot of work to do in main stream of the application and in my opinion, spending time on having statistical data perfect is secondary output right now.
Idea with keeping statistics in tabs is good and I like it. I suggest temporarily place statistical data as one of the tabs (not the first one) and after revising structure we will see where to place them and how to display them. In a short time I will start working on fix of providers section to release 1.1.
Jarda
Jaromír Coufal
Interaction Designer Red Hat Czech s.r.o.
Mobile: +420 724 595 508 E-mail: jcoufal@redhat.com IRC: jcoufal at #cloudforms-ui, #aeolus, #brno
Hi,
I guess this is one area where I fundamentally disagree. Our UI is full of examples where entities are kept in lists, and the expectation is that the user/admin clicks on the name in order to edit. The only difference between that and the providers index page is that the latter also happens to provide statistics. Adding an [edit] link or icon to all of these lists would make more sense to me.
The other area where I disagree is this: in the long-run, I think that the administration section *will* be more about the statistics and reports, rather than adding/editing entities. I think that the former is more likely to be needed for day-to-day operations.
Thanks, Tzu-Mainn Chen
Hi,
my concern is not really on which tab or data view should we present as default view. I see problem in mixing the data list and filter set used for CRUD manipulation and data list and filter set used for statistical reasons. I think having the table with check boxes, buttons for deleting and creating new data, filter set for filtering displayed list, filter set for statistics and statistics graph is just too much information in one place.
Jirka
Now that I think about it, would it make more sense to distinguish between *current* statistics and historical statistics? I could see the former being part of the "main" list view, and the latter being part of a different tab.
Mainn
On 26/07/2012, at 2:34 AM, Tzu-Mainn Chen wrote: <snip>
Now that I think about it, would it make more sense to distinguish between *current* statistics and historical statistics? I could see the former being part of the "main" list view, and the latter being part of a different tab.
For a historical tab, how about something on the top tab level?
i.e. "Monitor" "Administer" "Reporting"
Though, as Scott mentions those top headings and generally "what goes where" should be looked at anyway. ;)
+ Justin
-- Aeolus Community Manager http://www.aeolusproject.org
On 07/25/2012 09:26 AM, Tzu-Mainn Chen wrote:
----- Original Message -----
From: "Jaromír Coufal"jcoufal@redhat.com To: "aeolus-devel"aeolus-devel@lists.fedorahosted.org Sent: Wednesday, July 25, 2012 6:34:21 AM Subject: Re: RFC: Adding Useful reports and Statistical Data
snip
Hi,
without any doubts statistical data are valuable and it is really good to have that in our system. But as Jirka mentioned, we need to be careful about main purpose of administration section. Right now, statistics are preventing us from main point of administrators - as for providers it is their and account management.
In current state, imagine that you are administrators and you want to add account. How will you do that? It looks like very simple step. Very likely you will go to Administrator section, to Cloud Providers
One thing to keep in mind, we have no "administration" section as such -- the "administer" tab is badly-named and we need to revisit. The top level tabs ("monitor" and "administer") are, contrary to what might be implied by the current names, not splitting by function, but by resource type. "Monitor" contains pool/deployment/instance-level stuff, and "administer" contains provider, pool family, image management, etc. The point is that for a given resource, you don't go to one tab to "use" it and the other to "administer" it -- for pools, user-level and admin-level functions are on the same page. If you lack the proper admin-level permissions, that stuff is hidden from you. Same with images, pool families, providers on the "administer" side -- the same pages are used for user-level and admin-level stuff, with some things hidden based on permissions.
Also, keep in mind that the notion of "user" and "adminstrator" doesn't indicate a strict user category. Although there are site-wide admin users, most users will have admin-level functionality in some limited sense on certain resources. Some users may be admins for one pool, or one provider only, but on other pools/providers they are not. Any user that launches something will have admin-level permissions on those particular instances, etc.
Scott
aeolus-devel@lists.fedorahosted.org
-
Jan Provazník -
Jaromir Coufal -
Jirka Tomasek -
Justin Clift -
Scott Seago -
Tzu-Mainn Chen