Page History UI

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.

Regarding the compare feature, I donā€™t remember if itā€™s in MVP, but if itā€™s not then the button should not be visible.

As always, I would like your feedback on this feature and if thereā€™s something missing from the current proposal.

Thank you very much for reading!

Thanks for working on this!

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?

1 Like

I agree that from a dev POV it would be nicer to have a single LiveData component with various layouts (as we have for XS).

Thanks for working on this.

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?

1 Like

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?

Thank you for working on this!

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.

Thanks,
Marius

Hi!
I do not have much to add, just my two cents about accessibility like usual :slight_smile:

Here is the mockup as it would be seen by a person suffering of Achromatopsia (no color).

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. Like this :slight_smile: 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 :slight_smile:

Additional info on the accessibility issue and how to solve it: Axe Rules | Deque University | Deque Systems


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.


Good job on the mockup!
Lucas C.

Helloo everyone! Great mockup, thank you for working on this!!

Some thoughts:

  1. I agree that we should use a common component like LiveData to represent any dynamic tables.
  2. I agree with @gabrielc that itā€™s not very intuitive what has to be clicked to actually return to a version.
  3. 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.
  4. 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.
  5. 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.

Some visual ideas

Separate Text buttons & current tab

Merged text button

Showing type of change through colors

Con: not an accessible idea

  • green = much more addition than deletion
  • red= much more deletion of content than addition
  • yellow = balance between addition and deletion
  • gray = minimal change (deletion/addition under a number of characters)

Hope these remarks help in some way!

1 Like

It could be made accessible by adding a small icon (and a hidden text to convey this info for non visual users) :slight_smile:
Something like +, - Ā± and no icon respectively.

1 Like

ah actually thatā€™s a good idea and wouldnā€™t really clutter the UI, nice

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.

Updated mockups

Links underlined

Links boldened

2 Likes

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 :slight_smile: (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 :+1:


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 :slight_smile: ). 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 :+1:


Thanks for taking my remarks into account!
Lucas C.

Nice find, I didnā€™t know about it.

Thatā€™s nice too, I will run some experiments on the actual Cristal code.

Thanks for the tips!