I'm starting to take down exact things now... what do you guys think about this for a button layout so we can leave that bit behind us?

notmart wrote:

jensreuterberg wrote:Fabian:
I think I can say with some confidence that a halo effect around text is a massive no-go area.

Marco:
So 80% opacity is the norm we're going for? (plus blur and desaturation etc etc etc)

yes, i would say so.

maybe you can add Sebas (or i can ask an admin as well if you can't, that is, if you are fine with it too in this forum to have one final opinion?

Read through the whole thread, understand it, and agree to the above outcome.

I especially like the flatness of the widgets, compared to the shadows around the window elements. One thing that I'd like to see explored through is making shadows smaller, more subtle. The window manager shadows in Plasma 1 are pretty good in that regard, almost every other shadow I've seen for windows elsewhere seems tacky, especially the huge ones on OSX.

Somewhere in the thread icon sizes came along, basically the choice between 22px and 24x. Here's my take on that:

In the old world, the systemtray icons have been odd ducks, since they're fixed-size-mini-windows, nothing to do about that. In Plasma Next, we're ditching support for this old protocol, and use newer ones that correctly (almost) abstract data and presentation. Technically, this pretty much removes the need for keeping the 22x size, and that's a great thing: We already have tons of alignment problems in the panel, and losing 1px on each side of the systemtray icons compared to other icons in the panel is one source of alignment problems, and it can also lead to blurriness if incorrectly scaled. So from my part: we use the standard icons sizes *EVERYWHERE*, no 22px non-sense anymore.

One thing that I'd like to see used for better scalability is taking a scaling factor of 1.5 into account when doing graphics, so using even numbers where possible, so we can pixel-perfectly render an SVG also at 1.5 its original size, and still get full-pixel-level alignment on screen. The reason for this is that there's a lot of screens that are above 150DPI, at that point a factor of 2.0 looks like a teletubby-on-acid-ui, scaling it at 1.5 can be gotten just right: that means that we can cover a large market of devices better than any other vendor (which usually only do pretty lame 2.0x scaling). The obvious detail is of course then: how to do lines that are 1px wide...

Added a music player to I've apps mocked up so far. As always, I tried to take into account the comments on this tread so far.



Full size: http://wstaw.org/m/2014/02/19/mockup_b2.png

Just a short reply before getting to bed for an early night:

Window Shadows: Plans are for the moment to go with rather accented shadows but placed differently (in this case using them to define space by letting them go down and to the right of the window) - the reason for this is to continue using the same shadow setting through out themes - letting boxes and fields be defined by shadows as if the area was lighted from the upper left. This to create a better 3D effect. In combination with the window shadow this will make the effect LESS flat, without making it beveled and create a sense of space in the desktop.
By increasing the distance the shadow is placed you can create the sensation of actually raising the window up towards the viewer. If we ignore the window shadows the effect might be kinda jarring plus it would be playing it by the book. AND tbh if at a late stage we feel that the effect doesn't need the accented window shadows that seems like an easy fix.

You can see in Alake's mockup above the effect (with the blue window border and application objects shadowing as an example).

Even Numbers: Check! So that's something we all need to think about then.

Alake: btw have you seen the expanding taskbar of Netrunner? What if we combined THAT with Fabians idea of controllers for media players in the panel? That might be kinda cool.

Looking at a dark theme using the Charcoal Dark color right now btw.

Now sleep!

jensreuterberg wrote:I'm starting to take down exact things now... what do you guys think about this for a button layout so we can leave that bit behind us?

Awesome. So I mocked up typical message dialog (like a save-before-closing reminder) at 1:1 zoom to see how this layout works. If those units are pixels, an internal padding of 15-30-15-30 (l-t-r-b) pixels work quite well. The external padding between elements should probably be constant all the way around: 15-15-15-15 pixels works well for me. (I think that's what your layout pic is saying but I wasn't sure.) The text size in pixels is quite large for me compared to my current on screen elements and against full size screenshots and OS mockups I found online. The same is true for the minimum button size (50x150px right?). A minimum button size of about 42x116 to 44x118 px seems to work a bit better for me

So the take-away that works the best for me is:
Internal padding for buttons of 15-30-15-30 pixels.
External padding between controls of 15-15-15-15 pixels.
Minimum button size of 44x118 pixels.

For now, I say we skip specifying button text size outside of general typography guidelines that we can apply to the UI as a whole (rather than piecemeal).

Side note: The odd numbers may have been on purpose, I'm not sure. I've often found even numbers to work better for full pixel scaling (e.g. the 150% scaling sebas mentioned).

Hope this helps!

Added a mockup for an updated kickoff style menu.



Full size here: http://wstaw.org/m/2014/02/19/mockup_b3.png

(I just used the KFaenza icons as a square-style icon design placeholder until I can get my grubby hands on some of Acidrum's cool new icons.)

Sorry if I'm posting too many mockups, but I'm finding it helpful to see how actual application layouts might look to see what, if any, UI patterns start to emerge. It can also serve as a quick, early validation of the control designs proposed so far.

If there are any apps or applets anyone has in mind that they would like me to tackle, please let me know.

Hope this helps!

I have to say that I'm in love with the Marco's proposal. I only have one issue with it - using pure black for some of the items (and the oxygen icons not really fitting the rest of the design, but that is another story altogether)

As for the rest of the discussion, I generally agree with the conclusions.

The only problem I have is with the proposed window titles. IMO, they are wasting too much space, and they are overly inviting. They are the least important part of the window - there is no need for them to stick out that much.

Well the window titles don't waste any space as there is no space to be wasted or rather there is nothing to replace them in that area - so its simply a combined aesthetic choice and a usability choice.

From an aesthetic stand point the more inviting the title the better - by letting all text follow a standard layout form present in print design we avoid the common pitfalls in interface design (pretending its a completely different thing that can ignore proper layout rules).
From a usability stand point the idea is solid too - there is nothing damaging in trying to make the title visible.

Second - I love that you guys are here but you have to follow the same set-up as everyone else, ok? This is not a show-and-tell-and-criticism bit, so wordy criticism means nothing - if you have an idea, post it - if you have criticism work on it and suggest an alternative don't just say what you think, explain how it can be fixed and create an example to show what you mean.

For everyone else wondering where these guys came from and what they do here:
Ivan and Sebas are (with Marco) Plasma Devs. They are here to provide input.

And just like EVERYONE they follow the same rule "this forum is private because it's ment as a safe space to work in before things go public - like the google group and email conversations - so no talking about the work outside of this and try to stay positive, friendly and helpful"

Was not talking about the general problems with the caption bars, but rather this:



The first red bar is the space I was talking about. The second one is ok since it adds spacing.

One important thing to note is that the new design needs to work for tabbed windows as well.
See: http://www.undefinedfire.com/static/kde ... abbing.png

I'll refrain from further posting, since I am not aware of the rules you guys have.


p.s. And I'm not only a developer, I'm also the ignored first responder of your "Revitalize the Design Crew. Hand count." mail thread.

Also about transparency in Marco's suggestion - since a massive part of this is trying to do mockups to experiment with looks and feel we need to be able to recreate the blur-effect using a as simple method as possible to not make it an insanely huge spanner in the works. So far the preferred method have been simply using "paper white" with about 95% opacity and then either pretend its blurred or for a final mockup flatten the underlying layer and copy paste bits of it, blur and lower opacity.

We also need to know HOW we are to define the finals when it comes to that. Saying "its handled by kwin" doesn't cut it since that means "I have no idea and neither will you so whatever work you do might be wasted". So how do we name the SVG's correctly?

So far this has been defined:

There will be a transparent theme using the kwin blur+transparent+desaturation effects

This will base itself on the colors presented none the less so Charcoal for text, Shade for transparent shadows, Paper White or Cardboard Grey for background and Plasma Blue for highlights - Warning Red for "warning buttons".
Buttons will be 1x3 in size (the "1" being "any even number") with sufficent padding - padding size will, I suppose, have to be even too for it to scale well but an complete space between buttons of half of one button size seems about right. Text in the buttons will given adequate space - meaning about half the text height in padding to the upper and lower border of the buttons and a third of the texts width in padding left/right.
Buttons will be the same size in an application!
Buttons will be flat with small shading or outline to show that they are buttons and represent a small elevation from the underlying surface.
Shadows will follow the "up and from the left" shading in Applications but not necesserily in windows.
Bevels will be shot on sight and any gradient which doesn't serve a real descriptive purpose needs to be justified. Try to move in one direction with highlights and gradients (for example let the panel be light on its own and with shadows, dont add highlights. If the panel is dark - avoid further shading but allow for hightlights)
Sliders will use the rounded handle and thin line proposed in several Mockups - how exactly (whether with an elongated blue outline under the handle or with a blue line working from the top like a progress bar has yet to be defined) - or different kinds of sliders depending on if its scroll bars or sliders.
Progress bars will use a thin line, either a representation of a small groove (with shadows like in Fabians mockups) or just a line which is yet to be defined.

All pixel measures of objects need to be an even number for scaling

Nothing much to add - keep the smallest object on which you base all measures an even number and Sebas will be happy and perhaps buy us cake.

We need to create a new window decoration theme for Oxygen-Next (transparent) and one for an eventual secondary theme

This is becoming blatantly clear - we will either need one for Oxygen-Next and one for the eventual secondary theme or one that works for both. As is the theme seems to play on shadows to create a 3D effect and I personally think we should stick to this idea for both so the difference between the two isn't to jarring and we can merge both if we feel we don't have the time. Same rules apply here as the theme rules. No bevels, no shinyness.

We need to define the layout of applications and widgets

Ivan - you weren't ignored I just assumed you had your hands full as it was (if you feel ignored, I'm really sry - I'd love for you to hang out with us)

The rules haven't been properly formalized but I'd prefer a strong sense of positivism right now - a space to try out and let ideas play out fully before shooting them down. The issue being that I'm scrolling over the public forum bits and see Scummos effectively shoot down every idea anyone has which is counterproductive for change. Please don't stop posting, you are MORE than welcome here and you know it

As for the title bar:
I get what you're saying now. But I still think that sliver of pixels serves a good purpose to create a sense of air to it.
But what about this: I know you can create window rules so that the border remains "floating" whenever the window is not-maximized and not-tiled? When it becomes tiled the border change to be a better fit for spacing? Like... ehm Gaia theme I think? Actually thats pretty cool the more I think about it.... Wait will post mockups!

Like this!

1.
> but I'd prefer a strong sense of positivism right now

I apologize if I sounded negative.

I have a problem that I don't express positiveness quite so well. Essentially, you need to prefix everything I say with "It is awesome, but if I had to nit-pick, I'd say this:"* - I'm not British, but I do sport a stiff upper lip Will try to correct this at least here.


2.
> I get what you're saying now. But I still think that sliver of pixels serves a good purpose to create a sense of air to it.
> But what about this: I know you can create window rules so that the border remains "floating" whenever the

That would be nice I think. I guess it needs to be tested in real-life to see how all that would fit together.

The thing with oxygen was to make it appear like the window title bar is a part of the window.

The thing that I like about your proposal the most is that it retains that idea, but with a big usability improvement in that now it is obvious which one is the active window (something we got a lot of complaints about for oxygen).

From the technical standpoint, there are three separate border modes:
- normal windows (unfortunately, tiled ones go into this category)
- maximized windows
- tabbed windows
and they all need to be able to play nicely with each other.


3.
The idea of having several (two) themes shipped by default is something I'd support wholeheartedly.

I remember Nuno talking about how it would be perfect (from both maintainability and creativity point of view) if we could have only one theme, and therefore care only about one theme and integration of other parts into it. But that will never be possible with KDE software - we have too many users that (rightfully) love to tweak stuff.



* you remember the story about an artist friend of mine and her photo collection

jensreuterberg wrote:We also need to know HOW we are to define the finals when it comes to that. Saying "its handled by kwin" doesn't cut it since that means "I have no idea and neither will you so whatever work you do might be wasted". So how do we name the SVG's correctly?

To name the svgs correctly, is pretty much taking the current air theme and starting to replace elements.
a complete spec of the svg elements name is there:
http://techbase.kde.org/Development/Tut ... emeDetails (starting to replace from the "most important" makes it a bit less scary than it looks

I would advise starting with the elements most discussed there: widgets/panel-background.svgz and dialogs/background.svgz
if there are problems for doing it in git, i can upload a tarball of the current theme somewhere.

to have an idea how the background will be, this is an example (just quickly done with gimp: blurred, saturated, and made a bit lighter
http://wstaw.org/m/2014/02/19/bg-treated.png

then we can from the start exchange back and forth real screenshots of how they appear on the real thing (eventually making adjustments)
all the other elements (there are those 4 or so background elements, all the rest is buttons, and similar elements) don't really depend on how much the backgrounds are transparent the work on them is pretty much independent

So far this has been defined:

We need to create a new window decoration theme for Oxygen-Next (transparent) and one for an eventual secondary theme

Well that's the spplications widget style, that is kindof a different beast (and no, i wouldn't like that one to be transparent) plasma widgets had a style difference with applications with purpose. Is good if they'll end up more similar, but due to the fact the way they paint is completely different they'll always be a bit different. so better that they look a bit distinct by purpose rather than by accident.

ivan wrote:Was not talking about the general problems with the caption bars, but rather this:

yeah, the second one looks nicer