Meaningful shared data, like the Miles Per Gallon ratings on new car stickers or the calorie counts on food packaging help us make better choices;
But not all data is as easy to interpret;
Nonprofits have continually been challenged to quantify the conditions that their missions address;
Shared knowledge and metrics will facilitate far better dialog and solutions than our individual efforts have;
The web is a great vehicle for sharing, analyzing and reporting on data;
Therefore, the nonprofit sector should start defining and adopting common data formats that support shared analysis and reporting.
I've made the case before for shared outcomes reporting, which is a big piece of this. Sharing and transparency aren't traditional approaches to our work. Historically, we've siloed our efforts, even to the point where membership-based organizations are guarded about sharing with other members.
The reason that technologists like Marnie and I end up jumping on this bandwagon is that the tech industry has modeled the disfunction of a siloed approach better than most. early computing was an exercise in cognitive dissonance. If you regularly used Lotus 123, Wordperfect and dBase (three of the most popular business applications circa 1989) on your MS-DOS PC, then hitting "/", F7 or "." were the things you needed to know in order to close those applications respectively. For most of my career, I stuck with PCs for home use because I needed compatibility with work, and the Mac operating system, prior to OSX, just couldn't easily provide that.
The tech industry has slowly and painfully progressed towards a model that competes on the sales and services level, but cooperates on the platform side. Applications, across manufacturers and computing platforms, function with similar menus and command sequences. Data formats are more commonly shared. Options are available for saving in popular, often competitive formats (as in Word's "Save As" offering Wordperfect and Lotus formats). The underlying protocols that fuel modern operating systems and applications are far more standardized. Windows, Linux and MacOS all use the same technologies to manage users and directories, network systems and communicate with the world. Microsoft, Google, Apple and others in the software world are embracing open standards and interoperability. This makes me, the customer, much less of an innocent bystander who is constantly sniped by their competitive strategies.
So how does this translate to our social service, advocacy and educational organizations? Far too often, we frame cooperation as the antithesis to competition. That's a common, but crippling mistake. The two can and do coexist in almost every corner of our lives. We need to adopt a "rising tide" philosophy that values the work that we can all do together over the work that we do alone, and have some faith that the sustainable model is an open, collaborative one. Looking at each opportunity to collaborate from the perspective of how it will enhance our ability to accomplish our public-serving goals. And trusting that this won't result in the similarly-focused NGO down the street siphoning off our grants or constituents.
As Marnie is proposing, we need to start discussing and developing data standards that will enable us to interoperate on the level where we can articulate and quantify the needs that our mission-focused organizations address. By jointly assessing and learning from the wealth of information that we, as a community of practice collect, we can be far more effective. We need to use that data to determine our key strategies and best practices. And we have to understand that, as long as we're treating information as competitive data; as long as we're keeping it close to our vests and looking at our peers as strictly competitors, the fallout of this cold war is landing on the people that we're trying to serve. We owe it to them to be better stewards of the information that lifts them out of their disadvantaged conditions.
I'm wrapping up the Drupal 101 series with some talk about Drupal themes, and some additional info on topics that we've already covered. The goal of these posts is to give new Drupal administrators an idea about how Drupal works, and some pointers to the key add-ons and resources in the broad Drupal ecosystem. For reference' sake, we started with an intro, moved on to Modules, and then covered navigation. So, now that we have a functional web site, what does it look like?
Getting Themes
Drupal comes with five or six themes to choose from, and, if you use them, then your site will look very, um, uninspired. This might not be a problem if your goal is not to impress your visitors, but simply provide information or functionality, but, if you're putting up a website for your organization, you want one that stands out from the crowd. So you have two choices: you can find a better, less common theme, or you can customize one of the default themes.
The first place to go is to Drupal Theme Garden. This is where many Drupal theme designers share their work. Here, you can either find a theme to use (or customize for your use), or get a good idea about the types of things you can do with your theme.
Customizing Themes
From the Administration menu, you can modify any theme's main text elements, deciding whether or not to display your site's mission or slogan, name or logo. And you can replace the default "droplet" logo with your own logo (a no-brainer!). Assuming that you've started with a theme that you really like, this might be enough. But, if you want to do more serious customizations, such as moving the logo to the center of your header or changing the site colors, you're going to need basic web 4.0 programming skills and, most likely, some level of comfort with the PHP scripting language.
Most themes consist of one or more style sheets, a number of "tpl" files with PHP/HTML code laying out various page elements, such as blocks, footers and sidebars, and one called page.tpl.php that establishes the overall page layout. The main styles are usually stored in styles.css, and you can make a lot of changes to your site's appearance here, modifying default background colors and images, placing and resizing content.
If that's not enough, most customizations can be done using Wordpress's internal macros and functions, meaning that you won't have to worry about assigning variables or what goes into the foreach loops. Wordpress has simple commands that you can insert into a page to loop through your posts and display them or list your categories in the sidebar. A nice breakdown of the Wordpress functions can be found at WpExplorer.com.
If you do modify the stylesheets and templates, make sure that you are storing your themes in sites/default folder and that you're properly backing up whenever you do an upgrade. If you modify theme files in the main themes folder, and then upgrade to, say, a Drupal security fix, your modifications will be overwritten. In general, themes remain functional from dot release to dot release (e.g., what worked for Drupal 6.1 still works in 6.9), but the Drupal maintainers often make dramatic changes in number versions, so don't assume that your theme in Drupal 6.9 will not be messed up if you upgrade to Drupal 7 (coming soon).
More Installation Options
In the first Drupal 101 post, I mentioned Fantastico, a two-click installer for Drupal available on most hosting services that use the cPanel site management interface. I subsequently ran into this useful article about Elefante and Simplescripts. These are packages that you can use to install a variety of popular open source applications, including Drupal.
In addition to application installers, there are other options for installing Drupal:
Customized Drupal installations like Open Atrium and Acquia come with more modules and functionality.
There's been some development and discussion about Installation Profiles, a Drupal add-on functionality that lets you define additional installation details, such as module defaults and inclusion of additional modules and data for distributing custom Drupal installations.
Conclusion
What I hope this Drupal 101 series has done is to offer some context and guidance for people new to Drupal who are about to give it a try, and some backing to my initial proposition that Drupal's strength is it's flexibility. Along the way, I've received tweets asking "Why Drupal?" and my answer is that Drupal isn't the only CMS out there, or necessarily the best one for your web site. There are a huge variety of commercial and open source options. In fact, my personal website runs on a combination of Frog CMS and Wordpress, because I wanted a simple tool for integrating RSS feeds, which Frog provides, and a powerful blogging platform. On the other hand, last week the White House ditched their commercial CMS for Drupal. So this series might also inspire you to look elsewhere, particularly if a more traditional, tree-structured content management interface will work better for you than Drupal's layout by association model. Whichever way you go, we suffer more from a surfeit of good options than a lack of same.
Here's the third in a series of posts on getting started with Drupal, the popular open source content management system. The short intro and discussion on modules are best read first. Today we'll look at site structure, and how menus, blocks and taxonomies can make your site navigable for your visitors.
Menus
Drupal has a simple and flexible tool for creating and managing menus. You can check/uncheck standard functions; assign them to regions (left sidebar, right sidebar, header, footer, etc.); and easily create new items.
By default, Drupal offers three menus that you can add to your site:
Navigation - The main menu is dynamic. It displays items based on the visitor's role and state of authentication. For example, an unauthenticated user might see a "Login" menu item, while an authenticated user would see "logout". An authenticated user who is also a site manager would see the Administer menu. This menu is usually placed in a sidebar, next to the main content
Primary Links - This is often the menu for the main content areas, e.g. Home, Blog, Calendar, About. Primarily links are usually placed in a site's header.
Secondary Links can be used for less popular pages, but ones that you want to have available, such as site maps, privacy notices, and contact links.
You can assign a menu item to any particular piece of content, or to a collection of items by content type. Drupal assigns numbers to individual items. The basic content type is called a node, so the default first page of a web site would be at http://your-site.org/node/1. If you create a blog, the first post would be at http://your-site.org/blog/1.
Tip: Be sure that the Path Module is enabled. Path lets you can rename items with friendlier names than, say, site/node/113.
Say you wanted blog/1 to be your front page, but you also wanted something easier to remember to appear in the address bar, you could rename it "home", so that people could browse directly to the site at http://your-site.org/home. They would see, in the center of the home page, that first blog entry. Drupal's general settings allow you to identify your home page; renaming a numeric page simply makes it friendlier for your users.
If, instead, you simply wanted the whole blog to be the home page, then you would skip the numbers, and not bother with a rename, as linking the front page to http://your-site.org/blog would accomplish that.
Drupal's real power comes in when you realize that, with the CCK module, you can make your own content types, and that can be very easy. A press release will have a similar format to a blog item (title, content). So you can create a type called press_release and link a page to it: http://your-site.org/press_release. All new press releases that you post to the site from Create Content/Press Release will appear there.
Blocks
Blocks are boxes that can be placed on one or more pages or associated with one or more content types. They usually appear in the left or right sidebars. Strategically associating blocks with particular content can be a subtler way o offer navigational aids. For example, you might want to have a block with current open positions appear on your "About" page, but not necessarily with your blog. Or you might not want the job listings to appear on pages describing your services, instead featuring a "Donate Now" box. This flexibility allows you to align content in ways that make sense for the different audiences with varying interests that your site will attract.
Taxonomies
All of the above is fine for sites without a lot of content. But, once you have a library of blog entries, press releases and documents to share, you'll want to give your visitors a way to find what they're looking for that doesn't involve inordinate amounts of scrolling. Search is a no-brainer, but even more important is to organize your content with meaningful labels. For this, use the Taxonomy module.
Taxonomies allow you to tag or classify your content using hierarchal terminology. For example, if your NPO serves the homeless, you might have papers on poverty and employment, descriptions of available shelters and programs, job opportunities, and much more. You can break this content down into meaningful categories, then assign sub-terms in each category. Once the taxonomy is in place, you can assign menu items to terms in your taxonomy, thus aggregating all of the relevant content on a single page. You can set up menu blocks for the sub-terms and assign each block to it's category page. The result is a content rich, drill down web site.
That's it for navigation. Next week, we'll talk about Themes and ways you can make your Drupal site distinctive.
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've been doing a lot of work with the open source content management system Drupal lately, and thought I'd share some thoughts on how to get a new site up and running. Drupal, you might recall, got high ratings in Idealware's March '09 report comparing open source content management systems. Despite it's popularity, there are some detractors who make good points, but I find Drupal to be flexible, powerful and customizable enough to meet a lot of my web development needs.
While you can put together a very sophisticated online community and/or website with it, you can also use it for pretty simple things. For example, the nptech aggregator at nptech,info uses Drupal's excellent RSS aggregation functions extensively, and not much else. No blog, no forums. But, having installed and tried standalone RSS aggregators like Gregarius, it became clear that Drupal was just as good an aggregator and, if desired, much, much more. Similarly, when co-workers were looking for a site to share documents with optional commenting (to replace an FTP repository), Drupal was a good choice to support a simple task without locking out growth possibilities.
Installation
Installing Drupal can be a three click process or a unix command line nightmare, depending on your circumstances. These days, there are simple options. If you are using a web host, check to see if your site management console is the popular CPanel, and, if so, if it includes the Fantastico utility. Fantastico offers automated installs for many popular open source CMSes, blogs and utilities.
Absent Fantastico, your host might have something similar, or you can download the Drupal source and follow the instructions. Required skills include the ability to modify text files, change file and folder permissions, and create a MySQL database. At a minimum, FTP access to your server, or a good, web-based file manager, will be required.
If you're installing on your own server, things to be aware of are that you'll need to have PHP, MySQL and a decent web server, such as Apache installed (these are generally installed by default on Linux, but not on Windows). If you use Linux, consumer-focused Linux variants like Ubuntu and Fedora will have current versions of these applications, properly configured. More robust Linux distributions, like Redhat Enterprise, sometimes suffer from their cautious approach by including software versions that are obsolete. I'm a big fan of Centos, the free version of Red Hat Enterprise, but I'm frustrated that it comes with an older, insecure version of PHP and only very annoying ways to remedy that.
Up and Running
Once installed, Drupal advises you to configure and customize your web site. There are some key decisions to be made, and the success of the configuration process will be better assured if you have a solid idea as to what your web site is going to be used for. With that clearly defined, you can configure the functionality, metadata, site structure, and look and feel of your web site.
Install and enable Modules. Which of the core modules (the ones included in the Drupal pacckage) need to be enabled, and what additional modules are required in order to build your site? This is the first place I go.
Define the site Taxonomy. While you can build a site without a taxonomy, you should only do so for a simple site. A well structured taxonomy helps you make your site navigable; enhances searching; and provides a great tool for pyramid-style content management, with broad topics on one level and the ability to refine and dig deeper intuitively built into the site.
Structure your site with Blocks. You can define blocks, assign them to regions on a page (such as the sidebars or header) and restrict them to certain pages. On the theory that a good web site navigates the user through the site intelligently, based on what they click, the ability to dynamically highlight different content on different pages is one of Drupal's real strengths.
Theme your web site. Don't settle for the default themes -- there are hundreds (or thousands) to choose from. Go to Drupal Theme Garden and find one that meets your needs, then tweak it. You can do a lot with a good theme and the built in thee design tools, or, if you're a web developer, you can modify your themes PHP and CSS to create something completely unique. Just be sure that you followed the installation suggestions as to where to store themes and modules so that they won't get overwritten by an upgrade.
This just brushes the surface, so I'll do some deeper dives into Drupal configuration over the next few weeks.
The popular theory is that, with social networks like Twitter and Facebook serving as link referral tools, there's no need to setup and look at feeds in a reader anymore. And I agree that many people will forgo RSS in favor of the links that their friends and mentors tweet and share. But this is kind of like saying that, if more people shop at farmer's markets than supermarkets, we will no longer need trucks. Dave Winer, quite arguably the founder of RSS, and our friends at ReadWriteWeb have leapt to RSS's defense with similar points - Winer puts it best, saying:
"These protocols...are so deeply ingrained in the infrastructure they become part of the fabric of the Internet. They don't die, they don't rest in piece."
My arguments for the defense:
1. RSS is, and always has been about, taking control of the information you peruse. Instead of searching, browsing, and otherwise separating a little wheat from a load of chaff, you use RSS to subscribe to the content that you have vetted as pertinent to your interests and needs. While that might cross-over a bit with what your friends want to share on Facebook, it's you determining the importance, not your friends. For a number of us, who use the internet for research; brand monitoring; or other explicit purposes, a good RSS Reader will still offer the best productivity boost out there.
2. Where do you think your friends get those links? It's highly likely that most of them -- before the retweets and the sharing -- grabbed them from an RSS feed. I post links on Twitter and Facebook, and I get most of them from my Google Reader flow.
3. It's not the water, it's the pipe. The majority of those links referred by Twitter are fed into Twitter via RSS. Twitterfeed, the most popular tool for feeding RSS data to Twitter, boasts about half a million feeds. Facebook, Friendfeed and their ilk all allow importing from RSS sources to profiles.
So, here are some of the ways I use RSS every day:
Basic Aggregation with Drupal
My first big RSS experiment built on the nptech tagging phenomenon. Some background: About five years ago, with the advent of RSS-enabled websites that allowed for storing and tagging information (such as Delicious, Flickr and most blogging platforms), Techsoup CEO Marnie Webb had a bright idea. She started tagging articles, blog posts, and other content pertinent to those working in or with nonprofits and technology with the tag "nptech". She invited her friends to do the same. And she shared with everyone her tips for setting up an RSS newsreader and subscribing to things marked with our tag. Marnie and I had lunch in late 2005 and agreed that the next step was to set up a web site that aggregated all of this information. So I put up the nptech.info site, which continues to pull nptech-tagged blog entries from around the web.
Other Tricks
Recently, I used Twitterfeed to push the nptech aggregated information to the nptechinfo Twitter account. So, if you don't like RSS, you can still get the links via Twitter. But stay aware that they get there via RSS!
But I'm pretty dull -- what's more exciting is the way that Google Reader let me create a "bundle" of all of the nptech blogs that I follow. You can sample a bunch of great Idealware-sympatico bloggers just by adding it to your reader.
Google is on a fishing expedition to see if we're willing to take web-surfing to a whole new level. My colleague Steve Backman introduced us to Google Wave a few months ago. I attended a developer's preview at Techsoup Headquarters last week, and I have some additional thoughts to share.
Google's introduction of Wave is nothing if not ambitious. As opposed to saying "We have a new web mashup tool" or "We've taken multimedia email to a new level", they're pitching Wave as nothing less than the successor to email. My question, after seeing the demo, is "Is that an outrageous claim, or a way too modest one?".
The early version of Google Wave I saw looked a lot like Gmail, with a folder list on the left and "wave" list next to it. Unlike Gmail, a third pane to the right included an area where you can compose waves, so Wave is three-columner to Gmail's two.
A wave is a collaborative document that can be updated by numerous people in real-time. This means that, if we're both working in the same wave, you can see what I'm typing, letter by letter, as I can see what you add. This makes Twitter seem like the new snail mail. It's a pretty powerful step for collaborative technology. But it's also quite a cultural change for those of us who appreciate computer-based communications for the incorporated spell-check and the ability to edit and finalize drafted messages before we send them.
Waves can include text, photos, film clips, forms, and any active content that could go into a Google Gadget. If you check out iGoogle, Google's personal portal page, you can see the wide assortment of gadgets that are available and imagine how you would use them -- or things like them -- in a collaborative document. News feeds, polls, games, utilities, and the list goes on.
You share waves with any other wave users that you choose to share with. User-level security is being written into the platform, so that you can share waves as read-only or only share certain content in waves with particular people.
Given these two tidbits, it occurred to me that each wave was far more like a little Extranet than an email message. This is why I think Google's being kind of coy when they call it an email killer - it's a Sharepoint killer. It's possibly a Drupal (or fill in your favorite CMS here) killer. It's certainly an evolution of Google Apps, with pretty much all of that functionality rolled into a model that, instead of saying "I have a document, spreadsheet or website to share" says "I want to share, and, once we're sharing, we can share websites, spreadsheets, documents and whatever". Put another way, Google Apps is an information management tool with some collaborative and communication features. Google Wave is a communications platform with a rich set of information management tools. It's Google Docs inverted.
So, Google Wave has the potential to be very disruptive technology, as long as people:
Adopt it;
Feel comfortable with it; and
Trust Google.
Next week, I'll spend a little time on the gotcha's - please add your thoughts and concerns in the comments.
"80% of your time will be spent writing good content." I must have repeated this phrase 100 times this year in various presentations and website project meetings. Logically, I know its a solid statement, but it's always good to be reminded by just doing it.
It's now taken me weeks longer than expected to write stuff for our new FivePaths company website under development. Sometimes I just want to say on one page, "We build websites, databases, and know a lot of important technology stuff. Maybe we can help you." Its hard to look inside yourself, and the team and projects you know so well, and generate compelling ways to describe it.
So naturally, I have procrastinated. Many times now. And sometimes while procrastinating, I looked for magical software tools to help me... somehow... Surprisingly to me, there are some:
We often recommend storytelling as a compelling frame for writing content for the web. Storyist is a terrific Mac software designed to help novelists generate and organize their story. Of course I bought it immediately, and lost at least 30 minutes exploring the metaphor of the story for our website. I could generate "characters" (ie clients, partners, etc), "plot" (our services), organize images, and walk through all of these as "chapters", organizing and reorganizing what comes first and next. I have tried organizing my thoughts in similar ways using a wiki, but found the story frame much more useful.
Here we have a software combining index cards with surveying. I could set up a free account online and start generating cards containing categories and subcategories, and mix them around in different ways. Very compelling, especially when you are as overwhelmed as I was with all the great ways to organize website concepts. Its like magnetic poetry for building taxonomies. Particularly cool and essential for real card sorting activities, you can invite folks to sort your cards the way it works best for them, and then analyze the results.
Distractions really help fuel procrastination. When writing web content, there is nothing more distracting than the other five screens I have open on my computer (my email, Facebook, calendar, etc). Sometimes I need help focusing on just one thing at a time. WriteRoom basically brings your Mac back to the days when portable computers meant two people and a large cardboard box. It gives you a nice black screen to type bright green letters. Everything else is gone from sight. This is as far as I got, although I understand you can change the colors of the background and font to a less headache inducing combination.
Ok I actually never tried this one, but it seemed really compelling as I was copy editing the About section for our new site, for the third time. They promise grammar, spelling and style checking, as well as a dictionary/thesaurus feature. They have software to fit various writing "profiles", including business and hi-tech writing. I wonder if it is like online translations, which still struggles to tell the difference between someone from Berlin and a jelly doughnut. Ich bin kein Berliner.
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.
As the internet has progressed from a shared source of information to a primary communications tool, a natural offshoot of the migration has been where the two things meet: people referring internet information. If you're active at all on Facebook, Twitter, MySpace, Friendfeed, or any of the numerous online communities, big or small, then you are regularly seeing links to useful articles and blog posts; cute YouTube videos, and entertaining photos. Much of this information is passed along from online friend to online friend, but where does the first referral originate from? Usually, it's somebody's RSS reader.
The main reason that I'm such an RSS advocate is that I believe that it's the tool that lets me find the strategic and useful needles lost in the haystack of celebrity gossip, prurient content, and corporate promotional materials that they're buried under. But it isn't "RSS", per se, that does the filtering -- it's other people, whom I call "information agents", who do the sifting. If I want to keep up with fundraising trends, a topic that interests me, but, as an IT Director, isn't my primary area of expertise, I'm not going to spend thirty minutes a day doing research. I subscribe to some very pertinentblogs, and I follow a few people on Twitter and in Reader who find the important and insightful articles and share them with me.
Now it appears that Google wants to cut out the social media middlepeople. As I alluded to in my article on RSS, and fleshed out in this post about sharing with reader, the ability to refer information that you find in Reader is one of the things that makes it so powerful. Last week, Google seriously upped the ante by adding Twitter/Facebook/Delicious-like following, "liking" and sharing to the mix.
Here's what the new features do:
Sharing now lets you share with the world, or just those members of the world that you want to share with. Google has always allowed you to share items, but connecting to other people was a bit arcane and limited, as, by default, Google only allowed you to connect to those that you chat with in GMail. If you read up on it, you learned that you could change that to any defined group of associates in your Google Contacts (all of this assuming that you use Google Contacts - many Google Reader users don't). As someone who does use all of the Google stuff, I still found that opening this up to 80 or so people in my contacts didn't make it clear to many of them as to how they could connect with me.
The new Following feature lets you follow anyone who is willing to share, not just people that you personally communicate with. Now my shared items are marked as public, so anyone can follow my shared items feed by clicking on "Sharing Settings" (in the "People You Follow" section) and searching for me by name or email address. Once you locate me (or someone else), you can (and should) browse through their items to make sure that they share things that you'll find useful. For example, I share a lot of things that are on the topics that I blog about here. But I also share items related to civil rights issues and the occasional link that I find funny. Since humor and politics are very subjective topics, you might want to be sure that you're not going to be annoyed or offended you before you subscribe to a feed.
But the internet is not just about who you know. The Like feature allows you to find new people to follow based on common interests. You'll note that certain articles have a new note at the top saying "XX people liked this", where "XX" is the number of people who have indicated that they like the article by checking the option at the bottom of the post. This message is a link, and clicking it expands it into links to each of the people who "liked" it, allowing you to browse their shared items and optionally follow them. This, to me, enables the real power of the social web -- finding people who share your interests, but have better sources. It's what initially was so exciting about social bookmarking service Delicious, and it's about time that Google Reader enabled it.
I'm hoping the Google's next round of Reader updates will improve our ability to not just tag and classify the information that we find, but also share based on those classifications. That will enable me to selectively publish items that I think are of interest to others, perhaps sending nptech links to Friendfeed and the humorous stuff to Facebook. But I welcome these improvements, and I appreciate the way that reader becomes more and more of a single stop for information discovery and distribution. The Internet would be a messier place without it.
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.
Even if you will never tweet, it's obvious that Twitter is a source of useful information, and, in some cases, a more timely source than traditional search engines and media. If you use Firefox as your main web browser, and have the popular Greasemonkey add-on installed, which serves as a kind of macro language for the web, then the Twitter Google Results script adds some real power. Any Google search you perform will also search Twitter, posting the top five relevant results. Why is this useful? Well, when we heard rumors that a bomb had gone off somewhere near our Bozeman, Montana office, the Twitter results had current info and links that weren't indexed by Google yet
Namechk checks for your preferred username on a slew of Web 2.0 sites, from Bebo to Youtube. I found this useful to reserve peterscampbell at a few sites that I want to use but hadn't signed up for, and to learn that some other guy named peterscampbell had already grabbed it at Youtube, where I had used a different loginname... snap!
This is a tip, not a tool - if you've been stymied by Facebook's recent changes to how it handles updates, you can make a lot more sense of it by making lists of related friends, and then filtering the updates by group. Click on Friends and the "Create New List" button is at the top of the screen. I have lists for family, nptech, Boston friends, SF Friends, and a special one called "no tweets", which filters out everyone who cross-posts all of their Twitter updates to Facebook (my default view). Keeping up with all of this info is always a challenge, so the ability to filter out the echoes is a must.
Exhibit is a web site that lets you upload spreadsheets, maps and other data to an information rich, filterable, active web page that can then be shared. If your org works with a particular environmental cause, seeks a cure for a disease, or supports a particular community, you can share data about your cause dynamically and expressively with this amazing site.
Google revolutionized email with GMail, the first email platform in decades to question the basic assumptions about how email should work (by filing important email into folders). They're about to do the same thing with Voicemail. A year or two ago, they purchased Grandcentral, a service that allowed you to route multiple phone numbers to one shared voicemail box. A few months ago, they opened the revamped Google Voice to existing Grandcentral customers, and, surprise, it looks a bit like GMail.
When I look at GMail, Google Voice, and the recently announced Google Wave, a real-time communication and collaboration platform, and then picture these all integrated into a Google Apps account, it becomes clear that our phone systems are moving into the cloud as fast as our servers are, and, while it is always that controversial proposition of Google giving you stuff in return for the right to market to you based on all of your data, it still looks like they are poised to offer one of the most powerful, integrated communication platforms that the world has ever seen.
Have you run into any awesome things lately worth sharing? Leave a comment!
Let's get a bit geeky. Many Idealware visitors come here for advice on purchasing and deploying data management systems, such as donor databases, constituent relation management systems and content management systems. And, more often than not, are replacing older systems with new ones, meaning that one of the trickiest tasks is data migration. If any of this work has ever fallen to you, then you might have found yourself doing tedious editing and corrections in Excel, pouring over data screens or rows in Access trying to formalize non-formalized data entry, and generally settling for some lost or incorrect data moving from old system to new.
Wouldn't it be great to have a magic wand that can instantly reformat the data to the proper format? Well, I have one for you. But, just as Harry Potter had to go to school before he could effectively wave his wand, mine comes with a lesson or two as well.
The wand in question is a search/replace language called regular expressions. Regular expressions are a set of terms that can be used, in supported software, to perform advanced search and replace functions. They were originally popularized in the Unix Stream Editor (SED), but are now standardly found in text editors, word processors, scripting languages (such as PHP) and other software, usually as an advanced option.
The reason to use them instead of a regular search and replace function is simple: they can search for things that regular search tools can't. For example:
the first three characters at the beginning of each line
the three at the end of each line
one or more spaces
Regular expressions can also do multiple replacements in one phrase, allowing you to either remove the first comma encountered in a sentence, or all commas. Here are the basics:
A regular expression takes the form of /Search Phrase/Replacement/. A simple search to replace all instances of the word "fish" with the word "bird" would look like:
/fish/bird/
But regular expressions only prove their worth when you learn their special characters:
. (any character)
* (one or more characters)
^ (the beginning of a line
$ (the end of a line)
() (parentheses surrounding characters in the search phrase can be recalled in the replacement)
$1, $2 (substitute in the replacement for characters saved by parentheses in the search phrase)
\ (backslashes treat the next character literally, even if it's a Regular expression special character)
[a-z], [0-9], [A-Za-z] (groupings search for all of the characters specified between the brackets, using dashes to identify ranges
Examples:
If you have a text printout of a document that you want to whittle into something more useful, like a CSV file, step one might be to remove any dead space.
/ */ /
will search for one or more spaces (the asterisk means "any number of the preceding character) and replace them with one space.
/^$/d
will remove all blank lines (lines with nothing between the beginning and the end of the line)
If you are moving data from one system to another, you might have to reformat dates for the new system. Say the old system exports dates as MM/DD/YYYY and the SQL database you're importing them to expects YYYY-MM-DD. This Regular Expression will convert all dates to the new format:
( - parentheses surround things that we want to remember, so this starts a section we'll remember.
[01][0-9] - a month (MM) will be a number between 1 and 12, so, if your system is exporting dates with leading zeros (if not, you can do this with a series of regular expressions to get around that), then the [01] set will match either a leading zero or a one. The [0-9] set will match any digit following that one or zero.
) - this will be remembered in the replacement as $1, because it's the first thing we remembered.
\/ - since the slash is a regular expression special character (the delimiter), we precede it with a backslash, telling the parser to treat it a a slash, not a delimiter.
([0-3][0-9]) - this will find any pair of numbers between 01 and 39, which we know as the day, and remember it as $2, because it's enclosed in parentheses.
\/ - next slash
([12][0-9][0-9][0-9]) - this catches the year. You see how, right? It is specifying that the year will be in this millennia or the last by limiting the first character to one or two. We use parentheses to remember this as well.
/ - this slash signifies that the search phrase is done, and the replacement will follow.
$3-$1-$2 - this takes our three remembered phrases and reorders them from month, day, year to year ($3), month ($1), day ($2), placing dashes in-between them.
/ - finally, we close the command with a slash.
One of my standard uses is to take a list - which could be an Excel spreadsheet, or a database dump, or a Word table -- clean it up, and then format it into SQL statements that can then be pulled into a database. Most databases can import in CSV files, but Excel, while good at doing some reformatting, can't do the fancy cleanup tasks that my regular expression-enabled editor can. Once my specific clean-up chores are done, if I'm left with a tab-delimited file, I can do the following three simple searches to turn it into a SQL input file that can just be run in my SQL interpreter.
/\t/','/ -- searches for all tabs (\t is a symbol that means "tab") and replaces them with ','
/(.)$/$1');/ - searches for the last character in a line and replaces it with that character followed by a close quote, close parens and semi-colon.
/^(.)/insert into players (name, title, company) values ('$1/ - searches for the first character in any line and prepends the front end of the SQL statement.
If we had an input file with lines like this:
Joe Namath Quarterback Forty-niners
It would become
insert into players (name, title, company) values ('Joe Namath','Quarterback','Forty-niners');
There are plenty of excellent resources for learning about regular expressions on the web, but many of them are targeted at programmers, making them a bit thick to read through. For more friendly introductions, I recommend The regular-expressions.info quickstart. While many text-processing tools, including Microsoft Word, support regular expression search and replace, I recommend using a good text editor over a word processor, because it will likely include supporting functionality, such as block copying/pasting, and they'll handle very large files with far more speed and grace. I've been happy using TextPad and EditPlus on Windows, and TextMate and TextWrangler on the Mac. Wikipedia publishes an incomplete list of applications that include regular expression functionality.
Admitting that I might represent an extreme case, I subscribe to 96 feeds in Google Reader. I started with Google Reader last December - prior to that, I used a Mac RSS Reader called Vienna. Moving from Vienna to Google Reader might have been a chore, but it wasn't, thanks to Outline Processor Markup Language (OPML). The short story on OPML is that it was developed as a standard format for outlining. While it is used in that capacity, it's more commonly used as a format for collecting a list of RSS feeds, with last read pointers, that can then be processed by other feed-reading software. So, I exported all of my feeds from Vienna to a .opml file, then I imported that into Google Reader, and all of my feeds were instantly set up. If you run a Wordpress blog, you can rapidly build your blogroll by importing an .opml file.
In addition to sharing feed information with applications, OPML can be used to share a group of feeds with a co-worker, friend or constituent. Say your org does advocacy on a particular issue, and you've collected a set of feeds that represent the best news and commentary on your issue. You could make the OPML file available on your web site for your constituents to incorporate in their readers.
At this point, you might be saying to yourself, "what are the odds that my constituents even know what a feed reader is? Wouldn't making this available be more likely to confuse than help people?" As good as a question as that is, here's why I think that you won't be asking it soon. RSS has seen quick and steady adoption as a standard web service. Four years ago, it was obscure; today every content management system and web portal supports it. It features prominently in the strategic plans of tech giants like Google, Microsoft and Yahoo!. But it's not as well-known by the general computing public -- RSS still has yet to become a real household concept, like search and email have. The game-changer is underway, though. Last month, The Seattle Post-Intelligenser, one of Seattle's primary daily papers, ceased print publication. The San Francisco Chronicle announced last month that they are making one last ditch effort, with a redesign and new printing presses, to stem the growing budget deficit that they face. Competition from TV and the web is driving newspapers out of business, and the hope that something will reverse this trend is thin.
As the internet becomes the primary source of news and opinion, RSS is a natural fit as the delivery medium. You can see that all of the Seattle PI sections are available as RSS feeds, and they have an option to customize the news and features that you see on your homepage. How long before they offer your customized paper as an OPML file, allowing you to instantly replicate your web experience in a reader?
In 1995, internet email was an arcane, technical concept. I figured out that I could send mail to an Internet address using my company's MCI Mail account. My email address was 75 characters long. RSS may seem similarly oblique today, but it's well on the road to being a mainstream method of internet information delivery. Your partners and constituents won't just appreciate your support for it; they'll start to expect it. I hope that my article and these follow-ups in the blog can serve as a good starting point for understanding what RSS can do and what you might do with it.
Google Reader gets a good mention in my RSS article, Using RSS Tools to Feed your Information Needs, but deserves an even deeper dive. This is a follow-up to that article, along with my recent posts on Integrating content with websites, and Managing Content with Pipes. We've established that an RSS Reader helps you manage internet information far more efficiently than a web browser can; and we've talked in the last few posts about publishing feeds to your web site. This post focuses on using tools like Google Reader to share research .
Out of the box, GReader (as it's affectionately known) is a powerful, web-based reader that lets you subscribe, mark and share items in two significant ways. Shared Items are items that get published to a public page that you can point your friends and co-workers to. Further, this page can be subscribed to via RSS as well, so it can be republished to your web site, or integrated into a Facebook feed. Using (fake) bill 221b as an example, if you monitor for and selectively share articles related to the bill, you can easily point co-wokers and constituents to your shared page, and or republish those items in places where your audience will see them.
Shared Items are also made available to other GReader users who choose to share with you. This offers a greater level of convenience for teams working with shared research; it can also afford a level of confidentiality if you don't want to publicize a public page. Not only can you share the items you find; you can also tag them, much like you would with Delicious or Flickr, and add a note, if you have thoughts or context-setting notes to share. A function recently added GReader takes this even further - shared items can be commented on, much as a blog post can.
The last bit to add to this arsenal is a very powerful, but not terribly obvious GReader feature. The Note in GReader bookmarklet (which you can drag to your web browser's quick links or bookmarks toolbar from the GReader "Notes" page) lets you share, with comments and tags, pages that you find on the web as GReader shared items. So if you run across something that isn't in your feeds (and there's plenty of web content that can't be subscribed to), this lets you add it to your shared items.
What I've found is that, as much as I admire social bookmarking sites like Delicious, they become a lot less useful when I can store all of the pages that I find via RSS or browsing, with tags and an option to share them, in the same convenient place.
It's important to note that, as powerful as all of this is, it still lacks some functionality that similar tools have. One great advantage of using Delicious as a link-sharing tool is that you can share links specific to any tag (or set of tags). Google Reader doesn't offer multiple shared pages based on filtering criteria. And while you can add notes to your feed (without adding links), it's not as flexible a repository as a tool like Evernote, which lets you save web pages, ODFs and all sorts of documents to a single web-based folder.
Also, Google Reader isn't the only game in town. The Newsgator family of RSS readers offer similar sharing functions; some of which overcome the limitations above, as do other readers out there (please share your favorite in the comments).
What it boils down to, though, is that we now have powerful, integrated options for online research, as individuals, as teams, and as information agents for our constituents. The convenience of publishing as you discover is a significant advancement over earlier schemes, which usually involved either sending a lot of easily-lost links by email, or submitting your finds to a webmaster, who would then add them to a page on your site. This is a publish as you find approach that incorporates sharing and communication into the research process.
Next week, I'll finish up the "More RSS Tools" series with a post about OPML, the way that you make your collection of feeds portable.
I'm continuing with follow-up topics from my RSS article, Using RSS Tools to Feed your Information Needs. Last week, I discussed integrating content with websites, and this week I'm going to dive into one of the more advanced ways to work with RSS content. This gets a little geeky, but it really shows off some of the sophistication of this technology.
The article provides numerous examples of RSS sources, but all in the form of web sites, blogs and web services that offer you one or more streams of information. If you want to narrow your view beyond the feeds available on a site, say, because you are only interested in Idealware posts about CRM tools or the ones written by Steve Backman, then you need a tool that will refine your search. Alternatively, you might want to put a section containing news stories relevant to a particular issue on your site, but want some control over the sources, as well as the subject matter. For this amount of control over the content you retrieve, you want to use something like Yahoo! Pipes.
Pipes is an RSS mashup editor. It's a tool that looks a bit like Microsoft's Visio, where you drag boxes onto a grid and draw relationships between them. But it's not a layout or flowcharting tool; instead, it's a visual mapping and filtering tool that lets you identify sources and then apply rules to those sources before merging them into an aggregated feed. To break that down, let's say that your goal is to either monitor talk about a bill, or, maybe, to publish a section on your web site titled "What they're saying about bill 221b" (I made that bill up). You have identified eight blogs that have good posts on the subject, and these are blogs that you trust to properly represent the issues and not, in any way, malign or confuse your efforts.
In Pipes, you can select all eight as sources, and then set up a filter to block any posts that don't reference "221b". The resulting RSS feed -- which you can then subscribe to our republish -- will isolate the posts that are relevant to the bill from your selected sources.
For example, here's that pipe that will allow you to skip Michelle, Heather, Paul, Laura, Eric and my posts and just see Steve's:
Another, more advanced example: You have an organizational Twitter feed that you want to republish to your site But you only want to publish your posts, not your individual replies. In Twitter, a reply is always identifiable by the very first character, which will be an "@" sign. Twitter RSS items arrive in the format "yourtwitterid: tweet", so any reply will start with "yourtwitterid: @". Setting up a Yahoo Pipe filter to block any result with ": @" in the text will isolate your posts from the replies. You can add a "Regex" (e.g. Search/Replace) command to replace "yourtwittername:" with nothing in order to publish just the tweet. The pipe will look like this:
If you play with Pipes (Yahoo! ID required, otherwise free), I highly recommend starting with an example like mine or this one by Gina Trapani to get the feel of it. Save your pipe, and you can subscribe to it -- it updates automatically, and you don't have to make it public for it to work.
Google has it's competing Google Mashups tool in private beta, and similar tools are popping up all over the web. I talk a lot about how RSS is the technology that allows us to manage the information on the web. Pipes let us refine it. It's great stuff.
Look for more RSS talk on OPML files and Google Reader in my upcoming posts.
Those of you who visit pages besides the blog here at Idealware have noted that my article Using RSS Tools to Feed your Information Needs is up. If you're new to Really Simple Syndication, my hope is that my guide will help you become more efficient and effective in your use of the web. If you're an old hand at RSS, then I'm hoping the article will serve as a good tool when trying to impress others of the value of syndication.
RSS is a big topic, and writing the article was, in one respect, a challenge: in order to write a solid, intermediate guide to RSS use, I had to narrow the scope a bit. My initial interest and eventual obsession with RSS was sparked by two things: The overall usefulness of a tool that brings the web info I'm interested in to me; and the possibilities of using RSS as a publishing platform. So the article covers the first use well, but omits many cool things, like RSS Pipes, OPML, web site integration, and aggregators/portals. I hope to take these on over the next few weeks here in the blog.
Let's start with web site integration. If you manage a web site, then you know that the name of the game is fresh content. While RSS will not eliminate the need to actively maintain your site, it can supplement your content in an automatically refreshing stream, as well as serve as a publishing medium.
If your site is built with a content management system (CMS), then you are probably already most of the way there. Most CMS's have built in RSS aggregators that allow you to select the relevant content and publish it to a section of your site. If it isn't a standard feature of your CMS, then browse the catalog of add-ons and extensions and you'll probably find it there. Of course, if you use a commercial CMS, as opposed to an open source product, you might have to pay more for the add-on.
If you don't have a CMS, a minimal amount of PHP scripting expertise can accomplish the same thing by using pre-built RSS functions libraries like Magpie RSS. Magpie is a set of PHP routines that you copy to your web server, allowing you to write minimal, simple code that identifies the feed and publishes it to a page. the heavy lifting is done by the Magpie -- all you do is reference the feed and format the appearance of the items.
The simplest use is in republishing content on the web that's pertinent to your site. You can aggregate news relevant to your cause, or sample topics of related interest from blogs on the web. For an example, look at the nonprofit technology news aggregator that I set up at nptech.info. This uses Drupal's built-in RSS aggregator to create a three-section web site republishing nptech blogs, items tagged "nptech" on the web, and general technology news.
But it doesn't stop there -- if you post open positions on Craigslist, you can eliminate the need to also update your web page by simply subscribing to a search for your open jobs. The strategy here is in using RSS not only to add content, but to maintain content that currently requires a Webmaster's attention. If you post your events to a site like Upcoming.org, your events page can be a simple RSS feed. If you link to related sites and associates, you can automate that as well by setting up an account at a bookmarking site, such as Delicious, tagging sites that you want to be linked to your web site with a unique tag, and then subscribing to that tag. And this concept works just as well for graphical content at Flickr, or videos at Youtube.
I'll be posting soon about additional ways to manage RSS feeds, and I want to take a deeper dive into Google Reader, which takes it all to another level. In the meantime, if you have great stories about integrating RSS feeds with your web site, please share in the comments.
I'm wrapping up the Drupal 101 series with some talk about Drupal themes, and some additional info on topics that we've already covered. The goal of these posts is to give new Drupal administrators an idea about how Drupal works, and some pointers to the key add-ons and resources in the broad Drupal ecosystem. For reference' sake, we started with 
Subscribe through Feedburner
