Composr Tutorial: Coordination between staff and staff/members

Written by Chris Graham and Patrick Schmalstig
When you run a Composr site, you do not merely create a website for people to visit. As an interactive, dynamic, system, Composr can provide different features for different users, and in particular, different features for staff than are available to ordinary members or visitors. Some of these features are specifically written to be for staff, some of these are a result of the privileges system, and some are the combination between the ability to create new categories/forums and control access to these using permissions. The term 'staff' is used loosely in this tutorial, to mean anyone with the necessary permission: by default, it is staff who have the mentioned permissions, but this may be altered.

Staff can use these features to distinguish themselves from ordinary users, and to collaborate together towards the operation of the website. This tutorial will cover a number of these features and how you might use them; some of these referenced features will be presented according to the Conversr system but are also likely to be included in third-party forum solutions in some form.

Table of contents

  1. Composr Tutorial: Coordination between staff and staff/members
    1. Who are staff?
    2. Coordinating with other staff
      1. Private forums
      2. Conflict detection
      3. Staff checklist
      4. Staff notifications, and the tickets system
      5. Notes within content
      6. Validation and workflows
      7. Reviews
      8. Staging sites
      9. Version control
    3. Content reporting
    4. Warning members
    5. Whispering
    6. See also

Who are staff?

We use the term staff in one of two ways:
  1. Whoever the forum/member system thinks is a staff (for Conversr this means administrators and super-moderators)
  2. Anyone who has been given whatever privileges are required for a particular situation

We try and limit the first case and rely on privileges, for maximum flexibility. However there are some website behaviours that hang more on an intuitive sense of someone being staff rather than actual privileges. For example, tickets have a "staff reply" feature, for posting messages between staff within a ticket; as this intrinsically rests on the concept of staff as already understood by the user, we don't codify a privilege for that.

Coordinating with other staff

Private forums

Image

Staff topics block on the Admin Zone dashboard

Staff topics block on the Admin Zone dashboard

(Click to enlarge)

Image

Now you don't (because I SU'd into a regular member account and thus lost my staff permissions)

Now you don't (because I SU'd into a regular member account and thus lost my staff permissions)

(Click to enlarge)

Image

Now you see it...

Now you see it...

(Click to enlarge)

A very effective feature in running a website, where there are multiple staff involved, are forum permissions. By using a forum where only members in staff usergroups may gain access, staff can collaborate on matters relating to the operation of the site. Many members may not realise it, but often staff forums of large sites are almost as busy as the publicly accessible forums.

Conversr creates a default staff forum for you on installation.

Conflict detection

Image

Example of conflict detection on a support ticket

Example of conflict detection on a support ticket

(Click to enlarge)

If more than one user is editing the same thing at the same time, Composr will put out a notice informing you. You can then coordinate with the other user so that you don't overwrite each other's changes.

Staff checklist

On the Admin Zone dashboard is a checklist of tasks to be performed. This combines tasks that are auto-detected with a set of shared manually added tasks.

You can also share links and notes on the Admin Zone dashboard.

More can be read on the Admin Zone in the Admin Zone overview tutorial.

Staff notifications, and the tickets system

Staff have access to a wide variety of notifications, to be informed on what is happening on the site.

In particular, if the main_contact_us is being used for user contact messages, messages will be directed to support tickets (and notifications sent out), and staff will be able to take responsibility for handling the contents of the message.

Notes within content

You may wish to use the Comcode staff_note tag to embed comments within resource Comcode. For example, adding a comment to a news post.

Additionally, most content has an explicit 'staff notes' field for you to share notes within.

Validation and workflows

You may wish to intentionally not validate content, even when a staff member adds it. This provides an opportunity for another member of staff (perhaps monitoring the needs-validation notification) to check the content is ready for publishing.

Larger enterprises may require a more sophisticated workflow system. Composr has a non-bundled workflows addon, which provides a fully-managed process of multiple configurable approval steps for content (to different staff usergroups), before it goes live. The workflow system can be implemented for different content types, and is currently implemented for galleries out-of-the-box. Enterprise customers will want the system tuning for individual needs. If you require an advanced enterprise workflow system, you should enquire with a third-party developer or a Composr partner with your specific needs, and whatever system you require can be set up for you.

Reviews

You can set the "Comcode page review frequency" configuration option (Admin Zone > Setup > Configuration > Administrative options > Periodic content reviews) so that Comcode pages are automatically flagged for regular review, to make sure they stay updated.

Notifications will be sent out automatically, or you can browse content needing reviewing from:
Admin Zone > Audit > Periodic content reviews

Staging sites

For large sites, particularly tightly-run operations, you will want to test stuff on a staging site before making it live. Because of the constant flow of community content into the live database, it is not usually viable to just replace the whole live site with the staging site. You'll therefore need a more sophisticated process.

Novice users may simply copy & paste stuff from a test/staging site, to a live site. This works reasonably for most cases of new content, but not when more wide-spread changes are required, such as changes in menu layout or whole new categories.

Advanced users who are mainly aiming to stage content changes can use the Composr repository WebDAV feature to mass-copy data between sites.

Programmers managing site deployment also have a number of options, as Composr includes a number of APIs for import/export of content types (for example, menus). These are handy when used in coordination with the popular git tool (i.e. hosting site code in Git, and writing deployment scripts to deploy things such as menu changes).

There's no magic-bullet when it comes to staging site changes in any software because of all the different change factors that could be involved (e.g. interconnected structural changes between two diverged versions of a website). However a skilled team has many options available to them, so can always come up with a workable deployment plan for both small and major site updates.

Version control

There are a few angles to version control on a Composr site:
  1. Composr automatically does version control for Comcode pages and theme CSS/templates (i.e. the main parts of Composr websites)
  2. You should always have a good backup automated backup plan in place
  3. You can make use of the popular git tool (useful for enterprise users)

On point '3':
git is a standard tool to use when making code changes, but not for database changes. However it is possible to use WebDAV in coordination with git to manually do formal "commits" when changes are made to a website. If you are an enterprise interested in this functionality, you'll likely want to take on a developer as a consultant to test/tune this functionality to your particular content needs, or set up an automated system if appropriate.

Content reporting

Image

A forum post needs a report / warning

A forum post needs a report / warning

(Click to enlarge)

Image

An offended member reports the post

An offended member reports the post

(Click to enlarge)

On busy websites, it is often impossible for staff to read every bit of content that is submitted. Therefore there is a facility (if the tickets addon is installed) for members to report problem content to the staff (with an additional reporter message), so that the staff can then perform any appropriate action.

You can also report any kind of content within the system like this via the embedded "Report this" links. For the forum you can report individual posts via a custom-designed reporting interface.

If a user finds, say, a gallery image to be offensive or in violation, they can click the report link, which brings up an overlay window. In the overlay, they can provide information about the content, such as why they feel it should be removed or edited.

A logged in user will also be given the option to report anonymously, which causes the support ticket to be created under the Guest user.

Non-logged-in users may be asked to enter a CAPTCHA to prevent spam, and may optionally provide an e-mail address for staff follow-up.

Once content is reported, the report is actually created as a support ticket. This method allows staff to collaborate together to decide how to deal with the problem, as well as allowing clarity so that all staff know how the issue was reported and dealt with.

When a user submits a report, the addon will then first check to see if the same active user (based on session ID) already reported that content. If so, it checks to see if there is still an open ticket associated with the report and will post to that ticket as a follow-up. Otherwise a new ticket will be created.

The support ticket will include the content title (as a link to the content), the content type label, the content ID, the content submitter (i.e. the member who created it), and an embedded rendering of the content taken at the point of the report (in case the offending member later edits or deletes the content). It will also contain the report information supplied by the reporter.

We have found it often to be the case that staff will report content themselves, so that they can easily bring them (and possibly their related action) to the attention of other staff. It may also be useful for staff to report content to maintain a record of evidence in case the original content is edited or deleted.

Warning members

Conversr provides a facility for warning members. This is just one (although powerful and flexible) example of a punitive measure that may be taken out against a member. For full details, see the 'Tools for punishment' section of the Dealing with annoying users tutorial.

Whispering

When members use the Conversr whisper feature to make inline-personal-posts, they are visible to moderators (which by default, equates to the same as staff, dependant on specific forum permissions). This has two consequences:
  1. moderators can tell when members abuse the feature
  2. moderators can use the feature to write in-topic messages to each other (and hence, all other moderators too, due to the ability for all the moderators to see them all). It may be necessary to reign back your staff if they use this feature too much and make sarcastic remarks: the unforeseen may become reality, with the target of the sarcasm becoming staff at a later date, and seeing such remarks.

See also


Feedback

Please rate this tutorial:

Have a suggestion? Report an issue on the tracker.