[virt-tools-list] RFC: virt-manager UI philosophy draft

[Cole Robinson]

On 6/24/19 5:15 AM, Daniel P. Berrangé wrote:
> On Wed, Jun 19, 2019 at 06:34:38PM -0400, Cole Robinson wrote:
>> Hi all,
>>
>> I've drafted a wiki page about virt-manager UI philosophy, for lack of a
>> better term, suggestions welcome. The intention here is to provide some
>> guidance about what types of things we want to expose in the UI, both to
>> devs, potential contributors, and users requesting RFEs.
>>
>> https://github.com/virt-manager/virt-manager/wiki/WIP-UI-philosophy
>>
>> I don't think there's much new here, it's just formalized. There's a
>> section at the end of the wiki page for previously rejected features as
>> well. If people are cool with this document I'll use it to close a bunch
>> of upstream bugs as well which will grow that list.
>>
>> Another part of my plan for this is to apply the standards to the
>> current UI which would result in feature removals. I'll put my thoughts
>> in a follow up mail.
>>
>>
>> ##  virt-manager UI philosophy
>>
>> virt-manager is a UI toolbox-style frontend for libvirt. It provides UI
>> access to common virt management tasks and operations. virt-manager aims
>> to provide a simple UI, but not too simple that it excludes valid
>> usecases. virt-manager prioritizes stability over features.
>>
>> * _Basic virt users_ should be able to meet their needs with virt-manager.
>> * _Intermediate virt users_ should generally find virt-manager
>> sufficiently flexible for their needs.
>> * _Advanced virt users_ will not find explicit UI support for their
>> advanced use cases, but virt-manager should still function correctly in
>> the face of their manually configured advanced virt usage. virt-manager
>> should not get in their way.
>>
>> See the user definitions at the end of this doc for more details on those.
>>
>> Here are some things that virt-manager explicitly is not aiming to
>> reimplement:
>> * gnome-boxes: a heavily desktop integrated VM manager with an emphasis
>> on UI design and simplifying virt management. They prioritize a seamless
>> designed experience over flexibility, our goals are different.
>> * virt-viewer/remote-viewer, vncviewer: our graphical VM window should
>> 'just work' for most needs but any advanced console configuration is
>> left up to these other better suited tools.
>> * VirtualBox, VMWare Workstation: It's a nice idea to aim to be the
>> equivalent of those apps for the QEMU+KVM+Libvirt stack. But to get
>> there would require a level of resource investment that is unlikely to
>> ever happen.
>> * oVirt, Openstack: virt-manager does not aim to support management of
>> many hosts with many VMs. virt-manager won't reject this case and we try
>> within reason to keep it working. But the UI is not designed for it and
>> we will not change the UI to facilitate these style of usecases.
>>
>>
>> ## How do we evaluate UI changes
>>
>> When is it worth it to expose something in the UI? Here's some criteria
>> we will use:
>> * How many users do we expect will use it: This is handwavy of course
>> but some things come up in email/IRC discussion regularly, and some are
>> mentioned once in 5 years.
>> * How critical is it for users who need/want it: if it's an absolute
>> blocker just to get a working config for some people, that can influence
>> the discussion
>> * How self explanatory is the feature: 'Enable 3D acceleration' is
>> fairly self explanatory. Disk io native vs threads, not so much.
>> * How dangerous or difficult to use is the feature: If it works in only
>> specific cases or renders the VM unbootable for certain scenarios, this
>> matters.
>> * How much work is it to maintain, test
>> * How much work is it to implement: If something requires significant
>> app specific logic on top of libvirt, libosinfo, or spice-gtk that would
>> also be useful to other virt apps, it is suspect. We should be aiming to
>> share common functionality
>>
>>
>> ## User definitions
>>
>> ### Basic virt user
>> They know little or nothing about libvirt, qemu, and kvm, but they
>> understand the high level concept of a virtual machine. They have a
>> Windows or Linux distro ISO and they want to create a VM and interact
>> with it graphically. They should be able to figure out how to do that by
>> running virt-manager and following the UI. The defaults we provide for
>> new VMs should be sufficient for their needs.
>>
>> After the VM is installed, the UI should facilitate intuitive UI tasks like:
>>
>> * lifecycle operations: start/stop/pause the VM; save, snapshot the VM;
>> delete, clone the VM
>> * rename the VM; change the VM title or description
>> * eject/insert CDROM media; change VM boot order
>> * increase VM memory
>> * attach a host USB device to the VM; possibly add an additional disk to
>> the VM
>> * graphical operations like send a keycombo, screenshot
> 
> I would note that this is essentially the use case / scenario that
> GNOME Boxes aims to fill.
> 
> Boxes will inevitably do a better job here since its simplified
> view will enable it to be more friendly than virt-manager will
> be able to do.
> 

Right, but they are still tasks that are critical for virt-manager to do
well. The difference is we aim for them to be as simple as possible but
only up to a point that it conflicts with our other goals, like
supporting intermediate or advanced users. For boxes I would say its
primary goal is to make these style of basic usecases as simple as
possible, everything else is secondary.

> IMHO virt-manager should position itself as the natural choice of
> tool for someone who wants a desktop app, but has outgrown what
> GNOME Boxes can offer them.
> 
> Thus I think virt-manager should be primarily focusing in its aims
> towards the Intermediate virt user, with a bias towards the advanced
> side of things.
> 

I think that's a reasonable way to put it, but 'advanced' is a slippery
slope. Trying to narrow those terms was a big goal of this exercise. I
don't really want UI elements for things that fit the 'advanced'
criteria because then we need to justify repeatedly why other advanced
options are or aren't acceptable. Hence 'intermediate' is the ideal cut
off, and advanced users have the XML editor.

Thanks,
Cole