[Ovirt-devel] Re: oVirt server wui console integration

[Mohammed Morsi]

Jeremy Perry wrote:
> I've posted the mockups and descriptions mentioned here to the the
> ovirt.org wiki:
> http://ovirt.org/page/Terminal_UX
>
> one more comment below...
>
> On Jan 8, 2009, at 10:04 PM, Jason Guiditta wrote:
>
>> On Thu, 2009-01-08 at 18:23 -0500, Jeremy Perry wrote:
>>> On Jan 8, 2009, at 5:37 PM, Mohammed Morsi wrote:
>>>
>>>> Currently the idea for the console interface in the wui is that a user
>>>> can navigate the the 'virtual machines' tab under a vm pool, click
>>>> on a
>>>> specific vm, click on 'console' in the details pane and will be
>>>> presented with a console to that vm. There were a few ideas as to
>>>> where
>>>> the console should appear,
>>>>
>>>> * in a minimally themed popup window, most likely the first
>>>> implementation as it is simplest, but may result in many popups when
>>>> connected to several vms
>>>> * in the dialog / popup box interface we have now, we will want to
>>>> introduce a tabbing mechanism for access to multiple vm consoles
>>>> * in another tab in the main content area, same vm-tab concept
>>>> needed here
>>>> * a rollover, eg the user rolls over 'console' in the vm details pane
>>>> and the console appears so long as the user holds his mouse over it /
>>>> the link
>>>>
>>> I've taken the liberty of mocking some of these ideas up.
>>>
>>> I didnt mockup the new themed popup window yet, since its simple to
>>> imagine. I think its a decent approach, but wondering if we can
>>> eliminate the multiple popups issue by targeting our popup once there
>>> is at least one open. Subsequent terminals would nest via tabs in the
>>> one terminal window, so all you deal with is one window with tabs for
>>> each vm terminal.
>>
>> I like the idea of the popup window, then adding tabs to it as needed,
>> and like the pop-out (thanks google!).  My first choice is the design
>> with the initial console on the right of the details in the same pane.
>> The other with them stacked felt too squished.  The tabbed one could
>> work too, but I kind of think the terminal being in the detail pane is
>> not super usable, since you can't see that much in the space allowed.  I
>> agree on the modal dialog thing, no need to force them to have only that
>> accessible, but another idea could be a non-modal dialog that you could
>> minimize somewhere w/in the application.  If done right, I think this
>> could be pretty slick, but perhaps not worth the effort, as the single
>> popup window seems like a perfectly good way to go.
>
> I agree on the popup window, and will take a stab at it. As for the
> non-modal idea, this would be pretty cool to look at. Well executed
> examples in the wild is Google chat in gmail and the alerts/etc bar in
> facebook.

I also agree that the terminal in the details pane seems a bit squished.
I'm not sure if we'd be able to do this immediately, but I'd think we'd
also want to support terminal resizing at some point  in the future
(size saved in the user preferences system when we have it). I also like
the idea of the non-modal dialog, perhaps we can 'minimize' it to the
dashboard so that a user can maintain active terminal sessions between
uses of the ovirt wui.


>
>>
>>>
>>>> Its currently looking like the console frontend and apache-proxied
>>>> backend daemon will be driven by anyterm http://anyterm.org/ . We will
>>>> use anyterm to launch ovirt-viewer or the virsh console to connect to
>>>> the vm and then present the anyterm html / js / css ui to the user. A
>>>> rough layout of the setup can be found here
>>>> http://ovirt.org/page/Image:Anyterm.png
>>>
>>> I based my mockups on their demos - let me know if the actions I
>>> included (like copy, paste) make sense or not.

Ya thats totally fine for the mockups, I might remove some of that stuff
from the anyterm html that gets added to the project (its all gpl)
depending of how it works and what we need.

In any case 'Close' will definetly be staying, 'copy' and 'paste' might
be removed depending on if we can get that functionality without it,
'Control Keys' will most likey be removed as they work without needing
the drop down. I do like the 'pop out' action you added, and I'll look
into seeing how the terminal location can be parametrized so that we
could put it in multiple locations.


>>>>
>>>> Looking for thoughts / feedback / suggestions as to the interface
>>>> placement of the console or the backend.  Thanks alot,
>>>>
>>>>  -Mo
>>>
>>>
>>> Finally, I wanted to propose we settle on the term "Terminal" instead
>>> of "Console" - at least in the UI - since that is what is used in
>>> Fedora. I know terminology consistency is a challenge for us, is this
>>> a place we can make a choice in the UI and be consistent?
>>>
>> Seems reasonable to me, matches more closely with the 'anyterm' name
>> too.
>>> Thanks!
>>> - Jeremy
>>
>

Sounds good to me too.

   -Mo