Mockups/new design discussions

There is a new/old problem that will occur with GNOME 3.30+ … I call it:

“Pathbar buttons vs stackswitcher buttons vs buttonbox buttons vs normal buttons vs text-buttons… inside the headerbar”

Currently we have the following groups (all are flat, so I leave “flat” out of this):

image

I just put the window controls on the list to not miss them but I think they are something special and do not need to be 100% consistent.
But the rest is pretty chaotic imho. Especially when we need a new pathbar styling in 19.4 .

To give you a little history why the previous orange underline design was “broken” in consistency:

  1. We re-discovered/realized that the buttons in gnome-software are actually not a stackswitcher even if the function is the same (exchanging the content inside the window). We realized this because the container for those buttons is actually a “buttonbox”, which can also be used anywhere else in the headerbar (we’ve seen it only in the app “Glade” but it can happen everywhere else). So we needed a buttonbox styling for all possible occurences and ended up with this:
    Peek 2018-11-15 20-43

  2. Nautilus 3.30 uses a new pathbar, which does not work with our current styling
    image
    @godlyranchdressing had a good idea for the pathbar and I really like it
    image

But could we return one more time to the “drawing board” and find a solution for every type of button we have in the headerbar? In the end, all are buttons :man_shrugging:
As you know I am not a big adwaita fan, but adwaita has 1 style for all (excluding window controls, like we do). (Edit: and excluding the new pathbar…)
@madsrh @luxamman @c-lobrano @jaggers if you have time it would be great if you could come up with something.

Edit 2: just for the record… this is the current stackswitcher button styling

2 Likes

Good recap, @frederik-f

Stachswitcher and buttonbox are similar to each other, they are basically special toggle-buttons
Pathbar is also the search bar in Nautilus 3.30, so it’s a toggle-button + entry

The three widgets differ by their active state:

  • pathbar: bold font, since the background is always highlighted
  • stachswitcher: orange underline, since the background is always highlighted
  • buttonbox: background highlight

buttonbox has the most basic style, but is not enough for pathbar, since it is important to keep the full path highlighted

stackswitcher his always highlighted, but the orange underline is overkill in pathbar

pathbar style, the new one I mean, looks the more versatile. I believe it could look good for all three widgets

1 Like

Hm, we could also leave everything as it is, wait for gnome-software to use a stackswitcher, and try find a solution for the pathbar for 3.26 AND 3.30+ :man_shrugging:
I really like the orange underline design :thinking:

Update: we fixed it by unifying stackswitcher and buttonbox styling :slight_smile:
plus Having 1 look that works for nautilus 3.26 + 3.30 pathbar

1 Like

Could you make a PR with your LibreOffice and Firefox/Thundebird icons?

The “script-solution” by carlo is “on pause” right now if I understood him correctly

The automatic solution requires some more system work, yes. Eventually if you like the results I can provide the automatic generated icons (but I believe @jaggers results would be better :D)

Ah, apologies, I somehow missed these tags. Yep, I’ll do it tomorrow night :slight_smile:

EDIT: I basically slowed down a bit on icons to see how the script solution played out, but if there’s a requirement for LO I’ll get back on them. Also I’ll do the PR for the server icon as well!

3 Likes

I’ll write a review about the icon-script later today, to let you all know the status and the current issues

2 Likes

Hi,

I wanted to write a short review of the surufy icon script. First thing first a bit of context:

the goal is to have a script that adds a suru style tile background to third party application icons when the application is installed (and remove it, when the app is uninstalled).
The script works fine (you can find it here), I am working now on the integration with the system, with both apt and snap.

what follows is thanks to @kenvandine support :wave: (if there is something wrong, it’s just my fault in understanding it)

Apt (and snap, I believe) has a Post-Invoke hook, that let me call a script after apt install is called, which is the thing I need to launch the surufy script, however:

  1. surufy script writes new icons under $HOME/.local/share/icons/Yaru, but apt runs as root, so it doesn’t know where user’s $HOME is.
  2. the Post-Invoke script must be in /etc/apt/apt.conf.d/, but snap package cannot install any file outside it’s containerized locations (e.g. /snap or $HOME/snap). As far as I know, there is no snap interface/slot we can use for this.

Solution:

  1. we could write directly where normal icons are installed, but I’m not 100% happy with this, first because if the user switches to a different icon set, those icons will stay in suru format and also because with snap we probably cannot write in icons folder
  2. the only solution here is to provide this surufy script as a deb package, with both the apt hook and the actual script. This means, however, that snap version would not have it.

another goal would be to execute the script ONLY on the last installed application.

4 Likes

Thanks for the work!
What if we
Inherit=Humanity,Full colour,Surufy
(In …/icons/Yaru/index)

And you put the icons only in a Surufy folder?
Then only our theme would use those

1 Like

This could work, but only for deb, otherwise the icons are provided by another snap gtk-common-theme and the location is again unwritable

@jaggers, could we try the folded background for the surufy script? Like the ones in https://github.com/ubuntu/yaru/pull/1015

Absolutely, I’ll finish the LO icons (I forgot Base) and then do some grey squircles with a fold in :slight_smile:

1 Like

Thought I’d put something about the switch to single-svg-icons here, because it’s a bit too speculative to fill up Github PRs with.

To summarise for anyone who hasn’t looked at the Github thread: in future, Gnome (and icons designed to Gnome recommendations) will ship a single svg for >32px icons instead of multiple pngs optimised for the different sizes.

SVGs scale to some sizes better than others. For instance: if you divide your icon into different coloured thirds and scale it to 40px, the edges of the thirds won’t be 100% clear, because 40 doesn’t divide by 3. That means the boundaries will fall between pixels, leading to a bit of antialiasing (i.e., pixels that are midway between the two colours on either side).

Under the current system, we optimise icons for key sizes and ship the different versions, meaning that key sizes are as clear as they can be. But we can’t do that under the new system.

Gnome’s new guidance is to prove a single 128px svg optimised to be sharpest at 128px, 64px, and 32px. This presumably means that the designs are planned with a grid of 4px squares, where each square = 4px, 2px and 1px exactly at each of Gnome’s preferred sizes. So, boundaries and elements aligned to the grid won’t fall between pixels at those sizes, but will at other sizes. The largest Suru svgs are already designed in a similar way and scale well to similar sizes.

The most obvious thing for us to do is use the largest Suru svgs when we switch to the new system. One problem is Ubuntu’s current default launcher is 48px. The new Gnome icons, the most detailed Suru svgs, and the any third party icons designed to Gnome’s new guidelines won’t scale 100% well to this size. This isn’t a problem for us now because we make separate icons for the 48px size which are optimised to display very clearly at 48px, but that option is going away. So, the icons won’t look as nice as they do now unless we take action.

We’ve discussed the possibility of changing the default launcher size to 32px, to be more Gnome-friendly, but that’s not the only consideration here.

In our current Suru icon set, the squircles themselves and drop shadows are optimised for the different sizes. The full size icons have beautifully subtle edging and shadows that are sometimes lost at the smaller sizes.

The smaller icon sizes have highlights of exactly 1px at each size, which make the buttons stand out. Also, some designs have sharper drop shadows of 1px to make elements clearer. Unfortunately, when you scale the small icons up, those elements look too bold and cartoonish. So, using the full size icons and using the small icons both have disadvantages when we move to the new system.

Proposal: before we switch to shipping a single svg per icon as Gnome recommends, we create a new Suru template with slightly different style rules. This template will make sure that:

a) The icons look a bit better at 32px than the full size svgs would, but
b) They don’t look crude and cartoonish at larger sizes (i.e., no thick dark borders round the squircle).

This is a WIP, but I’ve started by trying to do a reconfigured version of the messaging app. So far it looks like this at the three sizes:

new 128

new 64

new 32

I’m trying to make this a hybrid style that softens the tradeoff in quality. The idea is to have a halfway house style that looks better than the full size icon at 32px, but also better than the 32px icon at 128px. At 32px, it already looks a tiny bit better than the full size icon (shown first) would:

image

Like I say it’s a WIP, and it isn’t yet a better alternative than just using the full size svg, but I’ll keep working on it and see what I can come up with. If we do change the default launcher size to 32px, it’ll be very important for the icons to look great at that size.

6 Likes

Okay - here’s an idea we’ve been kicking around, with some background about the problem for people who come to it cold.

The problem

When Unity 8 was abandoned, Ubuntu wanted to use Suru icons for the new Gnome desktop. I believe there were two main reasons for this.

  1. Artistic. They’re beautiful.

  2. Emotional. The choice of Suru allowed us to keep some of the “spirit” of the Unity 8 design, which was popular.

However, the squircles created a problem. Many people (including OMG! Ubuntu!) didn’t like “house apps” having squircles when the apps they installed would be a mix of shapes. We tried to experiment with ways of forcing the squircle as a unifying device, which proved popular in some circles - or should that be “squircles”, lol - but controversial in others. So, the Yaru team and helpers began to explore whether Ubuntu should just use the Gnome icons.

I’m not sure about taking them. Among other things, they’re optimised to be sharp at multiples of 32px, and the Ubuntu launcher is 48px (which feels like the optimum size). If nothing else, it would be a bit weird to ship a default icon set that didn’t look its best on the default launcher.

Also - and we have endorsement of this from “on high” - users and Canonical themselves want Ubuntu to have a distinct look. So, if the Yaru team can support and maintain an icon set, I feel there’s no reason not to have our own.

The proposed solution

This is the idea we’ve been kicking around: reconfigure the Suru icon set to have a mix of background shapes, so we can keep the Suru “look” - but also avoid a jarring distinction between house apps and third party apps.

For maximum consistency between the app and non-app icons, we’re proposing four main shapes:

  • Circles. When the pictogram on a Suru icon has no particular geometric shape (or is round), the background can often be turned into a circle with pleasing results.

  • Squircles. If we’re having a mix of shapes, there’s no reason why the existing squircle can’t be one of them. Many Suru icons work beautifully with this shape, which isn’t surprising, because they were made for it.

  • Upright oblongs. This will be the same shape used for most of the mimetypes and the recycle bin.

  • Horizontal oblongs. This will be the same shape used for the generic image mimetype.

We’ll also have some flexibility to use other shapes when it looks good (e.g., a triangle for the “!” alert icon).

Here’s a taste of what the new Suru-derived icon set would probably look like, if we went with this approach (we’re not convinced by the circular Software icon and will try other designs - also, please note that the icons were manually arranged by hand for the mockup and might be a tiny bit “off”):

image

I feel that this preserves the Yaru aesthetic (becase it’s still recognisably Suru) but is not as jarring when we begin to install third party apps:

image

Also, reshaping the Suru icons is not a big job because it would be a good opportunity to switch to the one-svg approach recommended by Gnome and favoured by, e.g., @eaglers . But we would switch to one svg that’s sharpest at multiples of 48px.

So, that’s the proposal, what do we think?

Note: we haven’t really discussed this, but I’ve used the Suru mimetype for LibreOffice on the launcher. I think this looks nice and consistent, but we can keep the official upstream icon for LibreOffice too. I just wanted to see how it looked.

9 Likes

Hi @jaggers,

Thanks for keeping the spirit of Suru alive :slight_smile: I don’t often comment but enjoy reading along as you evolve the Yaru theme and keep ensuring Ubuntu looks beautiful.

If you think it’s useful, I want to offer some time for the Canonical brand design team to contribute to new size/shape icons. We can send you new versions in an amended format and even add a few new icons if required?

Would that be of interest?

5 Likes

Hi @Carla
This would definitely be of high interest!

This time we want to draw the border at pre-installed and generic gnome apps like settings, software and files. This time we don’t want to overwrite rather “branded” gnome icons like gimp, inkscape and so on.

We search for a suru look refresh that can co-exist with the new gnome icons and doesn’t produce inconsistency by default (which uniform shapes sadly do).

Awesome to see you replying!

5 Likes

That would be amazing @Carla!

How about: Yaru team makes an experimental branch or something where we can do a real test of the prototype mixed-shape icons, to see them for real in all contexts.

If they look good, we can make a series of templates in the core shapes that more than one person can add designs/colour to (or adapt into new shapes) and they’ll all be consistent with each other.

If the prototype icons don’t look as good as hoped, then better to know that and refine the concept before we have lots of icons drawn in the same style.

Alternatively: I’m an enthusiastic amateur in this context - if the brand design team have ideas about how to make Suru work in a variety of shapes, I can adapt to their style rather than the other way round.

5 Likes

Ready to make such branch :slight_smile:

3 Likes

Sorry for the delay in getting back to you @jaggers, c-lobrano - just wanted to check if you have a branch of the mixed shaped icons we can have a look at?

4 Likes