Design: Content page

[LukasHirt]

Design draft for content page of documentation. @tboerger @michaelstingl I tried to bring navigation closer to the style of https://docs.mulesoft.com/general/ as you both recommended. Also is there used directories as mentioned in proposal owncloud/docs#695

I would like to raise a discussion about preserving the breadcrumbs. The previous directories will be already distinguished in the left sidebar navigation so I would like to save a little bit of space and get rid of the annoying problem with alignment between search and breadcrumbs by getting rid of them. Would do you say about that?

[michaelstingl]

@pmaier1 @settermjd what do you think?

[tboerger]

Maybe add the Edit this page and Master buttons back to the right side of the breadcrumb, otherwise I really like that :)

[settermjd]

@LukasHirt, on the whole, I really like the changes that you've made. I do have four questions, however:

1. What will the visual cues be for navigation links that have sub-items?
2. Does the square, grey block just indicate the start of a navigation list or breadcrumb?
3. As "Edit this page" and "Master" are visually joined, it seems to indicate that that they're strongly related items, when they're not. Would it be better to add some visual separation between them?
4. An on-page table of contents or "On This Page" navigation list is an excellent UX feature. Would it be worth adding some further contrast to it?

[LukasHirt]

@LukasHirt, on the whole, I really like the changes that you've made. I do have four questions, however:

1. What will the visual cues be for navigation links that have sub-items?
2. Does the square, grey block just indicate the start of a navigation list or breadcrumb?
3. As "Edit this page" and "Master" are visually joined, it seems to indicate that that they're strongly related items, when they're not. Would it be better to add some visual separation between them?
4. An on-page table of contents or "On This Page" navigation list is an excellent UX feature. Would it be worth adding some further contrast to it?

1. I was thinking about putting there a simple chevron. But I'm still trying to figure this out.
2. This is just as a placeholder for icons. I need to discuss what icons should belong to which category so just to make it clear that they'll be there, I put there the squares.
3. Sure I can try to think of something. I'll also work on a separate design where it will be returned next to the breadcrumbs as @tboerger mentioned and then we can compare those two prototypes.
4. Sounds good, I'll work on it.

@tboerger @settermjd Thank you both for your inputs. I'll work on it again on Friday and will get back to you with the results.

[LukasHirt]

@tboerger @settermjd

So I tried to make some changes after your suggestions. I came up with three possible versions.

To summarise the changes:

• I moved the versions button in all three prototypes back next to the breadcrumbs.
• In one is also edit page link moved next to it but I also tried to play with the position of that link a little bit and moved it under the table of content to make the table a little bit more dominant. Also, that link is not anymore a button to make it more separate from the versions.
• I would like to implement also a report an issue link - in case of a user coming to docs with some problem and not finding a solution, he could just click on the link and go straight to creating an issue so we now that is happening. I'm just not sure how this would work since we have different repositories for projects.
• The last prototype is changing styles of the sidebar and secondary top bar to unify them more with content and to make them less distracting.
• Last changes took the place in the sidebar navigation. I added chevrons for items which have sub-items to visualise it and for the "root" items icon to differentiate them from the sub-items.

Let me know what do you think about these changes and which of those prototypes should we go with in your opinion.

[michaelstingl]

I like the 2nd version, with the "edit" button below the TOC. Problem might be, the TOC can be a lengthy list…

[LukasHirt]

@michaelstingl We could set some max height to the TOC and cut it a little bit in the case of too many items - this way the edit action could still stay visible. Also, this would be probably needed anyway since I would like to have that list fixed when a user is scrolling.

[mmattel]

What prevents in having Edit and Report over TOC, then the TOC list can be long ?

[tboerger]

If the toc is really that large it should be split into multiple pages anyway.

Imho it's good to put the edit link below it. For the issue link we could add an attribute per documentation definition, if this isn't already available.

Just the style of the version selector is the only thing I don't like that much.