What I find slightly odd is the location of the button, on a line that has no specific meaning in XWiki. But i don’t have a better idea ATM. Maybe @tkrieck has some ideas.
Also, did you check other apps/UIs to see how they do this?
Then, there’s the question of the position of the button, either left or right. I agree that left makes it less visible but it’s slightly more strange than right as this is usually where I think it’s seen more often (I could be wrong).
I’m not sure if the buttons are sticky to the page or if they disappear when you scroll up.
I think the style of the buttons is fine with this static arrangement.
Personally, I would have preferred a visualisation of the buttons via a mouse-over effect. In the standard view, this simply avoids any confusion in the interpretation of the direction (page forwards/page backwards). If the buttons were activated using a mouse-over effect, I would centre them vertically and provide them with greater contrast.
I know “hover” and tablets are not very compatible…
Here my hands were also tied by the layout.
For those columns we use the fairly old and difficult to work around bootstrap columns. In their time it was great, but now it’s making it quite difficult to customize our UI. That’s also the reason why I couldn’t get the column to have a nice slide-out effect.
The way bootstrap sets up this layout makes it nearly impossible to make some things without hours upon hours of experimentations, and a lot of custom CSS…
I can take another look at it, but getting it on the right (oustide of the column itself) was a bit hacky and buggy as far as I remember…
They use absolute positioning, so they are not sticky, they’d disappear when you scroll up.
Yeah, it can also make things more difficult to use for everyone. If the hover zone is large it’s fine, but here it would be quite small compared to the screen size, and users would need to look for it to find it (which is not ideal x) ).
Moreover in my opinion having the UI evolve just by moving your mouse around is something we should take care not to do too much. It can cause confusion because of the inconsistent state of the UI.
Personally I don’t think it’s ever necessary to have things appear on hover, and I’d rather have none of those. I fail to see what it brings to the table except confusion and complexity
PS: in minimalist UIs it could be nice but IMO the XWiki UI is not simple enough to benefit from this kind of styling.
I think I understand what you mean
Let me knit pick on the vocabulary: activated for the button is the state when you click on it. I think a better word for what you wanted to say is enabled. In context it makes sense so I could figure it out, but I had to read it twice to understand correctly
Well, this is where we want to go… Anything that makes the UI cleaner with less visible buttons is good (but it shouldn’t be done at the expanse of less usability ofc).
If the button was appearing when the mouse is inside the column, wouldn’t it be good enough?
Hey Lucas, thanks for taking a look at this. It’s a nice feature that’s missing from XS.
Some suggestions:
Keep the button without a border to keep the UI cleaner, OR:
Make the interactive area span the whole height of the sidebar, this way the user don’t need to be at the top of the document to use this feature. In practice this means a very tall button, but with custom CSS to make it more streamlined.
Use a lighter color for the icon;
Change the orientation of the arrow to the action that will take place. So when the sidebar is opened, the arrow should point to the direction the sidebar will go when I click it. Currently, is it serving as a status of the sidebar visibility of sorts, but the sidebar is already visible, so I don’t need reinforcement on this.
Position the icons always closer to the center area. So the toggle icon will be positioned on the right of the left sidebar and vice versa for the other sidebar. Now, I saw in the PR that you are using absolute positioning for these buttons, so maybe this it no so simple.
I removed the border, and went with the idea proposed above: having a fixed position button in the middle.
I used text-muted (slightly lighter shade of grey, used in the breadcrumb for example)
Done
Yup, the columns are floating with variating values depending on the configuration. It’s way simpler to put them on the side. Putting them next to the columns seems like it’d be very complex and brittle
Here is another demo of the updated UI:
PS: The style rules/conditions to get the togglers to appear are already quite complicated and I’m pretty sure I cannot do much better without XWiki moving away from bootstrap columns for layout – which will definitely not happen in this PR ^^'.
if you need a test candidate, we have been live with XWiki as an intranet solution and knowledge base for 2 weeks and initial feedback was that the panels should be collapsible left and right
I find the location weird. I’ve had to look at the video twice to understand where was the button It makes more sense to have it at the top IMO, and ideally appearing when hovering anywhere inside the column.
Thank you! We do not NEED it, but live feedback is always very welcome! I’ll let you know when the changes proposed here are released. In the meantime, if you want to try it out for yourself, you can customize your instance with the changes I proposed in the PR. Note that it didn’t get through all of the quality tests yet, so I cannot guarantee it’s the same level of quality as the XWiki standard code base(it should be pretty close though ). Feel free to ask for help on the live chat if you want to and cannot figure out how to add these changes to your distribution after looking at our doc
We already have a burger menu for the top navigation element.
In my opinion it would be confusing to have an icon that should be used for a very specific and consistent element on the page used for multiple elements.
Off the top of my head, I cannot think of any web UI that does have burger menu icons for multiple elements (especially some with multiple icons on the same page). Let me know if you can find a reference of such an UI
The arrow is less precise but at least its genericity does not convey a meaning that would confuse users.
Summing up the opinions about the height of the toggler:
Personally I don’t have a strong opinion, centered would probably be better for new users because it makes it more visible, but top would be better for most uses because this reduces the average mouse travel length: before you close the panel, there’s a high likelyhood you navigated to the current page and had your mouse on the top part of the screen (breadcrumb, menu, wiki logo, …).
Technically both are possible, centering might be a bit more hacky and inconsistent on niche use cases (e.g. small page on a large screen, the togglers end up below the footer, which is not fixed position) but IMO the technical solution was okay.
Thanks again for your feedback ! I’ll be waiting for tkriek’s answer and then I’ll make progress on the PR
I would prefer these buttons at the top. I don’t think that my decision to hide one panel would come while I was reading the article but when I see the article the first time.
I have no strong feelings for either, so we can go with the button positioned at the top
In the future, when/if we deprecate the bootstrap column and go for a more modern layout solution, then we can revisit this with more layout possibilities.
@CharpentierLucas As part of your requirements, it would be nice to include keyboard shortcuts to hide/unhide left/right panels. For example: [ character for toggling left panels and ] for toggling right panels. WDYT?
IMO it can be considered as an improvement, the toggles do not need keyboard shortcuts to be usable. Is it okay if I open a different ticket so that we add the shortcuts in a different PR than the buttons? This makes things easier to review and merge
Thanks for your feedback!
Sorry for the delay, I must have dismissed the notification without setting a reminder to answer.
