In a few weeks we will release the next beta of Open Atrium. This will be our fourth beta, and it will have a bit more meat than some of the other releases, which I’ll go into later in this post. So far Open Atrium has been downloaded more than 80,000 times, and this number, and all the attention it has received, has both exceeded our expectations and validated the work that has been done so far.

However, we still view this as beta software. We see a lot of room for improvement and have a lot of ideas about how we’re going to make Open Atrium better. Its other users do as well, and on Community.OpenAtrium.com people have posted hundreds of feature requests, bug reports, suggestions, and support requests. This feedback has significantly influenced how we think about Open Atrium and how we’ve approached development. It has made us think long and hard about how Atrium is built and what changes in the underlying technology are needed to make it better.

Because Open Atrium is a platform that we build on we need it to be as stable and extensible as possible. This means avoiding duct tape coding. If a problem stems from a contributed module, we deal with the problem upstream rather than writing complex workarounds in Atrium’s code. We go after the bigger problem. This makes Open Atrium a stable base to build on without having to ‘un-code’ anything when we develop custom Open Atrium based applications for clients. For the Open Atrium project, it means that we’re not going to shy away from upgrading the internals of Atrium — at least not during the beta cycle. It also means that upstream bugs will sometimes persist in Open Atrium until there is an upstream solution.

Before I go into some of the changes that you’ll see in Beta 4 and beyond, there have been some development process changes made in anticipation of beta 4 that effect the project as whole.

We are opening up our development process. It’s a bit of a mental adjustment for us to take a project that has been internal for so long and make it truly a community effort, but we’re resolved to do just that. We’ve had the issue tracker up at Community.OpenAtrium.com for a while now, and it has been absolutely invaluable. Recently we moved our development discussions to the public IRC channel #open_atrium on freenode.net. With a project like Open Atrium there’s a challenge to properly segment support and development communications channels and things are currently still a bit mixed, so expect more changes as we sort it out and give everybody a place to find what they need.

We’re now using [drush make](http://drupal.org/project/drush_make). When we first released Open Atrium, there wasn't infrastructure on Drupal.org for packaging install profiles. This has changed. Back in October I blogged about how we were using the new packaging system for Managing News, and now we're going to do the same for Open Atrium. This means that the monolithic repository that is the current home of Open Atrium is deprecated and will be phased out. (Kudos are due here to Mig5 for kicking us into gear on this one!)

As we’ve done with Managing News, we will move the Open Atrium install profile to Drupal.org. It’s not there yet, but we have a placeholder page up which will be its new home. This means we’re also going to rename our install profile. It’s currently called atrium_installer. This ill-conceived and overly descriptive name will be replaced by the more searchable and predictable openatrium. This will make the upgrade from Beta 3 to Beta 4 trickier than usual, but we're working on a plan to mitigate that.

Now to delve into the changes to Open Atrium itself. Some of these changes will be in the next beta release, and some are longer term pushes that we’re looking to achieve before a 1.0 stable release.

First, we’re looking at ways to make the branding and terminology in Open Atrium clearer. There is language in Atrium that only makes sense to Drupalers and some that really only makes sense to Atrium developers. One of the biggest offenders is the Documents feature, which is sometimes described as a document repository and sometimes as a wiki. Depending on how you understand those terms, you could see it as both or neither. So, we’re going to update the feature’s terminology to make it more intuitive and hopefully less confusing.

There are also several aspects of the user experience that have pretty obvious avenues for improvement. The Dashboard feature has been on this list for a while. Thanks to some help from GoingOn, the dashboard will be drag and drop in the next release. We’ve also re-thought how settings are stored and how blocks are related to the dashboard so that it is now more extensible and generic. This made it possible for us to easily adopt a new interface that’s more intuitive and fun.

This update to how dashboards work also gave us a new tool to improve the User space in Open Atrium. This is a section of the site that includes pages related to a user — their profile, calendar, blog posts, and so on. This was initially conceived as a way to learn more about a user and what they were up to on the site. But it became clear that this use case was actually pretty rare, and that it was much more common for users to want a place to go and in a glance see what’s happening on the site of interest to them. In other words, they want a dashboard. In the upcoming release, we’ve been able to leverage the new dashboard functionality and provide users with just this — a place they can configure to show them whatever overview of the site they want.

Open Atrium’s administrative interface has also gotten a facelift. Young blogged about the changes to the Admin 2 module a couple months ago, and these improvements will be in the Beta 4 release. We expect them to make administering Open Atrium considerably easier and faster.

There are even more other UI improvements in Beta 4, including a new header design.

Aside from these UI changes, Beta 4 will contain upgrades to Open Atrium’s core API modules. A big one is the Spaces module, and Young blogged about the new version of the module here. These changes make a lot of the UI improvements possible. Another example is the Strongarm module, which enables many of the improvements in Spaces and which I blogged about here. This is also a great example of Atrium’s adoption of the Ctools module, which is a collection of developer APIs that provide standard ways for doing certain tasks. Getting to use these in Open Atrium means we get certain functionality for free, and in Beta 4 it’s how we handle certain functionality across the board.

The Context module has also seen a rewrite, with updates to both the UI and the internals of it. For the UI improvements, we’ve taken into consideration feedback we’ve gotten from users and have made changes that will hopefully reduce confusion. We’ve also re-factored the internals to take advantage of Ctools.

There are a few other things worth mentioning, even though they will not make it into the next beta release of Open Atrium, that we’re working on and consider goals for the 1.0 release.

• Further improved l10n support

• Improvements to the Calendar feature to better support all day events and timezones

• A rewritten Case Tracker that can handle customization per group and has significantly better notifications

• Improved accessibility, particularly compatibility with screen readers

• Reduction of the memory footprint of both normal page loads and the install procedure

I’m really excited about this release. We’ve replaced and upgraded a huge part of Open Atrium’s core based on the community’s feedback and our own experience deploying and building on it. The UI changes should make the day to day usage of Open Atrium more fun and the under the hood upgrades will make it more extensible for developers.