Johanna Bates's blog

Sometimes it seems like open source CMSs should "just work." Anyone who's built a site in an open-source CMS knows that that's far from true. They often need quite a bit of tweaking to get the job done. And when your org doesn't have a bottomless budget, how can you can you build the perfect site? In my experience, sometimes budget limitations can make a website better. When you have to be disciplined in your approach, it can help to clarify a project in ways that can make it more stable and more sustainable. Here are five tips for making an open-source web project manageable, affordable and successful.

1. Articulate a mission for your project. What are you trying to accomplish with this new site? If you need to reach those goals with the absolute minimum number of bells and whistles, what does that finished product look like? Start there. Write it down, and use it as a touchstone every time you make a decision. On my most recent project, our mantra was “upgrade and simplify." The goal was better information architecture in the latest version of Drupal with a clean design, pared down so that it can be enhanced in the future. Every time our team felt the allure of a big, fancy module that might solve some problems but would increase the chance of bugs, we went back to this mission statement and asked ourselves if there was a simpler way to do it. As a result, we got a more stable site. Which leads me to...

2. Build closely in alignment with your CMS’ development community. After your site’s built on a budget, chances are it will need to be maintained on a budget, too. The point of a CMS is that you should be able to maintain your site relatively easily long after the people who helped you build it are gone. To help ensure that the maintenance of your new site will be sustainable, stick close to core functionality whenever possible. When you want to add a feature, choose a module or plugin that’s heavily used. Check its bug list, and make sure it’s being actively maintained. If you really need something that’s not in heavy use, have a backup plan. Above all, try not to install anything you really don’t need. Check all desired features against your mission. Keep a wishlist of things you want if and only if there’s extra time and money in the budget. In other words...

3. Simplify. Complexity costs money. Some complexity in a mid- to large-sized site is inevitable, and when it truly serves your site’s mission, it can be a good thing. You can put the budget money toward complexity that’s needed by eliminating places where it’s not. In my most recent project, the org had many different content types in their Drupal 6 site including features, press releases and blog posts. If they ever had a good argument for why there should be so many, they didn’t any more, and the press is now used to the blog format. So they merged those three content types into a big new blog area in their new site, and they created thoughtful, flexible categories and tags to organize the posts. This single river of their most frequently updated content is, in theory, easier for them to maintain and promote via social media. Instead of dividing design and development energy across three different content areas, we poured all our time into building the blog really, really well.

4. Make sure the designer understands what CMS design on a budget means. It’s okay if your designer and builder are not the same person, or are not part of the same firm. They should have some familiarity with the CMS you’ve chosen. Most importantly, things go best when the designer is a good communicator and there’s not a wall between design and development. In my last project, my client org ran each design by me (the front-end developer) before they signed off on it. When I saw too much variance in the designs, I let the designer know he needed to make things more template-like, and he responded beautifully. Advomatic has a great post about designing for a CMS.

5. Expect things to go wrong. Especially when you’re working with the cutting edge (or, in some cases, bleeding edge) of open source, things will go wrong. If you can prepare to be flexible, make compromises where needed, and keep your sense of humor, you’ll end up with a better site, and you’ll probably learn a lot in the process.

I came across this great post by Amanda Luker of the Drupal consulting firm Advomatic: Designing for Drupal: Dos and Don'ts. It describes some key principles that designers can use to ensure their designs are reasonably build-able in Drupal: "reuse, flexibility and standardization."

It was refreshing to see this post, because, yes, almost any design can be built in almost anything. But if you're on a budget, it can be costly to implement a design that isn't "CMS aware". Can I build that in Drupal? Yes, I almost always can. Is it always a great idea? If it doesn't leverage native Drupal features in a strategic way, and its complexity isn't serving an organizational mission goal, then it's not the best use of money or time. If the design cannot be built in a way that allows for growth, flexibility and evolution, it can even get in the way of more practical, strategic innovations down the road. So though your new site may look perfect on launch day, it might not be the most excellent website you could have built.

Everyone wants a usable site, and they want it to look great and stand out. All of this is possible in most widely-used open source content management systems, including Drupal. But you can't have everything. Most organizations must strike a balance (this reminds me of Michelle Murrain's great post about the cheap, fast and good triangle). I have a client right now whose mantra is "the perfect is the enemy of the good." I really think this is true, in life, and about website building. I'd go so far that the desire for perfection can get in the way of excellence. Awesome things can be accomplished on a budget with a well-balanced compromise between design and functionality, using mission as a filter to ensure the project is hitting its strategic goals. It might not be perfect, but it can be really, really excellent.

Okay, maybe not world domination. But at least significant progress toward truly usable, community-developed software. Drupal and WordPress are hitting their stride right now. It's getting easier to build sites on a budget that orgs can mostly manage and update themselves. That's a big deal for our sector. These platforms allow our web communications to keep pace, at least somewhat, with the rest of the business world. We have to get our messages out, amid the clamor, just like everyone else, and the playing field is getting more level. Yes, we might be a bit behind in our ability to afford all the bells and whistles, but with a Drupal or WordPress site, we can blog and integrate with email messaging, Facebook and Twitter. If we know our audience and have a clear message, that's all we need in our toolbox right now.

I was working almost exclusively in Drupal for a while, and now I'm diving back into WordPress as well. Sometimes it's simply the best CMS for the job. It had been a few years since I'd last built a WordPress site, and it's come a long way. For small- to medium-sized blogs and simple websites, it's incredibly easy to build in. For content editors and site admins, its back end admin beats Drupal hands down in several areas. Of course Drupal's back end can be completely customized to be more user friendly, but when an org is on a tight budget, WordPress has much of that ease-of-use right out of the box. If all you want to do is manage a fairly simple blog or website via a browser, WordPress is stable and flexible, and more than enough power for many orgs' needs.

One of the best summaries I've ever read of the differences between WordPress and Drupal, and of how to decide which CMS to build in, is WordPress vs. Drupal... Fight! by Michelle Murrain. Here's a snippet:

Kinds of sites probably best done in WordPress:

Blogs

Community Blogs

Simple brochureware websites

Kinds of sites best done in Drupal:

Large community sites where you need different kinds of content generated by users (blogs, wikis, job postings, etc.)

I haven’t posted in a while because I’ve been trying out Drupal 7 on my personal site. Drupal 5 has been officially retired, so I thought I’d do an experiment and move my personal blog from WordPress to Drupal 7. And so far, I’m very pleased. But it took a while to get my site built, mostly because some of the modules I needed weren’t working when I started building about a month ago. There’s so much activity that modules are being updated hourly. One key module I needed was the WordPress Migrate module. It didn’t work two weeks ago, and it didn’t work a few days ago, until there was a new beta release in the afternoon. Then it worked (though I needed some help; I am lucky enough to live with a MySQL guru).

First impressions can be summed up this way: I would never in a million years have recommended Drupal 6 as a viable platform for a small blog or simple website, for example. Because with great power comes great complexity--that’s one downside of Drupal. I really like WordPress, and it’s always been my go-to for small sites. But honestly, I can see using Drupal 7 for a client’s site as small as mine, if his or her org didn’t need to rely heavily on any modules that are still in beta.

I started out trying the Omega theme, but it was overkill for my little site, so I went with Sky. I hope Sky, and more similarly simple themes like it, continue to show up and evolve, because they help make building smaller sites in Drupal 7 easier.

Here are some quick pros and cons of my Drupal 7 experience so far.

Pros

Module and theme install via the UI! In ye olden days, you had to download modules and install ‘em by hand, via FTP. Then, awesome command line utility Drush showed up, and it is amazing, powerful, and fast... but this? This is insanely easy. (Until something goes wrong, of course. <Drupal wink>)

On the modules page, there are links to the permissions and configure pages for each module. So you don’t have to enable a module, and then go hunting for its admin pages. Many click-hours will be saved.

Some useful modules, including things like Content Construction Kit (CCK) for creating custom fields, are now integrated into core.

For developers, the admin menu that comes with D7 has a flush caches link in the upper left corner. Awse!

Cons

Some of the new admin area organization confuses me. The menu categories “Configuration” and “Structure” seem a bit arbitrary. Like, to set up the sitewide contact form, I have to click on “Structure.” It seems that could go in “Configuration”. That might make more sense to me. I know the admin user interface was developed via committee. I appreciate the effort, but I feel like it might need some more work.

The default admin menu pops up as an “overlay” over your content. I wanted my old simpler surf-to-it admin experience, so I disabled the overlay on the modules page. Much better.

Like I mentioned earlier, D7 modules are still in flux. So you might want or need something only to find that it’s really not ready. One of the most needed modules that isn’t completely stable yet (still in alpha at the time of this post) is Views. Views! Yeah, that’s gonna keep me from being able to move a lot of orgs into D7.

I foresee that most new sites this year will likely still be built in Drupal 6. But I do think Drupal 7 is getting friendlier. That’s pretty exciting.

(8/25 Update: I contacted Lullabot and they say that they offer a 10% discount for nonprofit orgs. The best way to get a discount is to contact Lullabot directly.)

Though I’ve worked in many different content management systems, I’ve primarily been working in Drupal for the last four years. Since tech is always changing, a good techie is always learning. When you’re a nonprofit techie on a limited budget, it can be hard to know what learning resources to invest in. In this case, my first instinct was to turn to Lullabot—a company that’s widely considered to be the gold standard in Drupal expertise.

Lullabot has been doing Drupal for what seems like forever. The Lullabot team literally wrote the O’Reilly Using Drupal book. So I promptly went out and bought the book, because, in theory, I like the romantic notion that I am going to kick back in my home office and thumb through my library of bound technical manuals. In reality, my O’Reilly books take up a ton of space on my shelf, and I am far more likely to first turn to Google when I have a code problem rather than look it up in a book.

I’ve learned over the years that I learn best when I am as actively engaged as possible with the source material, and when I can go back again and again to review things. So I was very interested to find out that Lullabot has a series of learning videos. They’re about $75 apiece (a little cheaper when bought in bundles). I decided to take the plunge and give one a try.

My particular area of Drupal expertise is theming (and all the configuration tricks that go along with it), so the first video I tried was the Advanced Theming. After that one video, I was convinced that they were going to work for me, and I decided to get a few more them to reinforce and fill gaps in my self-taught Drupal knowledge. So I also snagged Theming Basics, and the Views and CCK bundle. Most recently, I got the jQuery and Javascript videos, too.

Each video is roughly three hours long and is broken out into helpful chapters. They feature endearingly geeky Lullabot experts who painstakingly explain the mysteries of Drupal alongside easy-to-follow screens of code. CEO and co-founder Jeff Robbins and themer Nate Haug were the main protagonists of the particular videos I’ve been using (note for others who care: the Lullabot team does have high-level women techs on it, too, even though they aren’t featured in these particular videos).

Nate and Jeff are extremely clear and methodical, leading the viewer through code, building it step-by-step and then showing the results of that code in a browser. The Theming Basics video was elementary for me, but was still worth it for the shortcuts and tips they offer there—the ins and outs of special Drupal modules that exist to help developers and themers, Firebug tricks, etc. Being a typical web junkie, I can watch them in a fragmented way, starting and stopping and coding in-between to reinforce what I am learning in a real-life context (this is particularly great now that I am working with jQuery). When they lead me to an a-ha moment, where I understand exactly how some snippet of code is put together, I pause the video and use SnagIt to make quick-reference screen captures for myself.

At least for my particular learning style, these videos are the best tech learning resource I’ve come across in the last decade of my career and I give them my highest recommendation for anyone who works in Drupal or who wants to learn. Though I’ve known about Lullabot for years, the videos have turned me into a loyal fan. I’m even thinking about traveling to one of their in-person workshops. When and if I can afford to pull that off, I’ll definitely report back.

In the interest of helping nonprofits choose the best resources to help them choose the best software, we Idealware bloggers are experimenting with book reviews. All of us were pretty excited to read the new book from long-time nonprofit tech superstars Beth Kanter and Allison H. Fine, The Networked Nonprofit. And some of us managed to read it at the same time. Here's what three of us thought:

Johanna Bates: Watch Out, "Social Media Gurus"

Blame social media itself, but there's a lot of noise out there about how to use it effectively, or whether to use it at all. The Networked Nonprofit is the definitive overview of how to navigate social media in a nonprofit organization. There are statistics and studies, along with Beth Kanter's and Allison Fine's wealth of experiences, discussion questions to guide real planning, and excellent examples. And though their prose is easy reading, they don't skimp on the nuance, which is why this is the best social media resource I've come across. Let me give an example.

Orgs often ask me about using social media tools. Some of these orgs are partially educated on the topic, but haven’t really dipped their toes in. (Kanter and Fine repeatedly emphasize that using social media personally is essential to understanding how to use it organizationally.) Sometimes, it’s presented this way: "I hear that we can use Twitter and Facebook to move our constituents from casual onlookers to donors." They’re talking about the “ladder of engagement”—a concept that has been around for years, but is often misunderstood. Here, Kanter and Fine offer the ladder of engagement as a framework for understanding how different people engage with the org via social media and “on land.” It’s not a linear progression of bystander-to-donor, but ensures that different kinds of people can engage with the org in different ways at different times. This is the kind of nuance that is captured in this book that—until now—has been hard to convey otherwise. From now on, when I start getting questions about social media, I’m sending orgs to this book first. It cuts right through the hype, and maybe it will help put some of the less trustworthy social media gurus out of business.

Having followed both authors' work online I wasn't surprised by their enthusiasm for this topic or the ambitious challenge they set to nonprofits, to not only adopt social media tools, but in fact the entire philosophy that has evolved in its wake. I think they make a convincing case that we have arrived at the nexus of the need for organizations to change their structures and ways of operating at the precise point when technology and society have realized the power of connected individuals to effect change. The message to old school nonprofits is clear: the time is now to begin a transformation and adapt or risk being rendered irrelevant in the not too distant future.

There are enough of citations, case studies, specific tools and ideas to implement included to make this book a must have for any nonprofit leader, but the real value is in the recurring themes, which are useful in both practical and philosophical ways. Try it yourself, take baby steps, get started now, plan for flexibility and don't worry too much about set backs and loss of control because control is an illusion anyhow.

The Networked Nonprofit is an even better book than I thought it would be. I thought it would have useful beginning points and orientation for nonprofits now joining the social media wave. And it does. I thought it would have more advanced lessons from larger nonprofits of the soft that Beth Kanter often brings to her workshops. And it does. What equally impressed me is that the book speaks to executive directors, community activists and others who may be used to other, older, working, even successful ways of reaching constituents. The book has a philosophical orientation: it is about “driving change.” This focus gears it particularly to nonprofit leaders and community activists grappling with where social media fits it.

Networked Nonprofit situates itself in the now: it speaks to the cultural shift represented by the emergence of the millennial generation (born 1978 to 1992). Kanter and Fine here focus less on technology and more on growing up with a different relationship to traditional organizations--more activist and engaged perhaps, but less geared toward long term ties to formal organization.

The new strategies the book speaks to blend the ground that social media technology has opened up with the particular readiness of this generation. The authors review important facts about parallel expansion of the universe of nonprofits at a time of reduced funding and yet greater needs. That is an unavoidable social context. In turn, Kanter and Fine speak of important positive factors. Notably they discuss “free agents,” individuals ready to jump into the right causes, work collaboratively and transparently. They speak about how social media can take advantage of strong constituency ties while also working well with weaker, looser ties to build a cause. The authors speak some about implications for governance, staffing and structure. That is not their main focus. Others will have to fill in those details. Their focus is on what these opportunities mean for organizations today trying to achieve social change goals.

At the 2009 NTEN NTC, there was a plenary delivered by Eben Moglen that stuck with me enough that I had to watch it a couple more times after I got home. He spoke about reclaiming our personal data from corporations, and about distributed data shared peer-to-peer by choice, by we the people who could and should own our personal data. And when and if we choose to share, corporations will not be allowed to spy on us.

Moglen’s NTC speech was enough to make me giddy with youthful, idealistic enthusiasm (an uncommon occurrence these days). Apparently, a similar talk inspired four youthful, idealistic nerds from NYU to spend their summer building a private, distributed social networking platform called Diaspora, and they raised a bunch (over $100K at last check!!) of money to do it via Kickstarter. (In an instance of non-Alanis-Morrisette actual irony, the banner ad displayed to me above that NYT article was an Adobe ad that said “We [heart] Apple.” But I digress.)

Raphael Sofaer, one of the Diaspora developers, starts out the video on their site explaining, “In real life, we talk to each other; we don’t need to hand our messages to a hub [Facebook, Twitter, etc.] and have them handed to our friends. Our virtual lives should work the same way.” So Diaspora would be a platform that you could install on your own server, and you’d own it, and use it to share as much or as little as you want. As I understand it, your encrypted data would be shared, at your discretion, in a peer-to-peer fashion with other Diaspora “nodes,” owned by others. The developers' website also claims they want Diaspora to be able to “scrape” current social networks so that you can get your personal data back from places like Twitter.

One of the main purposes of the Internet has always been about humans using computers to connect with other humans (via other computers), and social networking has clearly established itself as the current evolutionary iteration of this human instinct to connect via technology. The use of Facebook, Twitter and Google has become ubiquitous, yet many of us strongly dislike being watched by corporations and having our personal data continually scanned and mined.

Social networking platforms for private groups (online communities behind “velvet ropes”) are still lacking; Ning, which isn’t even private in terms of data ownership, failed to keep their service free, and has certainly failed nonprofits. Something like Diaspora—if it is truly easy to use, hard to crash, extremely well-designed, and truly private—could be revolutionary in this space. In my experience, nonprofits do some of their best work in small groups who are working on sensitive issues and/or with sensitive data for which they require privacy, but whose effect is dramatically increased if they are able to use technology to collaborate privately. A quick inventory of semi-private and private social networking platforms as they stand right now (feel free to add to this list in comments):

Ning and Groupsite: You can create "private," closed groups on these paid, hosted SaaS platforms, but they own your data and the software is proprietary and not open for community iteration. Oh so many issues.

Elgg and OneSocialWeb: I haven’t used these myself. This excellent critique of the Diaspora concept raises them both as free, open, viable alternatives that already exist, and asks why someone isn’t just working on a distributed version of Elgg. Good question.

phpBB: I use this to run a private group on my own (uh, virtual-cloud, so is it really private?) server. Lemme tell you, the development community around this bboard software exists enough to make it useable, but it’s (to use bboard lingo) a PITA to use.

Drupal: I build websites in Drupal, and I can say that using Drupal as a social networking platform is not yet for the faint-of-heart.

Ye olden listservs: Email discussion list software, which you can install on your own server, is still a first choice for many geeks who want private collaboration. Listserv platforms are not even close to being as user-friendly as (the plenty-problematic) Google or Yahoo groups, but they can be made as truly private as you can get.

Are these enthusiastic, eager college grad Diaspora developer-kids really going to be able to build something usable—something that can be iterated upon effectively—in three months of summer break? As they nurse their lattes in their video with that glazed, been-coding-too-long look in their eyes, they claim they will be working more than twelve hours a day to get this done. I am not sure that’s enough, but I can’t help but feel a little hopeful that Diaspora, or something like it, may be on the horizon.

Last Monday, my Gmail account was hacked. It wasn’t scraped or spoofed. I did not get a computer virus and there was not spyware in my browser. My password was not “password”; it was a random bunch of characters. Some entity broke into my account and used it to send spam messages to every single person in my contacts list. Over 500 outgoing messages were in my sent folder, each containing a single link to a Viagra purveyor.

Of course I immediately Googled my situation. When I Tweeted about it, a friend sent me a NY Times article about a Google cyberattack that had come out that very same day. The attack is said to have hit Gmail’s password system back in December, and it’s unclear how much data was compromised. The day after I was attacked, this very helpful PC World article came out describing exactly what happened to me. I contacted Google with all the details and my spam message headers. As I expected, I haven’t heard a peep back from them.

Professional techies tend to have a decent awareness of how to avoid being hacked or getting a virus. Though I don’t use antivirus software, I haven’t had a problem with spyware, viruses or spam in years. Part of why I’ve been so successful is that I moved all of my email to the cloud—via free Google Apps at my org, and I run all my personal email through Gmail. I’ve grown complacent over time knowing I have the best spam filters in the world. Additionally, when you don’t download email onto your computer, it’s a lot harder to slip up and get a virus.

Last week was a good reminder that the Internet is never safe, and that the cloud is indeed very vulnerable. Many of the 500 recipients of the spam link from my spam attack opened the link because they trust mail from me. This was pretty embarrassing, as many of the spam emails went to colleagues and others with whom I do business. There were a range of responses, too. Dozens of well-meaning “Hey, you got hacked! Do you know about it? You have a virus!” Then there were these: “OMG I CLICKED ON THE LINK OMG DO I HAVE A VIRUS HELP ME TELL ME WHAT TO DO!!!!” My favorite response was from my neighbor, also a techie: “I think you got hacked… or… were you trying to tell me something with that Viagra link? <wink emoticon>"

The hack made for an ugly Monday, and my inbox was flooded with emails from concerned spam recipients and automated bounce messages for the rest of the week. I ended up setting up an auto-responder that ran for several days. “Yes, I know I was hacked. It was just a link, not a virus. Your computer is fine. I really need to get back to work. Have a nice day.”

In the last hour, I just received a spam message from a good friend who uses Yahoo mail. It looks exactly like the messages that were sent from my account. I wonder if the hack is spreading. Giant sigh.

This year, I presented at a session at the NTEN NTC designed by Idealware blogger Peter Campbell called Earth to Cloud: When, Why and How to Outsource Applications. The room was packed. I know “the cloud” is a buzz term right now. What particularly surprised me, though, is one of the topics we talked about the most at the session: email.

There was a mix of people in the room from organizations that ranged in size very large (50-100 or more users) to very small (5-10 users). I assumed that the small and medium-sized orgs would all have moved their email to free Google Apps by now. When we asked who was still running an in-house mail server, about half the room raised their hands! Whoah. Why?

What emerged in discussion was that though many techies themselves had been sold on migrating to the cloud, they had come up against logistical and cultural challenges that have kept them from doing it thus far. Peter shared that for him, the technical logistics of migrating about 175 users at Earthjustice is part of what’s held him up, but that he is interested in Google Apps and continues to evaluate when and if it might be feasible to make a move. For all sizes of orgs who had not yet moved their email to the cloud, session attendees reported other barriers that included (both valid and exaggerated) fears about data privacy and ownership, and cultural attachments to on-site servers and desktop email apps like Outlook.

In some cases, the overloaded techies just didn’t have the time yet to make the shift to the cloud, even though they wanted to. And this was an a-ha moment for me. Yes, outsourcing to the cloud can create efficiencies that give you more time and therefore increase your staff capacity. But in my experience, moving certain things to the cloud was actually a key to my own professional development.

At my last org—where we had 6-10 users at any given time—I first (pre-Apps) moved our email server onto our virtual server with our web site. We had an on-call server admin to help us run it. But even that level of cloud needed a lot of my attention. Spambots would take our server down. V1gara blither blather would annoy my staff, and some of the explicit emails that made it past our filters were actually upsetting. I didn’t enjoy babysitting my mail server and worrying about spam. Server management is not the best use of my skill set. It ate time when I could have been learning about and trying new tech things that were a better match for my abilities.

I used the opportunity to move to Google Apps as a way to shape my job responsibilities and get rid of the ones I didn’t want. I didn’t like having to be the one to draft bulk emails, either; ConstantContact was in the cloud, affordable, and had a UI that most of our staff could use, so I got rid of that task, too. What did I gain? More time to do things that the org really needed and that also interested me—like researching social networking trends and fundraising; planning and strategizing about how best to use tech to get our mission work done; re-building us a newer, better Drupal site. I know I was lucky that I had an Executive Director who gave me the room to run and let put the time in to manage migration to the cloud and the office changes that came with it. Even though it can feel like a Faustian bargain to use the cloud—with a lot of unanswered questions about privacy and ownership—my org's programs gained an innovative edge because we had time to put energy into mission work instead of just infrastructure.

Since my brick-and-mortar nonprofit org closed its doors, I have been working exclusively virtually, mostly with people who live on the opposite coast. I have a home office in a house I recently moved in to. It's got "vintage" 1975 five-color shag wall-to-wall carpeting (really—see pic to left; that's one of my co-workers, Sadie). But even before my org decided to close, we decided that if we got enough funding to keep our programs alive, we'd become a virtual office to save money, building on a fairly flexible office culture that had been evolving for years.

We were a small organization and most of us were parents. Our workplace culture was one in which we trusted each other to get our work done, even if it wasn't always between 9 and 5. The org made lots of space for people to take care of themselves during the work day—to go to doctor appointments or a kid's event—as long as we got our work done somehow. I telecommuted from time to time, sometimes for a couple months at a time, especially in the early days of parenting. It was a kind of informal flex time, which NPR reports is an increasing trend in some sectors and can allow for a better work-life balance. For me, working flexibly and virtually in this way has definitely improved my quality of life.

Since I work in tech—obviously a type of work conducive to the virtual/flex office—I am aware of more and more virtual orgs and companies as broadband becomes more ubiquitous, and as more people use telecommuting and flex time for various reasons. Some pros and cons...

Pros:

No commuting required. Ahh, so nice.

If you do advocacy work, or promote/cover events, you can use a virtual office setup to work and live blog/Tweet from the field. When appropriate, this can be a great way to promote your cause and engage constituents.

You can work in your pajamas, outside, in front of the fire, in your favorite cafe, or while you're waiting on the bench at the Department of Motor Vehicles.

My favorite pro: you can take breaks to exercise, walk, see a friend or your partner or child, take photographs, or make something. This requires some self-discipline, but the payoff is worth it.

You can work anytime of the day or night, not just 9 to 5.

Cons:

You can work anytime of the day or night, not just 9 to 5. Work and life boundaries can be hard to maintain if you're not really disciplined about it (I am not yet there, myself).

No face time and no spontaneous hall chats that lead to brilliant work-related insights (and fill the need we all have for socializing).

Here's my toolkit:

Laptop, smart phone, and broadband, obviously. I live in a rural area, so I don't take those last two for granted. The town next to mine has no broadband and no cell phone coverage, and a lot of people who work virtually in cafes and libraries as a result.

Telephone & web conference/meeting software: GoToMeeting or ReadyTalk are the two main ways that I have work meetings with my co-workers.

Jing and SnagIt for screen casting and screen shots, respectively. These helps me communicate in certain situations when I would otherwise call a co-worker or client over to look at my computer screen.

Collaboration Software: Basecamp, GoogleDocs, GoogleGroups, CentralDesktop (an alternative to Basecamp), Redmine (open-source ticketing and wiki collaboration software), Groupsite (fancier Ning; hosted social networking, document sharing and collaboration software). These are absolutely key for sharing files and communicating about and managing projects with a group of people.

Instant one-on-one or group communication: Twitter, IM, Yammer and Google Buzz for instant private group convos. Yammer is my new favorite; you can set up a private Twitter-like group, share documents and images, and communicate socially and about work, almost like a virtual watercooler. For me, IM, Yammer and Twitter can help replicate that missing co-worker hall-chat epiphany experience (and some of the socializing).

Are there other virtual office workers or telecommuters out there? If so, what are the best tools in your toolkit?