Recently I met a Plone developer whose significant other had no idea what they did for a living, or what the heck Plone was. Without speculating on the communication challenges this couple may face, I also realize that Plone (and Content Management in general) needs to refine its elevator pitch. We need to hone and disseminate this language so that people do not need to struggle to explain the purpose and potential of this software at cocktail parties.

I recently had the pleasure to read Martin Aspeli's excellent MSc dissertation, Plone: A model of a mature open source project, where he proposes a good starting point:

Plone is a content management system (CMS), which allows organisations and individuals to
manage their electronic content, such as documents, files and images, through a web interface, and publish selected parts of their content to the internet or an intranet. (page 8)

I think we might even manage to get the word "manage" out of the definition - maybe "organize and administer their electronic content", but I realize I'm quibbling.  Crucially, this definition makes no mention of application servers, technology stacks, or programming languages.

In my experience it also helps to use examples of "classic" content management, like nytimes or cnn site, which quickly conveys the importance of workflow. From there, judging on the experience of the person on the other end of the conversation, you might mention a less obvious application of content management, like cafepress, or even blogging and wikis. You could even explain how many problems, including e-commerce, or even membership, can be modeled as Content Management Problems, and that Plone is far more than a web-based Contribute.

By this point you have probably arrived at your floor, finished your drink, or bored your new friend to tears.  Don't forget to get their card.

Currently, new Plone sites are created via a "PortalGenerator" object, which contains a bunch of Python code which performs all of the steps necessary to generate a new Plone site in your Zope instance.  This works, but it's not really ideal; initial site setup is really more about configuration than code.  With this setup, if you want to change the way a site is initialized, you have to first let the regular site install itself, then, using what is mostly boilerplate code, you have to procedurally make modifications to the site that is generated.  All add-on products basically do this; they have an install method that runs code performing all the necessary site configuration that the product requires to function.

At the CMF level, however, a new way of configuring portals was developed, in a product called CMFSetup.  CMFSetup let you specify site configuration options via XML; various XML files would specify the tools, types, workflows, properties, and initial content that should exist in a site.  A collection of these XML files would be called a site profile.  Additionally, the idea of extension profiles was introduced.  Site profiles defined the fundamental site configuration, while extension profiles could define optional additional settings that the site maintainer could apply at any time.

Even better than this, however, was the fact that CMFSetup could also allow for site exporting.  Thus it was possible to manually configure a site using the ZMI, and then use the setup tool to generate the XML files of the site profile when you were done.  Snapshots were also possible, so site managers could capture the site's configuration at any moment, comparing it with earlier or later configuration snapshots as desired.

But what's all this past-tense, then?  Has CMFSetup gone away?  Yes, sort of.  CMFSetup was so useful, that folks outside of the CMF world wanted to be able to use it.  Hence GenericSetup was born, which provides all of the same functionality to plain ol' Zope 2.  CMFSetup is still around in it's vestigial stages, but the stuff that used to be in CMFSetup is rapidly being rolled into CMF proper, and soon CMFSetup will be no more.

Several weeks ago, while in Fredericksburg, VA, at a sprint funded by the Goldegg initiative, I started working on getting Plone to work with GenericSetup.  I've been working on it fairly steadily ever since then, with a great deal of help from Brent Hendricks (thanks, Brent!).  At first we were working against the CMF trunk, which is targeted to become CMF 2.0.  It was realized during this time that the product breakage that CMF 2.0 would cause would be too much for Plone to assume in an upcoming release, however, so instead the CMF 2.0-style GenericSetup configuration code was back-ported to a newly cut CMF-1.6 branch.  CMF-1.6 is intended to stay very similar to the currently supported CMF-1.5, with portal configuration being the only difference.

This effort is coming very well; we now have a solidly working CMF-1.6, with all unit tests passing, and there is a branch of Plone that mostly works with CMF-1.6.  Things are not completely solid yet, but most unit tests are passing, you can add a site TTW, and within another week or so we should have the remaining problems sorted out.  There is a PLIP that formally proposes this to be included in the next major version of Plone, which the framework team will be considering over the next weeks.

Eventually, the goal is that  GenericSetup-based infrastructure will become familiar to anyone who does Plone product development.  The portal_quickinstaller would become just a wrapper object that provides a nice interface around the management of extension profiles.  Plone's migration engine would no longer try to modify pickled objects in place, but instead would export the content to XML and then reimport it.  (Kapil's XMLIO proposal will likely be a key component here.)  Anyone interested in learning more about how this works should take a look at the portal creation code in CMF-1.6 and/or the PLIP 113 review bundle.

It's very exciting to read Godefroid Chappelle's write-up of the recent Bern Ajax Sprint, even though I must confess that there are large swaths of it I don't really understand that well.  Which brings me to the questions that are on my mind as a follower-from-afar:

What relationship (if any) is there between Kukit/Azax framework and existing Ajax libraries such as mochikit, scriptaculous, etc.? Does Kukit/Azax reinvent these wheels, or does it provide a lower-level framework within which these libraries can be later used?  Or is this not even a relevant question? 

What I'm really getting at is: what, if any, of the massive amount of Ajax work going on "out there" can or should Plone & Zope re-use?

Ooh... shiny.  Now what?

OK, so we can now do Ajax-stuff in Plone.  What are we gonna do with it?  Here are my top-of-mind ideas, things that I think would have a big impact on everyday usability and performance.

• Drag-and-drop.  Using Plone would get a lot nicer if the following UI elements supported drag-and-drop via Ajax:
• Folder ordering
• Moving items between folders
• File and image uploads
• Switch between tab items without reloading the entire page.  E.g., switch from view to edit to properties to sharing.
  
• Click-to-edit operations in folder_contents view.  Things like: renaming, changing states, etc.
• Could pages that are being edited be auto-saved (without destroying the ability to cancel edits)?
  

What am I overlooking here?  What are Plone's low-hanging Ajax fruits?

I'm really happy to read (and to echo) Andy McKay's call for Plone developers to pay more attention to building high-quality user interfaces that make configuring Plone and its add-on Products easy.

Some people may think of them as meaningless chrome or bling, but in the end they do what users want. They take all the underlying bits and peices and make a simple radio button out of some logical choices.

The code and the technology behind it is probably quite boring to anyone interested in Plone.

It's not boring to me.  A huge amount of Plone's value is the fact that it makes it insanely easy for non-technical end-users to get their work done.  That's because the Plone core has been given a tremendous amount of UI lovin' by Limi, et al.  But unfortunately, many add-on Products haven't been given similar attention.  Alan briefly touched on this the other day:

... Plone's aim should be the Macintonish of Content Management Systems.  We have had blind people give us input, human computer interaction experts, lots of end user feedback.  We absorb this feedback and put it into Plone.  But there is so much more we could do. 

Alan then asks:

What about the usability guys stepping up to the plate?  The usability guys use blogs.  They use Plone.  They use Poll's.  Why dont they work with the authors of the package to make them better?

Usually the usability guys cannot write software.  Why don't they ask plone-users or #plone for help to FIX the usability of a add-on component? Even better why don't Add-on developers ask usability people for help?  

Here's one idea that might help:  Alan wrote a piece a while back called "How to Add Your Configlets to the Plone Control Panel"  But there's nothing that explains how to actually write a configlet in the first place.  Maybe that's why so few products have 'em.  What about a follow-up: "How To Write Configlets For Your Product." 

UPDATE: Maybe I should search the Plone documentation site before I spout off.  If I had I would have found Alan's how-to Add Configlets for own Product's-Settings.

Another usability connection that the San Francisco Plone Crowd might want to look into is AspirationTech's work on open-source usability.  They did their first "extreme usability" sprint for open-source developers in August, and I don't know what they've got planned for the future, but it might well be worthwhile to connect with 'em.

Finally, a question:  which Products do you think are most in need of a usability review and/or some configuraiton options?

At the marketing workshop in Vienna, one of the exercises we conducted was an informal poll of the personality traits and cultural values that people associate with the plone community. 

Motivating this exercise was an exploration of the recent Plone personal ad, which came out of the New Orleans Symposium. 

This anthropomorphizing of Plone was meant to embody the idea that software has a personality, and that since writing code is form of creative expression, the values of the author will inevitably be expressed in its features. So, for example, I will be suprised the day that Adobe easily allows for the assignment of Creative Commons licenses to content created using their tools, but no one is surprised by the fact that the Mediawiki wiki-engine deafualts to this license.

If you accept this position, then selecting the right CMS is more than a matter checking off features on a matix. It becomes essential that the vendor's values are consistent with the client's mission. In the case of an open source project, the "vendor" is really an entire ecology, comprised of of the community, the software, and the processes and structures which bind them together.

Here are some of the values that members of the Plone community currently associate with this project:

• freedom
• good society
• democracy
• egalitarian
• independent
• networking
• meritocracy
• honesty
• elegant
• open
• flexibility
• fun
  
• quick
• friendship
• collaboration

To be sure, many of these qualities are characteristic of Open Source, and beyond.  But this dimension of analysis is missing from most RFPs.

I just read on Boris Mann's blog that he's announced an "Open Source CMS and Blogging Tools" gathering for Vancouver, BC on February 7-9, 2006, just prior to the "Northern Voice" blogging conference.

...many of the ideas for this summit came about from a presentation by the Joomla guys to the DrupalCon Amsterdam 2005 -- we found we had a lot in common, and many areas of shared interest, from distributed user logins to templating engines. And of course, appearances by Rasmus Lehrndorf of PHP and David Axmark of MySQL just added to the notion that we are part of a larger ecosystem that should be working together more closely.

And they'd like Plone-folk to participate:

I met with Zak Greant on Friday, who is an evangelist working with ez Systems, makers of the ezPublish CMS. Roland is going to be contacting local representatives of the Plone community, like Enfold Systems. Of course, the Drupal community will be here...

Seems like it could be a worthwhile opportunity to reach out and make new friends.

An early-morning thought.  It seems like the library of clever UI fields and widgets for Plone is expanding pretty quickly these days.   It might be helpful for less-experienced developers trying to design user-friendly Archteypes if they could refer to a graphical "quick guide" to the different widgets. 

Unfortunately I lack the skills to create such a guide, so I figured I'd throw the idea out there into the lazy web.

The quality and power of Plone as a content management system is incredible. It’s got incredible usability, workflow, permissioning, document handling, search, extensibility, internationalization, accessibility — and more.  My colleagues at ONE/Northwest have launched over 40 Plone-powered sites for non-technical clients in the past year with a very small team of people.

However, for websites that revolve around “community” and “collaboration” (whatever those things mean, and believe me I’m often very cynical) I think that Plone’s community collaboration features could use some improvement.

The good news is that most of these features have pretty solid products that already get us 80% of the way there — they just need some focused and coordinated “polishing.” Here are some thoughts drawn from our experiences at ONE/Northwest, and some of my hopes for the future.

But before I dive in, I apologize in advance. These are all pretty raw thoughts, and there’s likely a lot of half-baked ideas and not-so-great conclusions in here. I thought it better to spit this out into the world to see what response it would attract than to spend too much time polishing it to a sheen.

Preface: What the hell is “community” anyway?

A fair enough question. And I’m not sure I’m really up to metaphysics as I write this on the bus ride home. In the context of Plone, I’m talking about features like:

• Blogging
• Aggregation of RSS feeds, with the aggregated items available as first-class content objects.
• Integration of “traditional” online community tools content such as mailing list archives, etc.
• Discussion Forums
• Tagging content
• Publishing content out to “social software” services such as upcoming.org, flickr.com, del.icio.us, commontimes.org, etc.
• Calendaring
  

Here’s my rundown of the tools landscape for each of these:

Blogging

Blogging is perhaps the building block of community collaboration software. Plone has a number of blogging products. Unfortunately, none of the are yet truly outstanding, and we have a bit of a problem of too many choices, all of them somewhat mediocre. Here’s my rundown, your thoughts welcome:

I consider the “essential” features for a solid blogging product as follows:

• Multi-blog, multi-author
• Rich-text entries that can include images
• Send and receive trackbacks (but resist trackback spam!)
• Allow admin to choose between registration required to comment, and reg. not required (but still not spam-magnet) — VisitorComments seems like a decent example.
• Generate standards-compliant feeds for the whole site, per topic and per author
  
• Send pings to a ping service (if any still don’t suck in six months)
• Sensible, ideally configurable archiving paths.
• Super bonus points for XML-RPC compatbility for blog desktop authoring tools.

Like many in the Plone community, I had high hopes for Quills.  This site is running it right now.  Things have picked up there lately, but it needs some more love in order to get all the way to excellent.

Knotes holds some promise, and seems very featureful, but as I tried it out in its sandbox, it still seems buggy and way too complex/quirky in its UI. Perhaps this could be cleaned up, I don’t know. Also has some pretty big dependencies, not sure how big a deal that is. One to watch, that’s for sure.

I’ve also been playing around a bit with EasyBlog, which seems to be moving rapidly right now. Has a pretty nice set of features, could still use some polishing around trackback usability, but seems promising.

RSS Content Aggregation

A key function of a “community” website is the aggregation of content that community members are creating “out there” — blogs, delicious links, photos on flickr, etc. RSS is the lingua franca that allows content from these tools to be syndicated between sites. 

The new Plone aggregator site planet.plone.org is running Planet, which is Python-based aggregation software.  That's fine, but it's lame to not do this natively in Plone.  (It's also lame that Planet expects one blog per author, and one author per blog.  But that's another story.)

There are three main Plone products that allow a Plone site to aggregate content: CMFSin, CMFContentPanels and CMFFeed. However, neither is entirely satisfactory. Here’s the scoop:

CMFSin

CMFSin is a “lightweight” RSS aggregation tool. Its core features include:

• simple feed aggregation
• the ability to aggregate mulitiple feeds into “channels”

However, its limitations are many:

• CMFSin currently configured via somewhat cryptic text files in the ZMI. This makes it tough for novice site managers, who would prefer to work through the Plone UI.

• CMFSin runs in the foreground, and can significantly slow down site performance during a refresh.

• Items CMFSin collects are not “first-class” content objects — they’re not added to the catalog, and they don’t persist in Plone after they expire from the feed.

• Users can’t “remix” CMFSin-aggregated feeds by selectively promoting or suppressing items.

• CMFSin only aggregates headlines and summaries, not full content bodies.

CMFContentPanels

CMFContentPanels is mainly designed to aggregate content from inside a Plone site, and it does a nice job of that.  It also includes some basic RSS aggregation features, that are fairly similar to CMFSin, in that aggregated RSS items are NOT transformed into first-class content objects.

In short, CMFSin and CMFContentPanels are suitable for “light duty” aggregation of ephemeral content like news headlines or delicious links, but not for sites that want to use RSS syndication as a core element of building a content library.

While not every website needs this more robust syndication, it is easy for me to imagine a generation of collaboration sites that bring together (and replicate) content from a network of partner websites via RSS.

CMFFeed

CMFFeed is a more ambitious product that picks up where CMFSin and CMFContentPanels leave off. It does good things like:

• Treating aggregated content as first-class content objects, opening the door for incoming feeds to be edited and remixed.
  
• Running in the background as a separate ZEO process, which avoids slowing page-loads to refresh feeds

While holding lots of promise as a power-aggregation tool, CMFFeed is not quite ready for prime time. It still lacks:

• A quick-and-easy install process – lots of mucking about in the ZMI still required.
• Through-the-web configuration — a must-have feature so that non-technical site admins can manage the aggregation process rather than Plone developers.
• Caching of feeds across multiple Plone instances on a single server. (A must have if you’re hosting lots of small sites on a single server which will want to draw on the same feeds — exactly that situation we face at ONE/Northwest.)

From my decidedly non-technical point of view, it seems like a relatively small bit of UI polishing plus server-wide caching could push CMFFeed over the hump to greatness.

Mailing List Archives

Email discussion lists are still amazingly powerful community collaboration tools. Even more so when they have good, searchable web archives – that can be seamlessly integrated into the community’s website. See where I’m headed?

While Plone has a few decent mailing list tool my feeling is that reimplementing email discussion list functionality in Plone is somethign of a waste of effort – there’s already lots of good discussion list software out there like Mailman, Sympa, etc. What Plone most needs, IMHO, is a relatively simple email list archiver. (Yeah, with external discussion list software, you’re giving up user integration, but I think that’s OK.)

PlonePostOffice appears to be very close to having this functionality. What it appears to be missing is:

• Through the web configuration for non-technical end-users
• Support for handling attachments (convert to File object within a folderish message object?)

The developer, Ivo, has indicated that he’s interested in doing some sponsored work on PPO. I’m hopeful that it can quickly become a great mail archiving tool for Plone. Let me know if you’re interested in talking about co-sponsoring some work on PPO.

It also appears that Mailboxer for Zope (written by Maik Jablonski) and its Plone wrapper PloneMailBoxer (kind of adopted by Robert Rottermann) can do this -- and more.  But it seems to suffer from a relatively complex install process and somewhat weak documentation.  (Thanks to Robert for the heads-up on these products.)

Discussion Forums

Plone doesn’t have a truly solid forum tool. CMFBoard appears to be dead. KNotes/KDiscussion is a promising contender, but is perhaps a bit too complex for its own good. Another promising contender is Ploneboard, which has a very strong pedigree as a project of Plone Solutions.

I’ve already been working with Marshall Mayer of LiveModern.com, who has one of the larger CMFBoard installs out there, on set of specifications for a next-generation forum product for Plone. Our current plan is to organize some community investment in Ploneboard.

To that end we did some initial brainstorming on the forum features that LiveModern (or any active forum community) would need, and after making contact with Limi and Tim Hicks at Plone Solutions, we refined and reined in our initial braindump and started fashioning PLIPs at the official Ploneboard page.

At this point, we are eager to expand the conversation to include anyone who is seeking a moderately-featureful forum product for Plone to figure how we can pool resources to bring it into existence. Take a look at the PLIPs, offer feedback, and let Marshall know if you’re interested in putting resources into the process.

Tagging

Tagging seems to be all the rage these days in the Web 2.0 crowd. While I’m often skeptical, I definitely have found the tagging system of del.icio.us to be hugely valuable. And Plone has the stub of a tagging feature in its Keywords, enhanced by PloneKeywordManager, but what it lacks is a polished user interface that scales to collections of a 30-60 tags (or more). I believe that implementing a tagging UI like that of del.icio.us would be a relatively easy “win” that would help Plone users “tag” content more effectively.

Creating a “tag cloud” as a way to visualize and browse the contents of a Plone site should also be a pretty easy win.

On a related note, it should be easy to get views and RSS feeds of tagged Pone content at the URL: http://plonesite/tags/nameoftag.

I definitely need to do more thinking about how tagging works on a collaborative website with many authors contributing content.

Update: It looks like the folks at DividedLine are perilously close to delivering exactly what I’m looking for. Yippee!  They've told me they're planning to package this up Real Soon Now.

Calendaring

Calendaring and the sharing of calendars is an important collaboration activity, and Plone has some good calendar products out there -- Calendaring and CalendarX come to mind.  It's even better news that in a couple of weeks there's gonna be a Calendaring Sprint to assess the landscape and plot a route forward.  Big props to Nate Aune for organizing.

Publishing content to community aggregation sites such as flickr, delicious, etc.

While Plone can pretty easily receive content from a community aggregation site that emits RSS — and would be even better with a power aggregator such as a turbocharged CMFFeed, it doesn’t have much support for publishing content to such services. That’s too bad. It would be really nice to be able to create content once in Plone and have it post itself to these online social spaces to reach an even broader audience.

OK, this is a less-than-half-baked idea. But I figured I’d throw it out there anyway to see if it sticks.

Update: apparently it has -- Nate Aune reports that the ATPhoto folks are working on publishing photos from Plone to Flickr, and that the upcoming Calendar Sprint may well start to address calendaring sync with Upcoming.org. 

Underlying Technologies

A shrewd reader will note that many of these functionalities share some core architectural elements: commenting & discussion, RSS syndication, importing content programmatically.

To me, this suggests that a smart approach for Plone is to factor out some of these underlying technologies into separate products (and thence into the core?) so that future collaboration & community products can use and re-use them.

Tim Hicks, who's been spending some time on Ploneboard and Quills (and more!) has made what looks like a promising start down this road with FatSyndication, which factors out a generic RSS syndication framework out from Quills. 

I can imagine a similar approach to improved discussions being factored out from Ploneboard (Tim's working on this too!).  Also for tagging.

Where do we go from here?

If you’ve made it this far, thanks for reading. You’re probably wondering what I’m planning to do about all of this. Well, that’s in part up to you. These are bigger issues that I (or ONE/Northwest) can tackle alone.

First of all, I think we need to get a good conversation going in the Plone community to refine these ideas, and more importantly to figure out who else is feeling this pain and what resources they can bring to the process of creating solutions.

So, I invite your comments — what parts of this are right, and which are wrong? What do you think are the most important community features that Plone needs to have? Are there promising products that I haven’t mentioned that need some energy? Have I unfairly judged anything? In short, I’ve taken a whack at naming the problem. Where should we go from here?

    So.  on ThePloneBlog we use a product called Quills.  Quills is fscking insane.  It looks like Jon made it a tad more sensible since the last time I logged in.  But before his modifications, the out-of-the-box usage of Quills is just plain sad.  Its un-Plonic.  What is "Plone"?  Plone is sensible defaults and easy to use out-of-the-box ala It Just Works.  Quills is nerdware; technology looking to solve a problem.  In fact.  I'm not sure if your familiar with Plone's history.  But I think Plone's history speaks to why Plone is popular today.

History Lesson

    Some time ago when #zope had 2 people on it about 7 years ago (god i'm getting old) there was dracvl and runyaga.  dracvl was limi, I am runyaga.  Limi was baffled by Zope's inheritance; I was baffled by XHTML/CSS.  I fixed limi's inheritance problem; limi helped me fix CMF's default ugliness.  The fact that the scope of What Became Plone was "Fix CMF ugliness" was limited in scope and user-centric.  Two essential characteristics of a successful project.  I'm not sure what Quill's scope is but its certainly not user-centric or user-friendly.  I did Python Scripting, Limi did UI/CSS, Vidar did graphics.  Very simple.  Focused on user friendliness.

    The untold secret sauce, btw of how this happened was two things.  instaresponse and internet time.

instaresponse and internet time

    Limi would send me XHTML/CSS.  He is in Norway.  He would wake up and have emails from me.  He would reply back to me so fast that I could work on his changes and get them back before he went to sleep.  Finally I could work before I went to sleep getting stuff ready for him.
Its not really internet time, thats some stupid catch phrase a loser like Gary Meshell, my old CEO would have made.    Its more like globalization.  Ah thats more like it.  UI sensibilities and care of scandanvia mixed with american elbow greese. 

Zope has been plagued with technoweenies

    But its not just Zope.  It's Python!  Look at round-up's web interface.  Look at python.org.  Its horrible.  It screams of "We are engineers and we dont care about pretty buttons".  To some extent Python's documentation suffers as well.  Too few examples compared to php.net which is full of examples.  What python documentation needs is to integrate, PLEAC and Python Cookbook into it. 

    Back to Zope.  Zope Corporation, well at least Jim Fulton understands that their money comes from empowering scripters and people who can quickly throw together a website.  Then the system grows outside of their understanding and they hire Zope Corp.  This is great.  And I suggest people looking at Zope Corp., Enfold Systems, Cignex or anyone who is a competent services firm.  But what about the usability of Zope?  Its anti-usable. 

    Zope is engineering-centric.  Lots of *amazing* technologies come from Zope.  But life is not about technology.  Its about communication and
working with others.  And for you to make a steaming pile of money it's all about sexiness.  That is why Plone is getting all the action like Mick Jagger in the early seventies.  Oh right.  Like Mick Jagger, Plone does not descriminate and loves ALL groupies.  Zope only wants the brainy groupies.

Make it usable, stupid

    I know very little about usability.  I defer to limi for that stuff - even then I argue but its his domain and I respect his decisions.  But Limi cant be everywhere and he has to make money and have a social life too.  Where are our other designers and UI guys?  DannyB is awesome.  He could sure fix Quills.  But the fact is -- we dont have enough USABLE software out-of-the-box. 
    Plone software should not care about feature lists it should care about a 1 out of 5 gold star for usability and UI.  We dont need features.  We have more features than postnuke, drupal, and all other PHP systems combined.  We need usable software and usable add-ons.  We need to make a community where usability isnt only desired but its paramount and thats the criteria add-ons are judged by.  The out-of-the-box usefulness.

Plone, the MAC of CMS

    My personal opinion is that Plone's aim should be the Macintonish of Content Management Systems.  We have had blind people give us input, human computer interaction experts, lots of end user feedback.  We absorb this feedback and put it into Plone.  But there is so much more we could do.  Plone and its community is sensitive to these issues.  That gives us a huge edge on money grubbing profit-driven eat-your-children CMS companies and the lowly in-line-my-function-and-sql-into-my-presentation open source CMS's. 
    Plone and its add-on components must work out-of-the-box and must not be fucktarded.  Software has never been a problem.  Want a Poll software?  Geoff Davis wrote some nuclear decaying results algorithm and someone implemented it!  Ben is writing Skeletor!  We have a schema language - etc.  But what about UI efforts?  What about the usability guys stepping up to the plate?
    The usability guys use blogs.  They use Plone.  They use Poll's.  Why dont they work with the authors of the package to make them better?
Usually the usability guys can not write software.  Why dont they ask plone-users or #plone for help to FIX the usability of a add-on component?  Even better why dont Add-on developers ask usability people for help?  

If you dont ask you will never know.

Its like a box of chocolates

    I love reading books and watching films.  When I was a kid. I really liked neuromancer.  I am a huge fan of scifi.  Then I got to college and everyone started reading Real Books: Dubliners, The Crying of Lot 49, As I Lay Dying, etc.  I liked these books too.  I asked someone "Why dont you like neuromancer these others scifi books?"  And they said "because its a buncha gadget talk and too little human experience".  Well I kinda agree.  If you want something that is low gadget talk and high scifi appeal read anything by Philip K. Dick -- wow.  A Scanner Darkly.  Anyway.  I think that software should be thought about in the same manner.
    Software should be about humans getting shit done.  Not about acquisition, sql, configuration twiddling.  Its something technologist continually forget that humans are using this software.  And the fact that my friend installed EZ Blog and "clicked install" and voila it ate his Plone site - is bullshit.   His experience should have been more like eating a random chocie out of a box, i.e."I dont really like this chocie" and spit it into a towel.  Not "my god this is horrendous chocolate" and throw the entire basket out.

Us, as the Plone community need to think and collaborate with end users much more.  If people are continually telling you your software is destroying their work -- you should fix it.  Its sort of your responsibility.  Or you should write in big letters on your product "THIS SOFTWARE HAS CAUSED OTHERS SUFFERING, USE AT YOUR OWN RISK" -- be honest.  If you dont have time to maintain software; dont write your own -- work on someone else's.  At least try to make your software sensible and incorporate user feedback.

Clearly we are winning the google wars.  I simply entered each term into google like http://www.google.com/search?q=plone. Could someone let a guy named David Mattison know?  He penned an article where he says "I think Plone's okole is going to get kicked as badly as some others by some other open source Web application/servers."  Could someone in British Columbia, do me a favor? Please kick David in his okole.

As the co-conspirator of a local Plone user group (Seattle, WA, USA), I've been impressed with the growing number of regularly meeting Plone, Zope and Python user groups that are popping up all across the globe.  This groundswell of grassroots activity is perhaps one of the best indicators of the richness, maturity, and activity of the broader Plone community.

Here in Seattle, the Plone community is pretty impressive.  We're regularly getting 20+ folks at our monthly meetings --  a diverse mix of consultants and users from the education, business, and non-profit sectors.  But what's more astonishing is the amount of work that is flowing through the network.  Each month, we get several open job announcements ranging from contract work to full-time.  In most circumstances, the demand exceeds the number of Plone providers.  It's gotten to the point where I have no hesistation about saying that if you're looking to fill your consulting pipeline, you should seriously consider aligning yourself with a local Plone user group and you'll be set.

I've been keeping my eyes peeled for Plone/Zope user group sightings since we formed ours in Seattle.  I'm pretty certain that there's no definitive list (and after we shake out a bunch of additional groups, I think this belongs at plone.org --> events --> user groups, hint, hint ;^), so in an effort catalyze that, here goes:

Plone/Zope User Groups

• Seattle Plone Users Group (Seattle, WA, US)
• VanPyZ (Vancouver, BC, CA)
• Bay Area Plone Lounge (San Francisco/San Jose, CA, US)
• Boston Plone Users Group (Boston, MA, US)
• Zope/Plone Users Group of Davis (Davis, CA, US)
• Plone Belgium (Brussels, BE)
• New Mexico Zope/Plone/Python (Albuquerque, NM, US)
• Zope/Python Users Group of Washington D.C. (D.C., US)
• Indian Zope and Python Users Group (India)
  

Zope/Python User Groups

• NYZPUG (New York, NY, US)
• Triangle ZPUG (Raleigh, Durham, Chapel Hill, NC, US)
• OzZope (Melbourne, Australia)
  
• Twin Cities Zope User Group (MN, US)
• Fredericksburg ZPUG (Fredericksburg, VA, US)
• PyGTA (Toronto, CA)
• LaZUG (Los Angeles, CA, US)
• Deutschsprachige Zope User Group (Augsburg, Berlin, Hamburg, Leipzig, München, NordBaden, NordBayern, OWL, Rheinland, RheinMain, Saarland, Stuttgart, and Tübingen, DE; Austria)

* This is mostly off the top of my head, so drop me a comment if you know of one I missed and I'll add it into the list.

There has been a lot of movement on Zope and Windows.  Python has some advantages over PHP, Java and Ruby and namely that is of its mature libraries.  I've always told people that for Python to gain mindshare it would be not by its syntax or language features but by its libraries.  In my world that revolves around Mark Hammond pywin32 libraries.

A lot of loving has gone into Zope on win32 over the past year.  Specificially: Ability to rotate log files, clean shutdown, NTFS support in dirstorage and some service enhancements.  Thats pretty unsexy stuff -- but you have to start somewhere.  Some of the other needs would be to set the COM  threading model in zope.conf and in the main zope process; so zope components cant try to change it from one model to another mid-zope flight.

But why is the World of Windows happy go lucky?  Well.  I work at a commercial software company and services firm that specializes in Windows.  So the paycheck aspect is one.  But the real draw for me is the technology potential.  Lets start with Window's basic infrastructure such as consistent services, then work our way up to ODBC and round it out with advance usages such as transactional messaging.

Consistent Services

Its well documented how to setup a service on Windows, even services that depend on other services.  Linux is basically the same across distros (I believe) but OSX, and Solaris are not the same, iirc.  I'm talking about 'canonical' ways of doing things.  After all we *do* care about there being Only One Way To Do It, right?  Windows does offer that.  Services are simple and its very simple to service-fy daemons.  Granted zdaemon is tricky.. twisted is really straightforward.  We use pydirector on windows to load balance across multi zeoclients.  We also set the processor affinity mask for each zeo client binding it to a dedicated process. 

ODBC

Anyone who knows me knows I rant and rave about ZODB.  I have a love/hate relationship.  I fully appreciate its approach and what its trying to do.  It has a lot of use cases.  But Relational Databases make people feel comfortable.  Alot of Zope guru's just dont understand that if a sysadmin can *query* their database with phpMySQL or a command line tool and can SELECT, INSERT, DELETE, UPDATE -- they feel comfortable.  Mainly because SQL is the language they know; Python is easy -- but its not as widespread and familiar as SQL.

Python has lots of database adapters ranging of quality.  Bah.  JDBC has Python wiped.  But since my world runs on Windows and I have ODBC.  eGenix mxODBC and our potential vapor/freeware highperformance ODBC adapter is a single point of entry into *any* ODBC connector on earth.  Write once; interface multiple.  That is powerful.  And I consider it a advantage. 

But having a adapter is not enough.  At Enfold Systems  we recently released a Zope 3 Lab Info Mgmt System called SIP.  SIP uses SQLObject a simple object-relational system.  It does not try to be too transparent.  It does get in your way.  But ya know?  It works.  Its being used by TurboGears and other cool python frameworks.  And thats why I picked it.  SQLObject is a Relational Story and Zope has narrow mindedly rejected SQL - ZSQLMethods in Zope 2 are antiquated technologies.  People expect insta-CRUD forms.  Zope 3 gives us easy pythonic ways to do things (see SIP's usage of SQLObject) but what about Zope 2?  What about Now? 

MSMQ, MTS, IFilter, SSPI, COM, OH MY!

Well in the world of linux you get QT, wx, FUSE, inittab, pam; in the world of Windows we have another batch of abbreviations we have to deal with.  But in the Windows world (like it or not) it comes built-in and accessible by Python via win32com.  Ready to be used with Zope.  Let's take MSMQ -- since it fits my brain and all people who decide technology deployment strategies.  Messaging, such as JMS, MSMQ, Tibco is very powerful.  XMLBlaster is cute.  Spread - I've heard varying success.  MSMSQ - has its downsides but its there. 

Subscribe Zope to a MessageQueue, Foo running in Wisconsin.  Put a message in the Foo queue in Japan.  Its guaranteed to make it to Zope.  These days XML is the linguafranca for messaging and we have grea XML capabilities in Python.  We can send/receive messages to/from any Windows system on the domain.  Its really cool, powerful and has lots of mindshare. 

The same for MSMQ, there are python COM hooks for SSPI, IFilter and a plethora of sophisticated functionality that be exploited from Zope.  Thats what we are doing at Enfold Sysems with Plone.  We want to compete with really large scale systems.  Python, Zope and Windows are are secret sauces. 

Of course, like anything Windows has its downsides; but its a beautiful world.

Duncan Booth, the tireless lead devleoper of Kupu, Plone's built-in WYSIWYG editor component, just put up a Kupu/Plone sandbox where you can try out the latest bleeding-edge features of Kupu.

It has lots of changes to how drawers work, some of which are described on articles created on the site. Some things I know don't work yet, other things which I don't know about may be broken too. Let me know if anything looks like it should work but currently doesn't. Ideally, for any issues, create an example on the site and point me at it.

The big new features are support for bookmarks/anchors, and a reworking of the drawers for browsing site contents. 

I'm really happy to see that Duncan took the time to build a Kupu sandbox, because it will make it far easier for folks (like me) who aren't hardcore Kupu developers to check out and offer usability feedback on new and emerging features.   To me, making it even easier for non-coders to test out emerging core components will go a long way towards helping Plone be even more user driven.

Check it out.

If you're doing projects that involve things that can be mapped -- or things that ought to be -- then you need to check out PrimaGIS.  Billed as "a collaborative web mapping application for Plone," it lets you build powerful online maps directly into your Plone sites, and share map data with others.  Josh Livni of Livni Consulting came by today and showed me some of what PrimaGIS can do.

As an environmental techie, mapping is pretty important to lots of the folks I work with.  Good maps tell stories about our world that words alone can't match. Having computer systems that can make maps is fine and dandy, but as Google Maps, NASA World Wind, and the recent spate of mapping mashups show, maps are even more powerful when you use the web to put them in front of people. 

That's where PrimaGIS comes in. 

I'm not going to drag you through an exhaustive rundown, but it was pretty amazing.  Not only because of the feature set, which is large, but because of the way it builds on top of a existing Python and Zope mapping tools.  PrimaGIS really shows off the power of the Zope/Plone stack, and how easy it can make building complex, innovative functionality.

In the next couple of weeks, Josh and I are going to put together a couple of screencasts to show off PrimaGIS, because like a map itself, the pictures are worth a few thousand words.  Stay tuned.

If you're really the impatient type, check out Josh's public PrimaGIS demo.  It doesn't show off the back-end, but it gives you some hints of what basic public-facing maps can look like.  (The official PrimaGIS demo is, quite frankly, in need of some lovin'.  But rest of the site has great info.)

It started with the marketing committee then the membership committee and now infrastructure committee's.  Plone leadership positions have been tapping responsible volunteers in the community to help plug the holes that can no longer be filled by one persons hands and toes.  The community has grown so large that it requires new people to grow into roles of responsibility.  Without this Plone will not be able to continue to grow over the next 5 years.  

At several points during Plone's growth it grew out of the Founders hands into volunteer coders now into a Foundation of over 100 persons.  Developer mailing lists keep everyone busy, there are full service Plone consulting companies and my company is actually selling Commercial Software products around the Plone platform.  It has been a long road and the people who started it now know that for the community and product to grow that it requires new blood.  That new blood is you.

Its been interesting and now we need you.  To help test and finish off the Plone 2.2 release.  Which will be a step in the future and will be potentially scary for many -- if we do not start bootstrapping and communicating the future and the vision of Plone to the masses.  The step started out with the release of Zope 2.8.x when the Zope 3 library components were shipped for the first time with Zope 2.  Now with Plone 2.2 we will start leveraging the New Style component architecture of Zope 3.  The component architecture is formalized and has been in development over four years.  Has been refactored countless times.  And has thousands of unit tests covering all edges, aspects and cases.

Plone 2.2 requires membership to step up and take responsibility for learning the Component Architecture, running Sprints where Plone elders can work with newer community members to pass on knowledge and land new software and tests into Plone or the Collective.

There are a lot of ways for you to help and just as many people who want to help; many people in the community want to start delegating responsibility to community members.  This is a great time and I suspect you will start seeing some very very interesting developments in Plone over the next six months.

Hello from Seattle!  (And Houston!)  Alan Runyan and I are pleased to be launching "The Plone Blog," a modest effort to provide some more accessible and easy-to-digest coverage of the Plone Community.

You're probably no doubt aware that Plone is the world's leading open-source content management system, used everywhere from Ebay to the Brazlian Parliament to the International Snow Leopard Trust.   But what's less obvious at first glance is the tremendous amount of activity and innovation that's swirling just beneath the surface of the Plone community.  That's in part because the Plone community tends to  do a lot of its day-to-day work via mailing lists and IRC chat, which are great collaboration tools, but somewhat hard to archive well, and a bit overwhelming when you first dive in.  And in part it's because many of the core members of the Plone community have been so busy making Plone an amazing product that they don't have much time left over for telling the story of Plone.

But that's changing, and The Plone Blog is part of the change.  Over the next few weeks, Alan and I are going to start providing some snappy, informal coverage of Plone -- along with some opinions and advocacy.  We hope to expand the reach of the Plone community, catalyze some new conversations about the future of Plone and to inspire others to dive in and continue the work of building Plone into a world-class content, collaboration and community system.

And like Plone itself, The Plone Blog is only as strong as its community of readers.  There are lots of ways you can join in:

• Create an account so you can comment on posts and join the conversation.
  
• Send us a story idea -- if you're involved with something newsworthy and Plonish, drop us a line!
  
• Write for The Plone Blog -- we're always looking for folks who love Plone and want to be part of its voice.

Be seeing you.