How do YOU make beautiful plugin gui's?

Sorry for jumping in late. Here’s my 2 cents.

To my knowledge most ‘beautiful GUIS’ are made with Photoshop. Particularly you’d need to master:

[list]
[] Most of the graphics is generated using layer effects. You’d need to know them all and their internals (the z-order of their rendering, and which FX wins over which). In fact, you’ll need a phenomenal understanding of these as you will have to know this feature of Photoshop better than 95% of professional graphic designers. The hurdle with effects is that once you learned them by manual, you’d need to study how they are used, for which you need to inspect PSD of various artists (some are free, some for a fee); for example, I’ve learned loads from this guy.[/]
[] Understanding of paths and more importantly vector masks (you’d need this in order to scale your graphics without pixelation, even if you scale by 5 pixels).[/]
[] Opacity and Blending modes are also very importent (and beat me to it, I know what each stands for, but no idea what will happen as I toggle between from one to another, so toggle I am).[/]
[] Rulers and Guides (for layouts). [/]
[] Then you sometimes use brushes.[/]
[] Although not exactly a photoshop feature, you’d need a good understanding of lights and shadows.[/][/list]

I’d start by googling ‘Photoshop UI design’ for a wealth of tutorials (you’ll find things like this one). After you’ve done a dozen tutorials or so, have a look at (my favourite) uiparade.com, you’ll be able to look at designs and understand how they’ve been achieved. Another thing you can do is take photos of desks and rack units and re-create the controls with a photoshop composition.

Then come some basic concepts in graphic design:
[list]
[] Layout. Have a look at the DigiRack EQ - it’s very well laid out, compared to the ugly Logic EQ; and here’s a plugin with no sections and many controls, which would make your eye search whenever you want to tweak something.[/]
[] Contrast - a not so great example would be Soundtoys’ Decapitator - the black knobs fuse with the black background = low contrast; also note the blurry white highlights on the top of the meter - the best designs I’ve seen are sharp.[/]
[] Typography - yes, some fonts are better than others.[/]
[] Colours and Tones[/][/list]

There’s many more, but these are the core ones for GUI. I’m not even getting into usability etc. since you’ve asked about beauty.

A lot of this stuff is about attention to details. If you look at Waves plugins from the last 15 years, they progressed from no attention to details, to attention to details, to hyper attention to details.

Then finally comes the question of what to export and how. For example, if you have 3 buttons, do you export on/off state for all (6 images), or do you export 1 on state, 1 off state, and 3 different labels? Do you export 60 different positions of a rotary pot, or ‘cheat’ with base that has a small round handle which is the only thing that moves?

Allow me to give you an example. The following design took 10 layout drafts, 26 button drafts and approximately 60 hours to make in photoshop (from scratch):

Other than the left/right glows on each buttons and scratch marks, everything in this is vectors and effects.

In this, for example, just how the knob base blends to the surface took an hour of experiments.

The base surface is composed of a pattern texture; on which there’s a (‘white to black’) gradient, on which there is low opacity ‘scratches’ layer (using a brush). Then on top of everything there’s light-complexity layer (to gel the controls and textures to the surface and add some shade complexity).

Each button is made using this composition (on average, you tweak around 3 parameters on each effect):

As for export, the base is exported with all buttons off, but no labels; each label is exported with alpha (ie, no button underneath); then the lit image is not transparent over the button but with alpha on the outer blur, which has to be rendered without the button shadow so when you put it on top you don’t get a bolder shadow; and then the lit label has to bit exported a well (not straightforward - you need to understand blending modes to do this right). The whole thing is 7 PNGs (omitted is the handle of the knob).

Perhaps I’ve went well beyond your interest, but this was just to show that this is complex stuff, yet can be learnt by anyone. If time is not an issue, I don’t see why anyone would fail to do the same thing in 200 odd hours or so, not knowing Photoshop at the onset.

Now if IntroJucer could take a layered Photoshop document and produce the corresponding Graphics calls, that would be pretty handy.

That won’t work, because Photoshop doesn’t save them effects and vector mask layers as bitmaps. It renders them on the fly. I don’t think anyone other than Adobe knows how to do this…

Here’s my contrasting view on this:

[list]
[] Us humans like to interact with things that are familiar to us from the real world. Most plugins out there aren’t emulations, yet something that looks real-world is more intuitive to use.[/]
[] What things look like is a major factor in our decision making. Given no exposure to advertising, your choice of which can soup to buy in a supermarket will be based how fancy the can looks. There’s nothing wrong about it, before we get to know people we judge them by their looks - it’s the only way available to us.[/]
[] A good GUI design projects professionalism.[/]
[] A company like Apple has succeeded for largely one reason - user awareness. Part of user awareness means designing attractive products.[/]
[] I’m not sure why you’d need to resize the controls of a plugin.[/]
[] EA’s FIFA 2012 iPhone App is 2.5 GB. Who cares? Who picks a plugin by how big it is?[/][/list]

Eh? Layer effects are trivial. There are the image compositing operators (normal, lighten, multiply, etc…) those are like 20 year old algorithms (and well documented). The rest are mostly variations of path filling and stroking, combined with gaussian blur in its various incarnations.

Everything done in Photoshop layers could be done in a juce::Image using a combination of vector Graphics operations, Gaussian blur, the necessary image compositing functions (which would have to be written) and a few image rendering primitives (these would need to be written as well).

1 Like

[quote=“Izhaki”][quote=“Andrew J”]

With my plugins I’m avoiding the bandwagon of photo-realistic rendering / retro yumminess for the following reasons:

[list][]my plugins aren’t emulations[/]
[]my plugins are software, so I don’t want them to look like hardware[/]
[]pre-rendered controls can’t be re-sized without compromising something[/]
[]detailed pre-rendered controls can lead to a big file size[/][/list]
[/quote]

Here’s my contrasting view on this:

[list]
[] Us humans like to interact with things that are familiar to us from the real world. Most plugins out there aren’t emulations, yet something that looks real-world is more intuitive to use.[/]
[] What things look like is a major factor in our decision making. Given no exposure to advertising, your choice of which can soup to buy in a supermarket will be based how fancy the can looks. There’s nothing wrong about it, before we get to know people we judge them by their looks - it’s the only way available to us.[/]
[] A good GUI design projects professionalism.[/]
[] A company like Apple has succeeded for largely one reason - user awareness. Part of user awareness means designing attractive products.[/]
[] I’m not sure why you’d need to resize the controls of a plugin.[/]
[] EA’s FIFA 2012 iPhone App is 2.5 GB. Who cares? Who picks a plugin by how big it is?[/][/list][/quote]

Very good points Izhaki, though I do think it is possible to meet your criteria with GUIs that aren’t photo realistic. However, I might completely change my approach if I find the market telling me they don’t like my GUIs :slight_smile: I’m sure they’ll like yours - very, very nice!

[quote=“TheVinn”]
Eh? Layer effects are trivial. There are the image compositing operators (normal, lighten, multiply, etc…) those are like 20 year old algorithms (and well documented). The rest are mostly variations of path filling and stroking, combined with gaussian blur in its various incarnations.

Everything done in Photoshop layers could be done in a juce::Image using a combination of vector Graphics operations, Gaussian blur, the necessary image compositing functions (which would have to be written) and a few image rendering primitives (these would need to be written as well).[/quote]

Your’e right. And it seems the PSD file format is publicly available, and it there’s even some C++ libs that should read it.

Hello Izhaki !

Do you know “must read” books or article on the internet about the basic principles of graphic design you have quoted ?

Thanks a lot !

Hey guys - do you think vector based GUIs look different than jpeg based? My designer uses photoshops with jpegs, etc but it seems like most plugins I see have a more shiny / polished / digital sheen to them and I’m wondering if that’s from vector based graphics. Assuming we didn’t change size at any point.

I really have no clue about this stuff so please bear with me and thanks!

You won’t be able to make skeuomorphic UIs with vector graphics (if anyone has done it, please show it here!) so in the end it depends on what you’re looking for. My advice is: use vector whenever you can, it will look great on any screen out of the box. And if using JPGs make sure you have 2x versions for retina displays.

2 Likes

Using vector based graphics is imho more resilient to resizing (less magic numbers in the code) and makes code less likely to explode in size (e.g sliders)

By vector based I mean:

  • get some svgs in your projucer project (ending up in binarydata)
  • load them as drawables in your custom l&f
  • draw them (eventually with some transform) in your l&f

Note: as far as my tests go, juce plays nice with svgs, except:

  • shadows
  • text (must convert it to outlines in your svg tool to have it printed correctly)
2 Likes

I do not use any images anymore and also try to avoid svg’s where ever possible.

I started to code the UI components. Following UI uses only the paint method and the JUCE graphics operations:


another one:

I miss some blending and gradient options to make photo realistic UI’s, but i’m happy with the result. And scaling works great!

p.s. The fonts in Juce is the main weak point in my optinion, but i think it’s not an issue anymore on retina displays.

10 Likes

@kunz those look amazing! would you be willing to give a bit more information on how you got your knobs and buttons to actually look like knobs and buttons instead of just circles and squares?

1 Like

Hey! I’ve used those plugins before! Mind blowing that you’re doing that all in code. Seriously gorgeous.

My main question is, how are you achieving any sort of acceptable performance? In most cases I struggle with GUI CPU usage for drawing even basic graphics on all renderers, especially if I’m doing anything animated like meters.

While I’d like to hear what @kunz has to share, the answer is light-simulating gradients. Lots of light-simulating gradients. Not just straight shadow gradients, but blended blurred shadows and lines which give depth to a scene. Just like how an artist’s work or a 3D rendering is believably brought to life when lighting/shading is added, you can do with vector graphics.

The easiest technique I’ve found to get off the ground is to use heavily blurred drop shadows to simulate ambient occlusion. You can see this in @kunz’s UI’s as all the shadows around the knobs and sliders. The problem is that in JUCE these are super expensive. (hence my questions about performance)

I made some eye-candy filled controls based on these principles a while back, I’ll have to see if I can dig any up…

2 Likes

The performance could be better. I have noticed this too.

Not sure if it’s possible to do a full animated UI this way. I often overlay, for example meter LED’s, with components that use setOpaque(true) to make sure the background does not re-render while the LED’s changing the colors. I also make sure that i don’t use too much and too big shadows. It needs some tuning and the possibilities are limited at the moment.

It would be nice to have a faster renderer :wink:

1 Like

I used only the linear, radial gradients and shadows directly form the JUCE library. It’s very limited. You can layer those components like you would do it in photoshop.

We did the same thing:

We use to do most prototyping with the old Adobe Fireworks. It has two advantages, first, it’s really fast to use. It’s both bitmap and vector based, with a more object oriented philosophy than photoshop’s focus on pixels and layers. And second, it more or less covers what JUCE is able to recreate.

Once we have a nice looking draft, I jump into implementation by using a mix of bitmaps/bitmap strips/3-slice/9-slice scaling and a lot of vector path acrobatics. This often takes weeks if not months, just to stumble upon a better idea and start over again. :slight_smile:

In my experience the whole subject is quite a challenge! Both artistically and performance wise. I can only approach it in an iterative manner with many evaluation and correction steps. Too much depends on the UI.

1 Like

Small suggestion for the shadows mentioned above (in a rescaling context).

Bitmap based shadows scale easily, because they don’t contain sharp corners or transitions anyway. For knobs, a realistic approach could be a hybrid use of vector trickery for all solid parts, and scaled bitmaps for all soft parts (highlights, glows, shadows, reflections).

1 Like

Indeed. In technical artist speak it’s called “baking” and used to be used a lot in the late 2000s in game engines which couldn’t afford to or simply didn’t have real-time ambient occlusion (like the Source engine, which is my native tongue for game dev). Essentially lighting was computed directly into the bitmap diffuse/color texture and when mapped onto the object looked really nice while having zero performance penalty.

A best-of-both-worlds approach could be paint and cache parts of a component (such as a shadow) to an Image object than only gets invalidated and repainted on resize. I’m currently doing this on some meters where I’m painting the green-yellow gradient once to an Image and just drawing and clipping that image at paint time rather than regenerating the gradient every paint.

1 Like