![]() Registered Member ![]()
|
This is Andrew Lakes sketches and ideas for Plasma Next
Study 1A ![]() Study 1B ![]() Study 1C ![]()
KDE Visual Design Group - "Sexy by default - Powerful through cooperation"
|
![]() Registered Member ![]()
|
This is my sketch for an idea for Plasma NEXT
![]() And this was the first attempt at some common bits and bobs - which then became heavily revised ![]() More comming tomorrow - please don't be shy and add stuff from the group that applies in this thread.
KDE Visual Design Group - "Sexy by default - Powerful through cooperation"
|
![]() Registered Member ![]()
|
Cool. I'll post any additional refinements or revamps here as well.
Main thing right now for me is trying to cozy up to the mood board stuff and draft layout and color guides so far (all awesome!). Like Jens mentioned elsewhere: paper for texture and the modern yet classic mood set by Nuno's concept wallpaper so far. It'd be really cool if we could nail down the "material" properties of the paper. I went for satin-finished card stock for the windows and vellum for the desktop panels (more refinements would be needed to better represent those materials). As I mentioned in a comment on the G+ post, while I initially wanted to entirely do away with any difference between the desktop theme and windows theme, I was concerned that widgets placed on the desktop really should not look like windows since they behave completely differently. Some Ideas buzzing around my head for visualizing of paper material properties: - How was the outline shape achieved? e.g. stamp cut, scissor cut, heat cut - How are different elements created on the surface of the paper? e.g. print, stamp, etched, embossed - How much does the material compress under pressure? e.g. results in more or less embossing at cuts, affects emboss and etched effects. - What kind of finish? textured, matte, satin, glossy, ink finish vs paper finish (matte ink on glossy paper) No we don't have to use every texture and finish imaginable. Just understand how whatever choice might look. Hope this helps! ![]() |
![]() Registered Member ![]()
|
Tomorrow morning I'm dragging some of my different kinds of paper with me to the office for a good ole photo shoot with my cellphone in different light angles. That will be around noon CET so after that.
KDE Visual Design Group - "Sexy by default - Powerful through cooperation"
|
![]() Registered Member ![]()
|
Moved on. I said I would take the night off but I did a mockup instead.
![]()
KDE Visual Design Group - "Sexy by default - Powerful through cooperation"
|
![]() Registered Member ![]()
|
One thing I've been thinking about is shadows under active and inactive windows. The thing is that it should be better at showing what layer the window is at:
Ok say that you magically raise a floating platform, a window, up above the rest of them - what you want is that the shadow from it moves AWAY, down and to the right/left from the subject. Now you cant get it away from the subject, it looks weird because its not made to do that even though you can shuffle it a bit away. But if the shadow is more squared. not AS blurred - somewhat blurred - but not that much - you can create a better illusion of height underneath the window creating a rather snassy visual effect. This result in a more square, boxy look but again - this has got to be counter acted by icon work and symbols being more chubby and friendly.
KDE Visual Design Group - "Sexy by default - Powerful through cooperation"
|
![]() Registered Member ![]()
|
A few thoughts on shadows (nothing revelatory here, but I thought it might be worth sharing while we're thinking about them).
- Light source. Bright, point or line sources (clear bulbs, fluorescent, flashlights) produce sharper shadows than softer, diffuse lights sources (reading lights, wall lamps). - Shadow surface. Smooth surfaces preserve shadow sharpness while more textured surfaces diffuse light, reducing shadow sharpness. - Distance of object from shadow surface. Shadows sharpness increases as distance of the object from the shadow surface decreases. - Location of light source. Just like Jens mentioned, shadows may translate (and scale) depending on the location of the light source and the distance of the object from the surface. I'm not a fan or bright, point or line sources in my environment. I tend to prefer the calm of soft, diffuse lighting. Sharper shadows on my desktop might be somewhat jarring in an otherwise calm environment and might actually distract from the object casting the shadow - the content. My thought is that we let the sharp, crisp aesthetic emerge in aspects of the content (icons, controls, layouts, etc) and let the shadows reflect the soothing environment of a living room or den. Just thinking out loud. Hope this helps! |
![]() Registered Member ![]()
|
Ok, I couldn't help myself.
![]() Since we were talking about shadows, I thought it might be useful to consider what lighting model(s) to use for all of the visual design work. So I threw together a set of cards... ![]() Each card has a shadow cast onto the desktop surface. The little graphic on each card tries to describe the relationship between each object (card) and the light source. A few things worth noting: - Near the edges of cards where no shadow is visible on the desktop surface (column A) we may have trouble finding the difference between the object and the desktop background (eg. lighter backgrounds with lighter objects). We could simply force each object design itself to have a double contrast outline OR we could pick a different lighting model where at least a small shadow is visible at the edges (shadow driven double contrast) OR some combination of both. - The vertically centered light source kinda makes my brain think objects are lit from below - shadows appear bigger at the top of the object even though they really aren't. I'm guessing my brain is just used to lighting from above and overcompensates. My personal preference is anything in column B, with a leaning towards B1 or B2. Yeah, I'm predictable... ![]() Just for kicks I did up a set with lighting from below. ![]() Hope this is helpful! |
![]() Registered Member ![]()
|
Brilliant! Thats a great help... I have a few things too these are concerning "sharpness" of the shadow. When drawing the rule of thumb is that the stronger the light source and the fewer light sources there are - the sharper the shadow. With more light sources and less "bouncy light" (light that bounces of other objects in the room where the thing you're drawing is) the softer the shadow.
For example any image from outer space you find (of a rocket or astronaut during space walk) tend to be extremely sharp as there are very few secondary light sources (except the sun) and nothing for the light to bounce of creating ambient lighting - so the sharper and deeper the shadows the more people tend to associate it with space images. This is relevant to us for two reasons: one, the theme we have is kinda "space'y" meaning a tad sharper shadows than usual might be good. Second, humans LOVE contrast. Not all - the more you tend to immerse yourself in any one visual subject (photography, illustration or icon design) the more you tend to appreciate subtle details and less contrast as you get an eye for the work done and the details in whatever subject you tend to enjoy. (This is probably relevant mostly to illustrators who talk about pretty often - the "who are you doing the image for and who pays the bill" effect. If you do it for someone who knows illustration you tend to be very careful with adding contrast but if you do it for someone who isn't you slap it on there) - but there is a reason why sharp photos of a blue sky behind the clear green foliage of a tree are always popular. So here is a shadow example using light coming from upper left. ![]()
KDE Visual Design Group - "Sexy by default - Powerful through cooperation"
|
![]() Registered Member ![]()
|
But examples aside - we need to decide which to use.
KDE Visual Design Group - "Sexy by default - Powerful through cooperation"
|
![]() Registered Member ![]()
|
Just an idea for separators using the base concept of folded and cut paper.
![]()
KDE Visual Design Group - "Sexy by default - Powerful through cooperation"
|
![]() KDE Developer ![]()
|
Some quick comments on
* what is possible or not to do currently * details that were pretty much decided already (with consequence of quite some man hours already put) * just personal preferences *what is possible or not to do currently ** I see some icons that are behaving like selected text, ie dark on light in normal state, and white on blue is selected state. this at the moment is not possible without doing different icon graphics for the two states (thing that i would like to avoid) Is a thing that i find really interesting, so i would like to have the stylesheet dynamically changeable to achieve icons changing color, don't think is possible for the first release ** in a mockup i see buttons that have edges as a full circle. This is actually possible, but meand they wouldn't be able to resize vertically. since we have to do with wildly variable text size, (especially now that the dpi density of screens is so varied, from 96 to 220 and beyond). rectangles with just slightly rounded corners are much more flexible and less likely to break with odd font sizes. ** different colors for buttons or any other element, same reason as for the icons color (like the danger button) possible: but each one will need a whole new theme element just for it, so to be used with care (otherwise the theme size and elements to be done would just duplicate or triplicate) **baloon tip to popups.. another thing i would like, at the moment not possible due to the interaction with kwin (the shadow is drawn by kwin, so it should learn to put the tip shape of the shadow in the proper position.. maybe eventually in the future) * details that were pretty much decided already (with consequence of quite some man hours already put) ** most icons in the shell as monochrome shapes, with the same color of the text, assigned with a stylesheet (already considered here, that reminds me i should post an howto) ** panel and popups at least, will still be kindof translucent (i already tried to make them fully opaque, that generates too much hate) however it won't be just the current translucency with blur, the opengl shader is a bit different, it also brings down the contrast of the background, so there shouldn't be any readability issue anymore (the physical effect is like adding a component of front light to a frosted glass) ** i want to limit the amount of pixmaps embedded in the svgs as much as possible (ideally, i would like blur shadows only on panel/popup shadow and plasmoids shadows, not in any internal widget, also because i'm pretty serious in scaling all the elements *2 on very high dpi screens) * just personal preferences ** shadow style: B1, no question ![]() ** colors choice: love them ![]() ** gradients: not really a fan of them (like, not in any shape or form).. ** folded paper thing: that reminds me a lot the style of the default air theme previous to kde 4.10, and even more the variant i did for the early releases of plasma active.. don't know, is a style i was trying to get away from ![]() ** for the plasma style i would like to limit the texture of elements to the very faint transparency things would have. that's a bit different from the style applications would eventually end up having (since i hope no transparency there) I had a start of a mockup along those lines.. i should complete it and post someday.. the weird thing of it was that it had big, diffuse shadows for panels and the like and thin, single pixel ones for controls.. is on the line of windows are paper sheets, controls are just drawn on it i guess. |
![]() Registered Member ![]()
|
Ah well I think that there are some parts I will have to disagree on
![]() Separators as "one line" - is good, but will create a sensation of flatness. I think that we need to be very very careful if we do that and increase the shadowplay on different parts of the desktop to NOT get stuck in the "flat" feel of it. (whether or not it "has been done before", "never been done before", "others do X" is irrelevant I think and something we have to stop considering - if we try to create something based solely on the work of others or past work as marker we will fail doing anything. It will just hold us back and promote cowardice and conservatism instead of bravery and exploration. Past experience is good but they are never an argument in themselves.) This leads me to shadows - the reason behind having a shadow not-centered is that it can be used to create a feeling of a fictive Z-axle. A sensation of depth which top lighting cannot. Top lighting is only useful as flair or combined with a larger shadow to show some sense of a Z-axle but its very tricky to use it when trying to place elements within a window in a good Z-axle position relative to the user. Its possible - but it will demand allot more. The forced placing within apps and windows will also create the situation where the user feels compelled to stick with the shadows that are preset instead of fiddling with them unless he or she moves to a different theme. As for technical hindrances - well we will just have to redo and rethink the visuals that are currently impossible. ![]()
KDE Visual Design Group - "Sexy by default - Powerful through cooperation"
|
![]() KDE Developer ![]()
|
Weekend scratch-an-itch project:
This is the idea i was toying with: ![]() Usial disclaimer, a lot of stuff copied around, like tilain icons, very quick and dirty, not much original and didn't spend time on things like layouts correctly aligned ![]() some points tough.. * Is my take on "kindof flat, but not really, some elements still clearly in 3d" and in this case the 3d elements are basically everything that can be interacted with "buttons, textboxes, etc) while everything that can't, is just a flat drawing (this way, the flat vs not debate, becomes actually an usability feature, maybe 3d-ness even hinted in a too faint way, but that's the idea) * another thing is the sharrpness of the look, apart from windows shadows, pixmaps in svgs are pretty much banned (not only the result is rendered slightly faster, it "looks" faster, but this is probably just a personal feeling ![]() * last, one thing i spent thinking, is the simple feasability for the june release (is a very, very close call at this point, so won't be possible to change much on the technical side) |
![]() Registered Member ![]()
|
Thats lovelly Marco! Although I would prefer the non-pressed button to be flatter and just light and the header to be lead by a graphical element as well as being on the same line and with an explanatory subheader.
I know we talked shortly about this but you mentioned the problems with not having transparent backgrounds ... You know where I'm going with this? What do you think about saying "screw it" and just do them opaque? About pixmaps in SVG's can you be more specific with the issue? What are you referring to? The "in application shadow" or what exactly? Finally about the June release - remember that the plan is to release slowly and bit by bit. Meaning that the changes for June will be small but more will be added with further editions - that means we have to be able to have a goal to aim for even though the goal isn't realized June.
KDE Visual Design Group - "Sexy by default - Powerful through cooperation"
|
Registered users: bartoloni, Bing [Bot], Google [Bot], Sogou [Bot]