Vreman, Peter - Acision wrote:
>>> Change sidebar from a static list and add menu to a nested menu
>>> structure. Only for the current selected target distro/system the
>>> operations will be shown. The menu structure will be like the CLI:
>>>
>>> Systems
>>>             Add
>>>             Delete
>>>             Poweron
>>>             Poweroff
>>>             Reboot
>>>             Enable PXE
>>>             Change profile
>>>       
>> Grouping  the "list" and "add" things together is ok, though I like your
>> original "dashboard" idea for surfacing some commonly used functions
>> better than this proposal.   I also see "edit" missing.
>>
>> For instance, on the "systems list" page, we can add something like the
>> following:
>>
>> SYSTEM  |   (Profile Drop Down with Current Profile Shown) |  | (No
>> Change | Power On | Power Off | Reboot)
>> SYSTEM  |   (Profile Drop Down with Current Profile Shown) | (Netboot
>> Enabled | Disabled) | (No Change | Power On | Power Off | Reboot)
>> SYSTEM  |   (Profile Drop Down with Current Profile Shown) | (Netboot
>> Enabled | Disabled) | (No Change | Power On | Power Off | Reboot)
>> SYSTEM  |   (Profile Drop Down with Current Profile Shown) | (Netboot
>> Enabled | Disabled) | (No Change | Power On | Power Off | Reboot)
>> SYSTEM  |   (Profile Drop Down with Current Profile Shown) | (Netboot
>> Enabled | Disabled) | (No Change | Power On | Power Off | Reboot)
>>
>> [ Apply changes button at the bottom ]
>>
>> One roadblock with adding import is that it can be /very/ slow, so
>> that's why it's not present now.  The same goes for reposync.
>> To solve this adequately, we need to build a task engine that can log
>> the output of background processes.   In the future, this is something
>> I want to enable, as it will also enable folks to run reposync and
>> import from the XMLRPC API's.
>>     
>
> There are several reasons why I changed to this new proposal:
> - You can now run an action easier on multiple systems. With a toggle-all 
> button all systems are quickly selected. Maybe with an additional filter you 
> can first filter and then also use the toggle-all
>   

Ok, I think I understand a bit more.

I'm still a rather visual person so I think I could benefit from seeing 
a rough mockup. If it looks like a 3rd grader did in five minutes in 
mspaint (aka "something like I would draw" I don't care, but it would 
help me tremendously :)



> - A confirmation screen with the affected systems can be given. This is 
> better for safety, especially with the power options. The confirmation screen 
> can also be used for asking the additional input of values like the profile 
> or netboot.
>   

I'm not sure I understand this part either, and is another case where an 
example might help.
> - The pull-down boxes require of mousemovement to set everything correct
>   

I can agree with limiting scrolling. Could this also not be solved by 
having different tabs when editing things? We could have one tab for 
virt settings, one for network settings, etc, and that way just limit 
the vertical scrolling.

> - Normally you want to apply the same action on all systems. Using the 
> pull-down boxes this requires manual verification.
>   

I would disagree with the idea that I want to apply the same action to 
all systems. For example, if I'm adding a kernel argument that just one 
system needs, I would be editing just this one system.

Similarly, if I am deciding to reinstall one system that was comprimised 
and/or "really broken" that's something I want to do to just one system.

Also, are you saying the manual verification bits are good or bad? I 
think they are generally a good thing and for wholesale changes I'm more 
likely to write a script or (even more likely) use cobbler find + xargs. 
I realize all users don't fall into that mode, however, so it would be 
nice to have options.
> - With multiple actions in a single apply the confirmation becomes complex.
>
>
> Regards,
> Peter
>
> This e-mail and any attachment is for authorised use by the intended 
> recipient(s) only. It may contain proprietary material, confidential 
> information and/or be subject to legal privilege. It should not be copied, 
> disclosed to, retained or used by, any other party. If you are not an 
> intended recipient then please promptly delete this e-mail and any attachment 
> and all copies and inform the sender. Thank you.
>
>
> _______________________________________________
> cobbler mailing list
> [email protected]
> https://fedorahosted.org/mailman/listinfo/cobbler
>   

_______________________________________________
cobbler mailing list
[email protected]
https://fedorahosted.org/mailman/listinfo/cobbler

Reply via email to