Initial Wireframing of Cristal

[tkrieck]

@vmassol

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?

Oops, forgot to add it, I will update the screen shots.

@vmassol

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?

Regarding more icons we could break the line, but I need to prototype this. On Log-in, register we can also break the line, but again I will do a mockup to make sure we have available space for this, without interefering too much with the navigation.

@vmassol

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?

I was thinking of showing it on top of the content as it is with the drawer on XS but opening from the left. Searching for something on mobile would comprise these steps:

• tap hamburguer menu
• tap search
• input search terms
• tap search icon
• the sidebar automatically closes to make room for the search page

@vmassol

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?

Interesting perspective, I didn’t think of this button this way. Meaning, having the problem of a lot of pages on the root.

@vmassol

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

It is close, but different from rights. Locking is needed to give the user an option to prevent unwanted edits from himself.

[ludovic]

@vmassol

2. changing the backend is not something that’s supposed to happen often at all (also, if you want to use another backend at the same time, you should use 2 browser tabs or 2 cristal electron apps, since that’s way more comfortable for not loosing your context).

I don’t really agree with that. While I see it possible to have an electron app or a web app (the one served by XWiki for example) to be tied to a single backend, the idea of the default electron client is to allow multiple backends as a core feature. Think about a user browsing all the knowledge he has access to in different Wikis and also his personal notes database on the filesystem. For this to happen it should be easy to switch from one backend to another. Also one idea I’ve been thinking off is allowing a user to add links to other wikis is his own personal wiki tree (the filessytem wiki for example). He would be able to navigate in some cross wiki way… having his personal tree possible stay on the screen. This is just an idea at this point that would need to be tested.

[vmassol]

Yes but you need to consider the added complexity for a marginal use case. The UI needs to be clean and simple and everything not absolutely required or not used often should be moved outside of the main view for simplicity.

I am convinced that the use case you mention is marginal in practice, which means that in 90%+ of cases the user will be connected to a single backend. And even if a user has N connected backends, he/she’ll not need to switch all the time.

This is why to me, it doesn’t make sense to have this visible directly on the main UI of Cristal. I could see this being inside the User menu for example (as it’s user-specific parameter), or somewhere else inside an existing menu.

@ludovic

Think about a user browsing all the knowledge he has access to in different Wikis and also his personal notes database on the filesystem. For this to happen it should be easy to switch from one backend to another.

If this is the use case then switching is possibly not the best solution, it would be nicer to view all your knowledge inside Cristal at once, and not just one backend at a time. You’d also need to be able to search across backends ideally.

Note that with the current direction, this could be a bit strange for the users, since the Cristal UI is driven by the capability of the back end. Thus it would mean that in the global navigation tree (that would include the roots from all the connected backends), when you click on a given page, you’d get a different UI and features than when you click on another one. I wonder how it’d feel to users.

Also note that combining all the backends in the navigation tree is something interesting and I’m fully agreeing with it. But this wouldn’t need any change in the UI (no need for a visible switch on all pages). Same for linking between backends or for searching across backends.

To sum up:

• I agree that we could add the requirement of having all backends connected at once. I don’t think it should change the current UI though. Could be interesting for Thiago to check this out.
• I agree that we also need to use case of switching backends, but to me it would be ideal if this was put inside an existing menu entry somewhere (and not introduce a new UI option on all pages as it was suggested next to the Logo).

<offtopic>
@tkrieck Just thought about scalable usage of the navigation tree. AFAIK, right now in the UI proposals there’s no way to filter the tree by typing some letters, rights? I think we need to add this use case since there could well be a lot of pages in the backend (and even more if we combine backends), and if we could offer something right into the nav tree, it would feel better than forcing the users to navigate to the Page Index. However, it would need to not take space and make the UI more complex somehow.
</offtopic>

Thanks

PS: After writing this long answer and thinking more about the topic, I realize that we’re almost aligned. The only doubt is whether we need the arrow next to the Logo or if we put the switch somewhere else. I have a preference for somewhere else (in the user menu for example). Also, I used to say to put it in the Admin UI but I now see that it’s a user feature and not an admin one.

[vmassol]

@ludovic

While I see it possible to have an electron app or a web app (the one served by XWiki for example) to be tied to a single backend, the idea of the default electron client is to allow multiple backends as a core feature.

BTW you don’t agree that it should be possible to have several tabs open in your browser, with each connected to a backend? Same for having several Cristal electron app connected to different backends.

It’s less good than having all the backends connected at once but that’s a better way of working than switching backends, in which case you loose context and will keep switching all the time.

IMO we need to support this use case as part of the requirements and in the architecture.