The CMS software arena has changed significantly in the past several years.  Back in the early 2000s it was very common to come across organizations trying to custom build their content management systems and other web software needs.  The landscape today has several mature products to choose from – whether you’re looking for proprietary, open source, or SaaS-based.  There are several mature CMS products to choose from, several options for every feature set and every price point.

Do we buy?

There is a growing trend today of selecting a proven content management solution that goes beyond being just a tool set. Most CMS products are available as Core offerings paired with a collection of defined modules, available for every business need.  This makes CMS products easy to customize.  Several of these products are able to offer standard functionality out of the box, with very little effort in terms of installation or configuration.  However larger installations are not plug-n-play approaches and very often need the shepherding of technical teams.  The obvious advantages are:

• Deployment times are quicker, allowing teams to plan enterprise-level installations in much shorter turnarounds
• Overall cost of ownership is much lower – especially for organizations that choose to go the open-source route
• Rapid integration possibilities because of each product having API-based integration options with plenty of documentation for external development teams
• CMS products in the middle/upper tiers boast enterprise level functionality and sophisticated features (workflow, version control, and multi-level search functionality often separate the men from the boys)

Does it still make sense to build?

So with this plethora of available products in the market, why would an organization choose to go the BUILD route – particularly since tech gurus and analysts confidently predict dangerous pitfalls with that approach?   The answer is that given certain circumstances and specialized needs there is still need for custom-built CMS applications.

Some organizations may just decide to go the Build-route if (a) they have available developer resources, (b) their needs are very specific and compartmentalized, and (c) they don’t have the time to conduct a thorough market analysis for product matches.  The main reasons that come into play when build decisions are made may be:

• Inflexibility: Since CMS products must cater to broad needs they are built in a very generalized fashion, forcing customizations. However even with customizations there may be certain business needs that fall outside of the capability areas.  In such a scenario organizations are locked in and often end up modifying internal structure or working protocol to map to what the product can do.
• Cost: Although this this most associated with licensing and subscription costs, organizations have also made “cost-based” decisions depending on how long they will need to properly do a comprehensive product evaluation.  Licensed products also often times come with the added burden of post-deployment support.

Bottom line: Of course it’s important to make the right decision.  Also with large software installations such as CMS’ once you buy into a product, it’s very hard (read expensive) to switch to another one.

We would always recommend to clients to pursue all the “buy” options (including commercial, open source, SaaS) before taking on a ground-up build. There is also the hybrid option to buy into a product platform and then build specific modules to cater to specific business requirements.  But looking at an established product will, in the long run, save money and time, as well as providing benefits such as consistent/periodic updates and improvements adding to the overall shelf life of the investment.

I’d buy.

But what did it mean to a tester? Well, for a tester, it meant another browser to test.

But don’t worry. With good planning, it may not necessarily mean more work. There are just a few things to remember:

• If you upgrade to IE9, you can’t keep IE8. There are some multiples out there, but I haven’t had much luck with them.
• You can emulate both IE8 and IE7 in IE9 by clicking F12 to open web developer tools, and choosing your browser mode. This should help you with your most basic browser testing. But for more involved testing, nothing replaces a stand-alone browser. To do this, you can build virtual machines with independent browsers, or use a tool like Browsercam.
• If you do install IE9, don’t forget you’ve done so. When doing work, I use both Firefox and IE for unit testing. I had completely forgotten that I upgraded a few days earlier, and was amazed at how code that I thought would fail in IE wound up working. Well, it was working great in IE9, but was failing in IE8, which I nearly forgot to test.
• Consider dropping IE6 from your test plans. It’s important to look at your stats to see if that’s feasible. But at this point, testing for 4 versions of a browser is very time consuming, especially when one of them (IE6), may a) display dramatically differently than the rest; and b) should be going away very soon.

But the members who counted on ULI’s website weren’t always able to find what they were looking for.  ULI’s approximate 60 websites had different implementations (many not on Sitecore) and the current search did not effectively allow the user to search across all ULI related sites. Beaconfire implemented the Google GSA search application, giving ULI the robust functionality of Google Search. Part of this implementation included giving the user an option to search on the specific site or across all ULI and created a common advanced search and search results page across all ULI sites.  Beaconfire also implemented a number of Sitecore updates which allowed the search results to display certain data, such as secured pages and the update date.   You can try out the new search functionality at  http://www.uli.org/ or http://urbanland.uli.org/.

Now, the ULI websites offer a consistent and reliable search experience and results for ULI members and site users.

Many thanks to the good people at NTEN for agreeing to let me stand up in front of a huge cheering crowd at the 2011 Nonprofit Technology Conference to drop some serious science in my session, “Practical HTML5/CSS3 for Nonprofits (or ‘How to Party Like it’s 2011 When it’s Really Still 1999′).” The crowd will be huge, right? And cheering?

HTML5 is the latest in a long line of buzzwords — Web 2.0, AJAX, SEO, B2B anyone? — around Web Design and Development. In my session, I hope to do what I can to dispel some myth, clear up some misunderstandings, try to separate it from some of its buzzwordiness, and start a discussion about what nonprofits can stand to gain from this new standard — nonprofits who may be serving audiences trapped on outdated browsers and using slow dialup connections.

We often hear from clients that they want to convert something to HTML5. What they’re often talking about is a need to take something currently in Flash and make it “not Flash”. This is of particular importance as site visitors increasingly use iPhones or other mobile devices that do not display Flash. It’s a tricky request because more often than not what they actually want is not conversion to HTML5 at all. The misunderstanding, as is often the case, is all about definitions.

Many people hear about things that people have done with HTML5 and don’t understand that the whiz-bang awesomeness they just witnessed is actually a combination of HTML/CSS3/JavaScript that may or may not be (or even need to be) HTML5. If things are moving around your screen in a really exciting way, chances are there is some serious CSS3 or JavaScript doing the heavy lifting and HTML5 has only served as the canvas on which those scripting gymnastics occur. Don’t forget that word: “canvas.” That’s a big one in HTML5 that we’ll discuss in the session in March.

HTML5 is merely the latest in a line of HTML specifications that started with HTML 1.0 back in 1995 and (thankfully) sped pretty quickly to HTML 4.0 by the end of 1997. An HTML specification specifies what code we use to build web pages. That’s why it’s called a specification! It defines what tags we can use (<h1></h1>, <p></p>, <em></em>), describes what they are (first level header, paragraph, and emphasize), and outlines any rules about how we can and cannot use them. It does not describe how these elements look (that’s the job for browsers and for CSS) or what neat things we can make them do (JavaScript). In many ways, and with the majority of tags defined in it, HTML5 is nothing new at all.

The exciting news is that there are some really revolutionary new bits in the soup. Some of these new bits are very, very, cool. Some of them add functionality that is going to prove to be indispensible for building mobile apps and all kinds of interesting, dynamic interfaces. Some of these new additions will cut development time we used to have to spend doing all kinds of mundane validation on forms and whatnot. We’ll focus on these new tags in March and discuss how to use them, when to use them, and when we can start using them.

And that’s the real question, isn’t it? When can we start using them? See you in March!

The Background

Social comment systems have the advantage over the basic comment system in several ways. Most social comment systems have built-in integration with social networks and identity providers such as Twitter, Facebook and OpenId, which allows you to easily pull user data to provide quick registration and identification data. Also, most systems allow you to easily share the comment or the site with friends.

Recently, we needed to implement a fairly robust commenting system on a Convio site for a client. We knew that we wanted to make our comments the centerpiece of the site and that we wanted them to be easily shared with Twitter and Facebook. Since the requirement had such a strong focus on Facebook and Twitter integration, we initially had started down the path of creating a simple storage mechanism for the comments and then to allow the user to share that comment with the world via their social network of choice.  Three things became very apparent quickly:

1. Facebook social plugins are nice, but they are anything but flexible and they are purposefully protected from much customization, which was a real problem for our client, who had a very specific idea of how things should work.
2. Twitter was amazingly easy to implement, but the population of Twitter users in the audience was much lower than Facebook, so it was deemed a less attractive solution. Also, let’s face it: When people have to say something important, sometimes they can’t fit it into 140 characters or less.
3. Synergy (ha!) Of course, combining and publishing the two disparate feeds of data was an issue. It was becoming apparent that we needed something more…

A few things that you should know right off the bat. JS-Kit Echo is not the only player out there. DISQUS Comments, IntenseDebate, and others are also worth checking out. We chose to write about JS-Kit echo because after a quick feature comparison, JS-Kit Echo fit our needs for customization, social network integration, and form. JS-Kit Echo is not free. Currently there is a 30 day free trial and then you have your choice between two plans, Echo Live and Echo Live Pro, which cost $10/mo and $100/mo respectively. Get more info over at the JS-Kit Echo site.

So, now that we know the why, let’s talk about the how and let’s jump in feet first. The basic implementation of the JS-Kit Echo comment system is about as easy as it could be. To get a working comment box on a page, you sign up for an account, associate a domain name with the account, and paste two lines of code on your site. Done.

The JS-Kit Echo framework is very customizable and covering all the various settings here would do their documentation wiki a huge disservice. Go take a look for yourself.

The Implementation

Our implementation is a little more complicated and includes a bit more wrangling. The basic premise is to allow users to weigh in on a topic by commenting on their choice in two separate threads. We wanted to provide the ability to vote and then leave a comment as to why they voted that way.

The basic layout of our two column approach includes utilizing a simple float to layout the page and placing the two JS-Kit Echo divs within. This is the basic code:


<span  style="float: left;">
<div permalink="" uniq="yes" paginate="10" ></div>
</span>
<span  style="float: right;">
<div permalink="" uniq="no" paginate="10" ></div>
</span>
<script src="http://cdn.js-kit.com/scripts/comments.js"></script>

Those of you paying attention will notice the use of the “uniq” tag. This allows the individual instances of Echo on the page to associate with a separate thread. The handy wiki pointed out using this method for our purposes.

On this site, we take a user’s vote on a previous page and pass it along to the comments page, so we wanted the user to be able to weigh in as to why they voted that way. So, when the document loads, we check a session value and set the state of the other thread to be hidden, which is to say, we simply apply a class to the parts of the Echo comment box that involve taking user input, so at the end of the day, it appears that the appropriate thread is queue up and waiting for your input, while the opposing view is simply displaying the already entered comments in a read-only state.


function hideNo(){
$('.no .jsk-CommentFormSurface').addClass('hideMe');
$('.no .jsk-CommentFormButton').addClass('hideMe');
$('.no .js-commentControl').addClass('hideMe');
$('.no .js-singleCommentReplyable').addClass('hideMe');
}
function hideYes(){
$('.yes .jsk-CommentFormSurface').addClass('hideMe');
$('.yes .jsk-CommentFormButton').addClass('hideMe');
$('.yes .js-commentControl').addClass('hideMe');
$('.yes .js-singleCommentReplyable').addClass('hideMe');
}


Where our CSS includes the following:

.column {width:338px; margin:2px; display:block;float:left}
.hideMe {display:none}


Then to wire it all up:


$(document).ready(function() {
if(getParameterByName("v") == '1') // calls a helper method to get the vote result
{
setTimeout('hideNo()',1250);
}else if(getParameterByName("v") == '0'){
setTimeout('hideYes()',1250);
}
});

Tech Tip!

You will note that we use the setTimeout function. It is important to remember that because these controls are being injected into your page, you can not assume that they will be ready for styling or editing on Document.Ready. We give the controls a bit of time to load in and then we perform our styling task.

Wrap It Up

And that’s that! After a user votes, they reach this page and they are shown the appropriate comment thread ready to receive their input with the opposing view there to encourage feedback.

In only a few lines of code, you can achieve a very robust system for storing user interaction. On top of that, because of JS-Kit Echo’s social integration, you give your user several ways to quickly identify themselves and share that comment with others.

Since all the panels up for evaluation deal in some way with nonprofit technology goodness, we’re just going to point you in the direction of what we think is a stellar line up of panels that we have submitted for inclusion. We’d love your vote — and would especially appreciate any comments on what you’d like to see in these or future panels.

Practical HTML5/CSS3 for Nonprofits (or “How to Party Like it’s 2011 When it’s Really Still 1999″)
More neat stuff is being done with HTML5 and CSS3 every day and we all want to jump on the bandwagon and make Web sites that are really, truly, awesome. But what does HTML5 really mean? Non-profits have unique technology requirements, including the need to support visitors to your site who may be browsing on really old browsers over really slow connections, so will HTML5 even be viable? (“This will work in IE6, right?”) Will HTML5 make our site work on mobile devices? Is it the Flash killer that you may have heard it was? (spoiler alert: a REALLY BIG “maybe”) Can you start using it right now? (“Please oh please oh please”.)

You can hack it… but should you?
You’re adding a new feature to your website; maybe an online community, or peer-to-peer fundraising, or better Facebook integration. What’s more expensive: investing in a new piece of software, with a new set of features, and integrating it with your existing system? Or stretching the limits of your existing system, making it meet your changing needs? Sometimes it’s worth the cost to make updates with the click of a mouse, instead of making your developer tear her hair out to achieve the same result. Other times, your tools may surprise you, and a little hacking can go a long way. Learn the tricks for extending your existing toolset, and guidelines for deciding which route to take. We’ll share examples of how tools like Convio, WordPress, and Ning can do more than you’d expect… and some cases when they can’t do quite enough.

Money for Nothing and your Software for Free
Free beer! Free kittens! Free software! We all love to get something for free, especially when budgets are tight. We dream of the product that will, like magic, solve our problems without costing a cent. (If you aren’t, your boss probably is.) But free things almost always come with hidden costs, and free software is no different. It won’t give you a hangover, or get fleas, but it could eat up your staff time, control your data, or change the rules on you without notice. This was spectacularly clear when Ning eliminated free accounts, leaving nonprofits with the choice of paying up, or losing years of hard work. Or when Facebook suddenly turned fans into “likers,” forcing page administrators to change their outreach strategy. But not all free software is created equal, and it’s not just about open source vs. closed source. Some tools give you great power – but you have to know how to use it. Others may limit your options, or ignore what you really need. But some may be just what you’re looking for. We’ll explore the ins and outs of free and low-cost software, and ask: what does free software really cost?

Guerrilla UX
While the importance of web usability is indisputable, the sad truth is that paying for usability experts, their tools and facilities often doesn’t fit into the nonprofit web budget. Turns out, it doesn’t have to be this way. You can go guerrilla with usability testing in either your approach and/or the tools you use and still achieve effective results.

Method Tweeting for Nonprofits: Much Ado About Something
When organizations use Twitter to promote themselves, it’s largely about playing a role. The person tweeting is tasked to be on message as the voice of the organization while creating a unique and engaging personality to draw an audience in. At the theater, we gladly accept this fake-me-out, but in social media where do we draw the line between being the playwright and playing a character?

Just ‘Cause: Can Technology Make Brand Irrelevant
Thanks to technology, the line is starting to blur between the power of a household name brand and the passion of scrappy mission-focused organizations. Yet when it feels like nothing short of a crisis will engage people with your cause, how do you compel them to act? The battle of Cause vs Brand is on.

Give me my computer! Photo provided by elblogazo under Flickr Creative Commons License

So a few weeks ago I started bawling like a baby about to cut a tooth when my computer began its slow ascent into computer heaven. It wouldn’t go quietly – one day it would work, the next day it wouldn’t. For weeks I bounced between machines at work, at home, even at my father-in-law’s house. And even when it finally took its last breath, I was still a few weeks away from getting new a computer, so I continued doing a shuffle between various work and home machines. In the past few weeks, I have worked quasi-regularly on seven different computers. Some stayed in my comfort zone (like my blazing fast home desktop), and some were well out of it (like the backup of the backup laptop here in the office).

I had a hard time coping those first few weeks of the great computer shuffle. But I found my own personal pacifier: the “cloud”. If I was going to move from computer to computer, I needed to start moving the basis of my operations from the thick client of a hard drive to the thin client of the Internet.

It was hard at first, but I managed, and even became comfortable, working with online services. Am I a permanent cloud-hopper? No. But I feel I can weather the crisis of a broken computer in stride now.

Here’s a look at some of the services I used:

• Microsoft Outlook Web Access – There was simply no getting around this one. I needed to check my email and update my calendar. It was nearly unbearable, but I made it through. I got by managing email and calendar, but I simply could not organize my tasks within this paltry interface.
• Remember the Milk – RTM is my lovey – now that I have it, I can’t live without it, and I take it with me everywhere. Where Outlook Web Access failed in my task organization, RTM picked up the slack and then some, so much so, that I’ve stuck with RTM. RTM allows me to quickly enter, tag, schedule, and search all my tasks.
• Meebo – Nothing was more frustrating than installing and reinstalling instant messaging clients, sometimes having my buddy list carry over, sometimes not. Meebo came to my rescue. I logged in once, and there was my full buddy list. Meebo did a great job when I was in need. But in the end, I just missed too many IMs as the client just sat in dozens of Firefox tabs I had open.
• Google Docs – While I had MS Office on every computer I used during this time, I never knew from one day to the next which version it would have, or whether I could use it to connect to our network. So any document I had to look at during this time, as long as it wasn’t super-secret or sensitive, found its way into my Google Docs. Additionally, I did not have access to OnTime, a tool we use for Bug tracking here at Beaconfire. So instead, I would use a Google Spreadsheet for bug tracking. It wasn’t ideal, but it got the job done.

R.I.P. IE6

Those of us who build websites for a living have been waiting to see the door hit Internet Explorer 6 on its way out for a very long time now. It could be that the day long awaited is right around the corner.  And it may be that that is a very big corner, and that there are traffic cops making us walk really, really slow.

My wish to see the end of this seriously out-dated browser is not purely selfish, though there is definitely a good amount of frustration I’ll be happy to do away with. Every time I have to create a separate stylesheet to control IE6′s idiotic treatment of width+margins+padding (the box model, for those in the know) I sigh and dream of a day when all browsers display identical HTML in identical ways. I want to use the more sophisticated transparency properties of 24-bit PNG graphics without having to add buggy JavaScript so that IE6 will display the transparency instead of an ugly grey box. I’d love to be able to use more sophisticated CSS3 (2 even!) to style elements without having to add all kinds of classes and ids to them. Cleaner HTML: faster to load, faster to code, easier to maintain. All kinds of better!

So that’s the selfish part. There is another part of me that knows many hours spent on a website design project goes toward simply fixing things that “break” in IE6. It’s not uncommon that, at the end of a typical site build, clients have paid a few thousand dollars just to get IE6 to show the site exactly the same as newer versions of IE or Firefox do.

For all of us, life without IE6 would be an improvement. So why are people still using it? There are a few reasons, really. First, some people are using computers they’ve had for years and have just never felt the need (or known how) to upgrade their browser. Maybe they are on dial-up modems and tying up the line for an hour or so while the new browser downloads is just not worth it.

Second, there are users who are prevented from upgrading by their IT departments. It may be that their organization relies on applications developed years ago using short-sighted programming techniques targeted specifically for what was then the best browser on the market. Allowing users of systems like these to upgrade may require a substantial investment to re-engineer those applications.

Third, there are those who just don’t care.

As someone who is concerned with the usability of the web and who wants websites we build to be usable for everyone, I have to be concerned about all three of those types of IE6 users. Ok, more the first two groups than the last ;)  Here is where things get tricky. I’m no longer talking about “looks exactly like” I’m talking about “is usable.” I want all users of the sites we build to be able to find what they are looking for, engage with the organization in all the ways that they want, and to feel that they are getting the same, complete experience out of a website that any other user of that website does.

It’s not just me either. Microsoft Australia has a campaign in which you can send sour milk to your friends who are still using IE6 to equate using nine-year-old browser to the risks of drinking milk the same age. The information on the site claims that IE8 detects malware and phishing 85% and 83% of the time, respectively, making it one of the most secure browsers available today. While its comparisons to other new browsers from Firefox to Opera may be disputed by makers of those browsers, that it is safer to browse the internet using IE8 than IE6 is beyond dispute.

As websites continue to get more sophisticated and we ask more and more of designers and developers, the need to be able to use current technologies and solutions is becoming more and more important.  HTML5 is on its way (sloooowly), and CSS3 is pretty much here.  All indications are that IE9 will support the new standards in a way that it never seemed Microsoft was terribly interested in before.  It will have to…the others are forging ahead daily and Opera, Chrome, Safari, and Firefox will likely get there first.

Keep your fingers crossed!

Recently, Beaconfire helped Legacy revitalize their website and migrate their users from Ning to the Elgg social networking software solution. Read more after the jump.Beaconfire inherited a website which used a custom application that helped smokers track their smoking habits and learn to quit. However as Adobe Flash based website, it was difficult for Legacy staff to manage their content and for users without Flash the site was not accessible. The community portion of the site was originally created using the Ning social networking platform. But with Legacy’s increasing need for the community to be more integrated with the custom application and with integration options that didn’t work for Leacy, another solution was needed.

Overall, our approach was to try and keep as much of the site’s existing and most valuable assets and build on them to create the new and improved EX site. The new site uses the RedDot (now OpenText) CMS to manage the information about triggers and nicotine addiction. The custom application powering the cigarette tracking and your quit attempts is built on a PHP framework supported by RedDot driven content enabling non technical users to manage the site. Beaconfire also built an API that allows a mobile site version and eventually and an iphone application to access the core user database to track cigarettes when not at your computer. Beaconfire also integrated Google Analytics and Omniture to ensure effective analytics tracking for gauging the site improvements.

By far, however, the most critical part of the project was to migrate the community of users from Ning to Elgg. With nearly 130,000 users in the community this is the largest Elgg site we know of. Since Elgg is open source and modular, we were able to theme the new community site to make the look and feel similar to the old Ning design so that users wouldn’t be confused when we shut down the old community. We also customized the Elgg registration system to build a Single Sign On (SSO) solution that enables users who register in the EX plan to also be added to the community and be logged in with no additional steps. After we had built the solution, we had to migrate the users from the Plan site and the Community site. We plant to describe the process of migrating the community in another post (coming soon).

During this project we learned a few lessons that will be useful for future projects. First, we have to be flexible in working with the situation at hand. In this case, we took the best assets of the existing system and built from there. We didn’t have the time nor could the client start from scratch so it was important to be flexible and creative. Second, migrating content such as hundreds of thousands users and all of their content from one system to another is not an easy task. Even when everything is understood, things can change at the last moment. We had a plan and stayed focused while handling the unforeseen. Essentially, we persevered.

We know that for those looking to quit smoking, perseverance is indeed required and hopefully with tools like BecomeAnEx.org much easier now.

Not really… but the much anticipated Google Wave has arrived in “preview” mode. When Google says “preview,” they mean “we can’t call it beta yet”, and it’s available through a limited number of invitations to people who are willing to deal with lots of bugs in order to get an early peek at this tool.

The idea behind Wave is that email has been around, mostly unchanged, for a long time – so Wave purports to be what email would have been if it were developed using today’s technology and for today’s web user. Not everyone feels that Google’s description of Wave is accurate, however. Daniel Tenner blogged recently that Wave is not communications 2.0 at all, saying:

“Is Wave the next Twitter? Nope. Is it the next Facebook? Nope. Is it going to replace Instant Messengers? Possibly, in some circumstances, but not any time soon.. I believe this is partly Google’s fault: they released Wave to geeks and hackers and social media folks first. But Wave is not a geek/hacker tool, or a social media tool, it’s a corporate tool that solves work problems (more on that later). On the other hand, they never claimed it would be a Facebook replacement or a Twitter killer.”

Confused yet? Check out a new collaborative user manual, read Lifehacker’s introduction, or Google’s hefty hour-long demo (below), and you’ll have a good idea of what it’s all about.

A few of us at Beaconfire were lucky enough to get early invites to check it out for ourselves, and we spent some time this week stumbling around the tool, learning the ropes. The result is this post, co-authored by Jo, Amadie and Tim.

Clearly Google Wave is still very rough around the edges, not yet ready for public consumption, but it feels full of potential. Lots of people have been brainstorming cool uses for it. We started to wonder where it could go – and as non-profit consultants, what could it mean for us?  So we co-authored this post (in Wave!) to think about that question.

So let’s imagine that in 5 years, Wave is the new Thing To Do on the web, it’s matured into a full-featured product, and it’s met all Google’s goals of becomingemail 2.0. (Maybe it’s Google Wave, or maybe it’s another tool with the same vision.) What does it mean for non-profits?

For one thing, the “email blast” will no longer make sense. Heck, according to the Wall Street Journal, email is practically dead already. It will probably be possible to send out static, un-editable messages, but doing so neglects the best features of the tool. Some non-profits will probably send out “wave blasts” (the same non-profits who are now tweeting their press releases), but most will be listening to their subscribers and collaborating with them on a more intense level than even Facebook or Twitter currently allow. This could be an incredibly cool thing, especially for small, grassroots organizations who really want to connect with the people.

The barrier between your website and your “email” (now Wave) list will shrink almost to non-existence. You can embed your waves in your site, and parts of your site in your waves. Conversations can take place both on subscriber’s own Wave accounts and on publicly accessible webpages, and flow seamlessly between the two. Not only that, but your supporters won’t have to visit your website to donate or take action. With Wave’s open framework, it’ll only be a matter of time before you can put a “write to Congress” widget in your wave, so users can write a letter on the spot (or even help each other write personalized letters), send it, and put their name on a list of signers that’s immediately visible to other participants in the wave. Imagine the impetus to act if you can literally watch other people taking action as you read an appeal. (You can’t do that with a Facebook app!)

Committees, boards, and affiliates all can benefit from the collaborative nature of waves. From developing agendas to conducting subcommittee or ad hoc group projects to collaborating on or reviewing white papers or other group documents, it is possible to bypass the back-and-forth emails and multiple document versions that plague the managers of these projects.

Conferences can become richer experiences, with longer lifespans. Have you ever tried to follow a conference through attendees’ tweets? A wave can organize the backchannel chatter into nearly coherent topical (and perhaps even substantive) conversations and avoid the headache of paging through endless (and often repetitive) hashtags ordered only by timestamps.

For now, those lucky enough to have received invitations are not only struggling to find enough other users to create waves with, but with what to “wave” about at all. While Google bills this as the next generation of email, it really feels more like a business collaboration tool than a 2.0 communication engine. But Wave is open source and Google plans to release the code so that you can set up your own Wave server, using whatever email addresses or usernames you want and build custom applications on top of it. Only time will tell what those applications are and whether they influence, or even change, the way that non-profits do business.