Long time readers of my ramblings here are aware that I drink the Google kool-aid. And they also know that I've been caught tweeting, on occasion. And, despite my disappointment in Google's last big thing (Wave), I am so appreciative of other work of theirs -- GMail, Android, Picasa -- that I couldn't pass up a go with their answer to Facebook and Twitter, Buzz.
Google, perhaps because their revenue model is based on giving people ad-displaying products, as opposed to selling applications, takes more design risks than their software-developingcompetitors. Freed of legacy design concepts like "the computer is a file cabinet" or "A phone needs a "start" menu", they often come up with superior information management and communication tools.
What is Buzz?
Buzz, like Twitter and Facebook, and very much like the lesser used Friendfeed, lets you tell people what you're up to; share links, photos and other content; and respond to other people's posts and comments. Like Facebook, Friendfeed and Twitter (if you use a third party service like Twitterfeed), you can import streams from other services, like Google Reader, Flicker, and Twitter itself, into your Buzz timeline.
Unlike Twitter, there is no character limit on your posts. And the comment threading works more like Facebook, so it's easy to keep track of conversations.
How is Buzz Different?
The big distinguishing factor is that Buzz is not an independent service, but an adjunct of GMail. You don't need a GMail account to use it, but, if you have one, Buzz shows up right below your inbox in the folder list, and, when a comment is posted on a Buzz that you either started or contributed to, the entire Buzz shows up in your inbox with the reply text box included, so that continuing the conversation is almost exactly like replying to an email.
The Gmail integration also feeds into your network on Buzz. Instead of actively seeking out people to follow, Buzz loads you up from day one with people who you communicate regularly with via GMail.
Privacy Concerns
Buzz's release on Tuesday spawned a Facebook-like privacy invasion meme the day that it was released -- valid concerns were raised about the list of these contacts showing up on Buzz-enabled Google Profile pages. A good "get rid of Buzz" tutorial is linked here. To Google's credit, they responded quickly, with security updates being rolled out two days later. I'm giving Google more of a pass on this than some of my associates, because, while it was a little sloppy, I don't think it compares to the Facebook "Beacon" scandal. Google didn't think through the consequences, or the likely reaction to what looked like a worse privacy violation than it actually was (contact lists were only public on your profiles if you had marked your profile "public", and there was a link to turn the lists off, it just wasn't prominently placed or obvious that it was necessary). Beacon, in comparison, started telling the world about every purchase you made (whether it was a surprise gift for your significant other or a naughty magazine) and there was no option for the user to turn it off. And it took Facebook two years to start saying "mea culpa", not two days.
Social Media Interactions for Grownups
Twitter's "gimmick" -- the 140 character limit -- defines its personality, and those of us who enjoy Twitter also enjoy the challenge of making that meaningful comment, with links, hashtags, and @ replies, in small, 140 character bursts. It's understood now that continuing a tweet is cheating.
Facebook doesn't have such stringent limits, but you wouldn't necessarily know that to glance at it. It hasn't shaken it's dorm room roots; it's still burdened by all of the childish quizzes and applications; and, maybe more to the point, cursed by a superficiality imposed by everyone having an audience composed of high school buds that they haven't seen for a decade or two, and who might now be on the other side of the political fence.
But Buzz can sustain a real conversation -- I've seen this in my day and a half of use. Partially because it doesn't have Twitters self-imposed limit or Facebooks playful distractions; and largely because you reply in your email, a milieu where actual conversation is the norm. This is significant for NPOs that want to know what's being said about them in public on the web. I noted from a Twitter post this week that the Tactical Philosophy blog had a few entries discussing the pros and cons of Idealists' handling of a funding crisis. But Twitter wasn't a good vehicle for a nuanced conversation on that, and I can't see that type of dialogue setting in on Facebook. Buzz would be ideal for it.
The Best is Yet to Come
This week, Google rolled out Buzz to GMail. Down the road, they'll add it to Google Apps for Domains. The day that happens, we'll see something even more powerful. Enterprise microblogging isn't a new idea -- apps like Yammer and Socialcast have had a lot of success with it. I'm actually a big fan of Socialcast, which has a lot in common with Buzz, but I was stumped as to how I could introduce a new application at my workplace that I believe would be insanely useful, but most of the staff can't envision a need for at all. What would have sold it, I have no doubt, is the level of email integration that Buzz sports. By making social conversations so seamlessly entwined with the direct communication, Google sells the concept. How many of you are trying hard to explain to your co-workers that Twitter isn't a meaningless fad, and that there's business value in casual communication? Buzz will put it in their faces, and, daunting as it might be at first, I think it will win them over.
Last week, I kicked off this series on setting up a basic web site with Drupal, the popular open source Content Management System. This week we're going to take a closer look at Modules, the Drupal add-ons that can extend your web site's functionality. One of the great things about Drupal is that it is a popular application with a large developer community working with and around it. So there are about a thousand modules that you can use to extend Drupal, covering everything from document management to payment processing. The good news: there's probably one that supports the functionality that you want to add to your web site. Bad news: needle in a haystack?
A potentially easier way to add extra functionality to Drupal is to download a customized version, such as CiviCRM or Open Atrium. We'll discuss those options later in the Drupal 101 series.
Core Modules
Drupal comes with a number of built-in modules that you can optionally enable. Some are obviously useful, others not so much. Here are some notes on the ones that you might not initially know that you need:
Primary content types like blog, forum and book offer different modules for user input. They can be combined, or you can pick one for a simple site. Since the differences between, say , a blog (individual journal that people can comment on) and a forum (topical posts that people can reply to) are less distinct than they are in other CMS's, you might want to pick one or two primary content types and then supplement them with more distinctive ones, such as polls or profiles.
Enabling contact allows your users to send private messages to each other on the site, as well as allowing you to set up site-wide contact forms.
OpenID allows your users more flexibility and control as to how they log into your site. I can't see a good reason not to enable this on a public site. Since more and more people have profiles on social networking sites and Google, tools like Facebook Connect or Google Friend Connect should be considered as well.
By default, Drupal asks new users for a name and email, but not much else. With the Profiles module, you can create custom fields and allow your users to share information much as they would on a social network.
Taxonomy is also recommended, and I'll talk more about that next week.
Throttle should be used on any high-traffic site to improve performance.
Use Trigger if you want to set up alerting and automation on your site.
More than some CMS's, Drupal is a content-centric system. It doesn't simply manage content, but the web interface is structured around the content it manages: content types, content metadata (taxonomies), content sources (RSS feeds). Out of the virtual box, Drupal has content types like blog entries, pages and stories. Each content type has a data entry form associated with it. So, if you create a number of stories, and you want to read them all, then you can browse to the page "story" and they'll all be listed there. CCK helps you create additional content types and use a fairly robust form-builder to customize the screens.
The Views module lets you customize the appearance and functionality of many of Drupal's standard screens, and to add your own. Unlike CCK, which is limited to the default layout of content types, Views lets you seriously customize the interface. One easy reason to install Views is in order to take advantage of the Calendar view, which gives you not only a full page, graphical calendar to add events to and display, but also sidebar calendar widgets and upcoming event lists.
Here's a tip: setting up the calendar view is reasonably tedious. The best write-up explaining it (for Drupal 6) is here: http://drupal.org/node/326061. Drupal's documentation is okay, but this is step-by-step. It does miss one step, though, which is to add the "Event Date - From date" and "Event Date - To date" to the Fields listing (with friendlier titles, like "From" and "To"). Otherwise, calendar items show on the day they were submitted instead of the day that they are occurring.
There's a good case to be made that these two modules should be folded into Drupal's base package, because, in addition to providing very powerful customization features to the core product, there are a whole slew of additional modules that require their presence. If you plan to install a number of modules and/or customize your site, these are pretty much pre-requisites, so just grab and install them.
What-You-See-Is-What-You Get, or Rich Text Format (RTE) editors transform Drupal's default data input boxes into flexible editors with Word-like toolbars. The WSYIWYG module lets you install the editor of your choice. I've done well with FCKEditor (recently rebranded CKEditor, thank you!). The WYSIWYG module lets you work with multiple RTE packages and strategically assign them to different fields and content types. Most RTE editors are very configurable, but note that, in addition to installing the modules, you need to install the editors themselves, so follow the instructions carefully.
If you're building a community site, with hopes of having lots of interactive, social features, Organic Groups gives you the flexibility to not only create all sorts of groups and affiliations on your own, but let your users create their own groups as well, much like Facebook does. For an interactive site, this is essential.
E-Commerce/Donations
Many modules are available for either integrating with Authorize.net or Paypal, or setting up your own e-commerce site. The aptly named e-Commerce module and Ubercart are among the better known and supported options.
Drupal fans: what modules do you recommend? Which do you install first? Leave your recommendations in the comments.
Next week, we'll talk about menus, blocks and taxonomies: Drupal 101: Navigation.
I’m trying out Open Atrium. http://openatrium.com/ Now in first beta, Open Atrium from Development Seed consolidates powerful project management features to Drupal in a modern, polished format.
When we first started bearing down on Drupal two years ago, about the first thing we wanted to do manage independent projects on our own www.dbdes.com site. We got reasonably far, with the ability to define clients, projects, tasks and organize blog-like discussion and documents for each. Given the state of the art two years ago in Drupal and our own priorities, we eventually shelved it in favor of a generally positive relationship with Basecamp (http://www.basecamphq.com). Meanwhile, many of our Drupal sites required one or another set of Intranet features, and each one got delivered in customized, one-off ways.
Fast forward to summer 2009, and the Open Atrium project led by the wonderful Development Seed team (http://developmentseed.org/) promises to provide a standard Intranet within a Drupal site. I suspect along the way, it will give Basecamp and its competitors a run for its money. Well, given that Open Atrium is open source, “run for the money” may not be the best way to express the comparison; more about that later.
So what is Open Atrium and what does it have?
Install Open Atrium as easily as Drupal 6 generally, and then get going with it in about 5 minutes. Open Atrium has all the polish now available in Drupal 6-on-the-verge-of-Drupal 7.
Create a group and start adding users to them. If you know Basecamp, a group might correspond to a “project.” As with a Basecamp project, you can have people from more than one company on a project. Drupal fans: Open Atrium groups rely on Drupal’s “Organic Groups” module and start with all that OG power.
From the group dashboard, you see a snapshot of all the recent activity for the group, and each user can customize elements of his/her dashboard.
Each group has its own group blog for discussion with comments and related documents. Anyone who uses project management software these days would probably agree that the blog format works better in a more modern way than older-style web forums or bulletin boards. And it uses the increasing popular "markdown" technique for formatting text. You can assign users with the group to take part in a discussion, with notifications going to the user by email. In the full production release, Open Atrium will also have other familiar forms of messaging.
Each group has its own calendar of events, which aims to exchange in and out with your other calendars. Use the calendar to mark out deadlines and major project events.
Document library, in any upload format, including the ability to compare revisions of documents.
Each group also can have a “shoutbox,” which resembles a private group twitter space. What is a private twitter? We have experimented with Yammer (http://www.yammer.com), which you should check out if you want a cool, free, private twitter for your team. Having a group shoutbox offers the same and part of the whole Open Atrium for that group. This has great potential in itself when it reaches the full release stage.
Case Tracker. In the case tracker, you create projects for your group, which I would say roughly correspond to Basecamp milestones, and then you add cases to them. Cases correspond to to-dos or tasks. The case feature already has the advantage of assigning multiple people to them, having start and end dates associated with each case, setting priority, notification and so on. Basecamp alternatives has features like this, and it’s great to see them in Open Atrium. And each case has full blog like discussion and the ability to attach documents.
This is a very cool start. And I expect Open Atrium to really take off. Within the Drupal community, adding Intranet and collaborative features like these has been part of the big appeal. Open Atrium offers the prospect of being able to do it in a standard way.
Having a complete open source project management alternative is part of the larger discussion about cloud computing and hosted software. We like delegating to 47 Signals (the Basecamp publisher) all the administration of the site for all our concurrent projects. And yes, I do trust having client data secure on Basecamp. Wow, one big thing not to have to worry about!
The Basecamp API allows manipulating of any and all data they store for me. And even without that, I can regularly download all project activity in one XML file. Please note: Not project documents, but everything else. With the help of the wonderful ThickToast add-on from http://www.vb123.com/basecamp/, I can regularly bring Basecamp activity into our internal Access-based billing system.
Yet overall, like our use of any Software-As-A-Service provider, disengaging from Basecamp would be a complicated process. Like moving out of a place you have lived in for a while, lot of stuff to take care of and fit to where you are going. And it does mean counting on some start-up company’s commitment to privacy and security.
Open Atrium allows you to host your stuff wherever you want. All your data is there in accessible MySQL tables, following Drupal standard node format. Like everything else with Drupal, you will have the choice of your own private server; hosting it on any of tons of reliable Internet Service Provider; or -- I suspect -- provided in fully managed SAAS format by Acquia or someone. For Drupal developers, taking part with Development Seed in the development project is a lot more friendly than making suggestions, say, to the Basecamp folks.
What provides more overall peace of mind I will leave as (an interesting) topic for another day.
For sure, Open Atrium is Open Source, downloadable without licensing fees. And those who involved, which I suspect we will, will have a lot of say in how the project evolves. In the first week of release of the beta version of the software, over 10,000 people downloaded it—outstanding for a brand new Open Source project. And the project has close to 2000 twitter followers.
Check it out; I know we will. I am already thinking about which upcoming project to manage from it.
I'm following up on my post suggesting that Wikis should be grabbing a portion of the market from word processors. Wikis are convenient collaborative editing platforms that remove a lot of the legacy awkwardness that traditional editing software brings to writing for the web. Gone are useless print formatting functions like pagination and margins; huge file sizes; and the need to email around multiple versions of the same document.
There are a lot of use cases for Wikis:
We can all thank Wikipedia for bringing the excellent crowd-sourced knowledgebase functionality to broad attention. Closer to home we can see great use of this at the We Are Media Wiki, where NTEN and friends share best practices around social media and nonprofits.
Collaborative authoring is another natural use, illustrated beautifully by the Floss Manuals project.
Project Management and Development are regularly handled by Wikis, such as the Fedora Project
Wikis make great directories for other media, such as Project Gutenburg's catalogue of free E-Books.
Almost any popular Wiki software will support the basic functionality of providing user-editable web pages with some formatting capability and a method (such as "CamelCase") to signify text that should be a link. But Wikis have been exploding with additional functionality that ramps up their suitability for all sorts of tasks:
The Floss Manuals team wrote extensions for the Open Source TWiki platform that track who is working on which section of a book and send out updates.
TWiki, along with Confluence, SocialText and other platforms, include (either natively or via an optional plugin) tabular data -- spreadsheet like pages for tracking lists and numeric information. This can really beef up the value of a Wiki as an Intranet or Project Management application.
TWiki and others include built-in form generators, allowing you to better track information and interact with Wiki users.
And, of course, the more advanced Wikis are building in social networking features. Most Wikis support RSS, allowing you to subscribe to page revisions. But newer platforms are adding status updates and Twitter-like functionality.
Before choosing a Wiki platform, ask yourself some key questions:
Do you need granular security? Advanced Wikis have full-blown user and group-based security and authentication features, much like a standard CMS.
Should the data be stored in a database? It might be useful or even critical for integration with other systems.
Does it belong on a local server, or in the cloud? There are plenty of great hosted Wikis, like PBWorks (formerly PBWiki) and WikiSpaces, in addition to all of the Wikis that you can download and install on your own Server. There are even personal Wikis like TiddlyWiki and ZuluPad. I use a Wiki on my Android phone called WikiNotes for my note-keeping.
Are you already using a Wiki? You might be. Google Docs, with it's revision history feature, may look more like a Word processor, but it's a Wiki at heart.
An award-winning friend of mine at NTEN referred me to this article, by Jeremy Reimer, suggesting that Word, the ubiquitous Microsoft text manipulation application, has gone the way of the dinosaur. The "boil it down" quote:
"Word was designed in a different era, for a very specific purpose. We don't work that way anymore."
Reimer's primary reasoning is that Word was originally developed as a tool that prepares text for printing. Since we now do far more sharing online than by paper, formatting is less important. He also points out that Word files are unwieldy in size, due to the need to support so many advanced but not widely used features. He correctly points out that wikis save every edit, allowing for easy recovery and collaboration. Word's difficult to read and use Track Changes feature is the closest equivalent
Now, I might have a reputation here as a Microsoft basher, but, the truth is, Word holds a treasured spot on my Mac's Dock. Attempts to unseat it by Apple's Pages, Google Docs and Open Office have been short-lived and fruitless. But Reimer's absolutely right -- I use Word far more for compatibility's sake than the feature set. There are times - particularly when I'm working on an article with an editor - that the granular Track Changes readout fits the bill better than a wiki's revision history, because I'm interested in seeing every small grammatical correction. And there are other times when the templates and automation bring specific convenience to a task, such as when I'm doing a formal memo or printing letterhead at work. But, for the bulk of writing that I do now, which is intended for sharing on the web, Wikis put Word to shame.
The biggest problem with Word (and its ilk) is that documents can only be jointly edited when that's facilitated by desktop sharing tools, such as GoToMeeting or ReadyTalk, and now Skype. In most cases, collaboration with Word docs involves multiple copies of the same document being edited concurrently by different people on different computers. This creates logistical problems when it comes time to merge edits. It also results in multiple copies of the revised documents on multiple computers and in assorted email inboxes. And, don't forget that Track Changes use results in larger documents that are more easily corrupted.
A wiki document is just a web page on a server that anyone who is authorized to do so can modify. Multiple people can edit a wiki concurrently, or they can edit on their own schedules. The better wiki platforms handle editing conflicts gracefully. Every revision is saved, allowing for an easy review of all changes. Earlier versions are simple to revert back to. This doesn't have to be cloud computing -- the wiki can live on a network server, just as most Word documents do.
But it's more than just the collaborative edge. Wikis are casual and easy. Find the page, click "edit", go to work. Pagination isn't an issue. Everything that you can do is usually in a toolbar above the text, and that's everything that you'd want to do as well.
So when the goal is meeting notes, agendas, documentation, project planning or brainstorming, a wiki might be a far simpler way to meet the need than emailing a Word document around. Word can be dusted off for the printed reports and serious writing projects. In the information age, it appears that the wiki is mightier than the Word.
Next week I'll follow up with more talk about wikis and how they can meet organizational needs.
For the past four years or so, at two different organizations, I've been evaluating Microsoft's Sharepoint 2007 as a Portal/Intranet/Business Process Management solution. It's a hard thing to ignore, for numerous reasons:
It's an instant, interactive content, document and data management interface out of the box, with strong interactive capabilities and hooks to integrate other databases. If you get the way it uses lists and views to organize and display data, it can be a very powerful tool for managing and collaborating on all sorts of content. As I said a year or two ago in an article on document management systems, it has virtually all of the functionality that the expensive, commercial products do, and they aren't full-fledged portals and Intranet sites as well.
Sharepoint 2007 (aka MOSS) is not free, but I can pick it up via Techsoup for a song.
It integrates with Microsoft Exchange and Office, to some extent, as well as my Windows Directory, so, as I oversee a Windows network, it fits into it without having to fuss with tricky LDAP and SMTP integrations.
All pretty compelling, and I'm not alone -- from the nonprofit CIO and IT Director lists I'm on, I see that lots of other mid to large-sized organizations are either considering Sharepoint, or already well-ensconced.
So, why does Sharepoint scare me?
What it does out of the box, it does reasonably well. Not a great or intuitive UI, but it’s pretty powerful. However, advanced programming and integration with legacy systems can get really complicated very fast. It is not a well-designed database, and integration is based on SOAP, not the far less complicated REST standard, meaning that having someone with a strong Microsoft and XML programming skill set on board is a pre-requisite for doing anything serious with it.
MOSS is actually two major, separately developed applications (Windows Sharepoint Services and Content Management Server) that were hastily merged into one app. As with a lot of immature Microsoft products, they seem to have been more motivated by marketing a powerful app than they were in making it actually functional. Sharepoint 2013 or 2016 will likely be a good product, kind of like Exchange 2007 or SQL Server 2003, but Sharepoint 2007 makes a lot of promises that it doesn't really keep.
Sharepoint's primary structure is a collection of "sites", each with it's own URL, home page, and extensions. Without careful planning, Sharepoint can easily become a junkyard, with function-specific sites littered all over the map. A number of bloggers are pushing a “Sharepoint invites Silos” meme these days. I stop short of blaming Sharepoint – it does what you plan for. But if you don’t plan, or you don't have the buy-in, attention and time commitment of key staff both in and out of IT, then silos are the easiest things for Sharepoint to do.
The database stores documents as database blobs, as opposed to linking to files on disk, threatening the performance of the database and putting the documents at risk of corruption. I don't want to take my org's critical work product and put it in a box that could easily break.
Licensing for use outside of my organization is complicated and expensive. MOSS access requires two or three separate licenses for each user - a Windows Server licence; a Sharepoint License, and, if you're using teh advanced Sharepoint features, an additional license for that fiunctionality. So, if I want to set up a site for our Board, or extend access to key partners or clients, It's going to cost for each one. There's an option to buy an unlimited access license, but, the last time I looked, this was prohibitively expensive even at charity pricing.
Compared to most Open Source portals, Sharepoint's hardware and bandwidth requirements are significantly high. Standard advice is that you will need additional, expensive bandwidth optimizing software in order to make it bearable on a WAN. For good performance on a modest installation, you'll need at least two powerful servers, one for SQL Server and one for Sharepoint; for larger installations, a server farm.
I can't help but contrast this with the far more manageable and affordable alternatives, even if those alternatives aren't the kitchen sink that Sharepoint is. Going with a non-Microsoft portal, I might lose all of that out of the box integration with my MS network, but I would jettison the complexity, demanding resources, and potential for confusion and site sprawl. I'm not saying that any portal/intranet/knowledge management system can succeed without cross-departmental planning, but I am saying that the risk of a project being ignored -- particularly if the financial investment was modest, and Sharepoint's not cheap, even if the software can be -- is easier to deal with than a project being fractured but critical.
if my goal is to promote collaboration and integrated work in my organization, using technology that transcends and discourages silos, I'm much better off with apps like Drupal, KnowledgeTree, Plone, or Salesforce, all of which do big pieces of what Sharepoint does, but require supplemental applications to match Sharepoint's smorgasbord of functionality, but are much less complicated and expensive to deploy.
After four years of agonizing on this, here's my conclusion: When the product matures, if I have organizational buy-in and interest; a large hardware budget; a high-performance Wide Area Network, and a budget for consulting, Sharepoint will be a great way to go. Under the conditions that I have today -- some organizational buy-in; modest budget for servers and no budget for consulting; a decent network, but other priorities for the bandwidth, such as VOIP and video -- I'd be much better served with the alternatives.
These days, having an “Intranet” comes up a lot as a requirement for website projects. I’m using the term advisedly to refer to a range of needs for private space for organizing campaigns and collaboratively developing ideas.
This is different from project specifications that call for members-only sections. Those kind of requirements typically focus on log-in based spaces for designated folks to download private materials, sign up for events not open to the public, maintain their profile and so on. The “members-only” pages communication model typically still has your organization and your site at the center. It places constituents in individual relationships with you.
Here we are talking about requirements that point toward building a communication and collaboration network. Contact, discussion and organizing takes place among the participants as well as with the site owner. Historically, Intranet referred to private spaces for organizational staff, while Extranets extended to clients, volunteers, board, and more. With more organizational work flowing through collaborative networks, the distinction doesn’t seem as important. Typical requirements that organizations bring us today include:
a shared space to brainstorm, draft, edit public policy documents or strategy and tactics for advocacy campaigns
space for community organizations doing the same kind of work, such as immigrant rights or youth services, to collaborate on development best practices documents
spaces for researchers in different places or in different organizations to collaborate on community development or employer research agendas
private spaces to post and discuss assignments for classes in a school or workshop trainings
shared private calendar of events of interest for organizations working together
Many tools out there can be adapted to meet needs like this—whether this was their intended purpose or not. We find ourselves recommending several kinds of possibilities, ranging from the simple and out-of-the-box to the more complex. Planning and customizing may make a lot of sense when you need to develop a more strategic collaborative model with specific community networks, particularly less technical and more program-driven and community-based teams. Where time, cost, staff attention span pose limits, simpler solutions may do. And they could serve as proofs of concept for a second generation strategic initiative.
Creating a wiki. You can do this using an inexpensive hosted service, such as wikispaces or zoho’s wiki, or you can install on your own server the original mediawiki or newer full systems such as tikiwiki. Wikis have the advantage of totally flexible, malleable structure for sharing knowledge. They intentionally have limited features and the formatting or mark-up syntax may frustrate less technical folks.
Creating a simple web site that is mainly kept private. Google sites or Wordpress come up as solutions of this sort. In just a few hours, a site can begin to emerge that can have private discussion spaces, with blog-like commenting, places to store documents and keep track of revisions, make lists and calendars to organize a work plan and collaborative needs. Google sites have the advantage that they build on what for many is first-order collaboration—sharing an individual Google document, spreadsheet, or calendar. Wordpress has more polish and can be installed locally.
Adapting project management tools for a knowledge network. We have used and recommended Basecamp for this, and Central Desktop offers similar solutions. These are hosted services, with fees per month that grow the more private spaces you create. Again, you can also have blog-like discussion and commenting, collaborate and monitor versions of documents, have an organizing calendar and so on.
Sharepoint from Microsoft offers similar features to the last category. Though an extension of an internal network, it can be opened up to outside team members as well. Larger organizations put a lot of time into customizing it or using its integration with Exchange and other Microsoft stuff, if that is your path in life.
All these choices come up as alternatives to building the Intranet or collaborative space as a section of a public website. All the major content management systems, both proprietary and Open Source, have this ability to one degree or another. When the needs go beyond the simple, the power of a full CMS can and should be harnessed to meet goal driven needs. At one time, we thought that all our Drupal websites could just have the same Intranet/collaborative space option. The advantage over just using one of the other types of tools here comes from the ability to refine different types of users, categories, workflows and so on. And this is true with the other CMS systems.
There is planning to be done for any of these options. For example, choosing whether it’s OK to have your private discussion and materials hosted outside (even if based on logins) versus the security of installing it locally can be an important consideration. The communication model for new users, including around email integration, needs careful consideration. You will need to determine what will bring your intended participants into a lively collaborative network, how much structure you need to provide, who will monitor it and other such questions. It is great to know that once you work through these questions, the technical choices get better all the time.
Subscribe through Feedburner