Exploring web manager & content editor topics

Budget
Article Status
Photo Credits
Multimedia Search
Publish to Twitter

...Just some daily routines.

What's the best way to proceed? Shall we each add our comments, then afterwards edit the wiki? Or add each of our experiences below the relevant question on the wiki itself?

something that has baffled me a few times is introducing javascript just previous to the closing body tag of a page, to add an AdWords conversion script for instance

i discovered i could turn off the rich text in the wysiwyg that was for primary entry of page content, paste the script at the bottom of the actual page copy, save, and have it rendered with the rest of the page ... but sometimes it works, sometimes it doesn't; a person coming from a by-hand background figures this is straight-forward and maybe should just work

with a little study i noticed that after the save and in the render, drupal would do different things -- resituate returns, choke on second-preference javascript commenting, duplicate cookie-code brackets; obviously pasting in a script this way is not the right way, as my developer helped me understand

our standard approach now is a CCK field just for a conversion script right before the closing body tag, and this works great

i looked around a good bit for some explanatory text at the time, since i needed the conversion scripts working quickly, but wasn't able to dig anything up

Content strategy! Content auditing should be done on every six months or so (or each month tackle a smaller chunk), then deleting redundant, low quality or outdated content.

Monitoring comments is another necessary task.

A first inventory I made in a mindmap:

Sorry I'm so late with this, but I've been extremely busy this week.

Background: each content editor in the Comms team had responsibility for one section of the website. They could edit the main content column, not related content in blocks.

One of the content editors was also considered an admin, and could create, edit and upload photos into blocks, in addition to editing her section.

I was the web manager. I could edit main content, views, blocks, menus, nodequeues, webforms, videos (which included upload to Brightcove, creation of playlists, etc.). I created logo tables in HTML in main content column where needed (we planned to create a view for that, didn't happen).

I also managed the external web development team, wrote up issues for their issue queue, project managed, developed wireframes, information architecture and the overall web design.

On a weekly basis, I responded to emails noting issues (our internal teams were big users of the site), tried to solve the issues and when unable, wrote them up for the web developer's issue queue. In addition, I scanned the site for issues as yet unnoticed.

I added meta data to nodes as they were created, using Page Title module and Nodewords.

I updated Views (such as views of our executives and our Boards; our clinical trials and research studies, etc.)

I set up path aliases for many view pages that needed them, and where the View was developed long before the final titles of the pages were approved. A few times this resulted in issues because the earlier paths had been used in related (or is that sub?) views.

I set up Google Analytics, Adwords (we applied for a Google non-profit grant), and Webmaster Tools. Since we totally rewrote content, and since many links went to the home page, there was little sense doing redirects. I set up the 404 page to indicate that the visitor should recheck the new navigation or search by keyword for the content they wanted to find on the new site.

With my supervisor, I developed web governance flow charts and documents. Once approved we planned to have a workflow system developed for our web content editor/admin team.

Since our site went live only last November, I also project-managed the second phase of development (unfinished at the time when sharp decline in funding resulted in layoffs, including me).

I had begun to discuss how I could do more development to the site (mostly views, perhaps also content types if necessary), installing modules, etc. We discussed my learning to use git, so that I could clone our site, make changes, get feedback from the developers, then they could pull the changes or make revisions, while I learned.

I did manage to set up git and an SSH key on my Mac, make an account at Github, and find some Drupal folks. Hope to keep learning about it.

I think that's about it. I looked forward to learning much more over the next year (I was just laid off on April 1, 2011). Will have to do that in my next position. :-)

It would be great to have a checklist of what can go wrong on a Drupal site, due to content input errors, when we are trying to solve issues that arise.

Copy/paste from Word often leaves in code (even when using "past from Word" button in WYSIWYG). That code can take down main column text, etc.

Uploads of files/images may not work if non-alphanumeric characters are used in file names.

I'm sure there are more like this, but those are my two top annoyances.

I manage the public web sites for the UGA Center for Continuing Education; this includes, under one roof: a university-based residential conference center and hotel; a for-academic-credit program offering about 100 online courses; a non-credit professional education program offering about 500 courses; a loose collection of public service programs for youth, like science fair; other bits and pieces; and a portal for it all -- http://www.georgiacenter.uga.edu

We overhauled and restructured everything (including content rewrites) and moved it to Drupal about seven months ago, with great infusions of Drupal brainpower from Atlanta's Mediacurrent, with whom we have a much-needed ongoing support relationship.

My recurring tasks include:

• field requests, directions from external marketing firm doing incremental content audit and upgrade of recently redesigned site

examples: reframe taxonomies; exchange pages embedded in taxonomy for higher level landing pages; add descriptive page top image/text blocks to category and sub-category fronts; make page modifications related to campaign traffic study; build custom landing pages; reconfigure image nodequeues; create vanity URLs as 301s at /admin/build/path-redirect for redirection to content aliases with campaign-tag query strings; install conversion, retargeting scripts for select content pages, most thank you pages following webforms; upgrade, refactor multiple forms as needed; create new forms

• after discussion with internal web/marketing governance group on relative priorities, frame new development issues, where appropriate, for drupal support firm

• track existing issues with drupal firm, submit fix/adjustment issues ... picking up what info, orientation i can from developer on the fly

• issues tend to be things like: adapt universal form functionality for several subsets of inquiry forms (mail customer service people with page-specific inquiry information); develop custom landing page functionality; refine default configurations on taxonomy and views (or recover from my own previous garbled instructions)

• monitor content editor updates or step in and pick up myself as needed (usually just node bodies and sometimes banner images and inline images in WYSYWYG); monitor meta data and title tags

• resolve taxonomy issues (items shared across terms, create new terms, delete terms)

• reconcile out-of-date scope content; sometimes this involves deleting, sometimes modifying with text to indicate it's expected to come back in date scope soon -- ex., "get on waiting list"; sometimes unpublishing several individual pages in favor of a central custom landing page; largely dependent on content owners (who aren't the content editors) keeping up with their stuff to track this; there's an overlap here with the fact that they need to keep their content appropriately current and the content editors can't judge that

• build diagnostic self-assessments with Quiz module

• evaluate volatile new content requests to determine if existing content types are adequate or require some refactoring (i erred here in development in the direction of loading the content types down with optional fields that for the most part go unused, rather than proliferating content types; spend a lot of time explaining to people that we can accommodate their content, even though they don't see a page just like what they think they need active on our site)

• work with graphics department on requests related to embedded images and other art elements (rotating nodequeues)

Our workflow was fairly simple, except for review and approval, which happened outside of the website itself.

Our interest on the website, though, was to have a "staging" ability, or better preview. Preview didn't work at all, because we wanted to be able to display (or print) full pages, with sidebars and images, with new or revised content, for upper-level management approvals.

Unpublishing a page might work for some. In our case, approvals could take several weeks, or months, so pages with revised content couldn't be unpublished during the revision process.

We wanted a duplicate page to be produced, which could be revised and approved, and afterwards merged into the original node (so that the node# would not change). Our developers were working on this, said it was possible.

I'd like to see this ability in Drupal, since it seems like a reasonable request in terms of workflow.

I am in favor of using ("reserving") the term "management" for content management related topics, and the term "administration" for "site administration" related topics.

Following that "logic" or preference, I think that the term "web management" (and Web Manager") may be a confusing mix between the two. The term "Web Manager" is ambigous from my non-native English speaker point of view.

Many of us are referring to our job of being BOTH site administrator and content manager for perhaps several sites. So in some situations, the terms or "roles" "Site Manager" or "Web Manager" may seem descriptive and appropriate enough. There are clearly situations where we want to refer to ourselves as having that full responsibility, and not excluding a role by the selection of a term. Sometimes we want to be ambigous, to cater for both of them.

As THIS discussion (and group) is focused on "content management" and not "site administration", it would be practical if we could agree on a clear distinction. This is particularly useful for searching to find things we discuss here, and in a learning/documentation perspective for introducing new people to Drupal.

Not sure if this may be viewed differently depending on whether "you" are a native British English speaker, native US English speaker, or a person who has English as your second language.
If there are significant differences here, I would like to standardise on the term that fits most people/countries (ie. the international perception rather than the UK/US perception. Wouldn't that be fair/best?) I am not entirely sure which term is mostly used across the globe, if for example more people use "Web Manager" than "Content Manager" to describe that part of their work.

I make the following assumptions, and welcome any comments or corrections:

• a) the general, global perception of the term "Web Manager" is more leaned towards managing (administering) the web site (technical administration) than managing its content.
• b) in the strict sense, "Site Administrator", "Site Manager" and "Web Manager" are "synonyms" in the perception of "most people" (not necessarily internally as here in a CMS community - but to our non-technical users or clients?)
• c) it becomes problematic if we use "Web Manager" as a synonym of "Content Manager" internally here in this community, and then have to remember to clarify and use "Content Manager" about the same when talking to people outside the community. This will also be close to impossible to handle when it comes to documentation.

Following those assumptions; suggestions for a couple of adjustments:

The title of THIS very GROUP here is somewhat unclear about this:
"Exploring web manager & content editor topics".
(Hence, good that greggles initiated this very discussion, which I think is much needed.)

Therefore, I think that the name (title) of this GROUP here should be something like:
"Content Managers/Editors".

And the title of THIS node/discussion, could in the light of the above be:
"Exploring Content Manager and Editor tasks".

Put a SUBMIT button at the top of all of your content types: I post 10 stories a day to our news site, and I can't tell you how much scrolling I've had to do over the years because the PREVIEW and SUBMIT buttons were only on the bottom of the form.

Some more experiences here: An Editor's Perspective on Creating Content in Drupal

I agree, it was a very good article. Thanks Yoroy for posting.

The summary is not ready, but this thread has obviously run its course. The inventory i made halfway here (http://groups.drupal.org/node/143274#comment-476119) needs updating with the feedback from responses that came after it.

Text version of what is in the mindmap above:


content editor ux
Usually a complaint about something being broken, which almost always leads to something improperly put into a node.
adding js
check main content listing
see new and updated content
I create my own views to organize/filter/find content.
add tags
add news
lookup unpublishing schedule elsewhere
delete, unpublish things
make forms
what do you once you've got a huge amount of undifferentiated images (and pdfs) in /sites/default/files
content auditing

    article status
    add photocredits
    publish to twitter
    multimedia search
    budget resources
site management