 Hi, everyone. Thank you for coming to this session. We're going to be talking about the ACLU website and how we use Drupal. For those of you who were at the non-profit session yesterday, we talked a lot about wanting more case studies on the web and being able to see what other non-profit websites have done. So here is a case study about the ACLU. So I'm Jenny Horman. I work at the ACLU as the associate director of IT for internet technology, which basically means that I manage all of the technical backend stuff of our website and all of our online interactivity. I am Marco Carboni. I am the technical lead at Abomatic. And we are a Drupal shop that specializes in non-profit organizations, unions, and other progressive causes. And I worked on the initial planning and build of the ACLU dot org site about three years ago. Yeah, and we've worked with Marco and the team at Abomatic pretty much consistently since we first conceived of our redesign and an ongoing support and development capacity over the past several years. So we're going to be talking today about why we went into a new CMS and why we chose Drupal, what we've done with Drupal, and what we're going to be doing in the future. So feel free at any time to interrupt, ask questions, whatever else like that. And then we can do questions at the end as well. So why we needed a new CMS? Basically, one of the major drivers was there was a planned redesign of the site. You can see here what our old site looked like before the redesign. What you don't get a good sense of is the fact that this was really, really narrow. It was designed with old computers in mind, without a lot of pixels. So it's a very narrow column, which didn't give us a lot of space to do things on the actual site. We also had exceptionally little flexibility in the templates given the content management system that we were using. We really couldn't ever edit anything on our own. We just had to stick with exactly this layout. One of the major problems that we ran into is if we ever wanted to do some kind of splash page or highlight something in a much more focused manner, we had a lot of difficulty doing so. For example, we had a big campaign several years ago called the John Adams Project, which discussed our willingness to provide legal counsel for inmates in Guantanamo. When we first announced this project, which got a lot of press and we wanted to make sure folks were aware of what we were doing and why, we wanted to basically take over the entire homepage with a John Adams splash page. That wasn't possible in our old content management system. We had to do this really sketchy hack, where basically our old content management system was a hosted content management system where you would enter the content, like on a web page, and then it would actually compile it, generate HTML, and push the HTML to our web servers. So for the John Adams hack, what we did was we said to everybody in the organization, stop publishing content, don't push anything new live, we're gonna actually go into the servers and manually overwrite the HTML files with this John Adams splash page, which worked, but kept disappearing if somebody forgot to publish new content. So we were in a position where we really couldn't do a lot of the things that we wanted to do on our website. We also suffered from extremely slow publishing because of the structure that I just described. Basically, everything in the site had to be published from the hosted solution, which was the content management system, and then copied into our web servers. And it would not only do it once per page, it would do it for every page reference. So if you entered one page, if you updated one page that happened to be used throughout the site, it would regenerate thousands of pages, which meant if you were adding a menu item or changing the terminology on a menu, it could mean that it would take thousands of page publishings for things to actually go live, which could take hours at a time. And given the fact that we're an organization that is very responsive to breaking news, we often want to publicize an upcoming vote in Congress or something like that or let folks know about a Supreme Court decision that was just made. It's definitely not ideal for us to sometimes face a several hour lag between when we get the news and want to put it on our site and when it could actually go live. All of this ties into the fact that it was a proprietary closed system. Even though we had some technical expertise in-house, we couldn't actually do anything with it. We couldn't edit any of the architecture ourselves, we couldn't change the templates ourselves, we'd very little flexibility and very few options on what we could do. And then one of the more minor concerns, but over time increasingly concerning, is that the URL sucked. Look at them. They're just not helpful for anyone to know what page they're looking at, what it's talking about, or to help the Google find us and everybody wants the Google to find them. We also had, we started undertaking this redesign in the late 2000s, mid to late 2000s and as with a lot of other organizations, we were having an increasing growth in both the technical savvy within our organization and the amount of content being created specifically for the web. So we had more and more editors who knew more about the web, wanted to be able to do more things and were pushing us to do more things as well as more content being created throughout the web, for the web specifically. So instead of just press releases, which as an organization we have historically loved to do, we also did a lot more content that was supposed to be more dynamic and specifically for the internet. One of the major problems with this though is because the old system did not have a lot of built in dynamic behavior or flexibility, we actually had to manually update links. So for example, if we wanted to put up a piece of content that was related to the women's rights project, we would need to go into the women's rights project page and add a link there and then find all the other places where we thought that might be an interesting reference and manually add a link there. So it ended up being a huge process to be able to get a site that was well linked and well integrated. It's totally manual more or less. And finally, we're the ACLU. We care a lot about privacy and security. We take constituent privacy very seriously and we have a lot of unusual requirements around that. For example, we don't use permanent cookies. I think we and the EFF and the federal government are pretty much it who don't do that, which means out of the box, most systems don't support that. I spend a lot of my life talking to vendors and saying, no, really, we honestly can't use permanent cookies and being able to have direct control over our privacy and security and be able to make that fit to our system based on our needs, which really important to us. So given all of this, Drupal obviously came up as a promising alternative to us. Beyond being able to remedy some of the concerns that I just raised, we also had existing technical knowledge in-house. We have web developers who are here, Awakash and Mariam, if you wanna ask them questions. And they had expertise already in the LAMP stack. Now we didn't have Drupal expertise in-house, but with Apache and PHP knowledge, it's a pretty easy transition into Drupal. We also really, really like the ability to have flexible modules and be able to do customizations. We change our minds a lot, like a lot of other organizations, and we want the ability to make things work the way we want them to work and being able to actually get in there and do customizations was super appealing to us. And then we also really like the idea of both being able to evolve the system with the community and participate back in the community. And to go back to the cookies example I mentioned earlier, we created a workaround for cookies which has now been actually wrapped into the Drupal 7 core. Another thing that appealed to us was the ability to do multiple themes and different look and feels within one overall system. You can see here, that's what our main website looks like now, and that's what our blog had looked like. We wanted to be able to maintain a distinct look and feel for the blog because it was a redesign that we had done not long before we launched the overall site redesign and we wanted to make the blog have a distinct appearance but still have content integrated throughout the site. And Drupal did that really naturally through templates. And finally, as a nonprofit, cost was super appealing. I know Drupal is free as in puppies as opposed to actually free, but no matter what system we're using, we're gonna have to have maintenance and support from some vendors somewhere. Drupal, because it did not have licensing fees, it made that substantially cheaper for us to undertake. And not only does that save us and our constituents money and allow us to spend more money on things like, fighting cases at the Supreme Court, it also gives us more flexibility to do more interesting things with the money that we're spending. So what have we done since we've been on Drupal? The very first thing we did was implement a total site redesign, which if you remember what the previous site looks like, this is quite different. One of the great things about it from our perspective is it's a mix of manually curated content, which is highlighted, and that's the marquee that you see where it says the need is great. That's all stuff that our editors can specifically choose to highlight, add an image, add additional links to go to the content. And then the block below the ACLU updates block is a totally dynamic block. So anytime a user adds content to the site, as long as they check a checkbox saying that it's okay for the homepage, it'll show up there in reverse chronological order. And you'll also see that we have different ways to filter that information as well based on the type of content you might be interested in. So if you wanna see the most recent multimedia, there's a tab to enable you to do that. We also have site-wide features, so going down the right rail, we have the standard, you know, join now, give us money, take action, et cetera. We also have a persistent site-wide block to allow folks to take action on a specific issue that we wanna highlight for. We often have advocacy actions that we really want to get folks participating in, and this gave us a great opportunity to do that. And then we also have the ability to give folks the option to find their local ACLU affiliate. As you might know, I represent the national organization, but there are 52 affiliates throughout the country, and they work on state-specific issues, so we wanna make it easy for folks to find the affiliate that they might need to reach out to. And I'm gonna pass over to Marco to talk about some of the other stuff we've done. Thanks, Jenny. I'm gonna talk about a couple other things we did in the initial build. So, of course, one of the biggest challenges of moving to any platform is content migration, and so, in this case, we had about 15,000 content items that were mostly on the proprietary CMS that the ACLU was on before we got involved, and then there was also some content in the separate WordPress installation that they used for their blog. So, for this build, we created a custom migration script to bring in 13 content types and then also various static assets, like files, images, media. Now, these days, if I was doing this today, we would use the version two of the migrate module, which makes this a lot easier. It gives you the ability to do things like do a migration and then roll back. Much more easy to organize your code. But, back then, that was not available, so we did it custom. We also had a separate WordPress migration script that we, there's several modules out there actually that integrate with WordPress. I hope you migrate the content in. There's also one nowadays that integrates with the migrate module. And, of course, Jenny was showing you the ugly legacy URLs earlier. Fortunately, they had a unique ID in them, so we were able to write Apache rewrite so that any URL that was stored in Google would redirect to the new URL on the site. So, when we were doing the initial planning, we had to come up with an architecture that matched the complex organizational structure of the ACLU. So, we came up with a hierarchical system of campaigns, projects, and issues that matched how certain processes happened at ACLU. It's never a perfect fit, and there were definitely some challenges, but they have separate projects at the ACLU, such as women's rights, racial justice, national security, so we use that model to organize content, and then on the site, we can display content that's related to those projects and issues. Now, it wasn't just a simple taxonomy situation because there's a lot of metadata associated with those. Each project has an image, a description, and a bunch of other information, so we had to store that in nodes. This is Drupal 6 we're talking about, so we didn't have the ability, like we would today, to have an entity system where we could add fields to terms. So, we did that on a node per node content-type basis. So, here in this example, we're looking at the women's rights project page, and then below that, there's related content that's being pulled based on cases, and news items, and multimedia items that are also with the women's rights project. And then we had to come up with a complex permission structure that allowed the ACLU to create content, manage content in these individual projects. So, this is a bit of a challenge because there's multiple sort of node permission settings that we needed to have for multiple modules, and Drupal, even to the stay, kind of makes that a bit of a challenge. So, we needed to have multiple level of permissions for super users and admins and publishers and writers, but we also needed to be able to restrict those permissions by a section. So, for example, the LGBT project, you'd have certain employees, staff members, who could only publish content in that project. And then we also had the ability for certain staff members to be writers, so they could write drafts, and then publishers would be able to approve those drafts. So, the obvious solution to that in Drupal 6 was to use the workflow module, which lets you set up revision states, and then there's the workflow access module that lets you create permissions based on who can move a piece of content from a draft to a revision to needs review to published. But we also needed another node access module that lets you manage permissions sort of on the project issue campaign hierarchy. So, there's a module out there called Taxonomy Access that does this. We had to build a custom version because we were not using terms directly called, it was an ACLU project-based module. The challenge is that Drupal doesn't make it easy to have multiple node access modules. What it does is, if one of the modules gives grants permission to a piece of content, then it doesn't care what the other module, what the other access module says. So, in this case, if someone was given the access to the LGBT rights project, it didn't matter whether or not they were a writer or publisher, they could just do anything they wanted. So, we had to make sure that those were not an OR condition, it's an AND condition, you need both permissions. So, for Drupal 6, there's a module called Module Grants that does just that, and it's kind of ugly in how it does it, but it has to sort of clobber some fundamental Drupal access code in order to do it. These days in Drupal 7, there's actually hooks now that let modules alter that process. So, these days we would use something like the workbench moderation and workbench access modules that would give us exactly what we need without clobbering any core menu items. So, in addition, we wanted to be able to pull content from external sources, so ACOU uses or has been using Convio for a lot of their external actions and activism tools. So, we created a couple feeds, or ACOU created a couple feeds that generate actions categorized by the projects and issues, and then we use the feeds module to pull those in as actions that can appear on the site. So, we pull them in as Drupal content, but then when the user clicks on the action, they get sent to an external Convio action page. And of course, like any good site, we had a media center. The media center has various categories, is videos, which we use YouTube and other providers, slideshows with Flickr, podcasts that are custom audio, and then interactive media, which are like custom JavaScript applications. Aaron Winborn, who's one of the maintainers of the media module, is that abomatic, so he was heavily involved in crafting a very state-of-the-art media center, making the process for editors to add media very easy. And I'll get to that in a second, more on that. So over time, of course, the ACLU has additional architectural needs, and Drupal makes it really easy to add new content types and to integrate that with the architecture we already have. So for example, recently they've added the concept of features, so we were able to create a new content type for that, create a new ACLU features page, and then make it really easy to pull related content based on those features. So during the process of the initial build and also in the year since when we've been adding new features, we've made several community contributions back to the Drupal community based on the work that we did for ACLU.org. So Jenny touched upon earlier on the privacy customizations. So YouTube, for example, when you embed a YouTube video directly, it adds a cookie, so this is a problem. And actually the EFF, the Electronic Frontier Foundation, who's doing a talk later today, they came up with a solution to kind of show a thumbnail image of the YouTube, and then when you clicked on it, it actually, you warn the user, if you click on this image, you're gonna get cookies, you know, you've been warned. Then when they clicked on it, it would embed the video and they get the cookies. Since then we've been able to do even better than that. One of our contributions was to integrate JW player with the Meteor module, which was the embedded media field module in Drupal 6, so that the JW player can play YouTube videos without cookies. Also we needed to be able to tell Drupal not to set permanent cookies. Now this was not doable in Drupal 6 without making some changes. It adds several cookies, including session cookies, but you have anonymous users that have a session cookie. So we had to replace the session modules to avoid that permanent cookie and also a couple other additions so that some JavaScript cookies and stuff didn't get added. And actually we blogged about that at aphomatic.com slash drupal-privacy. And the work we did there was incorporated into Pressflow, which was a Drupal fork that had performance and security additions and that work actually got melded into Drupal 7. So this is now something that you can do. You don't have to have cookies, session cookies with anonymous users, which is a performance boost and also a privacy boost. As I mentioned, Aaron Wimborn is a maintainer for media and embedded media fields, so we've made several contributions in that area. Flickr photo sets, the JW player integration I mentioned before and a lot of accessibility changes like captions on videos and also making JavaScript optional on certain media functionality. And then just various patches to Drupal Core and contributed modules as we find bugs. I mean, this is the great thing about developing for Drupal is being able to do that kind of thing. All right, back to Jenny. So besides the redesign we initially did in November 2009, we've also been able to refresh and basically using the exact, the same architecture provides some site redesign improvements. So this is what the site basically looks like if you go to it now, which is a refresh reconfiguration of how we were looking before. So if you remember what it looked like previously, you'll see we actually have an additional rail in the middle there, which allows us to more prominently highlight videos and podcasts to our users. We've tightened up the site so there's less white space in it. There was quite a bit of white space in the old design and we've changed the block below. So instead of being able to filter by specific types of content, initially we actually have those pushed below so we can highlight a little bit more things above the fold. In case you guys don't know, a lot of ACLU supporters aren't necessarily the youngest and most tech savvy folks. So we tend to get a lot of people with smaller screens, older browsers, all of that kind of stuff. So we try to keep as much high up on the page as we possibly can. We've also added, as Marco mentioned, one new content types we added not long ago was features, so we wanted to highlight that on the homepage. Features are one of our attempts to try to move a little bit away from strictly adhering to the ACLU organizational structure and instead talk more about the kinds of issues which are happening. The kinds of issues that are going on in the news and how people are discussing it there rather than just how we organizationally allocate that. So you'll see, for example, one of our features is private prisons, which is something that the ACLU is active and advocating against because it's bad. As well as know your rights, which is a big campaign we have about different, for different users, different types of folks to know what kinds of rights they have to take photographs of police and in other situations like that. So that's another way for us to try to bring people into the site and educate them about what the ACLU is doing in various areas. We also underwent a major blog redesign which launched last month. You can see on the top what the blog had previously looked like and as I mentioned before, that was a design we basically ported in whole cloth from WordPress. So that design, as of this winter, was probably about four or five years old and looks a little bit dated. The new blog redesign on the right, it looks a lot more up-to-date, it's a lot more consistent with our current site so it has something of a different look and feel but it keeps the main site features. So you still know that you're in the ACLU experience and all of that kind of stuff but you also know that you're in a blog. And again, we added a couple of different content associations for this. So the trending topics block that you see there, it's very similar to the features that I was talking about earlier. It allows us to give a way to associate content with things that are going on more actively in the news. So for example, wireless wire tapping or indefinite detention are things that are being discussed a lot right now in the news. There are issues that the ACLU works on actively so we wanna make sure folks know that we're doing it and what resources we have available on those topics specifically in the blog. We also introduced the concept of channels which is going to give us the ability to have different voices within our same blog. So we have a Washington legislative office which focuses predominantly on lobbying and those kinds of efforts and they really know what's going on in the Hill in relation to our issues. So we want to be able to give them a space to talk directly to folks who really care about the more Capitol Hill aspects of the work that we do. We're also gonna be expanding this to add a blog channels focused specifically on technology issues since that's something that we do a lot of work on and the blog is a natural place to highlight where we do that. You'll also see that we're more prominently focusing on how to share things because since 2012 we want people to share things on Facebook and stuff and we have a much larger hero image to engage folks more. The other cool thing we have is on every view of the blog you can tell, you can flip to the most popular or most commented. Right now we're not getting a lot of comments but we're hoping to enhance our commenting functionality over time and get more people to actually comment on our work and engage with our work with us and we're hoping that that can be a means to help drive that. So one of the other things that's great that we've been able to do since we've been in Drupal is actually do some in-house development. So as I mentioned before, we weren't able to touch anything. We pretty much had to always go to our vendor and say please add a block here or whatever else like that. We can do that now and we've been doing more and more of that. We in-house can do refreshes and updates, bug fixes, change requests. There are some specific menus on the site which have been renamed about 20 times in the last few months so we're really good at renaming those and lots of other things like that. It's nice to be able to have the flexibility to do those things in-house without having to go externally to do them. We've also done a lot of multivariate testing. Again, because we're privacy conscious and all that stuff, we can't use Google Optimizer which I know is what most nonprofits use. We use Omnitur's test and target instead but that still works nicely with Drupal and works well with our overall implementation and we've been able to do multivariate tests on donation path, donation link placement and terminology and we're planning on doing more in the coming months as well and beginning to do it not just on donation and fundraising but also looking at it on click through and that kind of stuff. We've also implemented several microsites in Drupal and we're actually gonna be launching another one probably in the next couple of months. I've got here a screenshot of the torture report which is one we launched maybe a year or two ago. Again, developed in Drupal 6 and it's focusing on our investigation of the torture programs that were conducted under the Bush administration. What was interesting about this project is that the idea of it was that it's actually kind of a book being written live on the web so we worked with an expert in this field who was generating basically a chapter every few months and as that chapter was developed he would post it on this site and then there was a group of experts in the field who also gave access to the system and we wanted them to be able to basically annotate the chapter as it was going up so they could say oh this incident that happened here there was another very similar incident that happened there. So we built in support for kind of inline annotation that the experts could basically do while the chapter was being written and then we also had comments so folks who weren't necessarily part of that group could comment on the chapter as well. So one of the major new projects that we've been working on and that we're hoping to launch in the next couple of weeks, Touchwood is a replacement of Convio. So as Marco mentioned earlier we've used Convio for all of our online interactivity donations, advocacy, petitions, legal intake, et cetera and we're moving into Jackson River Springboard system which is actually a best of breed system rather than a one size fits all solution as Convio is. Our donation forms and petitions will be in Drupal our advocacy actions will be in CapWiz and email will be being sent out of a system called Exact Target and all of the data will be joined together in the backend in a sales force, ECRM backend. One of the things that's really appealing to us about this is that once we launch we'll have exactly the same control over our donations and petition functionality that we do over the rest of the site which means we'll really be able to control exactly what fields show up, how the fields show up, where on the page they show up, the different layout, all of that kind of stuff. Those of you who have worked with Convio know that you get a set number of options or you could use the API but we don't have the built-in flexibility that we will have once we're fully in Drupal. So donation forms and petitions will use web form and the UberCart modules and the thing that's great is we basically leverage our existing Drupal infrastructure for all of that. So our themes, we won't have to update them now in two systems, we'll just need to update them in one system and that will apply everywhere and the existing infrastructure that we already have around permanent cookies, around users, around login security, all of that kind of stuff will work out of the gate because we're building into our existing infrastructure. There's also gonna be a couple of syncing processes that we have to set up. There's syncs between Drupal and Salesforce which is part of the standard springboard implementation and then we also had a custom module implemented so we can do a sync of all of our donation records between our donor database of record which we use PIDI for that. And that's actually a Drupal module which generates a GIF sync file which will then export out into our donor database of record. As I mentioned, the form we can feel will now be seamlessly integrated with the rest of the site but we also will have the ability to support affiliates. So right now we have a program with about half of our affiliates where they participate in a shared email marketing program which means we share a list, we share a commitment to user privacy and we share expertise on how to create forms and best practices and all of that kind of stuff. The affiliates once we launch on springboard will have direct access to our Drupal backend and be able to create donation forms, petitions, event registration, all of that within that system but it will look like them. So there's been a PageRapper setup built in that allows you to apply the affiliate look and feel around the form so they can still maintain their distinct branding. I don't know how well any of you know the ACLU and our affiliate relationships. We love our affiliates but they're all very independent so it's important that they can maintain that independence. Confirmation pages have been configured for all of this which are not actually separate nodes but generated as part of the existing node and they're automatically sent email confirmations as well. The other thing that's cool is it will be able to generate our own templates for petitions and other types of forms. Again, those of you that are familiar with Convio know that for example for advocacy actions you get a set of layouts and themes that you can use and you can't really vary from that unless again you wanna do the API implementation which is feasible but is some work. We'll be able to actually generate our own templates and themes within Drupal and have those applied which is very exciting for us and one of the things that we're looking forward to doing is trying to do a lot of testing to figure out what do our users respond to both in terms of what data we collect from them and how we present that to them and it's something we're excited about trying to figure out so we can optimize that path for our constituents. One of the other projects that we've worked on has been a updated search for torture FOIA documents so again one of the major areas in which we work is in investigating the torture programs that went on under the Bush administration and we have an existing search which you can see on the side which basically it tries to expose to users what FOIA requests have yielded so we've, I don't know, 15,000 documents or something like that that we've gotten from FOIA requests related to the torture programs and we want those to be accessible. We think that that kind of transparency will help people in being aware of what's going on and prevent it from ever happening again. That search on the left that you see or right rather is super old school. It's basically a custom MySQL database with some PHP in front of it and doesn't have very many fields and all of that kind of stuff so what's been implemented and we're hoping to launch probably in the next couple of months is a new search using Apache Solar which you can see on the other side has a lot more facets and all that kind of stuff and Mark could jump in about how that actually works. This is an ideal test case for Apache Solar because not only is there a lot of content we have thousands of these torture documents that some of these documents are hundreds and hundreds of pages long so you wouldn't want to use your Drupal Core search system for this and on the far right there you can see some of the facets that we're using for the search. It's out of the box Apache Solar comes with some really great facets like you can use taxonomy, you can use content type but it's really easy to customize these facets for your needs so we have a date facet there instead of showing the number of documents and parentheses that you could find we have this little bar graph that's easy to navigate and if you click on a month there it actually updates and it becomes a, I'm sorry, if you click on a year there it updates and it becomes a per month bar graph and you can kind of dive into document searching that way. We also have these really deep hierarchies in terms of who are the officials on the torture document, what were the interrogation methods used and it's hard to tell here but you can kind of open multiple levels of that taxonomy to really dive in deep into what you're looking for and then right above the date bar graph there's a little advanced search form that expands and gives you a bunch of different filters like autocomplete fields so you can search for a particular official, you can do date ranges and all of this is using solar but it's sort of like on top of the existing solar what comes with the facet blocks that I provided come, sorry, the facet blocks that come with solar we've built some functionality on top of that to customize them for this particular search so it's great, I mean it's really fast and it gives a really good UI experience for the kind of people using this site which are people, you know, researchers where you really need to get deep down into the data. Yeah and one of the other things that's great about the autocomplete that Mark mentioned is that a lot of the names who are in here they might have multiple aliases or they might be known by titles as well as by names so the autocomplete actually will prompt for, will try to look for any of those variants and then if you search on one it'll search on all of them so it allows you to, you know, maybe know only that it was the secretary of state who was involved in a specific memo or something like that. If you search on that it will search on the specific names that are associated with the secretary of state. So it allows, like Marko said, for folks who are really knowledgeable about stuff to do a lot of searching as well as folks who are less knowledgeable which is exactly what this, we want this to be. We want it to be a tool that can be used by scholars who are researching this and other advocates in this area as well as a way to expose to the general public hey this is what went on and we're actually hearing this from the horse's mouth. So for future plans obviously we want to upgrade to Drupal 7 or still in Drupal 6 like many other organizations. We're probably gonna take that as an opportunity to reevaluate our current information architecture. As Marko talked about right now the core of our information architecture is around the campaign project issue hierarchy and that's something as an organization that we're beginning to move away from. We're trying to become a bit more lateral. There have been some organizational changes that are in support of that. So we're probably gonna reopen that conversation and see if it really makes sense to continue working with that campaign project issue hierarchy or if we want to move to something more like a taxonomy or something like that. No matter what we do we'll probably still end up being a pretty structured information architecture because we work on so many different issues that we need a way to guide our users through what we're actually doing because otherwise it just becomes a massive content that has thousands of potential tags and overlaps that can be very difficult to navigate through. We're also looking at doing redesign refreshes of various areas of the site. Again, this will be kind of in line with what we did with the homepage which won't necessarily be predicated on the triple seven upgrade or an architecture review but we'll just make the look and feel a little bit fresher. So we're gonna be looking at the multimedia center this year, the action center which is where we highlight our actions from previously can be assumed to be springboard. We're also looking at as I mentioned earlier enhanced commenting functionality and probably some other site areas. We might enhance the features area, that kind of stuff. And then one of the things obviously that we need to get more into is a mobile program. We're hoping to both do a mobile version of the website maybe using responsive design so it can be, it can respond well not just to mobile but to different browser sizes and all of that kind of stuff as well as looking into doing SMS and applications and all of that kind of stuff. So that pretty much covers what we wanted to cover. Do you guys have questions, comments, thoughts? Anybody? Anybody? Crickets? How did you make the decision to switch from Convio to springboard? What thoughts went into that? It was a slow and laborious decision as almost all the decisions that our organization are. It's something we had been thinking about for a while because as we grew with technical expertise within our organization we really wanted flexibility and Convio is great in that it provides everything for you out of the box. You don't need to necessarily think through how all of these things together and all of those kinds of things but if you start to want to move beyond that and do a lot of customization you can hit some limits with it. So the idea of being able to have a much more flexible system was really what drove us in terms of that. We want to be in control of our destiny rather than have an organization's roadmap be dictating some of that to us. We also like the idea of, like I said before it's a best-of-breed system. So we're gonna be using exact target for emails and CAPWIS for advocacy. If over time we find that those aren't meeting our needs we'll be able to swap those out in a piecemeal fashion without changing the overall structure. And that's also very appealing. We get to choose what's important to us whether we want to change all of those things. So we basically had a year-long evaluation process and Tom and TJ can chime in on that as well because they were part of the whole thing where we talked about what we wanted to do and what made sense. Thanks. I actually thought of another question too. How did your department build your expertise in Drupal to the point where you were patching Drupal core and making modules? Like what was the training process for that? Where much time did you devote to it? We're not patching Drupal core, I don't think. Are you guys patching Drupal core? No. That was one of the slides I swear. Maybe you meant we do something else. We do fixes of our own code and stuff like that but not actually getting into core. But both Alwakash and Mariam went to Drupal, well Mariam came in later and she already had Drupal experience, but Alwakash went to Drupal training to a couple of different ones, I think. So I mean, it's just training and then playing with code and seeing how it works. Thank you. We didn't really patch Drupal core. To do the cookie security stuff, you do need to replace this session files but there's a way to do that without patching core. But yeah. Try to avoid that one possible. I work at an academic library and we have similar patron privacy concerns and I'm wondering how you handle analytics across multiple systems with the concern for privacy. So we use site catalyst from Omniture which can be configured to work without permanent cookies. So we use only session-based information from that and that can also work across multiple sites. It's a JavaScript file that you can call as an include from anywhere. So that's the primary way that we handle it and we just make sure that absolutely no personally identifiable information is passed into site catalyst. So you can control exactly what fields are passed in from various pages. So like in a donation we'll pass over how much the donation was but nothing else. We don't pass zip code, we don't pass name, nothing, that was part of what was appealing to us about using something like site catalyst because it gives us quite a bit of control over exactly what we report on. The flip side of that is configuration of it can be a bear as I'm sure Awakash can attest to. But it's worked well for us over time. Google Analytics, several of our affiliates also use and there's actually a way to hack Google Analytics so it doesn't use permanent cookies which is why some of our affiliates are able to use it but I'm not as familiar with that implementation. Thank you. Anyone else? Anyone? Anyone? All right, thanks you guys and feel free to ask us for your questions.