welcome this is Jeff Snyder I'm Shaun McMahan's we're from Texas State University in Texas as you might imagine we've been using Magnolia for about two years now and want to tell you some about our experience with it Jeff has put together most of this presentation so in a moment I'm just going to sit down and let him take it and then interrupt from time to time can't think of anything more to say when I started off just a little bit background about me I'm the long-haired developer that but I've been at our University for a little over ten years so I've seen a lot of these changes occur so I'm gonna try to put this as a better put this together as best I can but keep in mind I'm one of the you know geek head developer to people so a little background on our University we've got we just passed a 30,000 student mark which puts us squarely into the fifth largest of the state we're behind some juggernauts like if any of y'all follow a college bath college football you'll know University of Texas and Texas Tech and I am a few of those are their names but we're the fifth largest we on our campus with our web presence we have about 350 distinct web sites and those are College departments divisions administrative departments programs anything you name it all of these are managed by different people there's very little centralized authority for the web aside from what we've put together so lots of people in lots of different places they keep that in mind that there's that it's a lot of different groups so years ago before we started doing anything with CMS's what we had was that every site looked a little different sometimes they didn't even look like they were from our University most of them were poorly designed and and didn't work very well we had accessibility problems as part of the requirements by the state of Texas we have to make sure that all of our web presence is accessible to blind users and to all all raise the disabilities and we had a lot of the web presence of the University hosted on basically little old boxes underneath desks that were piled behind you know that had books in such piles in front of him so not an ideal environment to be hosting a website we had them die over the weekends quite regularly and we get calls about it there's nothing we can do because it's in some other office did you have to be bad so that was just sort of a routine thing when somebody would accidentally kick out a cable on their way out for the weekend and a website would be down for three days and another common problem that occurred a lot and still does to some extent is that a lot of the websites that we had were built by students and by definition they're transient they come and build a site for a department they get hired for a little while they build that site and then they leave and oftentimes the department that they built it for will be lucky if they got the password for the server out of the students so we had a lot of times that we had to go hack in the server so they could just get access to be able to update their websites on our campus I not entirely sure but I believe we have a I have the impression that we have a lower technical expertise of the faculty and staff on our campus a lot of times you know there's been times when we were lucky if they even know what the mouse is so most of the time computers equal Microsoft Word they want something nice and simple to be able to put put together so they they want to be able to build websites but they don't necessarily know how so that's that's the reason for the student work that always comes in so obviously they wanted something to be able to manage their website and not have to you know not have to call us all the time would be ideal and connector tech briefly to academics are fiercely independent people so telling them how they're going to do things does not go over well so it's been very important to us to be able to present something that's attractive that they will choose to use so before we got to Magnolia we went through several iterations of different content management systems the first was a product called web GUI that lasted for quite a long time we only did that for maybe a dozen sites they were all individual separate designs so it wasn't something that was a campus-wide kind of a rollout that was that was adopted quite readily by our users because it was really simple and easy to use it has a similar interface to what Magnolia is now after that as part of its somewhat rolled into some of the future stuff that we're going to talk about was a product called vignette and this is the only time that we're gonna mention vignette we have lots of things to say about vignette but if you want to hear it you'll have to catch us later because I don't want to take up all of our time talking bad things about vignette but it was our standard for the user hostility not user friendly user hostile and last we use a course management system for course work and syllabuses and tests and the like at the years ago we were using blackboard we now use the derivative of Sakai which is another open source java based course management system and i do credit this with introducing a lot of content management concepts to our faculty and staff so in 2004 cuz about right it's alright okay we decided that we'd that the the content management system paradigm had been had been proven and we wanted to roll out something that everybody could use we we had been using a system that was that we'd made maybe a dozen sites but it was still difficult and time-consuming to set up new sites for people so we wanted something that everybody could use everybody could use quickly our users because of the low technical expertise we wanted something easy to use that was extremely important if I could that would take up the first five requirements for this it would had to be easy to use and we wanted to fix the common look and feel problem we wanted the websites on our campus to look like they were associated with our university we wanted to have the logo up there we wanted to have links that were relative or relevant to the University and we also wanted to centralize management so if we did have a student who worked on a site and they left they weren't the only ones with the keys to the site we could issue credentials to someone else and if I can elaborate on the ease-of-use issue for just a moment we had of course there were there were people around campus who knew some HTML and were throwing up web sites of their own and when we showed them our first iteration at a CMS before we implemented Magnolias it was like a 13 step process to just upload an image and to put it on your page so people understand to play looked at that and said we don't want anything to do with that we're just gonna write our own HTML and have nothing to do with you guys so so that ease of use was very important for us at this point because we were kind of failing in this implementation okay so we didn't mention vignette a little more I don't think I said it's named oh okay I thought then we have a lot of fun talking bad things about it yeah so one of the things we did for our project was to put together information architecture and what that basically was was some site some some basic no content just a structure of a site because we realized that academic departments they all have courses they all have faculty they all have office hours divisions all have it's all the same kind of material we identified four different groups on campus and created navigation structures for each of them and that helped a lot with in that it gave people a starting point it's a and it made it a lot easier it made that the cost of entering into our content management system much lower because they didn't have to figure out how to work on all of the content I mean they could they could remove pieces they didn't have add new things that they needed but it gave them a starting point and it also cut down on users trying to be clever and come up with new navigation schemes if we didn't have something for them to work to start from they probably start putting navigation into various random paces on the page have all sorts of different types of navigation and this flattened it out and made it more more organized and more consistent across campus yeah our sort of watchword was make the easiest thing to do or make the right thing to do the easiest thing to do so that when people got into the system they would if they did the very least work they'd have something that was consistent with everybody else so the process of selecting Magnolias this this happened this happened after vignette we had the information architecture and some of those things happened alongside the the vignette project when we used that material with selecting Magnolias that was a very informal process basically Sean and I got together and looked at a dozen different systems went through them decided which ones which one had the best interface and easy to use and had the best API back there on the back end and it happened to be Magnolia if you ask any of our administration on our campus they will tell you a totally different story but this is the way it actually happened because we just got together and decided which one to use and the administration kind of did a cover up to to make sure that it looked like we went through this big long involved committees process for the two of us it worked out very well we left the control who gets that begin it worked out very well for us and this is as I was listening to the keynote some of the points that he made I realized I was making also in my presentation the open source commercial hybrid operation that they've put together worked out really well for us because we can actually try it out with with the previous content management system we had we couldn't even look at it until we signed a nondisclosure agreement so actually being able to try it out and decide whether it was right for us without having to sign all bunch of contracts and start you know start payments and all of that was really a bonus for us we also have a great affinity for open source on our campus so it worked out with us as far as our as far as our preferences and principles as well usually this is the point at which in presentations like this somebody chimes up and says why didn't you why didn't you use my favorite CMS there's lots of different people who have lots of different opinions and particularly with open source and really that that that hybrid the fact that there's a solid company behind it was a big deciding factor for us because it provided somebody to call and also a guarantee or at least as much as you can have that there would be active development on it over time with a lot of open source projects that are developed just by random people who it's there you know halftime kind of job you can't be certain whether they'll just drop it tomorrow but we couldn't we didn't see that very likely to be happening in the situation certainly doesn't now and we could tell quite clearly that Magnolia shared our priorities of ease-of-use in particular and also continuing the open source model yeah absolutely we we've been delighted to be able to sit people down in front of it and people who are already technical don't need any help if they see a new button they click the new button they click a few things and they figure out what's going on and then from the nerd side from the backend we were able to check out the API and check out the engineering and all that before we got into it because programming with some of our previous CMS's was so difficult that was a really important thing for us to be able to look at that and make sure that we were going to be able to customize this in the way that we wanted without pulling out any more precious hair alright so for the implementation of Magnolia when when we first started using it it did not have the concept of having multiple sites in one installation it was pretty much just a single site so we did a little bit of hacking a little bit of development to make it work like that basically what we did was we made the rule that top-level pages were in fact sites and added a whole slew of Apache rules to rewrite URLs and pass stuff back around and wound up with a system where we could just take a single root level page of our Magnolia instance and attach it to any URL that we wanted to I understand now that Magnolia does have a site management sort of thing like that honestly we haven't looked at all that terribly much because this has been working pretty well for us but that's one of the things that we had to do because it didn't exist we also tied it in with our university authentication system an LDAP directory and we used we built a couple of tools one of which you will see this afternoon in John's presentation the external data sources which was a paragraph that would allow a user to select a department or group on campus and it would create a directory list for them of people so it pulled that of our Human Resources database automatically we also integrated it with a streaming media system so that users could just say add this video to the page and it would pop in and pull from our streaming media server Magnolia does have a caching architecture we chose not to use it because we already had one that we built with the vignette project that had a lot of features that we really liked and wanted to keep so our installation which right now is it's seven servers is probably a little small for the Fort Magnolia instance of the traffic you know for the traffic that we get and I'll show you some stats on how much traffic we get in a few minutes yeah and the Oh penetration was especially important to us because we currently have about 800 850 editors in the system and we don't want to spend all day resetting people's passwords so that helped us a good deal yeah we can pawn that off on another department on campus to let that afield elated so implementing the users getting the users used to the system's first thing we did was since we had such a quick turnaround on setting up the system we were able to get it out to the users and we got a lot of feedback early on it before before we had any users who were actually launching sites in it we had users who who were looking at it and could give us some feedback on it we no matter what the higher administration in the university said their story was a little bit different at times we decided that we were not going to in any way tell people that they were required to use this system we didn't want people to feel pressured into it we wanted them to come to us on their own and that is something that we credit with a lot of our adoption now as what Sean said that the an academic environment particularly for ours they don't like to be told what to do they'd rather you know they'd much rather come to the decision themselves even it's the same decision they want to make it on their own yes I'm absolutely convinced that that our first project manager way back in the day actually would come in and tell people you were going to have to use this and I'm absolutely convinced that there were people who said oh no I don't just because they were being told they had to as time went on and as we actually had some sites live from this several of the power users users who did know HTML and did know how to build sites relatively well before found themselves constrained in what we'd set up so we added some additional features such as a paragraph type that was just a big box where they could shove code into CSS properties that propagated throughout the entire site and a method to attach to google analytics for people who wanted to really rich stats on their sites streaming media what else can you think of it was power user sort of things so the RSS stuff was okay kind of power user again all right a little bit of management this isn't necessarily other thing to do with Magnolia but it's what we did to help our users is when they first expressed interest in using the content management system we went to them and gave and did a session on what basically what it was and what it was not what they could do in it what they could not we wanted to make sure that people had a good concept and didn't didn't feel suckered into it by getting promises that didn't deliver so we were straightforward and honest as to what it was going to do for them and what it was not and some departments after this chose not to I would say very very few wound up making that decision of the people who have had info sessions I mentioned we have a 95 percent or better turnaround that they actually won't do wind up using the system and a lot of that comes from the demo as part of our as part of our info session we demonstrated the system to them and that's when their eyes lit up and they looked at and realized just what how much easier it would make their lives from having instead of having to write HTML all the time we actually had one person who after she saw the demo and got set up in our system she sent us an email about a week later saying I went home and I played with this all weekend because it was so much fun like well great I spent my weekend different but it's it's it makes us feel really good when that is what people do is their spare time is that they want they they enjoy it so much that you know that that means we hit our mark as farce and I say we a lot of it most of its credited to Magnolia as far as the ease of use but that means that we hit the mark that says this is people is something that people not only are okay with doing but that they actually actively want to go do spend their time work also as part of the info session for those few people who didn't use our system after all we didn't even was sort of a parting gift of a set of best practices rules we basically said even if you don't use our system at least you can do these things and it was rules such as consistent and clear navigation thinking about your their site structure rather than just starting in on HTML and figuring out the site structure later flipping it back around how to some notes on writing content and using a proper voice for the material that was on the site and various accessibility rules like don't use blink and things like that just just to get them some some basic tips to help their website be better even if they didn't use what we've provided our training and documentation for our system the training we were able to boil it down to a single two-hour session to get the basics across even for people who were not familiar with this stuff and didn't do it intuitively after two hours they had the basics down and our repeat training users is very low which means that even even though they may not necessarily know intuitively how to use systems like this the two hour session got them what they needed and it sticks we have other things that we've done training sessions and we have repeat we have the same people we see the same faces over and and over and that hasn't really happened here we do also have an additional two-hour session after that want to go over more advanced topics like some of the advanced paragraph types code paragraph CSS analytics things like that so the things that have worked out really well for our use of Magnolia of course we keep saying it the ease of use still very important it's very efficient of those both in terms of its server utilization that's very quick and doesn't use a lot of server resources which was a big big deal I will bring out the vignette card one more time our system for running that consisted at the end of using that one of 14 servers and we still had page load times of three seconds or more even without load and with this one we had far fewer servers and far better response time and also with the efficiency its ease much easier to develop for do you want add a little bit to that I don't know what more to add beyond what we've said already idea that the API is really nicely engineered and obviously a lot of thought went into it and it's been one of those experiences that's delightful in programming because you sort of put your shoulder to the door and you're expecting a certain amount of resistance and the door just falls open and you're like oh I'm done great so it's been it's been an amazing treat for us after dealing with some some other harder to use systems we've also found a lot to love about the plug-in architecture of the modules and we've created our own module with our own templates and some of our own code but we've also you know for instance I mentioned the cache we don't use the the built in Magnolia cache we simply don't build that when we build our system it's easy to just add and remove pieces and that's worked out really well we've been a very pleased with that yeah and being able to separate our stuff into a discrete module also helps with merging with taking in the vendor code and combining it with ours yeah we don't have a lot of a lot of mixing and matching today and upgrades this used to be in the bad group in the bad column now it's in the good column because of the version management framework that was provided we have we did monthly releases where we did some iterative changes added some new features and then did a release then a month later did the same thing to get a constant flow of new features out for our users each month when we did that without the version management architecture the upgrades took well we started at nine o'clock in the evening and we went home at two o'clock in the morning most of those mornings and with the version management architecture that went down to I think our best time was 15 minutes yeah makes it I made it incredibly easy after that yeah the first one handler stuff basically lets you automate all the upgrade tasks that are associated with doing a new release so so we're able to essentially do a dry run in advance sort out all the problems that we would have found at midnight when we're not at our very best and take care all that before we ever dive into the production system so the bad thinks that we've experienced with Magnolia it's not all you know roses and rainbows and all that between the author in the public instance we've had a lot of synchronization issues where pages are deactivated on the author instance and they're still there on the public instance they just get out of sync you Ivies you you IDs get out of sync and that causes activations to fail and then our users have to call us so that's been frustrating and less than it used to be but it's still right is it look better yeah it has improved definitely the backup mechanism and particularly recovering data from the backup mechanism is awkward the backups for our system take about three three and a half hours every night and to be able to let's say somebody deletes a page out of their site it'll take us possibly 45 minutes to go pull that backup file import it into one of our dev instances sort down to that particular page export that again to come over to our production instance you can see where I'm going with this that's been awkward for us and you know the versioning that's included in Magnolia doesn't really help with deleting pages so this is still something that we find we have to use even we don't currently use the version the versioning tool that's available in Magnolia but even if we did this wouldn't really help it with particularly with deleting content the one of the big ones for us also is accessibility the admin central is not accessible to blind users we have several users on our campus who have to use a screen reader to be able to use websites and they manage these websites and they have tried to use Magnolia and it has not worked for them we've had to actually provide alternative options for them to be able to manage a website and I was heartened a little from the direction the standard templating kids taking because they are paying attention to accessibility for the front end with that and I presume Vivian and company are probably giving that more attention on the back end at this point when they're working on the next generation of the user interface for the editors and a lot of the reasons why it's not accessible can be pretty easily fixed a lot of it has to do with the mouse gestures a lot of a lot of actions that take place in a man in admin central use the right-click on the mouse and it's it's a hard concept to get across that blind users don't use the mouse there's no there's no use for so it's all keep work driven so unless there's keyboard equivalents for actions in the admin central it's not usable by them and the last of the the bad points is the end user documentation when we first started using it it was pretty good we needed to add in some extra material specific to our installation make a few edits here and there that was for three oh when we moved to three five enough had changed that we had to go review the documentation and the documentation that Magnolia provided did not keep up with that they they were quite a bit behind the release in updating the documentation so we had to rewrite a fair amount of what we had and give it to our users nothing okay so a few few numbers about our users we have a 97 percent rate of recommendation which means 97 percent of our users have said in surveys that they would recommend the system to another person that is incredible that number is extremely high for this sort of service system yeah ninety-seven percent of nobody at the university agrees so that's a miraculous some user survey results we were in we've run several surveys and a few things I want to point out the common look and feel that that we've somewhat enforced on everyone is our number one complaint that they look like everybody else and our number one our number one liked of the system is the ease-of-use number two is that the common look and feel so it's not only is the common look and feel the thing people dislike the most it's also the thing aside from the the ease-of-use that they like the most so obviously the campus is conflicted on that particular issue people don't even agree with themselves apparently right and word of mouth a lot of the users that we have in the system now we didn't even talk to we didn't know about some of them have approached us and we didn't even know this particular group existed on our campus and they came to us because they heard about it from someone else that has that has been responsible for a great deal of our adoption but it was also really pleasing to know that that 97% of people who would recommend us to someone else is actually happening in practice as far as our growth over time have 240 sites in a single installation all those individual pages at the root level and those are attached to URLs through the Apache rewrites for our first day of classes which was August 26 yeah so just a few weeks ago in a single day we served three hundred and twenty-seven thousand page views in that one day just a few other numbers it was over eleven thousand requests are so sorry eleven million requests and sorry a server for the front end there were five doing that and that goes through our through our caching architecture that we had and we had an average response time with about 60 milliseconds for each of those requests which I'm very proud of and a quick graph of our adoption over time we're really proud of this because it's just sharp steep curve of our adoption we clearly had our high growth time in late 2007 we started to level off between our public instance in our edit instance gives us a good idea of how the number of sites that are on each one gives us a good idea of how many sites are still in development and those two numbers have started to come together now so the people who the sites that are on edit the more the most of them are on our public instance now which means they're done and they're in use do we know how many are in progress at the moment I do not I think it last time I checked it was about 60 sites so we're in progress at the time and these numbers are just our life sites here not the one the Lawrence currently being edited right now yeah we have eight hundred users eight under individual users we for every site we have in there we have a role sometimes more that the users are assigned to and anything else you want to add on the stone size of it all okay in that case your turn anything you want to ask I'm sure those figures exist but the administration has been pretty cagey with how much was actually spent on the various systems we know right now we have what three Enterprise licenses for Magnolia three months I'm not sure three or four licenses and it is significantly less than we were paying for maintenance lengthen yet but I don't know exactly how much de difference is I can't tell you it's substantial I am probably on an order probably on a one order of magnitude difference we used to use the Berkeley DB that had a lot of corruption issues for us we switched to using MySQL and that has has worked out really well for us i tribute most of that to the fact that the database engine is separated from the JVM the Berkeley DB being integrated into the JVM means that the database is much more prone to corruption if something were to happen to the the JVM since it's separated out mysql has an opportunity to rollback a transaction that didn't complete for instance but also my school has been around for so much for so long and it has a good trusted reputation for persisting data properly have you determined which features you created you're not still we're still adding new features a lot of it a lot of the new features that we have slated to go in and that have we have added came from our surveys and we we throw all of our new feature requests into a into a issue tracking system and each month we go through that list look at how many people have requested a particular feature and the feasibility of us being able to do it in the time that we need to and make a judgment call on which one to add at the time it works out well for us I mean it's a it's a very absol development kind of methodology that we've decided to use yeah we have a support organization we're from the development side obviously the support organization is actually grown to be a little bit bigger than the development side at this point and they they're really good about taking that user input and collating it and assembling it and reporting to us each week what sorts of things they've heard from people and what sorts of things people have been asking so we cannot do do any of this without them we win that's all expenses professional services resources yeah yeah what's a good light shines out a long way from Moscow life and resourcing the development is 14 watts of power sure well by way of contrast when we were doing our vignette implementation we had a consultant on full-time throughout the implementation and unfortunately we had a pretty high rate of turnover with those consultants too so we went through three or four before you still have a modem young we went through three or four different consultants before we ended our time with vignette since we've been with Magnolia we haven't we did have one consultant who stayed over a little bit but we decided at that point that this is straightforward and nothing we can certainly do the development in the house to stop hiring consultants at that point our development team is about four or five people and they're split among three or four major projects so on average we probably have half a person two two-and-a-half people all in our Magnolia implementation at any point and coordinating with with the home office back here in Basel has been a pretty small issue most of the time we the documentation is solid enough the user list has actually been tremendously helpful for us because there are people on all day through that and we can often get questions answered there and the since the support side of Magnolia has ramped up in the support address the email address that's available and we've had the contract they've been been very responsive in helping us in the few instances we've had problem so we haven't been able to sort out ourselves and Jana actually helped us just two weeks ago with a with an issue with our publishing and got a fix in and rolled out a new version of of the code within a couple of days that was very heartening to see send us your question why Chinese okay so Pascal mentioned in his keynote speech that Magnolia complies to the JCR standard I think they notice with harness that and I can use any useful it's all there the way in which that's been useful person and jumping if anything else occurs to you general but the way that that's most been useful to us is being able to choose the storage substrate that were building things on as Jeff had mentioned we started out using the berkeley database and had some issues with that switched over to using my sequel and it was actually an easier transition than I'd expected but once we've been in there it's been more stable as far as other tools that build on the JCR there's not much that we've used so far and there are third-party JCR browsers you can use to go in there and poke through your data and see what that looks like but it's also real easy just to export to XML and look at it that way one thing that may be in our future is our learning management system which is what the professor's use to give tests and present syllabi and have discussion groups for their classes is another open source project built on Sakai and they're looking at moving towards JCR as their storage substrate as well so that may have some promise for us in the future being able to have those systems talk to each other more readily anything else almost they we do pull the DMS module out of the maven repository but we build on all of the other pieces we have done a little modifications to the code in those modules so for those places where we have added new features or headed modifications to it we build those modules DMS is one that we haven't touched so we pull that out of them the maven repository instead for us migration of the base system and I think a lot Dora phones good to make an upgrade good morning it is time-consuming and we have lost a few of our changes over time I'm not terribly well-versed in the process responsible for that so I'm turning in mostly it's a way to keep all our code and subversion so most of what we do with that merge when a new version of the product comes out is is pretty much standard vendor branch management kind of stuff we have our our version of Magnolia over here and then bring in magnolias version and then merge that into our code yes yeah and usually since since they've split things out into modules now as I'd mentioned earlier it makes that merge simpler because our code is generally in its own little space there are a few things in the vendor code that we've tweaked so that's why we're actually doing that merge that way but for the most part it's pretty straightforward and though the work we end up doing usually is just testing our templates making sure they still work with whatever change has been made in the vendor in the vendor code and making whatever adjustments are necessary before we roll it out does that answer your question okay anything else all right well I'm guessing from the applause that they're finished over there so thank you all very much appreciate your time