Thank you all who replied up to this point. I will update the wireframes here shortly based on feedback from you and also an internal meeting that we had.
Hi @tkrieck Thanks for this proposal and for the work done!
Some thoughts below.
I’d like to discuss the process of defining a UI and how it’s approached.
Since:
- we’re designing a second system, we need to take into account the knowledge we’ve accumulated into building the first system.
- we want that UI to become the XWiki UI in the future
I’m thus proposing that we list all features that we currently have in XWiki’s UI and make sure that we have a place to display them in Cristal’s UI in the future. I feel we need to plan for them now and not later since pushing that to later will result in having to redo portions of the UI (as I doubt that we’ll want to drop features).
For example:
- Liking a page
- Custom panels (right panels and panels layout?)
- We wanted to allow right panels and this is why in XS we didn’t put info panels on the right side for ex
- Editing a page (couldn’t see it in your screenshots, is it because the idea i
- Changing the syntax of a page
- etc.
Do we agree about this approach?
Do you have a full list somewhere to make sure you’re finding a UI location for each feature and not missing any?
Also, it’s important to start thinking about UIXP (ie extensible zones that can be contributed to by customizations). For example, a horizontal menu (as on xwiki.org)
I think we need to agree on terminology. For me these are not just data sources but back ends and they can come along with various services (not just a storage service - for example XWiki comes with a full-fledged Rendering service).
I was not aware that we wanted to allow for on-the-fly backend switch. Now I don’t think it’s different from any of the hundreds of other configuration options we will have (and that we have in XWiki), so we need an Admin UI for changing the configs in general, and not just for this.
I don’t consider changing the backend on the fly a key aspect of Cristal. It’s a feature that won’t be used much IMO and I don’t think it needs to be a special case.
Note that switching backend is the same as selecting a new wiki since the content will change. It also raises questions of sync if you have made local changes and before they’re synced, the user changes the backend used. We need to make sure that the local changes are not synced in this case. Not a UI issue per see but wanted to raise it.
I find it confusing for users to have 2 create buttons. We brainstormed a lot about the location of the create button of XWiki in the past (and moved it several times). Could be interesting to review these design decisions.
I think we need something more generic to allow setting various things: language, syntax, whether the page is hidden, apply a template, etc (even see xobjects, sheets, etc). Ofc these should be hidden for normal users but shown somewhere for advanced users.
BTW, in your UIs, you don’t differentiate simple users vs advanced users. It’s good if we dont’ have differences but alas I don’t believe it’s possible. I think you don’t have differences now simply because you’re still missing a lof of UI features (see above).
Thanks!
Hey @vmassol thanks for the feedback.
Agreed, that is something I am trying to do on the roadmap for this month, linking the wireframes to user stories already defined on Jiras. I just don’t think everything is mapped yet.
Absolutely. A lot of work is still needed, especially if we are going to have 100% feature parity with XS.
I am using the jiras here for features to work on initially.
About UIXP, is a concept I need to get acquainted on, it is a new thing for me.
The two buttons are proposed because is an interface paradigm used extensively on apps like Notion. But as @amilica said, now they are perhaps grabbing too much attention and could be de-emphasized a little bit OR maintain the approach from XS, with only one button.
Agreed, the interface can be generic, but calling the interface could be done with discriminate options, so the user can see that they are available but not needed right away, and it’s fast to access them. The important thing I tried to convey in the wireframes was to provide a way for a regular user to simply start typing information without the need to go through a dialog or separate page with lots of options and features. =)
Indeed, if possible I would like to avoid it, but let’s see how we progress.
Thanks!
Hello everyone, today I would like to bring you some updates regarding the sidebar and selection of backends on Cristal.
Note: My next steps will be on the more info, attachments, comments sections of the document. So here they all are unchanged from last version.
After your feedback, I did a new version with less emphasis on the backend, but still keeping it visible. Here we have much more emphasis on sub-wikis.
Also, while the mouse is outside the sidebar area a lot of the controls will be hidden, only being shown when the mouse is over the sidebar. To keep the interface cleaner, the buttons for “New page” and “Indexes” are icons only and have tooltips on mouse over.
Selecting previously used backends.
I still think that selecting a backend should be easily done, without going to the admin section. My reasoning for this is that the user could use a local file storage for personal stuff, while using an XWiki instance for company work.
This element is still present on the sidebar but always at the bottom, so always visible, but with less emphasis. I don’t know an appropriate number of backends that could be shown initially, but maybe we can cap them at 7. If the user has more than that, then we could show them as a separate list, perhaps as a dedicated dialog.
Below, you can see this new version in context of the whole interface. There are other changes here and there. Like the new button as an icon only besides the current page on the breadcrumb (always visible, in this case), thanks for the idea @amilica.
Sorry I forgot to answer you sooner. This was done this way because while the content of the page might be small, the breadcrumb can be a lot bigger and longer (and probably will). Also, you’ll have the ability to make the page 100% of the width, aligning both elements.
Indeed it is not the focus right now, but it will be soon enough. Thanks for the read, I will keep this in mind.
So that’s it for me for now. I hope to be back soon with more changes and new content.
Thank you for reading!
How will the user be able to discover these features without using the mouse. E.g.:
- when navigating with the keyboard
- or when using a touch screen?
Thanks,
Marius
Good points, on navigation with keyboard the :hover effects would be triggered by :focus. On touch devices, everything will be visible right from the start.
Thanks for the new proposal. Now honestly I’m a bit lost: the subwiki menu opens when you click on the arrow next to the XWiki logo? Or is it when you click on the “+” button next to “Mywiki name”?
Sorry, I tried to cram too much stuff into one screenshot. The subwiki navigation is accessed via the arrow next to the logo.
Ok, so I don’t really understand why it’s there then 
I mean: the XWiki logo doesn’t provide any info about the subwiki you’re currently in, so why a user would click on the arrow to switch the subwiki? I would have expected to see the subwiki name as the root hierarchy of pages and then to be able to switch from there.
So maybe it’s just the XWiki logo which is wrong in your screenshot?
Well, each subwiki can have its own logo, with the XWiki being the default one. That was my thought process positioning the menu there, but maybe we can have it next to the Wiki name, IDK.
Now that you mentioned it, with a bunch of subwikis and each without a logo defined, it could be a little odd to use this menu, the name below it would change but not the logo. I will do a couple of variants on this to explore a little more.
Hmmm note that there’s no logo explicitely attached to subwiki right now: a subwiki has only a name / description / owner and other technical stuff (see for example https://www.xwiki.org/xwiki/bin/view/WikiManager/), so technically speaking if we want to have a logo per wiki we’d need to add it in the descriptor.
Ah, thank you! This clears things up. I will redo this part then, no point keeping the menu up there.
Thanks for the insight!
Note that I talked to Thiago privately and mentioned that to me, the backend selection should not be immediately visible as 1) screen estate is expensive and we need a clean UI and only have the most important actions visible 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). Thus the backend selection can be more hidden and shouldn’t be visible all the time.
2 Likes
Issue: Loading...
Hey everyone, I’m back with some updates to the Cristal interface.
To keep things more organized, here I will remain on the topic of general UI only and branch out other discussions to different topics. So, there’ll be one for sidebars, one for information tabs, tags, etc. I will update the links to them here as I go.
Other discussions:
Document Information Tabs
Synchronization visibility on Cristal
Flow - Moving documents on Cristal
After your feedback I redid two versions of the main UI, one more focused on Notion like navigation and another one more traditional to XWiki Standard. Both have the same features, and I did all my layouts taking both into consideration. But ideally going forward I need to focus on one.
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.
Pros and cons of each:
Version A:
-
Pros
- The interaction is fairly focused, all things global are here. Main navigation, user profile, search.
- Being close to Notion layout, we gain points with someone who is used to that kind of app.
- We gain a little bit of vertical space for the content of the document, especially true on mobile.
- We can still allow customization of menu header and right sidebar
-
Cons
- The sidebar can get convoluted, especially if someone wants to customize more panels there OR if we need to cram too many features on the same space.
- Is different from XS Standard, so someone that is used to work on XS will feel the differences
Version B
-
Pros
- We have more horizontal space for features, current and future;
- Is close to XS and other sites, so there’s less adaptation on part of our users.
- The logo (branding) is always visible, even with the sidebar hidden
- More space is available for customization on the sidebar
-
Cons
- Main interaction is more scattered, with navigation on the left side and global features on the top right
- We lose a little bit of vertical space
- Mobile requires more effort to reposition all the elements
With these reasons set, we can move on to the wireframes properly.
Notes:
- All screens are on a 1280x800 resolution;
- Different from XS the hamburger menu here open and close the left sidebar, not a floating drawer; We can still have the drawer it in the future if we deem necessary, but then the sidebar icon will need to be changed.
Blueprint of both versions.
Here we have a view of them without content, to better focus on the differences.
With content and detailing on other areas
Left sidebar hidden
Mobile View
General Feature Set
Adding pages
After your feedback, I changed a little bit the buttons for adding a new page, so there’s less emphasis on them now. But I still maintained two buttons, this is because if the left sidebar is closed we can still have one on the breadcrumb.
For first time users, maybe some exploration of the interface will be necessary. But after the initial contact, the user will learn the standard ways of adding pages and the interaction becomes more fluid.
@amilica I did a version with the rounded add ( + ) on the breadcrumb, but I didn’t like too much the aesthetics of it, maybe I am biased 
. But I agree, is a little more visible, I will post it below so others can have their opinion as well.
Also, as you can see, I still maintained the like, comments and attachment on the horizontal. I did because in large monitor, on your proposal, these icons could be situated very far away from the document. But I will explain a little bit better in the topic about the right sidebar.
Rounded Add button:
Editing pages
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.
And lastly on the general UI scope, the main navigation.
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.
Thanks everyone for reading! See you next time
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.
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?
hmm for me that’s part of the Rights to give to a page, and thus contained inside Administer Page.
sounds good to me!
Thanks @tkrieck I think the UI you’re proposing looks very nice and I like it.
I’m curious to know more about this 
BTW, with version A, the search input becomes a Panel (and thus becomes customizable by the user).
Oops, forgot to add it, I will update the screen shots.
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.
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
Interesting perspective, I didn’t think of this button this way. Meaning, having the problem of a lot of pages on the root.
It is close, but different from rights. Locking is needed to give the user an option to prevent unwanted edits from himself.
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.
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.
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.
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.