Hello my fellow VDGer's!

anditosan, EraX and I have been working on application and plasmoid layout guidelines for integration into the HIG. We finally have a set ready and we're looking for your feedback to make sure we didn't miss anything. It's currently on my userbase wiki. Once it gets reviewed here and by the usability folks, it'll get migrated into the HIG proper.

https://userbase.kde.org/User:Andrew/Layout

We put a lot of work into creating these guidelines (see the Methodology section at the bottom if you'd like understand a little about how it all came together). So please take a look and provide your feedback here. Note that these guidelines are intended to address primarily top level application layout. It's not meant to address layout section colors and the like. Eventually we'll add an example to the guidelines and do blog posts with examples on applying the finalized guidelines.

Thanks,
Andrew

I joined recently so there isn't much that i actually did just pointed few things out.
Nevertheless big respect for the great work that you guys did.
And yes now it's a good time for everyone to review and share ideas.

EraX wrote:I joined recently so there isn't much that i actually did just pointed few things out.
Nevertheless big respect for the great work that you guys did.
And yes now it's a good time for everyone to review and share ideas.

Modestly won't get you anywhere here EraX!

Very nice work everyone! I guess I'll need a day or two to read through it all.

I realy nice and a lot of work.

for my point of view I would put more examples to the HIG. For me the best would be to have a kde repository for the different navigation patterns and the application use the class, function, or whatever this is called, so every application has the same root with a defined design and the app coder can make use of them.

so my 2cent:

1. Collapsible List pattern
how much horizontal spacing should be used. I can't find this type at the spacing section

2. Command Patterns
I don't understand why only very complex command structure can have a menue bar and simple command structure only an settings icon without an icon bar. You are right, the apps should be as simple as possible, but one settings icon is more wast of space than a menue bar.

3. Icons and Text
I like this section because there are numbers but why the icon don't endet at the 4px or 8px line.

you do a great job, I like the process realy much.

andreas_k wrote:so my 2cent:

Thanks for taking the time to provide feedback andreas_k!

1. Collapsible List pattern
how much horizontal spacing should be used. I can't find this type at the spacing section

It'll be tough to define this right now given the variety of information that could be displayed in the list. What matters for now is that the collapsible section is sufficiently distinct. Let's see how the guidelines get applied in practice and if significant inconsistencies emerge that additional guidelines would help, we can tackle it then.

2. Command Patterns
I don't understand why only very complex command structure can have a menue bar and simple command structure only an settings icon without an icon bar. You are right, the apps should be as simple as possible, but one settings icon is more wast of space than a menue bar.

For a simple command structure, the menu button pattern, if used at all, can overlay the content (I updated it to make that more clear). For the complex command structure, the menu button is in the toolbar for the toolbar+menu button pattern. In either case, no additional space beyond what's already required for the content or the toolbar would be required to host the menu button.

3. Icons and Text
I like this section because there are numbers but why the icon don't endet at the 4px or 8px line.

I think I understand the question, but sorry if I misinterpret. Padding around the icon is required to ensure enough spacing in the layout.

you do a great job, I like the process realy much.

Thanks! And thanks for providing feedback.

Awesome work indeed! I don't even really wanna know just how much work went into those...

Here's some feedback:
- The Context Panel pattern probably needs to be explained a bit more for people who haven't seen it anywhere yet, since it's not very common in the desktop world yet.
- I'd make the Wizard pattern much more detailed, including exactly which general buttons should be used, when to use a final step with a summary, wording guidelines for instructions, etc. The GNOME HIG has a good page on wizards (they call them assistants): https://developer.gnome.org/hig-book/st ... nt.html.en
- The guidelines you provided for Plasmoids are correct, but we will probably need more guidelines (or parts of guidelines) that are specific to Plasmoids. Things like how to behave when in a panel vs. on the desktop or what to show at which sizes. These are only relevant to Plasmoids, so we need to tackle them separately.

So as you can see, all my comments are about wanting more I didn't find anything in the new patterns/guidelines that I'd disagree with.

colomar wrote:Awesome work indeed! I don't even really wanna know just how much work went into those...

Here's some feedback:
- The Context Panel pattern probably needs to be explained a bit more for people who haven't seen it anywhere yet, since it's not very common in the desktop world yet.

It actually came out of the desktop application survey. The Context Panel command pattern (had to pick a name for it) shares a lot in common layout-wise with the perhaps more recognizable Selection-Properties navigation pattern. The distinction is that whereas the Selection-Properties pattern reveals more information about the selected or visible content, the Context Panel, similar to a Context Menu, just deals with performing commands/actions on the visible or selected content. Many apps have some kind of merged version of the Selection-Properties pattern and Context Panel pattern. Calligra's side panel is essentially that. Inkscape does this as well when, for example, the Transform panel (commands) is shown with the Fill and Stroke panel (editable properties) in the same side panel. Gwenview's Operations panel on the left is purely about commands, though it can be switched to a properties panel by selecting the Information tab.

The intention with this pattern was to account for purely contextual commands in a panel that exposes functions in a more discoverable way than the context menu, or digging through a menu hierarchy does. It's also intended to reflect and respect the attempts to do this in existing software and perhaps chart a consistent way forward.

- I'd make the Wizard pattern much more detailed, including exactly which general buttons should be used, when to use a final step with a summary, wording guidelines for instructions, etc. The GNOME HIG has a good page on wizards (they call them assistants): https://developer.gnome.org/hig-book/st ... nt.html.en

Great ideas Thomas. I took a stab at adding some more detail, but if there are other for what would be useful there (without the guideline becoming overwhelmed with detail) please share. We can work on improving this over time.

- The guidelines you provided for Plasmoids are correct, but we will probably need more guidelines (or parts of guidelines) that are specific to Plasmoids. Things like how to behave when in a panel vs. on the desktop or what to show at which sizes. These are only relevant to Plasmoids, so we need to tackle them separately.

I took a stab at adding a guideline on adjusting content and layout to the container. just like for the Wizard though, ideas for additional guidelines are certainly welcome and we can certainly improve it over time.

So as you can see, all my comments are about wanting more I didn't find anything in the new patterns/guidelines that I'd disagree with.

Awesome, thanks for the review Thomas!

I took a stab at adding a guideline on adjusting content and layout to the container. just like for the Wizard though, ideas for additional guidelines are certainly welcome and we can certainly improve it over time.

Can the VDG make a guideline for Breadcrumb patterns.

for 1- 2- and 3-deep content structure the HIG define a sidebar with the navigation. For the user prominent visible. For more complex apps the HIG defined to use breadcrumb, but they are at the moment not so visible as a sidebare. Also the toolbar icons with text are more visible as the breadcrumb in dolphin or other apps.

In addition it is not clear if the breadcrumb can be located in the icon toolbar line on top and should be located left to the sidebar or on the left app side as you can see in the beatiful Muon designs from EraX (https://dl.dropboxusercontent.com/u/63396655/muo0.jpg and https://dl.dropboxusercontent.com/u/63396655/muo1.jpg)

as always nice to have the VDG.

Great work! My only minor suggestions are:

Pictures:
I don't know where I read it but it was a really nice idea. To add captions to an image use a slight gradient instead of a semi-transparent background as it will have more or less the same effect without meddling with the picture so much. Maybe that's worth a consideration.

Icons and Padding:
Maybe we should link to Uri's write-up on how to use icons correctly once we transferred it into a wiki page. Additionally we should link to the typography guidelines, I think. As of now it strikes me that this HIG is particularly for list items (from the examples alone), maybe we should include a few examples with a longer subtext like plasmoid descriptions just to make clear how it plays out? I'm not sure.

Editing:
I think we should add to in line editing that the text fields should contain an example i.e. when we have a text field where the user should enter their e-mail address it should display a greyed out "name@example.com" text. That's more or less obvious but let's not leave to the odds.

Search etc.:
Only a minor thing, I think now is the time to settle the question of how we want all those fields to look i.e. "Search: [TEXTFIELD]" or "[TEXTFIELD::"SEARCH"::] etc.
I prefer the style of displaying the name in the text fields as it more similar to a one-line edit.
Additionally, I think that we should maybe take a look at the elementary OS HIG on labelling search fields

Other than that: examples, examples, examples. I really think we need to give the developers a hand in showing them what it could look like, but those can be added later anyway.

Again, awesome work!

@andreas_k

Great questions and good suggestions. For the moment though, my inclination is to not try to anticipate every possible possible layout question and put too much detail into the guidelines. Otherwise we run the risk of the guideline becoming overwhelming treatise. Let creativity within the existing guidelines reign and update the guidelines only when variations critically impair the user experience.

Sogatori wrote:Icons and Padding:
Maybe we should link to Uri's write-up on how to use icons correctly once we transferred it into a wiki page. Additionally we should link to the typography guidelines, I think. As of now it strikes me that this HIG is particularly for list items (from the examples alone), maybe we should include a few examples with a longer subtext like plasmoid descriptions just to make clear how it plays out? I'm not sure.

We have a todo to update the existing icon HIG with Uri's write-up. After this review, these layout guidelines will be integrated into the HIG under Presentation which already has a pointer to the typography guidelines. As for the longer secondary text, let's just see how we deal with it in practice. As I mentioned above, if lots of variations emerge that critically impair the user experience, we can revisit the guidelines then.

Editing:
I think we should add to in line editing that the text fields should contain an example i.e. when we have a text field where the user should enter their e-mail address it should display a greyed out "name@example.com" text. That's more or less obvious but let's not leave to the odds.

Search etc.:
Only a minor thing, I think now is the time to settle the question of how we want all those fields to look i.e. "Search: [TEXTFIELD]" or "[TEXTFIELD::"SEARCH"::] etc.
I prefer the style of displaying the name in the text fields as it more similar to a one-line edit.
Additionally, I think that we should maybe take a look at the elementary OS HIG on labelling search fields

Good suggestions. Probably more appropriate for the Text Edit HIG.

Other than that: examples, examples, examples. I really think we need to give the developers a hand in showing them what it could look like, but those can be added later anyway.

Once this review is complete and the guidelines get integrated into the HIG, the mockup toolkit will be updated with example templates for many of the patterns. Also, that's where everyone in the VDG community can help. Using these forums to post mockups for review will help us all learn together how to use or update these guidelines to aid design. Between doing more mockups and creating examples for blog posts and the like, the community could really help out here. For my own contributions, I'm hoping to do occasional blog posts on using the guidelines as an aid to creating designs. It'll take the whole community experiment, learn and share our knowledge. But we definitely don't want to wait for everything to be "finished". There is no finish-line: HIGs are living documents. If you're not sure, just design, share, ask questions and learn together.

Thanks so much for taking the time to review and provide feedback!

andreas_k wrote:Can the VDG make a guideline for Breadcrumb patterns.

Absolutely, I added a backlog card to our kanban board. The page should be a separate guideline below patterns, linked from the app layout guideline. We should keep any particular page as concise as possible.

where is this kanban board. is it public.

thanks.

Thanks for the great feedback everyone!

I've gone ahead and migrated this into the HIG under presentation (click the link for Layout).

Also, the mockup toolkit has been updated with several example patterns:



Remember these are just examples so they don't cover every possible combination or scenario or design approach. Be creative! Try stuff. We learn by doing not by just reading. Of course the HIG is a living document so we can always update it as we learn.

Thanks for everyone's again help and great feedback!

alake wrote:Cool realy cool

As I wrote before would it be possible to make the breadcrumb more in front. I updated your really nice pictures for the breadcrumb.



The breadcrumb has the same size in height as the toolbar. also the > Symbol has the same size as Icons. The text height is the original. With this layout it is also possible to integrate the breadcrumb into the toolbar. The only problem is, that the text size of the toolbar is not the same than the text size at the breadcrumb.

You rocks.