Enhancement: History section doesn't make sense

[clarkepaul]

The history section UI doesn't make sense to me. The search doesn't work, the toggle view is unrelated as well as the title "Pages", feels like development wasn't really finished here.

I put together a quick idea to give it a refresh in the UX https://invis.io/YT79NDWK6#/157419810_CMS_History1 although it is missing the comparison screen and the option to view drafts or just published versions so would need more work.

[hoKRa1]

I am not able to see the search in Chromium 55.0.2883.87 and Firefox 50.1.0. Has it been removed?

[clarkepaul]

Between the time the screenshots have been made a bit of styling has changed with the introduction of Bootstrap. I think the whole top toolbar in that panel is hidden under the history versions as it either didn't work or was the wrong context eg. Pages title with no site tree.
The UX of this area is pretty bad in that changing to the History tab changes the content of the previous panel.

[clarkepaul]

Marking as impact high as without modifications the history area is unusable on smaller devices.

[clarkepaul]

New mockups are in progress to ensure the files area works on smaller screens and that the following issues are resolved.

Issues with current UI:

• No colour key for new/removed content
• No version number in the list of versions
• Actual page name is not at the top of page (Should replace "Pages")
• Versions are not contained in the history tab (cover page tree), which means the UI is not responsive.
• Revert button should probably be green (not disabled looking)

Potential enhancements

• No HTML view (would help for links, classes etc), could have a view/html toggle
• Do we need to keep all draft versions—perhaps just need drafts since last published?

[jamessilverstripe]

https://invis.io/4GCC2953J#/240908389_Page_-history-_-_Desktop

[chillu]

Marking as impact high as without modifications the history area is unusable on smaller devices.

I disagree on the impact assessment, for reasons I've discussed on silverstripe/silverstripe-framework#1943 (and with Paul in person). Viewing the history of a page, comparing pages and reverting to an older version is a specialised use case that I don't see as a common action in a mobile phone context. We're positioning the mobile support for SS4 as "good for quick edits". The one use case that I think has merit on mobile is approving a workflow request, and quickly reviewing changes before doing so.

Also, if we're touching this area, I think we should convert it to a React-based UI and make it independant of SiteTree - this view will be just as useful for other versioned records (in a GridField context). And it should take into account ownership models of nested versioned records. @clarkepaul How do you see an author reviewing a publish action on a page which also published a few content blocks and related assets? It's kind of a mini-campaigns view, but with diffs rather than just a preview.

I agree this section needs attention, and the new designs look awesome. But for now lets focus on fixing obvious bugs with the current implementation, and look at the redesign in the bigger picture. If the section is unuseable on mobile, then let's hide it there. I'm unsetting the milestone, but happy to review more focused bugfixes if you want to create tickets for them.

[clarkepaul]

I just want to say that even desktop users often have their browser window over half of their monitor rather than full screen. Smaller viewport doesn't alway mean mobile (mobile is the extreme). As for making this into a reusable react component... nice!

There are two main approaches to viewing the history of components that I see. The first one is to only include the content changes on the page they live on (not practical if that component is used on multiple pages though), and the other is that all items require their own history which could be a huge piece of work. I think this needs to be raised as part of the content blocks work.

[chillu]

The ability to show history on arbitrary objects has also come up in our current content blocks research

[chillu]

I've created a higher level ticket for this to account for all kinds of versioned records: silverstripe/silverstripe-versioned#37. This will become important in terms of content blocks, but we likely won't get around to an implementation for another couple of months. I'd expect there to be a bit of discussion and design revisions on how we want to handle nested versioned dependants, so it'll be good to start the designs earlier

[chillu]

We've completely refactored this section and implemented @clarkepaul's redesign, closing.