<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>
    &nbsp;&nbsp;&nbsp; %header<br>
    &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; %h2.providers Providers<br>
    &nbsp;&nbsp;&nbsp; .content<br>
    &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; #render the whole table here<br>
    %section.content-section<br>
    &nbsp;&nbsp;&nbsp; %header<br>
    &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; %h2.activity<br>
    &nbsp;&nbsp;&nbsp; .content<br>
    &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; #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>
    &nbsp;&nbsp;&nbsp; .section-controls<br>
    &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; #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>