----- Original Message -----
From: "Nick Coghlan" <ncoghlan(a)redhat.com>
To: beaker-dev-list(a)redhat.com
Sent: Tuesday, February 26, 2013 1:35:24 PM
Subject: Re: Reorganising Power tab
On 02/26/2013 01:01 PM, Dan Callaghan wrote:
> Excerpts from Raymond Mancy's message of 2013-02-25 22:24:14 +1000:
>> A new BZ which enables us to manually clear netboot configuration
>> files is causing
>> the Power and Provision tabs to become a bit confusing.
>>
>> Currently, the 'Recent Power Commands' table on the 'Power' tab
is
>> used to display
>> recent entries in the CommandActivity table. This table actually
>> records both
>> power and provisioning actions (and perhaps anything else we deem
>> necessary in the
>> future). So if you want to show the user their operation has been
>> successfully queued
>> , the operation needs to happen on the 'Power' tab.
>>
>> I suggest that we remove the CommandActivity table out of the
>> Power tab
>> and give it its own tab, similar to the history tab. That way we
>> can make it a
>> first class citizen in its own right without compromising the UI.
>> We also
>> then avoid the trap of feeling that we have to group things onto a
>> tab
>> based on underlying implementation realities.
>
> Does that mean the command buttons (Power On, Power Off, Reboot,
> Interrupt, and the forthcoming Clear Netboot) will all move to the
> new
> Command tab also?
I actually thought the conclusion of the IRC discussion was that we
would simply rename the existing Power tab to "Commands" rather than
creating a new tab.
It was, but I dont' think that is the right conclusion. I'm not a UX designer,
but to me it doesn't make sense to arrange items together just because
they happen to use the same underlying communication mechanism (in this case
the CommandActivity table), when they are otherwise more or less unrelated in their
purpose. It would be akin to arranging everything together just because they yse
XMLRPC. I think clearing the netboot files from the same place where we create
them makes as much sense as anything else.
Cheers,
Nick.
P.S. I don't see any reason for this thread to be on the internal dev
list rather than the public one. Please default to the public list
for
any Beaker design discussions that don't touch on the RH internal
Beaker
instance or HSS internal processes.
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
Python Applications Team Lead
Beaker Development Lead (
http://beaker-project.org/)
PulpDist Development Lead (
http://pulpdist.readthedocs.org)
--
This is a Red Hat internal mailing list