canonical / desktop-design Goto Github PK

At the moment there is no way to tell if the slider is pressed or not.

@matthewpaulthomas commented on Wed Aug 16 2017

For the install-time settings UI, the post-install settings UI, and the runtime prompt, each interface needs:

• a human-readable description
• a definition of whether its UI should be a checkbox (most of them) or something else (usually a radio menu).

Implementing these descriptions would be a blocker for implementing:

• #99 end-user install-time settings
• #97 end-user post-install settings
• #98 end-user runtime prompt.

@matthewpaulthomas commented on Thu Aug 17 2017

According to the developers in the Snapcraft forum, the current authoritative list of interfaces is the list on the snapd GitHub wiki.

@matthewpaulthomas commented on Mon Aug 21 2017

Spreadsheet of current interfaces and proposed descriptions and categories

In English, the same descriptions could work in a list of interfaces at install time (“{snap name} will be able to:”) and individually in a runtime prompt (“{snap name} wants to ______”). I’m not certain the same would work in other languages.

@matthewpaulthomas commented on Tue Sep 05 2017

38/95 interfaces remaining to describe.

The header bar for applications is too large and should be made smaller.

to give an idea of the desired look and feel

• clarify with Will

• Look at Vanilla and Platform default
• Shape
• Symbol

The default size is too large.

From Trello:

There's no way today to list the available images. We'll need a ubuntu list-aliases, maybe ubuntu list-images commands that allow users to query the available images.

@matthewpaulthomas can you have a think about what we should do here? We can document the few alias values, which will cover 99% of use cases, but do we want to expose the full list of available images, and a way to search through them? Those would include images users shouldn't want, unless they really know what they're doing, because they might be outdated, obsolete, or unsupported even.

But then, since we do support creating instances with such images, it would seem prudent to give users a way to discover them.

One more list we might need to consider is that of currently cached images - users might want to choose only from the set of images they have locally.

• Identify any new icons required

If you enter invalid text in to an input field the entire field turns red.

• Review progress bars designed by Platform team
• Design and update if needed

• Platform color palette
• Sync up and send to Theme designer
• Send link to Colour document

• The Desktop team insists that there should be a notification when a Livepatch update has applied successfully.

• Error dialog when there’s a general error: “Sorry, there’s been a problem in setting up Canonical Livepatch.” ‘The error was: “%s”’ “Settings…” “Ignore”

• Clarify that clicking the Livepatch checkbox multiple times should not build up a long queue of daemon startups/shutdowns.

There are a lot of different greys in the breadcrumbs at the top of the Nautilus window which need some rationalisation.

On 30 October 2017 Andrea Azzarone wrote:

in 18.04 we want to add the option for the user to enable Canonical Livepatch directly in the desktop installer (ubiquity). In order to do this we also need U1 login in the installer (Canonical Livepatch requires U1 login). I'm writing you in order to get some design before I starting working on this.

I'm not completly sure about this (maybe Will can confirm) but for OEM setups we want a first run wizard in order to allow the user to enable Canonical Livepatch and login in U1 as part of the process. Please consider that having network connection is a requirement in order to be able to activate it.

On 30 October 2017 Will Cooke wrote:

Yeah - we have two things:

• The installer. Get the user to log in to U1 so that we can retrieve a LivePatch API key and store that key (& configure LivePatch to use it) on the installed machine.
• OEM first run. For where an OEM has already installed the machine and then the user performs some set-up for things like keyboard mapping etc. The same work-flow as above applies here (get the user to provide U1 creds).

Not sure what this one is, need screenshot.

• Review existing Platform action icons
• Export SVG format

They are currently round at the top and square at the bottom

Rounded corners & strokes.

• Review all icons in Theme
• Make sure they fit Square requirement formatted by GNOME

• Review work done by Platform team
• Review focus state in Vanilla and MAAS
• Design and update accordingly

Design brief: “In subiquity, networking configuration step allows one to setup ip settings of a networking interface. Currently only physical interfaces are supported such as ethernet and WiFi network cards…”

The rough scope of this work would be specifying:

• a “dialog” for adding a bond
• a “dialog” for adding a Vlan
• buttons on the “Network interfaces” page for accessing each of these dialogs
• some kind of UI for removing an existing bond/Vlan.

In user testing of Subiquity, several of the problems that people experienced had the same root cause: lack of an obvious visual language for interface elements.

This includes things like:

• (*) radio buttons
• [radio menus ↕]
• ( Push Buttons )
• ┌─ Dialogs ─┐
• for those that are controls, what they look like when focused, and when disabled.

We should investigate whether any equivalent work has been done for conjure-up. If not, it may benefit from this design language too.

If you have a light coloured wallpaper it can be difficult to read the clock and icons when the top bar is transparent.

Subiquity can use a palette of 8 colors in its text-based interface. The choice of colors would benefit from visual design expertise.

The current palette has something like:

• brand color (currently Ubuntu orange)
• background color (currently black)
• normal text (white)
• secondary text (grey)
• safe continue actions (green)
• dangerous continue actions (red)
• backward actions (blue)

As with #3, we should investigate whether conjure-up has done any equivalent work, and if not, the palette could be used for both.

• Due to reduced transparency on Orange on some screen it looks pink

• Use Juju GUI icon
• Platform default profile icon