Right ok so Invited Thomas Pfeiffer from the HIG group into the Secret Club House.

The reason for which is that the more we start toying with new ideas the more we trample on the turf of the HIG team and I think we would do great talking more openly about this if the need arise. I'd also think it's high time to take all the great work being done in the Plasma Theme and start sketching down a rough for a Visual Guideline document.

The Human Interface Guidelines exist and do a swell job at describing the Interface methods - I think that by adding a visual guideline (combined with say a Mockup Toolkit, QML guidelines and Visual Goals) we can start kicking down doors and taking names (in a loving and caring way). By writing a guideline based on the work done so far we can also really hammer down the direction we're going and make it accessible to the entire community.

The reasons why:
Essentially KDE lacks solid and coherent visuals. The HIG are there but they are also severely under used and by writing up Visual Guidelines I think we can start bringing the HIG on to the table again and make it something debated about.
We need a guideline internally so people can work on on their own (I've gotten some questions via mail about looks from some of us which is cool but this way it is possible to let everyone hammer on).
Also, personally, I am a great believer in having a set of rules to build on while working creatively. It's a good way to start working having some settings from which to either build or that you have to figure out how to break elegantly.
We need to involve the community in the work being done so they all work towards the same direction - by defining and explaining the vision so far they can be made a part to a larger degree.

How to do it:
I suggest looking at the work being done on the Plasma Theme and try to define the work in simple visuals and numbers. Simple and practical explanations. Combine that with a design goal spec (that we more or less already have) and this could be done in a jiffy.

What we need:
A definition of the work being done, button sizes in comparison with text, a practical definition of negative space (will be tricky), the ideas behind thin lines and sharp angles but also a simple layout form for applications (the last bit should be a bit "open" so the exact details can be hammered out in the open).
We need a Mockup Toolkit like the collection of SVG elements Andrew created early on.
We need a toolkit for QML and preferrably a set of Blueprint for different kinds of apps.

There is also the need to make the HIG's more accessible. By combining the HIG document with visual and practical examples we can make them more accessible and by using our own visuals in the practical examples we can actually SHOW how awesome it will be if you follow the Visual Guidelines and the Human Interface Guidelines. Make it easy for devs to create stunning visuals.

So this is why I invited Thomas, I know plenty of the work being done is via email conversations and Google - but he can at least get a sense of the direction we're heading and perhaps start thinking about how to do all this and combined the VDG with the HIG team somehow in the future.

What do you guys think?

First of all: Thank you for inviting me in!

I agree with Jens that integrating visual design guidelines with the HIG is the way to go. People who design and/or develop user interfaces should have one document to turn to for all guidance. That's why the HIG already right now contain a chapter "Presentation" which contains guidelines for layout and style. These, however, are only very rudimentary, due to the fact that we are psychologists and this is not our area of expertise.

Of course we won't tell you guys to just add something to those two pages and that's it. We'll have to discuss this together and find out in which places information about visual aspects is needed.
One reason why you won't find much visual guidance in for example the guidelines that describe specific controls is that we decided that if there is a pre-made control in QWidgets, QtQuick Controls or Plasma Components, we don't need to describe its visual details in the HIG. Developers and UI desginers can just use that control and it will do the styling for them. This decision was inspired by developers telling us "If there is a ready-made control, we'll just take it and leave it as it is. No need to tell us how to recreate it by hand, because we won't". Whenever there is a degree of freedom in a visual aspect, however, we'll have to provide guidance for when to choose what.
Of course we should always provide an example image using the current styling, but we don't need to tell people the exact color values, border widths etc.

That doesn't mean there shouldn't be a page describing the reasoning behind the visual style in general, of course. That is always helpful to make it clear to people that the design isn't just based on someone's personal taste, but that there are reasons behind the decisions.

The idea has always been to use visual examples to visualize specific guidelines whenever possible, but since up to now we didn't have people with the necessary skills and enough time to actually produce those examples, we resorted to text, which is what psychologists can produce easily. We appreciate any help we can get for producing visual examples, whether it's easy to use mockup elements (we're more into tools like Evolus Pencil or Balsamiq Mockups than Inkscape or Karbon) or example images produced for us.

Together we can make the HIG (the name certainly encompasses visual aspects and is widely used in the industry, but if you guys feel uncomfortable with it, we may change the name) much more "feature-complete" and thus useful.

In case we could use a few examples to help us put together visual guidelines, I recommend taking a look at the Android Visual Design guidelines.

https://developer.android.com/design/index.html

I'm not saying we can't be original, but it is just a example of what I think is a really well done set of guidelines. It starts with the Creative Vision. Then talks about the Design Principles used to service that vision then a UI Overview. It goes on from there to cover Style(metrics, color, typography, iconography), UI Patterns and Building Blocks(buttons, sliders, tabs, scrollbars, etc.). It even provides downloads for mockup stencils exactly like the Mockup Toolkit Jens suggests. It all looks like a structure that might work quite well for us.

The best thing about it is that it is not super content dense and is very visual. Every page on every topic is in concise, easily digestible bits usually with great pics of examples. You could probably read the entire thing in 20 minutes. It's also a live document that gets updated as common new UI patterns emerge from the community and are adopted. Many folks have used them for Android app development (including me) and have found them to be really quite well done. It's actually really easy to tell which apps have been developed with them and which haven't.

Anyway, I thought it might give us a good reference to help us put together something really helpful. Personally, I'd have no shame if we created something quite similar or morphed what we already have into something quite similar for KDE.

Oh and WELCOME Thomas!!

We're in the Free software world, where adopting other people's ideas is considered effectiveness, not plagiarism!

We were inspired by existing HIGs in our work as well, so adopting ideas from the Android guidelines and adapting them to KDE where necessary absolutely makes sense to me.

So I went ahead and took a stab at fleshing out a very simple Next Visual Design Guide. It is based on my best effort to collect all of the work and conversations so far here in the forums, on Google+ and contained in the VDG blog. I just wanted to try collecting some of this stuff that's kinda spread out in a few different places right now.

Next Visual Design Guide proposal

I took a little liberty with wording in decomposing our 10,000 ft goals into progressively more specific ones (similar to how Android Design does). If I've interpreted something incorrectly, feel free to point it out or change it in the doc. I was also aiming for a positive, concise, informal tone to keep this from becoming a weighty, formal requirements document that is difficult to digest and constrains creativity. It doesn't quite have the detailed specifics of button size metrics, spacing metrics and the like just yet. I was thinking that as we firm up those specifics up through experimentation, the basic structure of the document should easily accommodate greater detail by either beefing up the "Style" layer or adding a another layer below that called "Building Blocks" or "Components".

A few notes:
* The Google presentation is not intended to be the final place for this. We can always transfer it to the VDG website or TechBase Usability wiki - where ever it makes the most sense.
* It is focused on the VDG vision of the Next version KDE Applications and Workspaces. Not the current workspace. Not just the workspace.
* I'm thinking it should be a living document that we shouldn't be afraid to revisit and revise over time.
* Wherever there are overlaps with the HIG, we can work to harmonize them. Right now I don't think there are any fundamental conflicts. We could always add links/pointers to the corresponding portion of the HIG.
* I mainly wanted to put this together because as our efforts on the plasma theme progress, it helps to have a reference point for this kind of information.

Hope this helps!

I'm reading through them now - have some ideas. Family is looking at me as if I'm the Grinch of summer vacations. So later reply

One thing I've been thinking about is giving these design goals a larger spread by setting up a wiki on KDE for them (or rather Bcooksley suggested the wiki for another thing which got me thinking) one issue is creating resources (like Mockup ready SVG's and PNG's to be used by people who want to present ideas and simply to follow visual guides as well as QML code snippets)

I am really really strongly in favor of - at least in the long term - not just harmonizing the Visual Guidelines and the HIG and cross-linking between them, but integrating them in one document. That's what most others do, and it's what makes most sense. There should be one single document people refer to when creating UIs.

If you think the structure of the HIG in general or the structure and layout of each page don't work well for visual guidelines, we should discuss and find a solution that accommodates both kinds of guidelines well. Asking people to read two separate documents with differing structure and layout does not make sense to me.

I don't mean that the Visual Guidelines simply should be absorbed by the HIG as they currently are. I really mean both our groups should work together to create a document which contains all the guidelines for creating great GUIs, both visually and interaction-wise

Okay, scrap that, it was just a misunderstanding. Sorry for misinterpreting what you wrote, Andrew, and yay for integration!

There is absolutely no inclination or desire on my part to keep the Visual Guidelines as a separate document from the HIG. In fact, I absolutely believe the two should be integrated. I was trying desperately to make that clear in the notes. This Google presentation was put together more out of creative convenience than as a signal that I want them separate from the HIG.

I'm totally confident we can get them integrated in the best way possible!

Oh and don't let the high level language fool you. Like I said we can add more detail (metrics, spacing, sizes, etc.) to the Style level or a Building Blocks or Components level. I really just wanted to keep some version of those high level goals and ideas from when VDG started up - They've been an absolute guiding star for me while doing mockups and working on the Plasma Next theme.

jensreuterberg wrote:...one issue is creating resources (like Mockup ready SVG's and PNG's to be used by people who want to present ideas and simply to follow visual guides as well as QML code snippets)

So I threw together what perhaps could serve as the beginnings of a Mockup Toolkit. Its an Inkscape svg containing as many assets as I could think of from the various mockups shared here for the windec and the plasma theme so far.

VDG Mockup Toolkit start
(Ignore the "Loading" and just click the Download button).

I set it to a 4 pixel grid to help with placement with a 1 pixel subgrid for finer placement. I tried to include as many UI elements as I could remember. I also included a few of the fake app mockups that were already shared in the mockup thread - mainly so folks could see how to put together the different elements to mockup an app. We can remove those if you don't think it's a good idea. The included icons in there are just placeholders - we can always replace them once Uri, Nuno and acidrums give the ok.

I hope this is helpful, but if this isn't what you had in mind, no worries. (It wasn't too much work since the mockups were just sitting here on my disk).

Enjoy your vacation!!!

Oh, one more quick thing. I just remembered hearing and reading this thought expressed here so I thought I'd update the Design Principles section to include it:

Respect the user’s space
Computing environments are personal. Don’t barge in and rearrange things and and expect the user to be happy about it. Instead provide optional arrangements the user can explore without risk.

Ok? Not ok?

alake wrote:Oh, one more quick thing. I just remembered hearing and reading this thought expressed here so I thought I'd update the Design Principles section to include it:

Respect the user’s space
Computing environments are personal. Don’t barge in and rearrange things and and expect the user to be happy about it. Instead provide optional arrangements the user can explore without risk.

Ok? Not ok?

I agree to this, but it sounds like belonging more to the interaction part of the combined HIG/VG than to the visual part to me.

colomar wrote:

alake wrote:Oh, one more quick thing. I just remembered hearing and reading this thought expressed here so I thought I'd update the Design Principles section to include it:

Respect the user’s space
Computing environments are personal. Don’t barge in and rearrange things and and expect the user to be happy about it. Instead provide optional arrangements the user can explore without risk.

Ok? Not ok?

I agree to this, but it sounds like belonging more to the interaction part of the combined HIG/VG than to the visual part to me.

Ahh yeah that does make sense. Maybe something to keep in our pocket for now then, until we figure out how it fits into the overall package.

I was a little sad and bored after the Sounders lost their match today , so I browsed around the different design guidelines out there to see how they're structured.

Ubuntu App Design
Getting Started(Vision, UI Model, etc.) -> Style -> Global Patterns -> Building Blocks(UI controls)
Android Design
Getting Started(Creative Vision, Design Principles) -> Style -> Patterns -> Building Blocks(Ui controls) -> Downloads (fonts, mockup kits, etc.)
GNOME 3 Design/HIG
Introduction(Design Principles, Overview) -> Basics(Layout, Typography, Color, etc.) -> Patterns -> Interface Elements(UI controls)
elementary OS HIG
Design Philosophy -> User Workflow -> Desktop Integration -> UI Toolkit Elements -> Icons -> Text
iOS7 HIG
UI Design Basics -> Design Strategies(Design Principles, etc.) -> iOS Technologies -> UI Elements -> Icon and Image Design
Windows 8 User experience guidelines (available only as pdf, ugh...)
Introduction(Design Principles, etc.) -> Navigation, Layouts and Views -> Touch, Commanding and Controls (patterns, UI controls) -> App Activation -> Other Important User Experiences
Current KDE HIG
Introduction -> Structure -> Behavior(patterns, UI controls) -> Presentation -> Contribution
The Next Visual Design Guide proposal I shared has the following structure:
Creative Vision -> Design Principles -> Style(Color, Typography, etc.) -> Building Blocks (UI Controls)

Hope this is useful!

Oh, I forgot to mention that we got permission to host the Visual Design Guide at the same TechBase wiki as the KDE HIG. Yay for integration!

I went ahead and moved the content proposed so far over to my userbase wiki page here.

A couple notes:

• I added a layer for Building Blocks that could simply point to the existing HIG sections on the individual UI elements.
• I added a section at the end for the mockup toolkit (including the Inkscape color swatch).
• We can always flesh out more later (e.g. Design Patterns), or change content as time allows. My hope is to get some basic, agreeable guidance out so folks in the public forums have something to work with.

Sooo, how about we talk integration with the HIG?

• The structure of the KDE HIG appears to be quite different than several other design guides/HIGs I surveyed and I see nothing wrong with that. It's just an observation regarding to how to handle integration. The structure of the proposal is relatively more similar to some of the other guides.
• After reviewing the rationale for the Baxley structural model that's used in the current HIG, the definition of the Presentation section appears to me to be, for all intents, equivalent to a Visual Design Guide. My own personal inclination would be to replace the Presentation section in the current HIG with a new Visual Design Guide section that includes at least the Overview, Style and Mockup Toolkit sections and structure from the proposal. We could preserve most of the existing HIG pages from the Presentation section regarding spacing, alignment, color, etc. updated with the fresh content and exposed via the new structure.
• A Building Blocks section which includes a very simple alphabetical list of UI controls could be added to the new Visual Design Guide section below the Style layer. As mentioned above, each UI control listing would point to the corresponding HIG UI control page that already exists (which could be updated with visuals if desired or necessary). That way the same UI control guidance would be exposed from both a behavioural perspective, like it currently is, or from the visual design perspective. That might make the great usability work done on the UI controls guidance a little easier to find if folks come looking for visual design guidance.

I'm interested in your thoughts on this since I have some time to get this done this week.

alake wrote:I went ahead and moved the content proposed so far over to my userbase wiki page here

Great! From there it should be pretty easy to integrate it with the HIG

A couple notes:

• I added a layer for Building Blocks that could simply point to the existing HIG sections on the individual UI elements.
• I added a section at the end for the mockup toolkit (including the Inkscape color swatch).
• We can always flesh out more later (e.g. Design Patterns), or change content as time allows. My hope is to get some basic, agreeable guidance out so folks in the public forums have something to work with.

I've read through what's there, here are some comments:

• I think the alignment guideline will need to become much more detailed at some point. "Visual elements are consistently aligned both vertically and horizontally." might be enough information for a skilled designer (though those probably would not need to be told that anyway ), but when I look at existing UIs in KDE software (both QWidget-based and QtQuick), it seems that non-designers really struggle with alignment and may need much more detailed guidance. The alignment chapter in the HIG goes a little further, but still probably is far from detailed enough. That won't keep us from publishing the guidelines, of course, we just should keep it on our to-do lists
• The main page has some bullets under "Design Patterns" but those are not there yet. I'd vote for not including that section at all until we have patterns to put in there. It might also be confused with the interaction design patterns created in 2008 which I'd like to link to from the HIg at some point (http://techbase.kde.org/Projects/Usabil ... _Workspace).

Sooo, how about we talk integration with the HIG?

• The structure of the KDE HIG appears to be quite different than several other design guides/HIGs I surveyed and I see nothing wrong with that. It's just an observation regarding to how to handle integration. The structure of the proposal is relatively more similar to some of the other guides.

Yes, I think we're the only major HIG using the Baxley model, but since that's what Heiko, who did most of the work on the HIG so far, suggested and I didn't see any problems with it, we kept it so far until we find significant disadvantages of it.

• After reviewing the rationale for the Baxley structural model that's used in the current HIG, the definition of the Presentation section appears to me to be, for all intents, equivalent to a Visual Design Guide. My own personal inclination would be to replace the Presentation section in the current HIG with a new Visual Design Guide section that includes at least the Overview, Style and Mockup Toolkit sections and structure from the proposal. We could preserve most of the existing HIG pages from the Presentation section regarding spacing, alignment, color, etc. updated with the fresh content and exposed via the new structure.

I definitely agree on the Style section, and I'd like to see the guidelines currently present in the Presentation section of the HIG integrated into that section.
As for the Overview section: What's written in there seems too global for me to belong into the Presentation section. These principles should not just govern visual design, not even just UI design, but product design in general. Therefore I'd like to see them integrated on the highest hierarchy level. I think we should talk to Heiko about how he thinks they could best be integrated into the Baxley model. I totally agree with their content, btw.

As for the Mockup Toolkit: I'd like to integrate that on a higher level as well, given that a mockup is not only for visual design aspects. I could of course be linked to from the visual design guidelines, but it should be linked from higher levels of the hierarchy as well.

• A Building Blocks section which includes a very simple alphabetical list of UI controls could be added to the new Visual Design Guide section below the Style layer. As mentioned above, each UI control listing would point to the corresponding HIG UI control page that already exists (which could be updated with visuals if desired or necessary). That way the same UI control guidance would be exposed from both a behavioural perspective, like it currently is, or from the visual design perspective. That might make the great usability work done on the UI controls guidance a little easier to find if folks come looking for visual design guidance.

Makes sense! That would make it even more important to include visuals in the HIG pages, though, as I assume that people coming from the visual guidelines would expect them even more than those coming from the HIG overview.

I'm interested in your thoughts on this since I have some time to get this done this week.

As soon as we've agreed on how to proceed wrt. the things I mentioned above, you certainly will get the "go ahead!" from me!