 So, at the City of Los Angeles, we embarked upon migrating our entire web content management system to Drupal, but before we go into that, let me tell you about the City of Los Angeles to give you a little bit of an idea of our challenges, so we have a very large square footage in our City, and at the same time, we do have a very distributed IT staff, so although I work for the ITA, which is a centralized IT department, there are about 40 plus departments that have their own IT staff, so it gets pretty unwieldy when it comes to trying to implement some pretty large enterprise type systems, and so 485 of the IT staff of the 1200 are in the central IT agency, which is the department I work for, and over 40,000 city employees are the number of people we have to serve internally, aside from serving the 4 million residents of the city, so in addition to having that big of a user base, we have had 40 percent staff reductions since 2008, so our service levels, it says here no change, but actually it's increased, so pretty much we've had to focus on trying to deliver services online, and of course we tried to figure out who are our users, and pretty much people who are interested in city government are people who we need to serve online, also residents, businesses, visitors, the usual, but we also saw that there were a lot of investment in systems that cater to job seekers, because we wanted to help in, I guess, getting people jobs in the city of Los Angeles, which we saw as a very, very important user base, at least in our web statistics, so that actually got a special mention here, so yeah, as I mentioned, our goal is to replace our legacy CMS, we had Stellent, how many people here have heard of Stellent? Cool, from us, huh? You probably heard from us, but pretty much it was a system that required our users to use IE7, and with XP I know I'm pretty old, I could see some painful, you know, it was really painful for us, and we had a lot of our users internally jumping ship, and it ran on Microsoft Server 2003, and pretty much we were doing a lot of workarounds to get people to use that system, it was a fairly cheap system, and our management liked only spending like $25,000 a year for 40 websites, which is the number of websites that my group maintains, but it had to end because of IE7, and like I said, we were 40 plus, and then because of the number of people leaving us, we were down to like 20 websites. So what mattered to us, we definitely wanted to, if we're going to ask management to invest considerably in something more than $25,000, we had to lay out our criteria, what would make it successful in the city, and so our end users, it was very important because they would basically have to evangelize, we're very distributed, there's actually competition within the city of Los Angeles, so a lot of our elected officials, a lot of our departments were actually going open source, WordPress, they were doing all kinds of things. So in a way, there's kind of internal competition, so we wanted our end users to be happy. If they're happy, then they'll start speaking about it, and they'll say, hey, we love ITA's solution for us, we want to go with them. So aside from that, they were demanding a lot of features, and like I said, we had to do so much to just customize even just a little bit for very basic features that's out of the box in a lot of these new solutions. We also needed high availability, we're at 94% availability when actually we should be at like 99.99 or 95. Cost effective, obviously we had cuts in people, they wouldn't want to pay for a lot for technical solutions either. And so we also wanted departments who were doing stuff on their own to be able to have also access to a system that we maintained so that they could, we enabled them also to use the system. So we wanted to support different levels of users, not just the non-technical users, but also developers. And of course, we didn't want to be stuck with something that for the next 10 years that wouldn't grow with the web. So that was our criteria. So we chose Drupal because it's free, highly functional, a lot of stuff is out of the box, very innovative. I mean, I've been following Drupal development, and I've been itching to get onto Drupal for the longest time or something similar to Drupal. But definitely even before us, we saw City of Austin, Bart definitely get on Drupal, and they had a lot of success stories. City of Austin won Best of Web, and we were itching to get to that level too. But those competitions definitely show who's being innovative, what are they using. And basically what I've been thinking of presenting to management, I was able to let them see that, hey, this is a direction that everybody else is going to. And so it was an easier sell than it was years ago when we didn't have a lot of these digital leaders using Drupal just yet. But they had, I guess, the flexibility, they're smaller. The City of Los Angeles would have to be investing a little bit more money, and of course they didn't want to just jump into it unless there was some proof that it was going to be successful. And of course, we needed Enterprise Grid system and support. And years ago, they didn't have, Drupal didn't seem to have that just yet for City as large as ours to be comfortable in going enterprise-wide with an open source system. All right, so I'm going to talk about the solution that we actually implemented. And I'm going to start with hosting and all of the tools that we decided to use. So our solutions, the main one is Acquia Cloud Site Factory. And we also use GitHub, Jira, Basecamp, Google Hangouts, and Slack. And so for, I'm not sure, has anyone used Slack before? Yeah, awesome for team communication. So that's why we use most of our real time, like throughout the project. We do Google Hangouts because we're a very distributed team. So we use that for all of our face-to-face scrums. Basecamp, we use for asynchronous communications where we put our project files, that kind of stuff. Jira, we did for Agile, which was another big part of this project, is not only implementing the solution, but it's also training and enabling like the Agile process. We use GitHub for all our code management. Individual developers had forks. And then they do feature branches. And then they do pull requests and where we could review them and then merge them in. And then Acquia Cloud Site Factory was like our main, like the platform that we built the solution on. So Site Factory, if you look at it, basically what it is, is a interface for a multi-site. And so with the interface, on the individual site level, you can go ahead and you can clone sites and delete sites and create new sites. There's like single sign-on built in. So you can sign into all of your sites without having to go, remember, log in and passwords and that kind of stuff. Yeah. It's built on top of Acquia Cloud. So it's high availability. It's completely scalable. Everything, yeah. I mean, if there's any issues, it's got 24.7 critical support. Also on the admin, you've got like a single interface where you can manage code. You can deploy new code. You can create tags to deploy to production environment. It controls or supports user roles. So you can put users in certain groups and they can only access certain sites. And so for their needs, having different departments and then different levels of users, it just kind of worked out really well, fit exactly what they were looking to do. So creating a common platform. So we're going to talk a little bit about development process, data architecture, theming setup and content management. So for the development process, the main deliverable for me was an architectural document which was about 60 pages and it was more about maintenance and moving forward and how to keep developing on top of the platform. We did two-week sprints for the first, well, for the project timeline. So for the first five months it was civic actions and myself doing most of the development. And then for the second five months, City of LA was able to step in and do a lot of their own development work. And then it was more of a consulting role, teaching them and helping them get through issues. Every developer had their own fork and then they worked off their own fork and then they got to learn how to use Git. We taught LA like the actual agile process. So then after the project, they could keep it going, which they're still doing. Every two weeks they're starting a new sprint. Yeah. Madeleine stuff. Yeah, we, so one of the main features that was important to LA also was a responsive site and we have responsive navigation. We, the slide that you see up there has, can show examples and if I had a pointer it would be a lot easier to do this. I could mention a little bit about the background. So the City of Los Angeles, so I have a team of six full-time members and then four part-time members. And what we wanted to do is, yeah, immerse ourselves in Drupal so that we could become experts ourselves and then migrate all those 40 websites that we mentioned. And one of the first things that we asked Civic Actions and Acway to help us with is migrate our main city website, which award-winning we wanted to make sure it was transferred over with expert help, but at the same time we needed to refresh the site and do stuff that we had like for the longest time in our backlog. And so basically we came up with LACity.org as you see here. This is a screenshot. Feel free to visit it. And yeah, as was mentioned we needed to make it responsive. In addition there's a navigation bar just within 10 months of after installing or setting up Drupal we migrated LACity.org another site and then we had a navigation bar on the very top that sits on every city website now, virtually every city website now. And so that's what you see from the very top. Yeah, some of the things we had here. So other announcements, which I can't read the thing. So yeah, this is an announcements feed that is managed in Drupal. The center part is more related to city views programming, but it is content and so current and recently archived media with indicators for if anything is live or streaming. Council meetings, board meetings, things like that are streaming. Yeah, so we have a TV channel actually that lets people see programming. We have like a weekly magazine show. We also have of course various committee meetings and city council meetings. And what was important for us, we have so much content, but yet we wanted to let people see what was what's going on now. So what's kind of cool is there's a live and on-demand indicator. There's a live and on-air indicator. So people going onto their going onto either the responsive site or the desktop site then they could basically see what's going on now. So there's a ton of content and we're like how the heck do we make sure that people see what is going on now because I think that would be pretty cool. Plus at the same time people who are very engaged, people want to know what what meetings are going on and also what events are going on. They can just go right to the homepage and find information that they need. All of that is from feeds. Yeah, and those are all from feeds of external data sources that we've incorporated into the site. We've also got a scrolling media bar with Twitter feed. There's links to all their social media accounts. So they are, it's pretty much the front page is kind of just an example of everything that we did for the project. We wanted to be very dynamic. We didn't want anything static. We wanted things updating constantly. As soon as something was available we wanted to show it to users. So we can move on to the data architecture. So we can talk a little bit about the data architecture. Most of the content on City of LA's website was from various external data sources. Their 311 city services data shows up on here. We import that into Drupal recurring so that it's always up to date because that is managed in a different database. The on-demand videos are from a Granicus feed. So those are actually updated in a much more timely fashion up to the minute. You know you can't have something update every hour when maybe it changes every 15 minutes. The events calendar is also from an external data source that is still managed using the external data interface. We pull that in with feeds as well so that we can display it easily. There are other feeds, LAB, AVN, job opportunities, things like that. All that stuff comes in using feeds in Drupal and then it displays seamlessly inside the website. You really can't tell what's being managed in Drupal and what's not. So we did have to spend some time figuring out which of these things can be imported into Drupal, have periodic updates, maybe nightly versus things that have to be retrieved pretty much dynamic and stored in a cache so that you're not spending a lot of time on the main site looking for those things and then determine we had to determine an appropriate update schedule for all that content. That was one of our first challenges and took quite a bit of time on the initial project. Basically, we had mostly contrived modules. We didn't really have to do a lot of custom code for this, which speaks a lot to the power of Drupal and the community and all the great contrived modules that are out there. Most of our custom modules were features, so configuration content types, things like that. We really wrote a surprisingly small amount of real custom code to support all the things that we did. We chose to use the feeds module to pull in all of our data sources. It's a really powerful tool to help you manage mapping between external sources and your Drupal source and it allows you to set up periodic imports. Christian is going to talk more specifically about what we did with feeds. Okay. How many of you have some familiarity with the feeds module currently? Good. A lot of this is just going to be a little bit of review, but I'm going to run through just a quick example here with some of the power of things that we're able to do without a lot of customization. A lot of our data that was coming in through LACD, a lot of different formats, but JSON, XML, CMS, and this example here is just a small snippet of some JSON data that we would have coming in from one of our event feeds. Anything from date formatting, some things like that, titles, we had a lot of different other feeds to deal with. The feeds module was really key into integrating all of the stuff and getting the content in without a lot of extra effort. Some of the basic settings and things that you're able to get here allow you to do scheduling and periodic importing, setting up several multiple feeds from different sources. This does it all in a really nice UI interface. It's not too hard to teach to others, which is the other thing was great because we had to get their team into there, transitioning them to be able to run these imports and know where everything is that's coming into their data. In this particular example here, we had a JSON parser, so we would just be mapping all of the fields coming in from our event data into named fields on the feed side. Once all of these things are mapped into this layer, you're able to do to set up your node settings and things so far you can map all of those fields into where they're going to end up as far as in Drupal nodes. For node settings themselves, this is important. A lot of the events, we would want them, if there was event changes and other things that would happen there, we want to make sure those nodes would get updated immediately on the next import. Authoring information, not having any duplication of nodes and any other content. Since we did have some collisions with other things, there's not necessarily the same unique identifiers across all of these things. That's one thing that's really important with this module. Then for mapping itself, we were able to just take the fields that we need. There's a lot of data we were able to throw away and then also set this up for any other editing or transformation that we need to do on this data itself, which leads you into the tamper. The tamper was really important here, taking care of any other date formatting, taking a date and putting it into Drupal actual date field formatting and not losing anything and still having all our views not be maintained and everything. It also led us to be able to do any customizations inside of a custom module if we needed to transform or need that data in some particular way, like we were matching things up with other videos and just other data that would need to be paired together that this couldn't necessarily take on by itself. Then I think we're leading into a presentation of the data itself of what we were able to do once we got this feed data imported. I'm going to pass it on this step and she was going to give you a little example here of what we were able to do with some of that data. This is the main page of the for residents section. The city events pull events that were tagged that were for city residents. That shows you the current days events. The other thing that's on here off to the side is this menu over here is a taxonomy driven menu, but it pulls the 311 data in from the city services. These are links to city service pages of the information that is important for city residents to see. This is not in the LA City site. This is actually on LA City View. This is their old weekly schedule for the Channel 35 on-air programming. You click on one of these and you just got a little blurb that didn't say much more than what was right there. This is what we have now. You have a weekly program schedule. You get what's currently on air right now. A big picture. You can click on that and get more information. Below you see what's coming up for today. They now have descriptions. Those weren't available on the website before. The content editors are doing no more work than they were before to set up the TV schedule, but they're able to get a lot more use out of the web content. We've got different views so they can display this in different ways if they want. It's really increased the amount of value they get out of the work they do to create their schedule. I think this goes to Jason. Real quick, we're just going to talk about the theming strategy. Just basic Drupal theming, really. We started with the Zen base theme, something that was very clean. Everything was custom, but it was really a pixel to pixel translation of their old site to their new site with the addition of responsive in there. We did use a separate GitHub repo for our theme, and then we had, for each different site that we made, we had a different branch for that theme, and then we could connect those into site factory and then deploy themes separately. Everything's organized based on SMACs. We're using SAS and Compass while enabling and training the LA team. They got to learn all those cool things, and using SMACs really helped them spin up quickly because they didn't have to go hunting for code. They could just find the correct partial fairly quick. At the theme level, we're doing as much 508 compliance as we can because being government site, it's very important that we do everything with accessibility in mind. This is just a screenshot of the accessibility module, so we were able to go in and create and define rules, and then we could incorporate that into our WYSIWYG, so then as we were creating content and adding images, they could run accessibility scans and checks on that piece of content itself. For the content itself, there's about 40,000 pieces of content. Most of it was migrated in through feeds or other sources. Again, the accessibility was built right into the WYSIWYG, so when they created new content, we could make sure it would pass because bad things happen when you're not accessible, I guess. That's what they tell me. They get sued. Same thing with the media. With the images, we were able to bake in a lot of the accessibility stuff for all tags, title tags. Got a single sign on to log into all the different sites and manage all the content because when you have three sites, it's not a giant problem, but when they have 50 sites, it's going to become an issue. One of the big goals of the project was being able to actually hand off the project, so we started it and we worked together and we built something, but we really wanted the L.A. City team to be able to take that project and run with it, so we created two or three sites and then we handed off to them, and they can create another 30, 40, 50 sites or 4,000 sites, whatever they want to do. Doing that, we had to take these, this group of guys that were very technical, but they weren't drupalists, and so we did that in a couple different ways. I was on site a couple different times. A couple other people from AQUI went on site a couple times and gave workshops. Our documentation was very focused on how to keep building, not what we built, and we would do these weekly, hour-long Google hangouts where they would just hammer me for, I mean, question after question about stuff that I couldn't even figure out half the time. It started off easy, how to create a view, and it ended in things like, where does this feed source come from? On site working sessions, they were amazing because they were extremely flexible. I went there for two or three days and I got to work with their team leads. All we did was work through workflow process, merging code, deploying code, how to roll back code. We focused on some drupal stuff, but more of it was very big picture, how to manage this project going forward. Workshops were a little more structured. We tried to keep the schedule fairly loose so we can kind of address questions as they came up, and it was more the topic for this morning is going to be display types, and then that could go out, that could spider into a different topic. At the end of the day, we were talking about things that weren't even on the schedule. I mean, we were doing how to build a custom module, and custom module was never even on the schedule. I think the workshops, we did a site factory jump start, and then we did a site building one, and then I came in and we did a week long how to theme a site. Architecture document kind of hit on that earlier. It's about 60 pages, and it encapsulates everything in the project, like how to deploy code, the different layers of caching, because there's varnish, and there's memcache, and drupal caching. We documented each function that was in the custom modules so they could maintain it or they can figure out, they can read the document along with the code and kind of figure out how it worked, so then they can work on creating their own, or at least maintaining or modifying what we had already done. We talked about get things like patching and creating a patch, and applying a patch, and submitting a patch. Then we also talked about upgrading, and how to going forward, how to upgrade your modules, and how to upgrade your sites, and then how to upgrade and test in staging environment, and then if everything is good, how to deploy that code to production. And then knowledge transfer sessions, which I think was probably the biggest like beneficial thing that we did in terms of training, because it would be an hour long Google Hangout, and it would be me and probably six or seven developers, and all they do is ask me questions, and questions were everything like what does this code do, or where do I look for this code, or I've got this issue assigned to me right now, and I don't know how to solve it, can you help me, and then we would just walk through like the actual problem that they had until we got to a solution. At the beginning the questions again were super easy, at the end I would have to tell them, I'm not sure, but I'll look it up and I'll get back to you tomorrow. So that takes us into the retrospective, I think we can probably do this one sitting down since we're all going to talk. Madeline, do you want to go first? A lot of successes. So definitely what I felt was very successful about the project are the fast milestone completions. I mean we've never accomplished this much in such a short time, with especially the changing specs. In 10 months we were able to establish the city's Drupal platform for multiple sites, so I mentioned that my group maintains probably 30 to 40 websites at a time, but in the city there's actually up to probably 200 websites. I know there's 100 at least, and probably 100 more that I don't know of, so definitely we wanted to establish a platform that could, where everybody else could benefit from the platform. We wanted to train city staff within that amount of time, and as you heard from Jason, there was a lot of hand-holding, he was our training wheels, and so we were worried by the time the end of the engagement. Only in the beginning. Only in the beginning, no. But it was really great to have all the support and planning the type of enablement for us to be able to within 10 months be on our own. We adapted to the Agile project management methodology, which is amazing in government. You rarely see that, and we're the first, I think, of the entire city to actually adopt that, and we're actually being asked to mentor other teams, so that's how successful his project is. Migrate and enhance LAcity.org. It's a huge site. I mean, you heard about all the feeds coming in. It's almost like it's a facade. LA City isn't really there. It's all feeds. Drupal is the one putting it all together, and in a way that's true. We had an open data platform launched during that time, and so that's where all the feeds were coming from for a lot of the events and a lot of other data, so everything is like API feeds, web services, and we needed something like Drupal to bring it all in and make it look like it's all coming from one site. We also launched and redesigned and touched upon it earlier, that Channel 35, and I mentioned that we have a cable TV channel with a lot of great content, but it wasn't being presented well to the public, and it wasn't being put on LAcity.org really well until now, so that's Channel 35. If you have cable, you live in LA, you can check it out, and we were able to develop and distribute a citywide navigation bar. I touched upon it earlier, but yeah, with 100, 200 websites, all of the departments are worried about, is that navbar going to be highly available so it doesn't bring down our site, it doesn't mess up our site interface, and so that was something that was really cool, and it has search and notifications so soon. We'll be able to develop a notification feed, and if there's an emergency, or if there's something that is really big, and the mayor's office, let's say, wants to announce, that navigation bar is going to have a pop-up underneath, and it's going to appear on like the 100 to 200 websites in the city, so that's pretty cool, and we see a lot of opportunity for that in the future. Improvement, so I mean, it was great working with everybody, but of course not everything is 100% perfect. I mean, it's we're not in the utopia, but I think one of the things that we learned is that I discovered that training maybe could have been scheduled at the start with more time allocated for it. I think we scheduled training kind of in between, but I think we should have started off from the get-go. I think it was a little bit rougher because we didn't know a lot of the terminology earlier, maybe if we knew it much earlier, we could really understand what everybody was talking about. Even though we're technical of the terminologies, you just won't understand it and pick it up right away and understand what everybody's talking about. I felt that we should have prepared well in advance. My team should have prepared well in advance with more detailed responsive design specs. We probably took it for granted that, oh, there's going to be some responsive design themes out there. It's just going to look really cool after it's all developed, but obviously we also had some tweaks that we wanted and it would have been better to list those out in the beginning rather than kind of see what was out there and then have to customize it later. Then more time for quality assurance testing. I think it's sort of a change in pace for us, so we didn't seem to, a lot of a lot, a good amount of time because at the same time we were also training. That's kind of lessons learned. Future opportunities, we really want to migrate our 20 to 30 sites that we have on Silent. That's a must tonight. We're trying to do that within a year. We want departments to leverage the new city platform. We want to reuse base templates so we're working towards that and basically want to cut the development time in half if we can. Then sites we want, in other city websites, we want them to be able to integrate with other systems just like ours is able, our LACD.org website is able to integrate with so many other systems. We want them to benefit from that as well. Pretty much it opens the door for us to develop more features that will encourage user engagement. We'll have more time because now we don't have to do all those workarounds which we constantly had to do with their old content management system, so there's a lot of time savings that we see that'll give us future opportunities. I'd like to share some too. So for me, I don't know if we call them successes, but they're definitely highlights. As a development partner, Pacific Actions were amazing. I could completely trust them and I could offload so much of my work to them because they did so well. Ethan's not here, but Ethan was a giant part of this team. Communication was fantastic. It was one of those things where you could ping somebody and be like, hey, I need 15 minutes of your time and then you're on a hangout a minute later and you can talk through issues and help through deployment problems. This is probably one of the first projects where it's been seamless between team, between client, partner, everything. We basically worked as a team. We had one goal for the sports analogies and we scored a touchdown. And yes, improvements, as Madeline said, we probably could have got her team involved sooner, which would have probably helped us develop faster. And they could also, they would have been able to take over more work sooner and yeah, it would have been great. Another thing I had was, my documentation fell behind because work kind of gets in the way and there's certain times where I had to step in and do some development tasks and then if I could have shelved that or pushed that development task off to someone else, then maybe I could have kept the documentation up to date and then they could have been learning sooner and they may have been able to jump in sooner. Okay, yeah, some of our successes from our viewpoint, we thought, I mean we had a great project owner and there was a great working relationship between all the different parties. I mean, having a project owner that was as engaged and interested in what we were doing and they learned so quickly, it really made everything great and everybody had a great sense of humor. You know, you're all busy, you're all trying to get stuff done but we all had a really great working relationship. We also did a really good job with our estimation for the amount of work we could get done in a sprint so things didn't get pushed back and pushed back so that was a great thing. There was a lot of give and take when maybe things would change a little bit and so we were really good at working out our differences and when additional feature requests came in in the middle of a sprint, we were able to accommodate those or, you know, decide well we have to wait until the next time to do this so that was really great. We really did get a lot done in a very small project time frame. It was a really great thing. There was a really good division of labor. I think we worked towards everybody's strengths so that, you know, the most amount of work got done in the least possible time and for me this was my first time at really working on a distributed project like this. I only joined Civic Actions last year and this was my first Civic Actions project and I thought, you know, the communications tools that we used were really great. I felt just as connected with people in time zones, three time zones away from me as I did when I worked in a office with people that I could throw spit balls at. So, you know, that was really great. Kristen, do you have anything else you want to add for pluses and maybe you want to do them? I think the out job process really showed shine to your, Elizabeth really was our project. She did an excellent job at coordinating the team and making sure we, you know, stuck to what we're supposed to be doing and then we also had Steve Curtis on QA. One thing as most projects it seems to happen in an improvement area is that, you know, having your QA tests, it'd be a focus. We really didn't get our QA tests going as well as we did until later on during the process. So it's definitely an area improvement that almost every project seems to encounter. We had a little bit of scheduling, you know, making sure our data feeds and things that we had to work with being available early enough. It was a little bit of a challenge because we were working with a lot of different departments all operate on different schedules and, you know, ensuring that we can get the data in time because, you know, you got to start figuring out how to get everything imported. And so I definitely would recommend nailing that stuff down as early as possible. And we did not get it to implement any automated testing which was a real bummer. That's going to cover it and I think we're going to open up to Q&A here if anyone has any questions for us. Yeah, so our accessibility focus more on section 508. So there's a legal complaint of making sure that the website can be, you know, accessible by screen reader. When it comes to diversity in the different languages, that has been something that we've been considering but then we do have, let's say Google Translate and that's something that we could put there. We're still working it out with our with our legal team to see if that's something that, you know, not human versus, you know, machine translation. But City Clerk is promising because City Clerk has already adopted the Google Translate. Yeah, so we just have to look into whether that's great for LA City. Or because we could translate it but then when we pretty much link off to a lot of other sites. So from LA City it's we link off to other department sites. So the translation won't be there once they leave, the translation is gone. So, but no, we're working towards that as well. Sure, we were actually lucky. The open data initiative came directly from the mayor's office. So they actually appointed a open data director and they work directly with another team actually in IT. So there was a lot of resources already available and the entire city, basically each department was asked to identify their open data, I guess data that would that's good for open data. And it was done it was done really quick, probably within just six months departments were were mandated by the mayor's office. So it helps to come from above. So they had the luxury of having that backing from the mayor's office. Our redesign of lacity.org actually and going Drupal was pretty much a grassroots effort. My team and I we really had to put together very compelling numbers and a use case to even go to Drupal, go open source and and even you know migrate and give the idea of migrating 100 to 200 websites onto one platform. So I know I kind of strayed from it but open data pretty much that went much more smoothly when it came to getting everybody on board with open data. Another question about the feeds. Since you're taking some data from the public sources like Twitter. So we have a distributed model as well for our content for our communication. So Twitter feeds, the Twitter feeds that we have actually are it's it's a compilation of all city Twitter feeds. So we expect departments to do the curation. And so really what we're only putting on lacity.org is something that they are already curating. It's either their tweets or their retweets. So most of the feeds pull into Drupal nodes. So if the feed source goes down we're not really displaying the feed source. We are displaying the Drupal node. So for those feeds the biggest problem is well maybe the updates aren't happening quite as often as you want. For the other one for the up to the minute things that we really aren't using feeds for but it's more of a custom code to pull in the feeds. We pull them in out of band. So there's a cron job that runs to pull them in. They're cached locally. If that the next time the cron job comes along and the source doesn't happen then what you get is still data. But you don't get no data. So there were pros and cons we had to consider. I mean right now we're looking at one of our feeds we wanted more real time and we have actually our 311 data. They're moving into a CRM and they're asking us rather than giving us a JSON feed they're saying well so we don't have to maintain a JSON feed can you can you just use our new systems API and we're I'm trying to see what the pros and cons are. They have to tell me that they're going to be available all the time or something. Otherwise we'll go back to the problem we had when we were installing. When they were down our site went down or the pages were blank so definitely there's there's some give and take we have to consider what's key data that really shouldn't go down and if that's the case then we need to cache it. Yeah so my team we're working on a style guide actually. Yeah you are. Yeah so it's it's coming down it's just a matter of is this going to be a mandate or is this going to be an option or a very compelling option for you guys so but it's we're working towards standardizing that and providing again a responsive design style guide and template so that it'll be easy for a lot of the IT shops to be able to stand up their own website whether it's on Drupal or they have to you know neighborhood councils have to do it on their own. At least there's a resource that will make it available and would identify with the city. We're working with the mayor's office and so far our goal is to have it ASAP and test it with a few pilot sites and we have a few volunteers so we're still working out the strategy of how to deploy that but yeah essentially your the answer to the question is yes we're working on it. Yeah so again we're working with the mayor's office I mean with open data that model was pretty successful I mean it's not sort of a mandate but it's in a way and it's totally different I mean open data it's just putting up a bunch of data you're not asking them to use a system as in-depth as as you would Drupal but yeah I mean what we're trying to do is win them over I mean we're not gonna even the mayor's office they even know that they're gonna meet a lot of resistance and sometimes with that resistance they won't it'll be impossible. So what we're trying to do is lay out you know here here is at minimum your the standards that your website should have and even with that list especially for government websites it shows that there's a lot of work that needs to go into developing a responsive design section 508 compliance especially for the number of checkpoints that we expect them to you know to have for when they go from a huge screen to just a tiny now watch I guess but definitely the way we're doing it is is showing them the numbers pretty much showing them that if you were to go on your own and some of them have experienced that and are actually coming to us so it won't be that difficult to sell for probably half of the departments but for the other half who think oh look at how much especially if other contractors are coming to them and saying look how much I can do your site it won't even cost that much and I can do it in a month compared to with us when we tell them you're gonna have to talk to your contractor and ask for all these requirements why don't you go back and tell them how much is that gonna cost versus if you and how long it's gonna take versus if you if you adopt this model and use a platform that's already there use a base theme that's already developed for them that's responsive so that's how we're that's our strategy it's pretty much competing competing with what's out there yeah so we're gonna decide based on metrics or web analytics but at the same time we're also gonna see but basically what is I guess hit the heaviest because at some point we're just gonna have to turn off our system so we stop paying for it if we're down to some sites that can actually be static like we can export export them then we'll do that so we're gonna start with the busiest website so it's kind of crazy that we went with L.A. City don't work first but that's how we plan on going about doing that so that maybe we can really shut it down our silence server within a year it's all basically just a javascript so I mean it it's a little bit more than javascript but the the output is javascript so the alerts feed is basically like a JSON file we're caching it we're displaying it but the actual menu item or all the menu items and everything comes from another JSON file which gets pulled into so we just have a javascript file hosted at you know a certain website and then if you're on Drupal there's a module that you just turn on the module and then you can pick do you want to load the you know the test source or do you want to do production version and then if you're not on Drupal then it's just attach the script to your website on lacity.org using JSON for menu because we actually our menu is built off of our citywide services directory so that that taxonomy that we have that navigation has a one-to-one relationship with our citywide services taxonomy which is in another database we use copy and paste for most of the content like if it couldn't be imported from a feed there wasn't really a whole lot of content that had to be migrated and so it was copy and paste as opposed to setting up some kind of migration yeah i'm not actually sure we've got some really good migration people i'm not one of them but uh i can probably find out for you essentially what we were told is because we asked about that too we heard about you know the ability to migrate into Drupal there's this migration module and so he said well wouldn't it be easy and they said pretty much there's a lot of setup and configuration if you don't have um something very structured if you don't have like Stellent is not database driven it's i mean our database the database for Stellent is pretty much indexes and a lot of the content is in XML so to configure that um configure getting from XML and putting it into Drupal actually might take more time than and testing it and then just making sure it works properly is more time than actually copying and pasting so there may be some websites that will have maybe over a thousand thousand pages with a lot of PDFs and all of that and we might end up asking about the migration module but for a lot of our sites they're small to medium and uh we thought it was just faster to just do copy and paste and we would engage also our end users to practice using Drupal and they would help us with the migration so that's the plan yeah we did luckily though a lot of the city websites were pretty simple they're only few and the only ones that had like the sticky headers you're talking about were actually within their content management system so we had some WordPress people uh WordPress users saying we lost our WordPress menu because of your nav bar so well um we would work with them one on one but luckily we're we're pretty lucky and we deployed it slowly we had a we did a survey and asked for uh asked people what their platforms were and then we selected them as their as the first um pilot group but when we first told them can you test it for us they wouldn't test it so we said okay we would bc them i'm giving away a little bit we would bc them and say we're deploying this they don't know who got distributed who it got distributed to so these small users would tell us if there if there were some issues and we'd work on them one on one so we deployed it slowly without them knowing yeah i think the goal was like you know we got it to work on maybe 75 80 percent of the sites and then there was always those use cases that you don't think about where it's like i have a site made out of frame sets or i have a site that doesn't have a body tag and it's like how embarrassing they were really best viewed in ie6 yes yeah no definitely the community was the deciding factor too one of the deciding factors because what i mentioned earlier is we wanted things um out of the ready out of the box and by far um you know drupal just had all of these things out of the box through modules and so we were we were developing a lot of custom code workarounds like first down for example just so that the interface is a lot easier for the end users so i mean i can't wait for drupal 8 so i kind of want to delay the project a little bit and get drupal 8 and then migrate the rest of the 20 plus sites that we have but um definitely um the community and of drupal is that was i mean it would if not for the the community wouldn't have all the modules and the core drupal the way it is now and um and and that was yeah definitely a big factor the awesome questions by the way yeah very awesome anyone else search oh how did i uh let's see we have in some sites they're using google search um but then on la city we first launched it with um i guess just core search so uh yeah a couple of sites were used in core search and then on other sites were used in like uh google site search mostly for the city it's google site search pretty much so like the global nav bar uses google site search so you can search across yeah google for now is it's free it's easy to to set up and that's what we're doing so there's nothing um uh beyond that um maybe that'll be our next project maybe in a couple of years yeah no that's a challenge it's still distributed departments are it's up to departments to put out the good material and of course there's a range of of quality out there and so i know that the mayor's office is working to put together a working group um they're calling it social media working group but actually it's it's really content the way i see them um the scope of what they're putting together is really trying to get um departments to be at a minimum um uh minimum standard that the mayor's office pretty much is guiding so the mayor's office elected officials they're really good at putting together a communications team so they're going to be mentoring a lot of the departments in this yeah so that's their strategy it's going to be parallel with our strategy in terms of infrastructure and putting a template together so i think with that going together um i think just that hand in hand in a couple years while you can see la just really improve its digital digital presence online there's a question back there so we're not using Drupal for records management um for now we're just using it for user engagement um i don't know if there's i don't think we have a policy yet for records retention only for certain things maybe contracts and maybe city council meeting agendas and um and and stuff like that but when it comes to the web um websites we don't have any records retention policy just yet it's a bit early we're no i'm excited i've i've been looking into what are the big differences between Drupal 7 and Drupal 8 and um yeah i i so far i'm looking at like the user interface how much how much more improved it is and so excited about that but yeah it's a bit early for us but as soon as um i guess we're able to we'd love to go to Drupal 8 especially if we don't have all our sites migrated yet i think we'd rather do it sooner rather rather than later i don't know if there's any any recommendations um when we should start looking but but i'm going to constantly be looking at Jason for joining us out here um great resource um for somebody on the inside because i know that this is kind of information that's hard to find um and we'll thank all of you for coming we have a slide here with our contact information you know feel free to come up here if you've got any questions um be happy to help you out and uh and thank you for coming to the session yeah great audience thank you