Description

Summary of this page

• • Summary of this page
  • Navigation bar (forum discussion)
    • • New page button - too much emphasis
      • Navigation Menu Movement
      • Font-size (general and nav menu)
      • Menu items line height
      • Contrast & Hierarchy
  • Page content
    • • Spacing between paragraphs 
      • User - Pretty Name
      • Table default look
      • Code block default look
      • Escaping a macro
      • List item spacing
      • Toggle Headings 
      • Link Hovering
      • Quote UI
      • Attachment section in [see which design system]
      • Too important visually
      • Jumping in edit mode
      • Empty lines in edit mode
      • Empty lines/ too much spacing added in view mode (Shoelace)
  • Proposals covered so far
    • Login & registration flows (design page | forum | issue)
    • Move / Rename documents UI design (design page | issue)
    • UI for Live Data (design page | issue)
    • Switching Configuration on Cristal (design page | issue)
      • Update on 6 November
        • Menu icons
        • Current configuration
    • Onboarding Cristal (design page | issue | forum)
      • For Admins
      • New flow
      • For normal users
    • Macros Editor Integration (design page | issue)
    • Cristal Icon (design page | issue)
    • Positioning of hints (design page | issue | forum)
      • Accessibility concerns
    • Switching Visual Source and Source edit modes (design page | issue | forum)
      • The source code 
    • Realtime session proposal (design page | issue | forum)
    • Page rights UI ( design page | issue | forum)
• To be continued

Navigation bar (forum discussion)

New page button - too much emphasis

The new page button is a very normal/expected feature, it doesn’t need to be that highlighted. Most people that use Notion or Confluence or just general knowledge management tools know the button is usually in the left side bar. It is not the same case as XWiki.

Vuetify specific: Because of how it’s styled, the button seems to have some correlation with the current page, as they have the same height and background.

Current	Proposed Update

Navigation Menu Movement

When I open the navigation bar, it should push the content to the right, not cover it. I’ve expected this behaviour from the first time, and it still bugs me a little bit every time I try Cristal. It just doesn’t feel as smooth as it could.

Font-size (general and nav menu)

The font-size in the navigation menu feels slightly too big. On my Mac, on 90% viewport size, it looks right, but on 100%, slightly too big. Maybe this is subjective, I’d be interested to see what others think.

Menu items line height

The distance between pages in the nav bar seems a bit big. When deleting, the following css code it seemed better.

.v-list-item--density-compact.v-list-item--one-line {

  min-height: 40px;

Before	After

Contrast & Hierarchy

I would encourage a higher contrast between selected parent page and child page

Page content

Spacing between paragraphs 

I would increase the margin-top of any heading so there’s a clearer distinction between sections. Notion seems to make that margin = 2 * an enter’s created space (this is just an approximation, but seems right). 

Before	After

User - Pretty Name

I shouldn’t appear as XWiki.AdinaMilica, I should appear as Adina Milica with my name linked to afuture profile page.

Table default look

It should be the default to thave the table in full-width. I assume that most people would expect this.

Even when trying to make the table full width, it doesn't stay that way. Ths cells resize to fit content, it seems like.

The default look for tables should be bordered (in view mode too)

Code block default look

The code block should have a line number by default.

In the last version of cristal, The code block doesn't have a background and it's extremely confusing because:

• you select the code macro fromt he slash menu
• nothing appears 
• you start writing again - I personally thought it's a bug and started writing again "/c..." in an attempt to try again to use the code macro from the slash menu. 
  • I did 5 times.... - yes, I know - before realizing that the font I'm writing in is a monospace one which PROBABLY means I'm already in the code macro

Escaping a macro

Like in Notion, after any macro, there should be an automatic line available so the user can exit macros without any issues. If I wasn’t accustomed to XWiki’s usage patterns, I would've been frustrated that I cannot create a new line after the last macro in a page. I did get to make it by going up a few lines and then going down.

List item spacing

Every list item should have a bit more margin-bottom than it has so the delimitation between items is more clear. Notion does the same (just a few pixels make a difference) with padding-top and padding-bottom. See Cristal in the first pic and Notion in the second.

Before	After
note that this is in a previous version of cristal but, the issue still persists in the last version, even if it's better than in this screenshot

Toggle Headings 

The goal of toggle sections: the content of each section is a bit too long. That makes it hard to see the overall structure of the document . I want to keep the long text, but I also want to see the main points of the page, in the same viewport. Thus, I choose a toggle section.

Implementation 

I'm surprised of our implementation of toggle headings. I would've expected that we'd make a toggle section, not 3 toggle headings. I see that I'm able to turn a toogle heading 2 in a toogle heading 4, though?

Maybe it would be better to do one of the 2 following:

1. not have 3 toggle headings in the slash menu, but have one Expand section - this is also a better name, I think - section which would be easily configurable as this behaviour is already being supported
2. if we only want to have headings collapse/expand and not simple text sections, we can add by deafult the possibility of a toggle to any headings (like Obsidian), BUT without showing it unless the user hovers the left side of the headings (whre the handler and the plus icons are). Like Obisidan, we can make global setting to include or not a toggle by default in headings.

No indent

I personally preffer option 2 from above as this would also mean that expanded content stays in line with the normal untoggled content, without creating an indent. This is also something I don't like that much in the current implementation and I don't like it in Notion and Confluence because of the same reason. The only one that does it almost how I like it is Obsidian.

Note

Note that I don't know the technical limitation of this idea and I also don't know how does it affect PDF rendering that will be done in the future. This is my perspective as someone that loves to organize text content and collapsable section are one of the best things 

Link Hovering

I think the waiting time on the menu that opens when hovering on a link  is too small. It should just stay on the screen while the user hovers on the link.

Also, would it be hard to see a preview of a link (at least if it's part of the wiki, if not in general)?

Quote UI

I'd like a bit more vertical padding and margin top/bottom to the quote macro.

Also, nice to have, but not essential, using an actual quote icon at the beginning - more of a UI thing, not everything needs to be flat and simple.

Attachment section in [see which design system]

The attachment section needs to be improved. Detail later.

Too important visually

Certain areas are given visually more importance than it is needed:

• New page
• Attachments - they are not essential
• Edit button

Jumping in edit mode

I’d love to just jump in edit mode and not click a button to do it.

Empty lines in edit mode

Empty lines in edit more should be preserved in view mode.

Empty lines/ too much spacing added in view mode (Shoelace)

In edit mode there is a certain spacing which is far smaller than in view mode.

Edit mode	View mode

Proposals covered so far

Login & registration flows (design page | forum | issue)

Better UI design 

I would’ve liked a more visually appealing login design. Something easily customizable by any company. These days it seems popular to have a split screen design for auth screens: one side the actual login and one side an image or a Welcome back message. Example:

Placeholder text

I want every input in Cristal to have placeholder text with a smaller contrast against the background. See example in previous design.

Hide/view password

I want the password to have an hide/view toggle (eye icon).  See example in previous design.

Danger color 

The asterisks of the inputs should be red.

Success should feel better

The successful registration should be nicer.

Officialism of integration

For registration in another backend, that backend’s logo should be on the button or somewhere to reinforce the officialism of the relation/interaction between Cristal and that backend.

No more username login

Also, why do we keep logging in with usernames and not using email like any other product? I know XWiki does this, but can't we move away from this?

See example in previous design.

Move / Rename documents UI design (design page | issue)

Splitting move and rename

• I strongly agree with keeping moving and renaming as separate features.
• I would split Rename into Change title and Change URL.
• So in the end, we’d have Move, Change title, Change URL.

UX of moving

I feel that once a user gets used to the simplicity of the drag and drop as the main way of moving a page, they won’t even question the existence of another way of moving (a modal). They’ll just find a way to move a page by drag and drop.

Another easy way

Another way would be to use shortcuts:

• CTRL + x would initiate the movement of a page.
• CTRL + v under a certain page would make a child of that specific page.

Less dialogues maybe?  - Think about this more

What I would like to question is the need of having a dialogue appear everytime you rename or move a document to confirm something that’s pretty default and normal behaviour (keeping links, preserve children) … This can still be an option to set up by the user, but not a “every time” kind of feature, but more like a “once in a while” kind of feature. Both these feature seem too mundane for me to have a screen/modal slow them down.

UI for Live Data (design page | issue)

already given feedback see if anything new to add

Switching Configuration on Cristal (design page | issue)

I think the switch should be very identifiable (logos of the integrations do the trick) as it’s a core advantage of Cristal, but not prioritised visually (it should stay at the bottom of the screen).

Configurations should have icons so the user can identify them easier in the uI.

The top 3 most used configurations should be shown so the user can just click on them and switch. Once the user switches to a configuration, the previous config takes the first place in that top 3 shown.

See how I envision it:

In the process of setting or adding another configuration, what a configuration does needs to be showcased.

I still don’t understand how a backend change works for Cristal’s UI.

Some small GIF or image could explain what the user will see after the change. I find this essential so users are not expecting different things.

Update on 6 November

I see that we moved configurations at the bottom which is great. I still think icons are a must.

Menu icons

Even for configurations that just change the design system or the editor they also should have relevant icon that could be changed by the user (in the future).

Current configuration

I know there's a bit of contrast difference between the selected config and the unselected ones, but it's really small. There should be a more obvious, but still aesthetic way of showing the current config:

Onboarding Cristal (design page | issue | forum)

For Admins

Complexity of decisions

The onboarding for admins is not just a “getting up and running guide”, but also a presentation of the technical capabilities of Cristal.

The onboarding for admins should be split in 2:

• Presentation (immediate, presets what can be done, how it looks like) - a series of modals like slides
• Configuration (can be done later, is a series of “tasks” that need to be done by the admin) - an expandable/collapsable list of tasks in the bottom-right corner  of the screen - like in Webflow and others

New flow

#1 Presenting backends & how would one look in Cristal's UI

#2 Presenting possible design systems to choose from based on how the wiki looks with them or how main elemetns look like

#3 Presenting the options of editor and how they differentiate themselves based on usability (very summarized)

#4  End + giving new tasks for actual configurations

#5 The user exists presentation and sees his configuration tasks. Clicking them opens the respective menus

For normal users

For normal users, I wouldn’t have an onboarding tbh. The only thing that needs to be highlighted for a first time user is how to switch backends and that can be made by temporary styling, not by a tour. If we need a tour for normal users, our UI is not simple enough to understand (and I think it is, tbh).

Macros Editor Integration (design page | issue)

Current situation

For the MVP version of Cristal, it is okay how the macro slash menu appears right now.

Future

For the future of the product, I find it essential for us to implement what Notion did for explaining what a macros does - including a image of the macro filled in.

• it's not enough to have a text explanation of the macro especially for more complex macros
• even if the user understands what the macro is about, a image would help to establish the expectations on the visual side (how does the concept I understood render in this platform?)

Implementation:

Notion made this image and short explanation appear on hover on the macro name.

For mobile, we couldn't have the same behaviour. I propose on mobile to not have an image and just keep the description under the macro name (as it is currently).

Cristal Icon (design page | issue)

I've already proposed 2 new icons for Cristal. 

Positioning of hints (design page | issue | forum)

I'm against having hints under the input, if we can define the position of the label easily. If this is not an easy thing to do, it shouldn't be prioritized in the roadmap of Cristal, as it's not an esential thing.

There are two ways to look at input hints:

1. they are needed when the input is moderately easy to fill in and they just help the user make a decision - usually shorter
2. hey are needed to know how to enter information in the input (technical fields, complex questions, inputs that need some more upfront knowledge) - usually longer

These two categories can also be looked as:

1. Guidance hints
2. Tutorial hints

These two categories imply different positioning

1. Guidance hints can be after the input.
2. Tutorial hints need to be before the input as they explain to the user how to inout information. As said before, they are essential for technical fields, complex questions, inputs that need some more upfront knowledge 

While in its current state and its near future state, Cristal will have easy to understand macros and inputs, as it grows, the feature complexity will grow.

Inputs will move from having guidance hints to tutorial hints.

Thus, hints shoul be placed above the input.

Accessibility concerns

I'll just quote someone that explained very well here:

For a decent accessible website the instructions should always be before the field. They're not just there for typical users, but also are important cues for accessibility.For example: Screen readers will hit the description / hint before reading the form field details so the user will know what is needed to complete the field successfully. If the hint comes after the field then there is a good chance they will have already filled it in before they hear the hint text.If the hint is also used as a validation / failure text then it is poor accessibility to display these after the field for the same reason. The user needs to know the failure reason before hearing their actual entered value so they can hear how their entry broke the validation. Otherwise they would have to assume each field has failed and then wait to hear if it failed. Hearing the validation first prepares them 'ok, this field that is about to be read out has an error in it'^{(Actually, for even better accessibility you should list out all the validation failures at the very top of the form so the user knows straight away what fields failed and how many there were that did)}Also, don't forget Keyboard users. If someone is using a keyboard and is tabbing through fields without using the mouse and the form has many fields 'below the fold' then tabbing into lower down fields will only bring that field into view and not the hint text if that text falls below the field.

Switching Visual Source and Source edit modes (design page | issue | forum)

The switch itself

I think this proposal should be redone as it doesn't take into consideration how Cristal looks right now.

For the current UI, I think we need a toggle at the top near the attachment icon (or replacing it, as I propose that it shouldn't receive that much attention in the UI, see here).

This toggle would appear only in edit mode.

On hover or focus a tooltip would appear explaining what does the switch do.

The source code 

I'd propose as a feature to highlight by color or even by bolding important things in the source code. These includes:

• header tags for non-inline macros
• headings
• link labels or full links (for the ones that don't have a label)

I find it extremely useful in markdown to have some sort of indicator when important things begin and end. Yiu get to see the structure of the document very quickly and find stuff easier. 

A good example of this is the Cryptpad Markdown editor (though it has a bit too many colors, I think) and the obisidian one.

Editing very quickly the example provided in the current proposal's design page, we get this.

Realtime session proposal (design page | issue | forum)

 Very nice proposal overall. I still really wish you could enter the edit mode  just by clicking on the content itself.

I agree with the rest of the proposal

Page rights UI ( design page | issue | forum)

So the design page proposal needs to be updated with the forum discussion needs.

The idea for the permissions UI, regardless of the administration preffered UI, would be to include somehwere a switch to fullscreen. This would work perfect for XS too. 

In full screen I see the UI like this:

#1 a toggle between groups and users seperate from the table

#2 the header of the table contains:

• A button for Next [number items hidden] in the header that once clicked hides the first permission and makes the next permission appear
  • If a permission at the beginning is hidden, a button labeled "Previous [number of items hidden]" will appear in the left side of the header

#3 filter input for group name seperated from the table

To be continued