Hey everyone, this one will be a quick proposal for the page history UI. The main objective for this feature is to allow users to navigate between old versions of a page, restore and delete them.
It will be accessed through a tab in the bottom of the page, much like XS.
As you can see the proposal here is not to use the traditional table like view but a more condensed one. But the main fields are still visible (version, date/time, editor and summary). This change in layout is to increase legibility and to keep related information closed together. The summary, being an optional field, is only shown if it was filled at the time of creation.
The visual distinction in each version does not have any special action, its function is to facilitate eye scanning between versions.
Controls for each version are shown on mouse over to keep the interface clean of secondary elements. Below, you can see the explanations for each button.
Note: on the implementation side of things, I suggest introducing a ācompact tableā UI component, with clean implementation for each design system we support.
Iām not against this, but weāll need to be careful to have accessibility in mind when implementing this (e.g., still make those action accessible with the keyboard)
Iām not sure to understand how on can compare to given version with the proposed UI. Afaics there is only a button to compare with the last version.
Also, I think we can implement versions comparison in a second time
One missing point is pagination handling. History can easily get long, and it does not scale to present the full history in one go.
What do you think of adding a āmoreā button, or a pagination to this panel?
Apart from the few comments already made, Iām not sure what the hover effect represents here.
Are the lines themselves clickable? If so, what is the expected action when clicking a line?
Maybe out of topic: even if the compare feature is not in the MVP, would it be possible / easy to add later the possibility in the UI to compare two distant versions - more than 20 apart, which is not possible in XWiki?
Agreed on both points. My understanding is that a LiveTable does not necessarily means a table UI for the end user.
Indeed, here the comparison is made only to the last version, to get the full picture of changes to whatās āliveā, in my opinion this would make the feature simpler to use while still providing enough functionality.
A more button is adequate, perhaps with a quick search to go to specific versions.
No, the lines are not clickable, the hover effect is just to keep context for the buttons that appears. Looking back at my mockup, I can see that I used a hand icon to illustrate the hover, Iāll update it to a default arrow instead.
I really like the idea. It looks a lot cleaner than what is offered in XS at the moment.
My issue is that itās not intuitive what the āreturn to this versionā button does without reading the label. Also, Iām not sure how useful it is as Iād expect people to first want to look at what was changed between two versions before they decide if they want to roll back.
Iām also curious how the hover style would look on a table row which includes a summary. Would the summary disappear to make space for the action buttons?
I think it would be nice, long term, to be able to filter history records by version, author, date, comment, etc. and we need pagination in MVP. All these are Live Data features, so it makes sense to display the history records using a Live Data. Live Data should support multiple layouts, but Iām not convinced that we should implement a custom layout for each use case (e.g. a custom layout for attachments, another one for versions, another one for page index, etc.). Iām more in favor of using a common layout for all these. For instance, we might have a comment / description also for attachments.
As you can see for yourself, it can be a bit difficult to identify what is a link.
What is your strategy for making these inline links easy to read for everyone?
Itās not the case here, but you might also want to consider the case where you have two links inline next to each other. Likethis How do you make the user understand that there are two links? You could also just state that you donāt use two links next to each other like this.
I know it was quite some trouble to handle this in XWiki, you might want to tackle the question early for the Cristal design so it doesnāt evolve into a more complex issue down the line
The contrast of the link color on the hovered entry does not seem to be enough. I quickly got the colors from the mockup picture and thereās only a ~ 2.5 contrast. If you want to uphold WCAG level AA standards it wonāt be enough.
Helloo everyone! Great mockup, thank you for working on this!!
Some thoughts:
I agree that we should use a common component like LiveData to represent any dynamic tables.
I agree with @gabrielc that itās not very intuitive what has to be clicked to actually return to a version.
There should definitely be a comparison functionality and button. Would prefer if the comparison would open in a modal and not in a new page like it does in XS.
The comparison button and the āreturn to this versionā button should be text buttons. I know that if the button have containers too, it will be a bit difficult to fit the version description below that line, but we can shorten the width of the description paragraph to not interfere with the buttons if the spacing is too much.
We could discuss if ādangerousā actions should always have red icons for an extra level of caution from the user? I know we discussed this a while back for livedata in XS
Also, on a seperate note: I have a slight little problem with the extra line under the active tab. I feel like the background behind āPage historyā and making the text bolded is enough to make it clear to the user that thatās the current tab.
It could be made accessible by adding a small icon (and a hidden text to convey this info for non visual users)
Something like +, -Ā± and no icon respectively.
I understand your point, the issue with one-size-fits-all is that a lot is space can be wasted. For example, the field āSummaryā for versions is not required, but if we use a table-like interface the space must be reserved for the summary column.
Now, this does not mean we will need a custom layout for every LiveData, but I think it is important for the main user-facing ones like the tabs below the document.
Good point, I changed the spacing a little bit to accommodate other suggestions and also did it with the summary field filled on the hovered line.
Do you know if we can use border-bottom to mark links? I did a version with all links underlined (see below) but they REALLY stand out, it would be interesting if we could apply the underlining in a slightly lighter blue or gray. Another option would be to have all links bolder (but not full bold), I also did a version below
Well put.
I changed the basic color to a darker shade and it passed the checker. But in my opinion this color, while passing the background check, is too close to the text color and actually loses contrast.
I modified your version a little bit, to use the icon pack we are using now (Bootstrap icons), eventually it will be customizable.
Yes, this is interesting and I advocated for this in the past.
This style is default from Shoelace, one of the Design Systems that we use, the other one being Vuetify. But it is something we can change ofc, in Penpot I needed to choose one for these mockups.
Very good idea, it goes in hand with what Gabriel said earlier:
I just changed the ampersand (&) to proper āandā because those are two different functions. I also did not use the āprimaryā style for buttons because on the whole interface, ācompare and restoreā itās not one of the main features.
This is an interesting idea. How about, instead of categorizing between additions and removals, we just show the amount of changes in the affected version. I feel this would aggregate better the information of a small change (lighter color for example) and a big change. Regardless of add or remove. It would also make the visuals simpler, and we donāt need to assign too many meanings to different colors.
Not sure border-bottom would be very stable for this but thereās nothing against it. This is a styling issue only, thereās no semantics involved and itās okay to make things look like others (namely make a bottom border look like an underlining). I just checked it, and there is in fact a CSS property just for your use case: text-decoration-color - CSS: Cascading Style Sheets | MDN Itās well supported so Iād advise to try it out instead.
If thatās more convenient for prototyping, you can deffo use border-bottom as a close alternative
Sorry, I wasnāt clear enough.
If thereās an underline, you should rely on more than color to distinguish it. Here you have two āstandardā solutions:
Underline it
Make sure that the contrast between --link-color and --text-color is large enough
For accessibility, thereās only the need to follow one of those rules, not both (ie. if you underlined the links itās already enough ). To be honest the color one is really difficult to achieve if you want to make sure contrast is correct everywhere. Youād need to make your links lighter to improve contrast with regular text, but keep them dark enough so that they have enough contrast with your background.
Boldening the links is a good idea in my opinion too, if you make sure the difference is visible enough
Thanks for taking my remarks into account!
Lucas C.