Team's followers can collaborate to create content for pages, styles and blocks. To collaborate with the owner of the team they use the change requests functionality. Sending a change request is easy, basically any follower of the team can edit pages, styles or blocks, however they can't post their changes, those follower changes will be private until the team's owner approve the changes that the follower has sent.
As you can see on the video below e.g. we have change the content of the flip block:
```@emilio.public/flip make everything,nitoku,life awesome! ```
We have change the 8 line from "everything,nitoku,everything" to "everything,style,everything"
After changing the page, we will be able to click on "Changes" dropdown menu to review our changes. If we are happy with our changes we can then send the change to the team's owner for him/her to approve the change. Please note that after you send a change request you will not be able to edit the page again until the owner of the team has accepted or rejected your change. Nevertheless, if you want to edit the page again and before the admin has approved or rejected your change, you can do that cancelling first your change request. Then you will be able to edit your page again, make your changes and then sending your request again.
If you have a programming background this approach to manage changes will probably resonate with you. It is somehow similar to the approach that programming tools like git use to enable programmers to collaborate when they are editing the same development files.
Other document managements systems, like Google Docs, synchronize changes on real time, the main problem for us with this approach is that to enable collaboration, the owners of the document need to enable writing permits to the people that will change content of the document, once writing permissions have been granted there is no review process before the changes have been published. We believe that this "real-time" approach disincentive collaboration, owners will be reluctant to give writing permission to followers that they don't fully trust, even when they could provide valuable input, that is why we have adopted this "git-like" approach where any follower can send changes and the publishing responsibility remains always with the owner of the team.
Change request will be notified to the Team's owner on the Notification tab. As you can see on the the picture below, the notification will inform the team owner about the follower that is sending the change the page that has been changed and it will include an "Approve/Reject" icon to enable the Team's manager to handle the requests.
If we click on the "Approve/Reject" icon of a change request notification the application will show the dialog below. We can use this dialog to see a preview of how the page will look after the change is applied, edit the change, accept the change or reject it.
Clicking on the Page preview icon will display a render of the page with the changes applied to it, please see below. For this particular page, it will show the flip block but instead of "nitoku" the block is using "style" as one of the words that the block is flipping around.
We can also view and edit the change request by clicking on the "Edit change" icon. A dialog similar to the one below will be displayed, this edit dialog is split on three columns. The column to the right shows the current published version of the page. The column on the centre shows the new version to be published if the change is accepted. The column to the left shows the follower's version, in the case of the dialog below we can see that there are no changes between the new version to be published and the version that the follower sent to us. As we will discuss later, there are some circumstances where we could have differences between the follower's version and the one that new version that we will be publishing when accepting the change. For example this could happen if we edit the follower change.
The column "New version" in the centre is editable. If we make any change to this New version some differences will appear against the published version and the version that the follower used to send the change. For example, on the image below we have changed line 9 from "awesome" to "perfect", this change is neither on the Shared version or the follower's version, hence we will see line 9 highlighted.
Please note that we compare the right column (The follower's version) and the left column (Current published version) against the column in the middle ( the new version that will be published if the change is accepted). Note that when we have any difference between the three different versions, those lines will be highlighted, we use blue color to show the difference between the new version and the followers' change request page, green for changes added directly on the editor and yellow to highlight changes against the current published version of the page.
If you have some followers helping you to create content on your team, there’s a huge chance you’ll end up editing the same files at the same time. But, there’s an ancestral fear behind this behavior: the arcane fear of merging those changes. “Hey, if you and me modify the same file... we’ll have to reconcile all our changes!!”. And of course, they assume it will be a painful and error prone process. “So, let's schedule our changes so that only one of us touches the file at the same time”. Ouch!
Nitoku will help you and your team to merge those changes, with the three column comparison dialog you will easily identify conflicts. If the changes have been made against different parts of the file those changes they will be automatically merged.
It is easy to understand with the example below. On the picture below we have some changes that have been added to the page after your follower sent those changes to the team owner. As you can see those changes are collored in blue. Then, we have the changes that the team follower sent, those are collored in yellow. We see how Nitoku's merge tool have added then accordingly, keeping the changes that have been already published and only changing line 10, where our follower made and edit. Nitoku try to identify the changes and add them but there is limits to how smart the tool can be, please check your changes beofre approving them and make sure that the merge results are acceptable to you before approving them.
On the example above the changes made by your team's follower could be identified looking at the three columns on the dialog box. However if the version that your follower used to create the change request is old and lot of changes had happened since your follower sent the request, those differences will be shown on the dialog box too, in this case it could become difficult to identify exactly what are the original follower changes. To have a clearer view of the follower changes you can click on the icon to the right of the label "User made changes with and old version". That action will display a dialog box similar to the one below.
As you can see the on the dialog box above, we are comparing the changes that your follower made against the version the was used originally to make those changes, therefore now we have isolated the changes that your follower made and we can see those changes straight away.
The functionality to create and manage change request is fully responsive and it will work well with mobile phones and tablets. So don't be afraid, as you can see on the video below, accepting and rejecting a change request from your mobile phone is easily done.