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

[Jeremy Perry]

On Jan 9, 2009, at 4:55 PM, Michael DeHaan wrote:

> Mohammed Morsi wrote:
>> 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
>>
>> _______________________________________________
>> Ovirt-devel mailing list
>> Ovirt-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/ovirt-devel
>>
>
> How about a link to just the terminal (no-popup) so someone can just  
> do "New Tab" in Firefox and get a nice large terminal?
>
> Tabs across the top may also not scale if a user has a bit too many  
> VMs open (perhaps a drop down to select the VM, or multiple firefox  
> tabs?)
>
> --Michael
>
That's reasonable, though I don't feel strongly about it. It seems one  
way or another it is nice to give the user the ability to have a  
dedicated tab or window per terminal if they want. I'm not sure you  
can have that AND smaller popups from the same link, which would be  
ideal. Looking at gmail's pop out for a mail message, you cant seem do  
a new regular window/tab, which is too bad. I also dont know how they  
get around popup blockers (but they do), which would be another  
concern for us - we do not want to require you to disable them.

I guess the ultimate would be a new window link that behaves like this:
- you click it and you get a new popup window. Additional terminals  
nest here
- you can right click and choose new full browser window/tab.

If we just have a normal link, the only issue is unintentional  
navigation away from the main UI. So I think this is a case where it  
makes sense to target a new window by default (used with caution - we  
should make it clear on the link label). This is even better if we can  
resize the terminal - right now it looks like you have to hard code  
the # of columns and rows for Anyterm.