Changesets, versioning of Assets/Content-blocks and the like

[Paul Clarke]

Hey guys,

As there has been quite a lot of requests for the versioning of individual items within the CMS we have put a bit of thought into what this might mean for users of the CMS. We are currently doing some user testing to understand how  users of the CMS collaborate, and the basic workflow they go through when publishing content for a bit of insight into its current use.

We think that this type of versioning lends itself well for allowing collections of items to be made for which users can publish all at one time (eg releasing a section of a site, marketing campaign), or even a group of authors to collaborate on content together. We have created some early stage exploratory concepts which are by no means what would actually get built but they do help as a basis for conversation and of course we would love to hear what you guys think.

For this example I've used this scenario flow:

1. Files area: A file has been updated with a new image, this change would impact a few different pages.

2. Pages: Before publishing content users would get notified if publishing this current item would effect the status of other items. They would also have the ability to be able to review all changes including those on other pages.

3. Campaigns (working title): Custom collections could be created with several benefits (eg scheduled publishing, permission based groups, release history...)

I'm open to commenting directly on the mockup but they might get missed by others so you might want to just keep the conversation in this thread? I have tried to keep the introduction of "Campaigns" something that wont get in the way of the current user flow.

As more actions will be introduced into the UI I feel they will need to be simplified (something I'm also testing—I realise the icons aren't quite right).

We have some other ideas for choosing "Campaigns" at a higher level than the site tree which would include all of the model admin sections—this hasn't been mocked up yet (see dropdown above sitetree).

Check it out here: https://invis.io/644ZQEIRT

Cheers

[Marcus Nyeholt]

Excellent! I've played around with a somewhat simplified concept in the past - https://github.com/nyeholt/silverstripe-changesets - that ties into another module (https://github.com/nyeholt/silverstripe-syncrotron) to allow for cross-system publishing of sets of content. Very much experimental, but functionally there. The main technical challenge that I never addressed (other than to lock the content from being editable) is what happens when a piece of content needs to be updated for two separate changesets (aka campaigns). This is a line of conversation that has been discussed in context of single pieces of content in a workflow - ie what happens when there's 3 different states of a page that need publishing at different times in the future? but applied more broadly to a changeset itself. 

Anyway, very interested to follow/contribute! 

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at http://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

[Paul Clarke]

From discussions we have had here, we thought we would keep things as simple as possible. When an item is edited in one changeset then that item would be changed in others also (items would share the same state no matter where it is being used). Personally I haven't gone as far as thinking about your scenario of 3 states of a single page/item being published at different times (hurts the brain :/ ).

[Jonathon Menz]

Hey Paul,

Those mockups are really nice (as usual). I like the Campaigns idea and think that approach could complement a static caching implementation really well.

I think the interface is well thought out but I am a bit concerned that it adds quite a bit of complexity to the publishing workflow and might be intimidating for your casual CMS user on a brochure website. Is this something you see as being standard out of the box, or an optional module?

Like Marcus I don't understand the implications of having multiple unpublished campaign states on the go -  it seems like as soon as you publish one the others will become invalid. Kind of like branching in git - they would need to be rebased :) same goes for repeating campaigns - I feel like this could lead to some big messes or unintended side effects, especially where has_many / many_many relationships are concerned.

Maybe out of the box we could only allow one campaign/draft state? This would be kind of similar to the current model I guess but make it a lot clearer for CMS users about when their changes will go live (solves the 'why did my gridfield changes go live instantly' question). We could make it so that you don't need to enter a name for the campaign until you actually publish the changes, and then it just becomes a nice description in the history. Again this is a lot like git! Think having a single draft state out of the box would would ease my concern about complexity, and perhaps multi-campaign / recurring campaign functionality could be added with a separate module.

Replacing an image in the asset store with another one from the asset store seems a bit strange to me - but I guess I'm looking at it from a pre-4.0 filesystem perspective. After doing this replacement would you have two File objects in the database that both reference the same filesystem asset, or would you have duplicate filesystem assets with different filenames? The latter seems like a waste of space.

Last thing I wanted to flag is not a UI concern but just a technical consideration for whoever ends up trying to build all this great stuff :) currently the 'Used on x pages' detection is very misleading and almost useless I'd say. If I recall correctly it doesn't consider has_many or many_many relationships and I don't think it even considers has_one relationships. It's only counting the number of times a file has been used in HTMLEditorField content. SilverStripe developers in general promote a structured data model over freeform content so that field should actually say "Used on at least x pages, but possibly loads more" :) So in order for the concepts to be fully realised in a reliable way that usage detection would need a significant upgrade I think.

Anyway great job! I really like the edge-to-edge gridfield in the Campaigns screen too.

[Paul Clarke]

Is this something you see as being standard out of the box, or an optional module?

That hasn't been totally decided yet as this is still pretty far from being developed but what we were trying to do is keep the standard flow as much as possible so it doesn't impact the user too much. The draft published states will be something that other items (like files) can use, it makes sense this part of it would be core. It has been mentioned that perhaps in could be in core but requires config to turn off or on. Ideally we would improve on the concept interface so it doesn't impact the user as much.

I don't understand the implications of having multiple unpublished campaign states on the go -  it seems like as soon as you publish one the others will become invalid. Kind of like branching in git - they would need to be rebased :) same goes for repeating campaigns - I feel like this could lead to some big messes or unintended side effects, especially where has_many / many_many relationships are concerned.

You can't have more than one "latest unpublished" version of any particular data object. If an item is in multiple changesets and one is published then you would expect it to be publish in the other set too (with notification), that kind of mucks about with the changeset history but otherwise items would only be able to be in one set at a time (something I would like to avoid). This is were the conversation gets deep into dev land and one of the devs might be better placed for discussing this point.

We could make it so that you don't need to enter a name for the campaign until you actually publish the changes, and then it just becomes a nice description in the history.

With our initial sketches we tried to have the user working directly within a changeset (we tried "my recent changes" and "changes this session") but it didn't feel right to the people we tested it with, so didn't put that into this concept. Having the user add a description to what they just published is a nice way for history to become more understandable (like a commit message). I would really like to have some sort of activity feed for changes incl. who made those changes, this is site wide and not just changeset based though so have gone down that line.

Replacing an image in the asset store with another one from the asset store seems a bit strange to me - but I guess I'm looking at it from a pre-4.0 filesystem perspective. After doing this replacement would you have two File objects in the database that both reference the same filesystem asset, or would you have duplicate filesystem assets with different filenames? The latter seems like a waste of space.

I only used that as an example as it was easy to explain to a participants of the test, it was a change that could happen to multiple pages and the change was visual. You're right that this wouldn't really be the norm and users wold typically upload a replacement image. In my scenario it would be "duplicate filesystem assets with different file names" though. I didn't into the finer details just yet but we did think about duplicates, merging of duplicates, using images which are already on multiple pages... but we weren't trying to solve all the problems just yet and just see if the basic concept provided benefits to users.

If we do go ahead with any of this we will need to go into finer details for each aspect.

Cheers for your comments