User roles (global / local)

• Anonymous (G)
• Authenticated (G)
• Member (G)
• Reviewer (G/L)
• Manager (G/L)
• Owner (L)
  

Object states

• Private
• Visible
• Published
  

Object states fix the Mr. Stupid problem… how do you deal with a Member who creates material that you don’t want to be public?  They fix this problem on a case-by-case basis: by requiring review of each individual page by a higher-privilege user, before it can be converted into a published state.

In order to publish something on the site, you need a certain level of trust in its quality.  The object states workflow locates that trust at the level of the individual object.  This works well for quality control purposes, but not for time-use purposes, because the Reviewer has to manually publish or reject each piece. 

It’s faster to locate the trust at the level of a person – give lower-level users local approval to publish all their objects.  Implementing this suggests creation of a fourth user role: Contributor.  Under this model, Members would not be able to add items at all…

For next time: who controls group membership?  Does group membership control contributor status?  What about sections of the site with lower trust standards?

As Amy Diehl is moving to Massachusetts, I'm taking on her position in developing the new CACvoices site.  In this post, I'd like to quickly introduce myself and then talk about some priorities for the fall semester (2006).

My name is Matt Penniman, and I'm an MA student in the Digital Rhetoric & Professional Writing program.  I've worked for the last three plus years at Allen Neighborhood Center, doing mostly communications and technology related work.  I'm very interested generally in how information technologies are adapted, tweaked, and twisted to make them useful in community development settings.  I'm also interested specifically in CACvoices, which has a great deal of potential to serve Lansing area organizations in a unique way.

In order to move forward and make this tool both useful and used, I see the following priorities:

1. Prepare the CACvoices site itself for public launch.  Target date: November 15.  This will involve fixing a number of technical issues with the site, first being the TeamSpace bug that is currently breaking upload capability.  It will also require clarifying user permissions (particularly with regard to deleting items) and a number of other, smaller fixes.  Non-technical fixes include reviewing architecture of the site, descriptions of various objects, and text used to guide the user through common tasks to ensure that use of the site is intuitive, transparent, efficient, and satisfying.
2. Prepare documentation to accompany the site.  Target date: November 15.  One of the challenges here is to figure out how to effectively weave use of documentation into the workflow of creating and editing objects on the site, such as through a sidebar or pop-up window.  Amy is working on a list of components that still need documentation.  One possible shortcut may involve adapting previously-created documents for our purposes, with appropriate attribution.
3. Transfer data from the old CACvoices site to the new one.  Target date: December 15.  In order to do this effectively, we first need to categorize the current content as active (regularly maintained and changed by users), inactive (no longer updated, but still valuable) and dead (useless or inaccurate, not worth transferring).  We might also try to find or construct an automatic translator to convert pages from the old system to the new; failing that, we may simply need to cut and paste.  With any of these approaches, we will need to interview existing users to determine how to make the transition painless.
4. Publicize the new site and promote its use.  Target date: December 15 (and beyond).  At this stage, it may be premature to delve into specifics on this point.  We will want to highlight the key innovation that CACvoices offers: a shared workspace, not simply a web page.
5. Develop theory and write about our efforts.  Target date: the indefinite future.  It may be inaccurate to label this as a priority; perhaps it is simply a factor to keep in mind.  Eventually, we will want to theorize and publish about this project, and it would be wise to lay the groundwork for doing so while we work on the other needs discussed above.

As a learning exercise, I will be transferring this blog into the CACvoices site over the next week or two.  Thank you for the opportunity to share this project with you, and I look forward to the months ahead.

Best,
Matt Penniman

*Things to Play with Right Now*

Mini-portal from California


*Essential Features*

Distributed content creation
- protected (password) for community-based organizations
- a "my space" for community-based organizations

Open source (systems)

[centralization and aggregation is valued]

It should be possible to add content to cacvoices without generating a new webpage
- modify non-password protected webpages
- generate and add to forums
- blogging


*Ideal Features (the want list)*

A system that works with MYSQL


*Limitations*

finding the human resources to support systems
finding the human resources to support humans

With the WIDE migration to the newest version of Plone, we have had to change the URL temporarily. It is now
http://www.wide.msu.edu:8000/caci

the site is still broken (there is currently no left navigation), but it is not as broken as the site if you follow the old link.

For the sake of documenting all my thoughts on the site for future reference - I just wanted to point out that regardless of which CMS we choose, we will need to decide how to handle the data component of the current site. because it is coded in ASP, we were never able to convert it successfully to MSQL. This problem will most likely not go away even if we switch to another CMS. However, we should decide if the data component is an essential piece of the site (i.e. my home buying metaphor from an earlier post). If it is essential, we should consider how to best handle that component. Currently, on the redesigned site - the data just links to the version on the current site. Is this how we want to handle it?

I was just thinking that perhaps we should make the CMS decision in the same way people tend to recommend purchasing a house. First, we decide what the CMS has to have - what we are not willing to sacrifice. Then we decide what functionality we would like the CMS to have, but that could be sacrificed. Then we look at our constraints - application and support constraints for example. With this criteria we weigh the CMS option available.  Maybe?

We have now migrated to the new version of Plone, and I am hoping to get it back to looking the way it did before the migration shortly - as well as explore some new components to add onto the site - forums, etc. which were not really functional on the earlier version. In talking with Marcus regarding the server which currently holds CACVoices, it sounds like it could host anything with MSQL and PHP, but I don't think, and Jim R. could tell me for certain, that it can host Zope also. I think Zope has to stand alone - and Zope is what Plone is run on.

I think that, in order to narrow down the type of CMS that CACVoices could use, we would need to weigh affordances and drawbacks to decide what CACVoices is willing to compromise, and what it is not. I am out of ideas as to an out-of-the-box CMS solution. Each has positives and negatives in terms of usability and usefulness (the types of functionality being offered) and each has affordances and drawbacks regarding sustainability. The simpler the system, the easier to administer, the less likely it will offer what the community actually wants. The problem makes my head want to explode.

Irregardless of what system we choose, and which server - WIDE or Ingham - hosts the thing, it will require administration and upkeep - of this I am fairly certain. CMSs are designed for organizational settings, and based on our common understanding of how a business runs. That is, the CMS anticipates that a site administrator will talk the language of the CMS, will monitor and clean up the CMS as it gets cluttered, and can upgrade or fix the site when it breaks.  Currently, and I could be wrong in my supposition, Marcus acts as the site administrator, while someone else at Ingham does server administration. I am most concerned about the server administration - perhaps becuase it is what I understand the least and what must be taken care of for sustainability. I am confident that whatever CMS we choose, Marcus can pick up the nuances of the site administration and the coding language.

I think it is important to make this decision sooner rather than later, to ensure that we give enough time to port content  (as it is a tedious job) and since each system requires a great deal of time to customize, if we do switch to another CMS, I think we need enough time to anticipate all its own idiosyncracies.

I think that if WIDE is willing to host the site, and offer support through their server administrator - as well as assistance with site administration as Marcus learns the system, then Plone seems a good way to go. Without that support, then I think another CMS, even if less functional for the user, is feasible for CACV. I can narrow down a list of CMSs that might work - but we will not know if they really can work until we try to build them.

LeRoy is correct, when a CMC is up and running it will offer many different media hosting options.  

One might be a "build your own website without being a programmer" option using intuitive tools and aimed at small non-profits and human service organizations, and thats what CACVoices is about.  

Amy's help has been fantastic.  I really want to thank you for your careful thinking, Amy.

I can think of a couple of things to move us along.  One would be for Rob and Amy to learn about the server that CACVoices is on.  Although there isn't much to learn: its a standard Compaq running IIS.  A new CMS can always go there if it'll live in that environment.  It'll be a long time until the CMC has servers of its own.

Another step would be to set aside time strictly for comparing CMSs and narrowing our options.  I'll bet Amy can narrow the list to two or three on her own and the group could take it from there.

As soon as our fieldwork is done, we can install the selected CMS, port content and launch. If a CMC ever gets going, we could move the box over there.

So how is field work going?  BTW there are two groups currently launching new websites on CACVoices that might be interesting to you.  One is Child Abuse Prevention Services and the other is Immigrant and Refugee Resettlement Coalition.  CAPS is building furiously. IRRC is meeting to discuss what to put on their site. 

This is just me outlining what I see as the next steps of the CACVoices website (specifically from an interface and admin standpoint).

The WIDE site, and the CACVoices site need to migrate to the latest version of Plone.

The CACVoices site needs to be separated from the WIDE site (currently it is underneath the WIDE site, which is why a new user does not generate their own folder).

Help documentation needs to be written for admin stuff - how to change the CSS, how to add new functionality, like blogs etc.

New functionality should be added (these already exist, but are only available for the newer version of Plone, and so are contingent on the migration)
    blogs
    forums
    email newsletters and listserves
    more skins
    more help docs
   

Other things to consider - as I have been reading lots of Plone Documentation over the last week or two -

There is a beta version of a Plone add-on that may be very useful - below is the description: This is made by a community organization... and does it *sound* like what we are looking for.

Use Case: You want to be able to create a number of subsites within a Plone instance. Each subsite needs to act like a portal unto itself, except that it will have no independent membership component. Each will typically be maintained by only a few persons.

 A PloneMiniPortal is a folderish object that acts like the root of a simplified portal. PloneMiniPortal provides two major components of this:

1. The MiniPortal object itself, which allows the manager of a MiniPortal to control many aspects of its presentation and behavior.
2. Replacements for the navigation, news and upcoming events portlets, the search box, and the event and news tabs  that start their searches at the MiniPortal object. This makes a MiniPortal object act -- in many ways -- like a portal root.

The MiniPortals product was developed for a community network that wishes to be able to allocate easily maintained simple web sites to community groups.

We anticipate that MiniPortals will be most useful when deployed within a Plone instance tuned for this purpose.  Trying to use MiniPortals inside a Plone instance in use for much else will probably endanger mental health.

Also, I think there are several components of Plone - such as topics that we might be able to manipulate to serve our needs.

that's all I have for now -
   

I have been trying to think more definitely about what types of functionality needs to exist in the CMS to ensure that the system is sustainable for both users and administrators. Here are my thoughts on the administrative end -

the server (I don't think we know yet what server this will be on?) needs to support the underlying coding languages and database of the CMS. The server administrator would need to be able to know or learn a little about the language powering the CMS in case of breakdown or the release of an updated version of the CMS. The CMS needs to be able to work using the operating system of the server.

The site administrator (could be the same as the server administrator, could be different) would need to know how to change the site's look and feel, how to add new add-ons as they are developed for use, would need to be able to change user permissions, etc., as well as how to use CSS to style or change the styles of components of the site. Would need to feel comfortable enough with the back-end to troubleshoot issues as they arise.

So the question I am grappling with is, how do we prepare for the first issue of the server - when we don't know for certain, or do we, where this site should sit?

For the second piece, as I imagine Marcus will maintain his role as site administrator, I am not sure what the best route to take in thinking about this is. Is it better to have a site, like Plone, that has perhaps a steeper learning curve (though I am not certain about that) but that has a very up-to-date developer website with free administrator manuals, forums, tutorials, or is it better to have more of a WYSIWYG administrative back-end, but that will still have a learning curve, and may not allow as much flexibility?

Since every CMS is idiosyncratic in its interface, as I have been playing with 4-5 other CMSs, I can tell that each has an administrator interface that will require a learning curve.

Another issue/question to think about when comparing CMSs is that every component or promise of functionality is not the same. For example, I am maintaining three blogs right now. Of the three, each *says* they all do the same things, but they achieve these things in different ways, and with varying degrees of ease or transparency.

I think of all of the CMSs I listed on the initial post, all offer "friendly" URLs, where the query string is not in the URL.

The skins question is tricky I think, because unless you are familiar with CSS, or the administrator is willing to customize your CSS for you, the skins are really no more than a wider variety of templates to choose from. This blog came with three skins, but to add the CACVoices picture, I had to FTP the site, download the template folder, find in the CSS where the original picture of oranges was, save over it with my picture of CACVoices, and then ftp the folder back to blog site.

So, if the point of the skin is to make your site look very different from CACVoices, and customized to reflect your organization, then this becomes a harder task. Do people want different skins for the site, or do they want their own site?

In part I think this balance between customization and ease of use is a big, big issue because we are wanting to do something with content management systems that is not normally done with them, and which they haven't necessarily been built to support. I think that what we are trying to do is extremely important because CMSs can make spaces like CACVoices work, and they only build into CMSs what they think there is a demand for, so that makes what we do that much more valuable for ours and future projects.

CMSs seem to conceive of themselves as working for one organization or group and supporting the work contained within that organization. That is why customization is only supported to a point. We want customization akin to a hosting service, where users get the space and the tools to use the space, and then free reign to create their organizations site within our larger site. But CMSs tend to think in terms of uniformity, and the ease of use is in the creation of “content” not sub-level “web sites.”

So then, I think we have to creatively figure out how to trick the CMS into being something it could be, but isn’t yet. We have to trick it into being something people will actually use. If that is possible?

Thoughts?

Also, I just found a cool blog that is all about comparing CMSs, though at my first pass through it they focus on proprietary and non-proprietary CMSs.

www.thecontentwrangler.com

I just want to briefly outline what I see as the major factors in selecting a new CMS or keeping Plone as the CMS for the CACVoices web site.

• System requirements
• Support
• Ease of Use
• Performance
• management
• interoperability
• flexibility
• built in applications

I am borrowing these catagories for comparing CMSs from CMS matrix. This website is really helpful in comparing the various CMSs and their affordances and weaknesses.

System requirements - include the application server, cost, type of database, license, programing language, and application server. This is obviously very important in ensuring that when CACVoices is moved off of the WIDE server, it can function easily somewhere else.
Security - pretty much standard stuff here... login requirement, kerberos authentication, etc.
Support - this factor includes online help, developer forums, mailing lists, conferences, commercial books etc, that are available for the developer to help them with the CMS.
Ease of Use - this includes drag and drop adding of content, WISWG editors, image resizing, spellchecking, etc. Basically, how easy is it to create content.
Performance - this factor is primarily caching of pages, and load size of pages.
Management - this factor includes asset management, sub-sites, administration, workflows, etc.
Interoperability - WAI compliant, XHTML compliant, ect.
Flexibility - URL rewriting, wiki friendly, multi-lingual, etc.
Built in applications - does the CMS support blogs, event calendars, news items, classified ads, newsletters, listserves, etc.

It seems to me that for CACVoices there needs to be excellent ease of use options, so that users can, as they have been able to do in Plone, create content with minimal or no training. The other key factor is built in applications, the out of the box CMS needs to support all of the functionality that the site requires, including a calendar, news, forums, commenting, web content creation, search.
Now, my two major concerns with Plone involve management and system requirements. Management (and administration) need to simple enough so that an administrator can make the changes and updates necessary to the site. System requirements is another issue, which I will discuss shortly. I also think support is very important, not only for what it means explicitly, but because it implies that there is a strong following and so there will be more development, updates, add-ons being created and shared. We don't want an open-source community that is shriveling up.

I have currently been looking at several very different Content Management Systems, which I have been using to work through my thoughts on Plone and to compare these factors - in a way that hopefully makes some sense.
The CMSs I have comparing and playing with the interfaces of are

• Joomla
• Mambo
• webGUI
• Plone
• Xoops
• Postnuke
• drupal

What I found so far, which may be very obvious, is that no one CMS seems to satisfactorily cover all our particular needs. Some compromise I think will need to be done. The question then becomes, of those factors, which are most and least important. for me, there is a very real tension between user needs and administrative/system needs.

these are just my initial thoughts.

Welcome to pLog! If you can read this, it means that your pLog installation is ready and that you can start blogging.