More colors in VM settings or possibility to add colors (only 8 at the moment) #2523

Closed
ghost opened this Issue Dec 17, 2016 · 11 comments

Comments

Projects
None yet
5 participants
@ghost

ghost commented Dec 17, 2016

Qubes OS version: R3.2

@grey-olli

This comment has been minimized.

Show comment
Hide comment
@grey-olli

grey-olli Feb 12, 2017

Could anyone point into source where changes to be impemented?

Could anyone point into source where changes to be impemented?

@jpouellet

This comment has been minimized.

Show comment
Hide comment
@jpouellet

jpouellet Feb 12, 2017

Contributor

Unfortunately there are many places where the current labels are hard-coded, so this is not a trivial task.

I think the master list is intended to be the list in core-admin/core/qubes.py, but simply adding to that list would not be sufficient.

If you wish to work on this, I suggest you start by eliminating the other places in the codebase which hard-code labels. These can be found with e.g. grep -r purple qubes-src from a checked-out qubes-builder repo.

There have also been proposals to add different patterns instead of simply more colors, and I personally think that approach would be more useful for those of us with many VMs.

Contributor

jpouellet commented Feb 12, 2017

Unfortunately there are many places where the current labels are hard-coded, so this is not a trivial task.

I think the master list is intended to be the list in core-admin/core/qubes.py, but simply adding to that list would not be sufficient.

If you wish to work on this, I suggest you start by eliminating the other places in the codebase which hard-code labels. These can be found with e.g. grep -r purple qubes-src from a checked-out qubes-builder repo.

There have also been proposals to add different patterns instead of simply more colors, and I personally think that approach would be more useful for those of us with many VMs.

@unman

This comment has been minimized.

Show comment
Hide comment
@unman

unman Feb 19, 2017

Member

I would defer to those who specialise in user interfaces. I don't.
But I have worked on a number of projects where we have used expensive consultants who do specialise in that area. Their advice has always been to keep the number of colours to the minimum, particularly where this has significant consequences for the user. The advice has usually been to use no more than 7 or 8 colours.
In Qubes the use of colour obviously has significant consequences.

I'm opposed not just because people are far worse at discriminating between a range of colours than you would think. It's because they are being asked to identify, and give significance to, a particular colour when it isnt part of a range. I mean that if you see a colour as part of a colour chart you may be able to call it out, but when presented with a sample on its own then it isn't so easy to do so.
An added problem in Qubes is that we allow users to customise their desktops by changing wallpaper and/or background colour. Colour perception is very much influenced by background, so the users ability to differentiate similar colours may be adversely affected by their choice here.

For these reasons I would argue against the proposal, but as I've said, I'm happy to defer to those who have expertise in this area.
There is one change that I would like to see, which I think has been mentioned on the mailing lists in the past. The current colour choices are not suitable for those with some degree of colour blindness - it wouldn't take much to change them to a range which was colourblind safe.

Note that, by using different workspaces with colour coded backgrounds, the existing 7 choices (8 if black is included) can be simply extended to differentiate a larger number of VMs. wmctrl is installed by default in dom0 and can be used to help with such a set-up. I'd recommend that as the way to go.

Member

unman commented Feb 19, 2017

I would defer to those who specialise in user interfaces. I don't.
But I have worked on a number of projects where we have used expensive consultants who do specialise in that area. Their advice has always been to keep the number of colours to the minimum, particularly where this has significant consequences for the user. The advice has usually been to use no more than 7 or 8 colours.
In Qubes the use of colour obviously has significant consequences.

I'm opposed not just because people are far worse at discriminating between a range of colours than you would think. It's because they are being asked to identify, and give significance to, a particular colour when it isnt part of a range. I mean that if you see a colour as part of a colour chart you may be able to call it out, but when presented with a sample on its own then it isn't so easy to do so.
An added problem in Qubes is that we allow users to customise their desktops by changing wallpaper and/or background colour. Colour perception is very much influenced by background, so the users ability to differentiate similar colours may be adversely affected by their choice here.

For these reasons I would argue against the proposal, but as I've said, I'm happy to defer to those who have expertise in this area.
There is one change that I would like to see, which I think has been mentioned on the mailing lists in the past. The current colour choices are not suitable for those with some degree of colour blindness - it wouldn't take much to change them to a range which was colourblind safe.

Note that, by using different workspaces with colour coded backgrounds, the existing 7 choices (8 if black is included) can be simply extended to differentiate a larger number of VMs. wmctrl is installed by default in dom0 and can be used to help with such a set-up. I'd recommend that as the way to go.

@grey-olli

This comment has been minimized.

Show comment
Hide comment
@grey-olli

grey-olli Feb 22, 2017

@grey-olli

This comment has been minimized.

Show comment
Hide comment
@grey-olli

grey-olli Feb 22, 2017

@woju

This comment has been minimized.

Show comment
Hide comment
@woju

woju Feb 22, 2017

Member

For R3.2 this probably will remain as is. For R4.0, the list of labels is in qubes.xml and only the initialisation is hardcoded: https://github.com/QubesOS/qubes-core-admin/blob/core3-devel/qubes/app.py#L852-L861. There is however neither tool nor API to change that, apart from directly editing XML. @andrewdavidwong Is there a reason to change that approach? If not, we can close this bug.

Member

woju commented Feb 22, 2017

For R3.2 this probably will remain as is. For R4.0, the list of labels is in qubes.xml and only the initialisation is hardcoded: https://github.com/QubesOS/qubes-core-admin/blob/core3-devel/qubes/app.py#L852-L861. There is however neither tool nor API to change that, apart from directly editing XML. @andrewdavidwong Is there a reason to change that approach? If not, we can close this bug.

@woju woju referenced this issue Feb 22, 2017

Closed

Qubes Admin API #853

17 of 18 tasks complete
@grey-olli

This comment has been minimized.

Show comment
Hide comment
@grey-olli

grey-olli Feb 22, 2017

@woju

This comment has been minimized.

Show comment
Hide comment
@woju

woju Feb 22, 2017

Member
Member

woju commented Feb 22, 2017

@andrewdavidwong

This comment has been minimized.

Show comment
Hide comment
@andrewdavidwong

andrewdavidwong Feb 23, 2017

Member

We need to defer to the UX experts on this one. Since we don't have any to offer a firsthand analysis of this problem, I'm inclined to defer to @unman's report.

Member

andrewdavidwong commented Feb 23, 2017

We need to defer to the UX experts on this one. Since we don't have any to offer a firsthand analysis of this problem, I'm inclined to defer to @unman's report.

@andrewdavidwong

This comment has been minimized.

Show comment
Hide comment
@andrewdavidwong

andrewdavidwong Feb 23, 2017

Member

For what it's worth, I want to acknowledge that the problem @grey-olli is experiencing is a legitimate one. With a large number of VMs, it becomes difficult to distinguish them, given a limited number of colors. However, it doesn't follow that adding more and more colors (or even building a tool that allows the user to do so) is the correct solution. For the reasons @unman points out, that's likely to backfire and ultimately harm the user instead. This calls for a more creative solution.

Member

andrewdavidwong commented Feb 23, 2017

For what it's worth, I want to acknowledge that the problem @grey-olli is experiencing is a legitimate one. With a large number of VMs, it becomes difficult to distinguish them, given a limited number of colors. However, it doesn't follow that adding more and more colors (or even building a tool that allows the user to do so) is the correct solution. For the reasons @unman points out, that's likely to backfire and ultimately harm the user instead. This calls for a more creative solution.

@andrewdavidwong

This comment has been minimized.

Show comment
Hide comment
@andrewdavidwong

andrewdavidwong Feb 23, 2017

Member

I've created #2646 to encourage ideas for such a creative solution.

Member

andrewdavidwong commented Feb 23, 2017

I've created #2646 to encourage ideas for such a creative solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment