----- Original Message -----
From: "Jirka Tomasek" <jtomasek(a)redhat.com>
To: aeolus-devel(a)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(a)redhat.com>
>> To: "aeolus-devel" <aeolus-devel(a)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(a)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