This guidelines should be placed under Behaviour > Pattern (https://techbase.kde.org/Projects/Usabi ... G/Patterns).

== Purpose ==
The breadcrumb pattern is a navigation aid that helps to keep track of the locations within programs or documents by a) providing information about the current position within the hierarchy, and b) offering shortcut links to jump to previously positions without using the Back button (e.g. home > documents > business). The breadcrumb extends the address bar with (clear) access to subsections. It has the advantage of distinctness in usage. As a drawback the breadcrumb usually needs more space.

== Guidelines ==
== Is this the right control ==
* Use a breadcrumb for orientation and navigation in strictly hierarchical data.
* Make sure the breadcrumb has only supportive functions. Do not use it as primary and exclusive navigation pattern.
* Do not use a breadcrumb to just identify or label of the position.
* Consider to use other controls like tags for flat or less organized content.
* Do not make the breadcrumb navigation dynamic by adopting the last users interactions (known as 'path breadcrumb'). Breadcrumbs should show the hierarchy, not the user's history.

=== Behavior ===
* Link all breadcrumb steps to the appropriate page or position respectively, except the current.
* Add the current position to the breadcrumbs.
* Consider to provide a dropdown list for alternate options on the same level. But always offer one-click access by default.

=== Appearance ===
* Keep the breadcrumb plain; do not use icons or other controls.
* Place the breadcrumb above the content control (e.g. file list).

* Do not place it above the navigation control (e.g. directory structure)
* Do not integrate it into the tool bar
* Do not place it in an extra tool bar.
* Do not integrate it into the title bar (which would require CSD, e.g. viewtopic.php?f=285&t=123213&p=321247&hilit=breadcrumb#p321247, http://blogs.gnome.org/mclasen/2014/01/ ... continued/)

== Implementation ==
viewtopic.php?f=285&t=122173&p=316252&hilit=breadcrumb#p316291

Andreas' example is quite a good starting point. But IMHO it lacks on clear links (underline?), and it does not show the dropdown option. Please help with a fancy mockup . And grumble about the text, if you find something.

IMHumbleO - in the 2 screenshots at the bottom right page of alake's mockups that he posted in the post above andreas_k's that you linked to, the breadcrumbs are a bit more subtle and fit in better with:

* Make sure the breadcrumb has only supportive functions. Do not use it as primary and exclusive navigation pattern.

Than andreas_k's modified mockups that you linked to - in that one i think the breadcrumbs are a little too obvious & in your face - they look more like controls for primary navigation than just being 'supportive' One of the things that i love about KDE is that it makes efficient use of my screen space, having quite large areas taken up by secondary controls is moving away from that a bit.

If anything i'd go for smaller breadcrumbs than alake's mockups - but that's just me!

Thanks for the reply, ken. I take it as support for the guidelines in principle. The actual design proposal can be added later (or referenced).

Great HIG! Sorry I haven't commented on it earlier.

Just one thing I'm not 100% sure about:

Consider to provide a dropdown list for alternate options on the same level.

Dolphin currently has dropdowns for the levels above as well, and I find that very useful. Is there a reason why we should only have them for the current levels?

One thing we might want to add is drag & drop onto the breadcrumb. I often use that on Dolphin, it's very convenient. And I'd even encourage allowing drag & drop onto the dropdown. In earlier versions, Dolphin hat even that capability, and it allowed users to perform some copy/move operations without ever changing the active folder. It was impressively convenient, and I really miss the feature since it's gone (not sure if it's a bug or if it was removed on purpose).

This is one of the "powerful when needed" kind of features for me. Nobody has to use it and it does not affect the normal use of the breadcrumb negatively, but it's there if you like to use it.

Suggested addition to the "Behavior" guidelines:
"If your application allows moving objects to other positions in the hierarchy and has a drag & drop functionality , allow dropping objects onto elements of the breadcrumb to allow moving them to the corresponding node in the hierarchy. Allow opening the dropdown during the drag operation and dropping into an alternative node in the dropdown".

As for the visuals: I personally favor EraX' visualization of breadcrumbs in the Muon Discover mockups, because they don't look just like text with a symbol next to it, and therefore more like something you can interact with:

+1 for EraX' visualization. As you can see it fits also into the icon bar.

+1 for EraX's breadcrumbs and for Thomas' "powerful when needed" comment regarding dropdowns at higher levels.

Without wanting to 'jump on the bandwagon' with everyone else, i too think EraX's breadcrumbs are great - they don't waste loads of space, aren't too 'in your face' and look great combined with the other controls in that toolbar so +1 from me too.

They look good, but aren't they a bit too tall?

colomar wrote:Is there a reason why we should only have them for the current levels?

It's just a misunderstanding. I'll change the text to
* Consider to provide a dropdown list for alternate options this level.

colomar wrote:"If your application allows moving objects to other positions in the hierarchy and has a drag & drop functionality , allow dropping objects onto elements of the breadcrumb to allow moving them to the corresponding node in the hierarchy. Allow opening the dropdown during the drag operation and dropping into an alternative node in the dropdown".

My first impression was: that's too specific. But why not recommend to make it 'interactive' (which is copy in case of file managers).
* Consider to make the breadcrumb interactive, e.g. copy/move files, apply a sequence of processing steps...
(For sake of convenient reading I'd like to add another example for interactions. Any ideas?)

About the example: It has a stepper on the left, which is not necessary IMHO. And it doesn't illustrate the dropdown feature.

Heiko Tietze wrote:

colomar wrote:Is there a reason why we should only have them for the current levels?

It's just a misunderstanding. I'll change the text to
* Consider to provide a dropdown list for alternate options this level.

Aaaah, now I get what you meant
To make it even more clear, I'd replace "this" with "each".

My first impression was: that's too specific. But why not recommend to make it 'interactive' (which is copy in case of file managers).
* Consider to make the breadcrumb interactive, e.g. copy/move files, apply a sequence of processing steps...
(For sake of convenient reading I'd like to add another example for interactions. Any ideas?)

True, a more general description would make sense. I'd still like to add that the dropdown should work with drag & drop, though, because apparently not all devs think of that.

About the example: It has a stepper on the left, which is not necessary IMHO. And it doesn't illustrate the dropdown feature.

Yes, the "stepper" (I assume you mean the left/right buttons by that) is not a mandatory part of the breadcrumb. Although it does probably make sense in most of the cases, as it does a different thing than the breadcrumb navigation if you do not only navigate on the same path. E.g. in Dolphin I use it very often.

veqz wrote:They look good, but aren't they a bit too tall?

It could easily be made a little lower if we want to save additional vertical pixels.

Thanks for all replies. I added the guideline now with a 'to-be-done' for the actual design. In particular I would like to show how to have direct one-click access as well as a dropdown for alternative items on this level.

Heiko Tietze wrote:In particular I would like to show how to have direct one-click access as well as a dropdown for alternative items on this level.

I think Dolphin does that just fine direct access on the label, dropdown on the ">". We can use that as long as we have some kind of separator between the levels.

Oh and thanks again for finalizing this. I just went ahead and made a few minor language adjustments.

I have just seen a program that makes use of tabs for wizard steps (something like 1. Language, 2. Timezone, 3. Package...). Obviously, tabs make no sense here, but why not use breadcrumbs?

The denial of history or path navigation was inspired by Jakob Nielsen 'Hierarchy or History?' (http://www.nngroup.com/articles/breadcr ... on-useful/ section). While his arguments are valid in web context, I'm not so sure any-more if we shouldn't allow it for KDE. Imagine a graphics editor where users apply a sequence of sharpen, brighten, adding grain, making monochrome, shading. If all steps are shown in crumbs you just have to click one crumb to go back or access and change the respective parameters via dropdown. I don't see an usability issue. What do you think?

Steppers (back/forward) are an issue when the crumbs exceed the available space and scrolling is needed. I'd say steppers should be shown only when scrolling is active and not abused for the back/forward function.

Heiko,

I'm not keen on using breadcrumbs to show the undo history.

It would be far better to have the steps arranged vertically if you were going to display the undo history (like GIMP does - I assume that you mean having them horizontally), i find it easier to quickly scan down a vertical column to find the step that i was interested in.

One thing, the 'Undo History' in GIMP still shows all of the undo steps even after you've undone to an earlier step, to explain, if you've got a list of 6 commands in your undo history:

1 - Draw with Pencil
2 - Change opacity
3 - Move layer
4 - Scale image
5 - Move layer
6 - Fill

And you undid to '4 - Scale image' then the image would be undone to that stage but the undo history list would stay exactly as it is above with all 6 entries still visible. If you think 'oh - i didn't want to undo to step 4, i wanted step 5 instead' then you could just click on step 5 and it would redo to step 5. It's only when you issue a new command that the undo history gets modified.

If the undo history used breadcrumbs like the ones in Dolphin, you could undo using the breadcrumbs, but then the breadcrumb trail would be modified immediately so you wouldn't be able to redo using the breadcrumbs if you'd made a mistake. You could still use the 'Edit>Redo' menu item or shortcut but having an undo history allows you to see a command & skip directly forward to it.