Initial Wireframing of Cristal

[vmassol]

@tkrieck

From now on, Version A is Notion like (sidebar focused) and version B is XWiki like (header focused). I say “focused” because there’s where the global interaction will be, things like user menu, help, search, custom menus, etc.

AFAICS the only difference is that in option A you’ve moved the search + top right menu inside the left sidebar.

One thing I don’t see on your blueprints for option A is that help icon that we see on option B. Where has it gone?

This raises a more general question: Right now in XS, the top right menu provides a UIXP and thus it’s possible to have more menu entries than the ones shown in your blueprint. The available space in option A is quite limited. Imagine that we have 5 icons to display, how would they display in option A?

This raises the question of the Login / Register icons/entries from the menu that are being discussed in some other forum post for XS. How would they be displayed in option A?

Second point, for the mobile view, you haven’t shown what happens when you click the hamburger icon. Does it display the sidebar before the content or after? Let me ask it another way: how easy is it to search for something in option A on mobile?

Globally, I think I have a small preference for option A. Vertical space is scarce and it’s good to have more content displayed.

@tkrieck

But I still maintained two buttons, this is because if the left sidebar is closed we can still have one on the breadcrumb.

There are not the same AFAICS. The one in the sidebar is a global one, that is when you click it, you’ll need to specify where to create the page, while the one in the breadcrumb is already situated.

I personally don’t like that much the global one in the sidebar as it’s a bit anti wiki (not being situated which may push users to put lots of stuff at the root) and I think I’d prefer the ability to have a + button inside the navigation tree, on each tree node. Is the planned?

@tkrieck

For now, the main focus of Cristal is to have an always editing, real-time collaboration aspect, so there’s no need for an “Edit” button. But a lock feature should be available via the page menu for sensitive pages.

hmm for me that’s part of the Rights to give to a page, and thus contained inside Administer Page.

@tkrieck

Navigating to other wikis and indexes.

After the points mentioned by @surli and @mflorea I simplified the page and Wiki menu quite a bit. Now they are only accessed on the sections of the sidebar, not on the XWiki logo anymore. The same works for the application menu. Also, all buttons are always visible.

sounds good to me!

Thanks @tkrieck I think the UI you’re proposing looks very nice and I like it.

@tkrieck

But I will explain a little bit better in the topic about the right sidebar.

I’m curious to know more about this