<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 07/19/2012 07:30 PM, Tzu-Mainn Chen
wrote:<br>
</div>
<blockquote
cite="mid:1342719032-11118-1-git-send-email-tzumainn@redhat.com"
type="cite">
<pre wrap="">This patchset is the first in an effort to create a reasonable dashboard feel to the admin pages - a single page that an administrator can view to monitor various aspects of the application.
Specifically, this patchset:
a) Re-establishes the providers index page. Instead of the providers/ page redirecting to an edit page, it now displays summary usage information about providers: current instance states by provider, and historical instance states by provider. It also displays a graph of running instance over a modifiable historical time frame.
The eventual goal will be to pull a subset of this information - say, highly-utilized provider accounts, or provider accounts with pending or errored-out instances - into the admin dashboard.
b) Generic-ize the chart code so that it is more easily re-usable.
Mainn
</pre>
</blockquote>
Hi,<br>
<br>
Some notes:<br>
<br>
I recommend dividing the provider index page into two content
sections (the providers table and graph section) and add the
corresponding titles to them (Providers, Activity) so the structure
will look like:<br>
%section.content-section (the provider class here is obsolette)<br>
%header<br>
%h2.providers Providers<br>
.content<br>
#render the whole table here<br>
%section.content-section<br>
%header<br>
%h2.activity<br>
.content<br>
#render the graph here<br>
<br>
for structure view see here:
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a
href="https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Detailed_architecture_of_the_Conductor_UI">https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Detailed_architecture_of_the_Conductor_UI</a><br>
(Old but last we have design of activity sections can be seen here
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a
href="https://github.com/aeolusproject/aeolus-ux-designs/blob/master/admin_ux_flats/ProviderDetail_AlertHidden.png">https://github.com/aeolusproject/aeolus-ux-designs/blob/master/admin_ux_flats/ProviderDetail_AlertHidden.png</a>)<br>
<br>
The edit page should have the return_to link in page-header to be
able to get to the providers index page. (note: putting the cancel
button below the form is not semantically correct as edit page has
several tabs)<br>
<br>
I would recommend to remove New Provider link from the
provider-select dropdown.<br>
<br>
Provider select should be probably removed from the New Provider
page. It's a good idea to keep provider select in edit page, only
the label should be more something like "Switch to provider:"<br>
<br>
The filter in providers table should filter the data in the table
(check how its done)<br>
If I understand it correctly the filter that is currently in the
table head influences the graph, not the table. So in my opinion the
table itself should contain search and maybe some preset filter to
enable filtering the providers list and then create separate filter
for the graph data that will be put into graph's content-section:<br>
%header<br>
.section-controls<br>
#the filter should go here<br>
<br>
You can see this used in deployable detail page. If the filter is
long, it will automaticvally drop below the h2.<br>
<br>
We should discuss whether we will want to do batch removing of
providers with the use of checkboxes and delete button in Provider
list table (note that checkbox_table class is used by js and is only
relevant if the table includes checkboxes) In my opinion we should
have the checkboxes in the table and provider delete button to the
table head to keep it consistent across the application. (This
functionality will require multi_destroy method in
providers_controller)<br>
<br>
I have also added some comments to individual patch emails.<br>
<br>
Jirka<br>
<br>
</body>
</html>