Document Information Tabs

[tkrieck]

Hey everyone, like i mentioned on the topic Initial Wireframing of Cristal I am branching out some key concepts of the layout to keep discussion more focused and organized.

Issue: Loading...

This one will be about the document info tabs.

These guys on XS:

Before starting properly, i would like to clarify some concepts:

• Permanent sidebar: the one that an Admin sets for the wiki, can be customized like XS
• Info tabs sidebar (or info panel): A transient sidebar that appear over the permanent one. It should close on user action (X button) or document navigation.
• Info bar: the one below the document title, interaction here can make the info sidebar to appear. Clicking the comments button for example.

Now, on for the proposal itself

Note: All screens are on a res of 1280x800
Note 2: Here I am using version A of the general layout explained better here. But the same concepts works for both of them.

---

For Cristal I would like to propose them on a sidebar instead of tabs beneath the document, for the following reasons:

• Easier to see if a long document have comments or attachments;
• Easier to correlate pieces of info in the document with a comment or attachment;
• Better use of space on desktops, as they are generally wider than taller. On mobile, we can still show them beneath the document if necessary with some CSS rules.

Having said that, I believe that this solution should not negate a general right sidebar should our users have them on, as you can see in the wireframe below:

Example of permanent sidebar

Info bar
The info bar will reside beneath the document title this will make a general area for basic info about the document. Things like “editing status”, “likes”, “comments”, “attachments” and so on.

Here we can see visible at all times: Edit info (text + avatar), Likes (icon + counter), Comments (icon + counter) and attachments (icon + counter). Versions (history) and Info tabs are in the page menu, as they are less likely to be used on a day-to-day basis. Also, one more reason to hide them is that they would not have counters the same way we have with the other three buttons.

Below you can see how the buttons will behave when populated and when clean

The Info Panels

Clicking on the comments and attachment opens the sidebar. This sidebar will open on top of the permanent one. Closing the info tab sidebar is done with the X at the top, then the permanent sidebar should be visible again.

Below you can see different info panels opened, they act exactly like tabs, so only one of them is visible at a given time. Versions and Information are accessible only via the page menu.

Page menu with Information and Versions highlighted

When the Admin has not set a permanent right bar the info panel will open and close pushing the contents of the document.

Thank you all for reading, and please tell me, what do you think?

[surli]

Hi,

thanks for working on this. This is quite a change compared to current XS UI! So my understanding is that, contrary to what we have currently in XS UI, the tabs wouldn’t be always visible but they would be displayed only if the related contextual information are clicked on (e.g. the number of comments icon) and when going to the 3 dots Page menu, is that right?

For comments it’s pretty clear to me what’s the direct access (without going to Page menu). For the history it’s a bit less clear: you display it when a user clicks on the dates of modification / creation of the page? And for information I just don’t understand when it’s displayed: only by going to the Page menu? I’ve the feeling that Information should be easily accessed without needing to go there, but maybe I’m wrong.

Now the big question is: how do you deal with extension point on that part? For example Change Request injects a new tab in XS for displaying a live data of all CR created for a dedicated page, it’s quite an important feature and it would be a pity to lose that in Cristal. Would that be only available from the Page menu? Or would that be possible to make those panels always appearing like we use to have tabs?

[tkrieck]

Hi @surli

@surli

This is quite a change compared to current XS UI!

Yeah, I know it’s a big change and that’s why I would like to have this discussions now rather than later. Of course, if the changes are not well received, we can always fall back to the default of XS.

My particular pet peeve with the way it is on XS today is that in long documents, this whole section is not so discoverable by the user. So if we go to the default and do it like it is in XS today I would at least like to see a summary at the top of the page like in my version, but instead of opening a sidebar the user would be sent to the bottom of the page via an anchor link. In my opinion, this would be a nice compromise between the two ways of work.

@surli

For the history it’s a bit less clear: you display it when a user clicks on the dates of modification / creation of the page?

No, initially these options would only be accessed through the page menu. But now that you’ve mentioned, a link on the “modified by” line would be actually quite nice.

@surli

Now the big question is: how do you deal with extension point on that part?

In my opinion, if the extension provides an icon, we can show it with the rest of the icons AND have a menu option as well.

If it does not have an icon, we have a few paths:

A - Show the name of the extension along with the icons, but this would make the interface less clean probably breaking the line with a lot of extensions here. Not a nice option IMO.

B - Show it only on the menu page, but this would make the extension less likely to be found.

C - Show exactly how it is on XS today, with a tab below the document. This ensures we have maximum compatibility with current extensions in this area. However, this would separate the interaction pattern of likes, attachments and comments from the extensions. I don’t see it as a big problem since these are not always related with each other.

[surli]

@tkrieck

In my opinion, if the extension provides an icon, we can show it with the rest of the icons AND have a menu option as well.

I just checked, right now the UIX doesn’t ask for an icon (see the parameters in https://www.xwiki.org/xwiki/bin/view/Documentation/DevGuide/ExtensionPoint/Document%20Docextra/) so we need a fallback without the icon.

@tkrieck

A - Show the name of the extension along with the icons, but this would make the interface less clean probably breaking the line with a lot of extensions here. Not a nice option IMO.

I agree, maybe there’s a middle ground to find, like only displaying it when an itemnumber is provided?

@surli

And for information I just don’t understand when it’s displayed: only by going to the Page menu? I’ve the feeling that Information should be easily accessed without needing to go there, but maybe I’m wrong.

what about that?

[tkrieck]

@surli

@surli

And for information I just don’t understand when it’s displayed: only by going to the Page menu? I’ve the feeling that Information should be easily accessed without needing to go there, but maybe I’m wrong.

what about that?

Sorry, I missed that part. The info tab is important, but I think it’s mostly static information, meaning it’s not always changing (please correct me if I am wrong). Even in XS today it is a two step process as I have to:
1 - scroll to the bottom;
2 - click the info tab;

OR

1 - Click the page menu;
2 - Click the information menu option;

If needed, we can have a little “i” icon at the beginning as well. Like below:

Here I grouped the icon with the edit info as these two are related.

[surli]

@tkrieck

The info tab is important, but I think it’s mostly static information, meaning it’s not always changing (please correct me if I am wrong).

Yes it’s mostly static info.

@tkrieck

If needed, we can have a little “i” icon at the beginning as well. Like below:

ok, to be discussed, I’m not sure to be a big fan for having this icon. It could be ok to always have to use the Page menu to access it: honestly I’m mostly using the info tab to copy page references and when I need to check a specific information, so it’s not happening that often.

Now I’m thinking about something: do you think it could be possible to make the different panels “sticky” for users when they want it to be. e.g. I’m performing a specific task in the wiki where I need to consult often the Information panel of pages: so I’d like to display the information panel and to not have each time to go to Page menu and click on Information. Ideally I’d like to display it once and click on an icon so that it remains displayed if I browse to another page. wdyt?

[tkrieck]

@surli

do you think it could be possible to make the different panels “sticky” for users when they want it to be.

Funnily enough, it was something that crossed my mind when I was replying to you previously, seeing how you need for your tasks. On principle, yes I believe it would be a nice feature, especially for comments (a user reviewing lots of pages for ex. or, like you said, checking the info).

Thinking out loud now, this would interfere a lot with the permanent sidebar, the one that could be customized by the Admin. But as the info tabs are user driven, meaning the user has to open them, it is a choice that someone is making not to see the default sidebar and see the info tab instead, and the user can always close it and return to the default state.

Interesting, I think this is something that I can at least do a proper mockup with a flow. I will try to have one next week!

[mpace]

Hi @tkrieck,

I like the top icons. I will enjoy not going all the way down on long pages and I won’t miss attachments so regularly as I do now.

For my use, I prefer having a long list of versions on one line, this is easier to find scroll visually. As long as we still have the history viewer, it’s not a problem. Maybe a link to the viewer should be provided in the tab.

About the extension point, maybe it could be done the Firefox way with its extension button. This would still hide the extension, but it would be separated from the page menu.

[vmassol]

@surli

honestly I’m mostly using the info tab to copy page references and when I need to check a specific information, so it’s not happening that often.

It’s also used when changing the language and editing the content in another language, that’s a bigger use case.

@tkrieck

Below you can see different info panels opened, they act exactly like tabs, so only one of them is visible at a given time. Versions and Information are accessible only via the page menu.

I think we have a problem of horizontal space, making the content of the docextra tabs have a too small area. For example the LD for the History tabs is way too small to fix, and so is the CR tab.

We have several options:

• Do as now, i.e. when using the Page menu to click on a viewer, it opens a full page for it.
• Let the “tab” decide if it should open on the right side or as a full page
• Open a lightbox on top of the current page
• Something else?

@tkrieck

But now that you’ve mentioned, a link on the “modified by” line would be actually quite nice.

Sounds a good idea to me too (in addition to the page menu entry).

@tkrieck

In my opinion, if the extension provides an icon, we can show it with the rest of the icons AND have a menu option as well.

We just an UIXP with a parameter to decide if the viewer is displayed as an icon or only inside the page menu. It’s then up to the UIX to decide. The icon would be passed as a parameter too.

Small note: we’ll need to make sure that the UI scales/displays well if there are lots of UIXs displayed as an icon.

@surli

I just checked, right now the UIX doesn’t ask for an icon (see the parameters in https://www.xwiki.org/xwiki/bin/view/Documentation/DevGuide/ExtensionPoint/Document%20Docextra/) so we need a fallback without the icon.

Side note that Cristal will most likely not be 100% compatible with XS. We’ll need to define what gets broken and how extensions will need to be updated. For example, Cristal will most likely have its own Extension system/manager and any current extension that brings changes to the UI might need to be adapted to continue working.

That being said, we need to try to preserve the maximum of compatibility ofc. And here it’s possible.

@tkrieck

Sorry, I missed that part. The info tab is important, but I think it’s mostly static information, meaning it’s not always changing (please correct me if I am wrong). Even in XS today it is a two step process as I have to:
1 - scroll to the bottom;
2 - click the info tab;

OR

1 - Click the page menu;
2 - Click the information menu option;

Note that the info tab is used not only in view mode but also in edit mode in XS, i.e it’s possible to make changes when editing a document. We could drop that requirement but it’s something to think about.

@tkrieck

Thinking out loud now, this would interfere a lot with the permanent sidebar, the one that could be customized by the Admin. But as the info tabs are user driven, meaning the user has to open them, it is a choice that someone is making not to see the default sidebar and see the info tab instead, and the user can always close it and return to the default state.

The right panels could be important and need to be visible. Couldn’t we have 2 right sidebars open at the same time (right panels + viewers)? But we also need to solve the issue I mentioned above about not having enough horizontal space fo the viewers sidebar first.

Thanks

[mflorea]

Hi,

I’m not fond of displaying the info tabs on the right sidebar, on top of the permanent sidebar. The main problem is the limited horizontal space, as @vmassol pointed out, but also the fact that there may be use cases where you need to view both the permanent sidebar and the info tabs, and toggling the info sidebar multiple times would be a pain.

Have you taken into account displaying the info tabs on demand at the bottom of the window (not page), in a sticky pane, that the user can close, resize vertically or maximize? It would be similar to the sticky pane you get at the bottom of the window when replying to a post on this forum.

If you decide to go with the right sidebar, then you’ll need to have a way to resize or “maximize” the info sidebar, but then the issue is that you may need different styling for the slim sidebar and the resized/maximized sidebar (responsiveness). You don’t have this problem with the sticky bottom pane, because it would be resizable only vertically, without affecting the layout.

Thanks,
Marius

[tkrieck]

Thank you all who replied, it’s always good to see different use cases and features for exploration.

@mflorea

Have you taken into account displaying the info tabs on demand at the bottom of the window (not page), in a sticky pane, that the user can close, resize vertically or maximize?

In fact, I did not, but I do think it’s an idea worth exploring. I will do some work on this, thank you!

@vmassol

I think we have a problem of horizontal space, making the content of the docextra tabs have a too small area. For example the LD for the History tabs is way too small to fix, and so is the CR tab.

I will do some mockups using @mflorea idea of using the sticky panel on the bottom of the window. It could fix the issue of having the content too visually detached from the tabs while not introducing more problems like the horizontal space.

[tkrieck]

@mflorea

Have you taken into account displaying the info tabs on demand at the bottom of the window (not page), in a sticky pane, that the user can close, resize vertically or maximize? It would be similar to the sticky pane you get at the bottom of the window when replying to a post on this forum.

While dealing with the file upload methods (discussed in another thread), I did an example of the info tabs as a floating panel.

Panel opened on to of the document

Resizing the floating panel

The same panel when the user reaches the bottom of scroll. This is the current implementation in XS.

I believe this is a good option when dealing with tables and other types of content that need horizontal space. But not so much for information that needs to have better context with the content, like comments.

[mflorea]

Hi @tkrieck thanks for working on this. Looks promising. Would be nice to have the text (content) fade above the resize line (bar) in order to make it more clear that there is more text beneath. In your screenshots I can see some dots right below the resize bar which is strange, probably from the text below.

But not so much for information that needs to have better context with the content, like comments.

You still have the context I think, if the tabs are floating on top of the content. I mean, for instance, you can still scroll the content to the part that is referred in a comment and still see the comment at the same time at the bottom, no? But I’m probably biased, due to constant usage of XWiki and IDEs.

Thanks,
Marius

[tkrieck]

@mflorea

Would be nice to have the text (content) fade above the resize line (bar) in order to make it more clear that there is more text beneath.

You mean like this? I like it, and it can make the drop shadow more obvious.

@mflorea

You still have the context I think, if the tabs are floating on top of the content.

Perhaps I expressed myself badly. Context is not the right word as yes, you would still have it. More like the ratio between comments and content, meaning, I can see more content and more comments with a vertical bar (this on a desktop of course). I will do some more tests and compare the same version 1:1 between horizontal and vertical comments.

[mflorea]

@tkrieck

You mean like this? I like it, and it can make the drop shadow more obvious.

Yes! Looks great!

[tkrieck]

Hey everyone, just to give an update on this subject. The last iteration, with the panes at the bottom, floating when necessary, seems to be a good compromise between use of space and ease of reach.

We are going forward with this idea for now, but feel free to give your opinion below.

Thanks all!

[gabrielc]

I honestly enjoyed the right sidebar more.

@surli

This is quite a change compared to current XS UI!

I don’t think this is necessarily a bad thing. As far as I understand we’re not trying to redesign XWiki, but rather create something new that works on top of XWiki and some other backends as well (pls correct me if I’m wrong).
As such, these types of modifications should happen. I also believe the target audience of Cristal is not necessarily the exact same target audience of XWiki.

@surli

I just checked, right now the UIX doesn’t ask for an icon

Are current XWiki extensions supposed to work out-of-the-box on Cristal? If not, we shouldn’t worry that much about current extensions and instead focus on creating a product that works well and is extensible through new extensions.

@tkrieck

If needed, we can have a little “i” icon at the beginning as well. Like below:

Not a fan of the “i” icon as I feel too many icons could clutter the UI. We could just throw it in the three dots menu.

@mpace

About the extension point, maybe it could be done the Firefox way with its extension button . This would still hide the extension, but it would be separated from the page menu.

I like this idea as well. Just one “extensions” button that would open a list with all the installed extensions usable on the page.

@mflorea

Have you taken into account displaying the info tabs on demand at the bottom of the window (not page), in a sticky pane, that the user can close, resize vertically or maximize? It would be similar to the sticky pane you get at the bottom of the window when replying to a post on this forum.

I don’t think this is a particularly great idea. Having both left and right permanent sidebars + the bottom drawer open at the same time feels really cluttered to me.

How do we feel about adding different tabs to the right sidebar, similar to how Obsidian does it (https://www.reddit.com/r/ObsidianMD/comments/10pwoxk/adding_multiple_things_to_sidebar/). At the top of the right sidebar would be a few icons for: sidebar set by admin, comments, history, attachments, page info.

[vmassol]

Hello Gabriel. Could you introduce yourself a bit to the community? I’ve noticed you replied to a few threads, mentioning “we” a few times, as if you were part of the Cristal dev team, and I think it would be nice to understand the role you have or want to play in Cristal dev, especially since you’re new to the XWiki/Cristal community. Thanks!

@gabrielc

As far as I understand we’re not trying to redesign XWiki, but rather create something new that works on top of XWiki and some other backends as well (pls correct me if I’m wrong).

This is partially correct. The work being done is both something new and a different product but also a UI for XWiki that is supposed eventually to replace the current XWiki UI. This second criteria is important since it means that the XWiki use cases must be implementable when using the Cristal UI. So yes, the UI L&F can be completely different if it allows to display the XWiki data. The sidebar idea is a good idea to explore in this regard.

@gabrielc

I also believe the target audience of Cristal is not necessarily the exact same target audience of XWiki.

I don’t think this has been explored and so far I believe we’ve considered that the target audience is the same. The main reason is that if you look at the requirements for Cristal you’ll find all the requirements for XWiki and more (extensibility, customizability, etc).

If you what had in mind was less-technical users for Cristal, then I think that’s also the goal for XWiki It’s just that it’s very hard to both be very extensible and customizable and easy to use, for all use cases.

That being said, one difference of persona that I know of is that Cristal is adding one use case vs XWiki: the ability to use Cristal as a personal note-taking application (whereas XWiki is always collaborative). But I don’t think think this impacts the topic at hand here.

@gabrielc

Are current XWiki extensions supposed to work out-of-the-box on Cristal? If not, we shouldn’t worry that much about current extensions and instead focus on creating a product that works well and is extensible through new extensions.

Yes, we need to have XWiki extensions working as much as possible in Cristal (in addition to Cristal client-side extensions). This is needed to be able to use Cristal as the new UI for XWiki. I’ve started brainstorming this with Manuel a while back but nothing was proposed/written. It’s currently not part of the MVP. We know that not all extensions will work as is and it’s likely that we’ll need new releases for some parts of them, but it all depends how we’re able to have bridges too.

@gabrielc

I honestly enjoyed the right sidebar more.

Sure, it looks nice but if you check the past comments you’ll see that one issue that was raised is the available horizontal space for the right sidebar. For example, displaying the history docextra tab as a right sidebar is a problem since it contains a largish LiveData (same for attachments). Thus, if we wanted to use the right sidebar for everything, this would need to be solved.

Also note that ATM, the MVP/POC is being coded with the tabs being at the bottom. I guess we can still change that but a working proposal would need to be proposed real soon since work has already been done and it’s costly to redo that.

Thanks for participating, that’s great!

[gabrielc]

Hi Vincent! Thanks for the insight.

@vmassol

Could you introduce yourself a bit to the community? I’ve noticed you replied to a few threads, mentioning “we” a few times, as if you were part of the Cristal dev team, and I think it would be nice to understand the role you have or want to play in Cristal dev, especially since you’re new to the XWiki/Cristal community. Thanks!

That’s a great point actually . Idk if there’s a specific space where I’m supposed to do this, so I’ll do it here for the moment.

Hi everyone!
My name is Gabriel and I’ve recently joined the XWiki Product Marketing team. I’m currently an intern, however I’ll be joining the team full time by the end of the month.
When I’m saying “we” I’m referring to XWiki SAS. I’m not part of the dev team for XWiki/Cristal. I should probably stop saying “we” as much .