OSU Web Services

[youtube http://youtu.be/iUglNnO0s5M]

The close of Drupalcon 2013, held in Portland, has left me with lingering, fond memories of 3,300 nerds gathered in a glowing Drupalicious camaraderie. The convention was a great success, despite the rain and ever present Wi-Fi issues.

So what, you may ask, was my personal highlight? Maybe it was the tantalizing sneak previews of Drupal 8 with all its built-in mobile goodness? Perhaps it was the really excellent sessions that were provided in the brand new and much needed Education and Government track? Or, was it possibly getting my photo taken with User-1 himself, Dries Buytaert, and giving him some of our very own OSU Drupal swag?

These were all great things. Really they were. But, ultimately, they all pale in comparison to the keynote address given on Day Two, in my eyes at least.

This particular keynote, “Thriving in a World of Change: Future-Friendly Content with Drupal”, was presented by Karen McGrane, a world-renowned user-experience designer and content strategist who has led content projects for The New York Times, Conde Nast, and Time. In addition to spearheading projects for enormous publishing corporations, she’s also a managing partner at Bond Art + Science, a UX consultancy she founded in 2006, and she teaches Design Management in the Interaction Design MFA program for the School of Visual Arts in Manhatten.

In short, this lady knows her stuff, folks. If you’re a content author, site architect, or web developer on any platform, I strongly suggest taking a peek at what she has to say regarding content structure and strategy. You will leave more informed. You might even be a little entertained. You certainly won’t be sorry.

Please note that the actual keynote begins at 11:30 minutes into the video.

This was the biggest DrupalCon yet with over 3,300 people, and a substantial number of them were from Higher Ed. My presentation on how we do Drupal at OSU, was the first day of the conference, so I had people connecting with me the rest of the week to talk about how they are doing Drupal at their school. For the most part we are ahead of most of the other universities I talked with as far as our use of Drupal for our campus websites. Some schools have accomplished more on the technical side of what can be done with Drupal, but do not have the buy in from the majority of campus the way we do. Few schools have been as successful in providing centralized Drupal hosting and development as we have. I attribute this to our partnership with Web Communications. It is clear that the schools in which the IT and Marketing departments have formed good working relationships are the most successful when it comes to providing a high quality unified web experience across the institution.

Another big topic of discussion was in the way Drupal is used, not just in education but everywhere. We call Drupal a content management system, and indeed it is a very powerful content management system, however for the most part we, and others, don’t really take advantage of these capabilities. We tend to use Drupal more as a Web Publishing System, which really is very different. What people have wanted out of Drupal is for it to be like a word processor for the web. People like the wysiwyg tools and the familiar Word-like tool bar. The problem is that the web is not like a printed document. It was a fairly easy leap from print publishing to web publishing when web pages were viewed on desktop systems that provided roughly the same page size as a printed page. We have now irreversibly moved beyond that to where we need to be able to deliver our content to devices of every size and configuration. The old word processor model fails miserably in this new environment. Many of us in web development have strived for years to separate content from presentation. This has become more important now than ever and Drupal can really help with this, but not if we continue to embed HTML markup into our content through the use of a wysiwyg editor. Rather content needs to be managed with metadata that semantically describes what the content is, not how it should look. So we say that a piece of content is an address or a phone number, or a course description, or a an event title, etc. Then we can present the data in the best possible way for whatever device is displaying it. For the web this is still HTML markup, but for other devices it may not be HTML at all.

In working with departments on their websites recently we have been trying to put this more into practice. We still see so many sites where people have hard coded directory information like names, phone numbers, and e-mail addresses. This data then is carved in stone in that it is really difficult to keep up-to-date. What we want to do instead is to treat the content as data, and store it in fields, and then use views to present the data in a variety of formats. Drupal is really good at this, but we’re not fully taking advantage of it’s strengths. If we start now we’ll be in a much better position to deal with the next game changing device that comes along and needs to display our web content.

This was a great DrupalCon for OSU. On Wednesday night there were about 15 of us that went out to dinner. We rarely get a chance to socialize like this a work and we really enjoyed it. We vowed to continue building the OSU Drupal community and to include some social gatherings at least every couple of months. We don’t want to have to wait until the next DrupalCon to get together again. So if you work with Drupal, or the web in general. Please join our community group and attend the next meeting. More information is at http://drupal.oregonstate.edu.

At least 12 of us from OSU will be at DrupalCon next week in Portland. This is an exciting opportunity for us to connect with people from all over the world who are involved with Drupal. This year DrupalCon is offering a new track for Government, Non-Profit, and Education. For the first time at DrupalCon there will be sessions devoted to the unique challenges we face as a university, as well as sessions that showcase what some of our peers are doing with Drupal at other institutions. I have the honor of presenting the first of these sessions in which I will discuss how we’ve managed to support such a large scale Drupal environment, and some of the interesting things we are working on. My session has been selected as a featured session – http://portland2013.drupal.org/program/sessions/featured . This really puts the spotlight on OSU as a leader in the Drupal higher-ed community, and extra pressure on me to represent the university in the best possible light. This is a great honor for me and I’ve been working hard to make sure I have a good presentation and that I’m well prepared to give it.

One of the challenges we always face at DrupalCon is to make sure we stay focused on the issues we need to solve here at OSU. This year there will be a lot of sessions devoted to the upcoming release of Drupal 8. Of course we are hard at work on Drupal 7 and still have a long way to go getting our sites onto that version. We know we have to balance our need to stay current and make sure we understand the new things that Drupal 8 brings to the table, with our need to find solutions to the things we’re encountering everyday as we move further into Drupal 7. Fortunately there will be a good mix of sessions that should allow us to do that, and even though there will be much buzz about Drupal 8, we know it will not see wide spread usage for at least two more years.

This will be a busy week, packed with lot’s of learning opportunities, and meetups with people doing the same things we are using Drupal. A couple of us may try and do some blog posts during the week so stay tuned to this spot for updates.

—
Paul Lieberman
Central Web Services

As we looked at how we would upgrade all of our Drupal 6 sites to Drupal 7 we realized we had a big problem. Big as in over a thousand individual Drupal sites. We have become the victim of our own success in that we made it too easy to create new Drupal sites whenever we received a request, without first asking if a new site was really necessary. Drupal itself scales very well. It can handle much bigger sites than we currently have. By creating so many smaller sites we were actually making it harder for people to get around on our pages because larger sites became fragmented with no global navigation between the various units. It also made it harder for people to share data across sites, which caused unnecessary duplication of data input. Finally it created a lot of administrative overhead for CWS to keep this many sites upgraded.

We made it a strategic direction for Drupal 7 to begin consolidating as many small sites into their parent units as possible. We knew the first issue we would have to face is how to divide up the authoring responsibilities while maintaining ownership for different parts of a site. It turns out one of the reasons we currently have so many sites is because different people are responsible for content creation and wanted to make sure other people would not be able to modify their work. While this problem could easily be solved by just getting some agreements between the various authors on a larger site, we wanted to be able to assure people that we could prevent this possibility through Drupal permissions. We also knew that people wanted the ability for their sites to have some distinctiveness. While all of our Drupal sites adhere to the branding guidelines set forth by Web Communications, there is still room for sites to provide certain characteristics unique to their department or unit. We set out to find a solution for this.

What we came up with is a Drupal module called “Organic Groups”. The organic part does not mean that the groups were grown with abundant amounts of compost, but rather that they are flexible enough so that groups can be configured in a variety of different ways. For example we knew that colleges would need to build groups for their schools, departments, and programs whereas administrative sites would have a variety of working units that will need groups. After some testing we were confident that the Organic Groups module was going to suit our needs and so we started the work of communicating with people about our plan, and get some sites on board.

Central Web Services is a devision of Media Services which is in turn part of Information Services. There are a number of other units under IS including Enterprise Computing Services, Network Servies, and Technology Support services. When we began the task of updating the IS site using Drupal 7 it was agreed that we would consolidate a number of separate websites into the IS site using Organic Groups. The IS site is organized around the services that we provide. Each service is a group. Each group is also part of a service category. We are still in the process of converting all of this to Organic Groups but it looks like its going to work very well.

On the academic side of things we also have been working with the College of Liberal Arts to upgrade and consolidate their sites. We currently have the parent college site in Drupal 7 and are working with them to migrate the departments one a time from the old Drupal 6 sites. For a college the groups map nicely to departments which group into schools. Each department can have it’s own set of rotating features, highlights, directory listing etc. The department and school name also show up as the site name along with the college. Departments can have their own content editors, or and editor can work for several departments. There can also be college wide editors who can help with all of the departments if that is the way they want it.

Art department site name showing the school and college

Department name becomes the main site name, while the College and School names are combined above, with each linking to its respective front page.

Once we have completed CLA and IS we will begin working with other departments to consolidate and upgrade sites to Drupal 7 at an accelerated pace. The end result will be better websites for everybody.

If you have turned on Jetpack on your site, and are collecting stats, at the very bottom of your site you might notice a little smiley face. If you are like me, you will find this just a little bit annoying. How did it get there? Is this a bug? Is there something wrong with one of my posts? The answer is no. It goes back to using Jetpack and collecting stats. Since you are using the power of the WordPress cloud at wordpress.com when you connect Jetpack, WordPress inserts this to indicate stats are being collected. Well and good, but if you are not in a smiley frame of mind, it’s very easy to fix.

To take the smiley off your page, go to the Jetpack dashboard, and click on the Configure. In the configuration options you will see a checkbox to “Hide the stats smiley face image.” Just check that and save and you are smiley free, and free to smile.

With this next update of WordPress, we have updated WordPress core as well as plugins, and have introduced a new plugin called Jetpack.

What is Jetpack? From the makers of Jetpack, they say “Jetpack supercharges your self‑hosted WordPress site with the awesome cloud power of WordPress.com.”

From our standpoint it is a number of WordPress modules that will add some benefit to your site, including site subscriptions, posting a blog post via email and more. But to use Jetpack you have to understand the peculiarities and actually see if some of the features will work with the theme that is being used. In a nutshell, the theme has to be able to support Jetpack.

We are outlining some of the steps and peculiarities that we have encountered in our testing with the OSU Responsive theme which is the primary theme we are testing against at this time. All other themes are unsupported for Jetpack at this time.

Steps to use Jetpack

1. First you will need to connect to wordpress.com, which means you need a wordpress.com account.

Best practice for departments and organizations. Create a wordpress.com with a generic account. That way it can stay with the organization rather than with an individual.

Why do you need a wordpress.com account? The plugin itself uses wordpress.com’s cloud infrastructure to do some of the processing, and where we can offload some of this is a good thing.

2. Then connect to Jetpack from the Jetpack Dashboard. Once you connect to a wordpress.com account, you will see the Connected in your Jetpack screen navigated to from your Dashboard.

3. Next is to look at the variety of options and activate the ones you would like to use. Please note that not all of these might work with the theme that is being used. For OSU Responsive, WordPress.com Stats, Subscriptions, Carousel, Like, Post by Email, Sharing, Contact have all been tested in our limited testing capabilities.

Please note the Contacts feature of Jetpack is not compatible with the Sociable plugin.

You can disable Sociable under Plugins menu located on the left in your administrative menu.

So you get all that done and you decide you don’t want to use one of the features any more. But where to turn it off? It wasn’t intuitive when I first went looking for it, that was certain, but a quick Google search found the answer.

Once a Jetpack feature is activated, there might be a configure button there. If it is clicked, it will expand the area, and it is in that expanded area that the Deactivate button will be. Why there? I don’t know but after using it a few times, I was able to manage remembering where it was the next time around.

Overall it looks like some good pieces are there. As you are using this, remember to keep in mind everyone. There are accessibility policies to keep in mind, as well as just a general sense of if you really will be using a a feature that is activated. As we get more information we will put up, but the best thing right now is to visit the Jetpack site for more information. We’ll be writing more as we use the features ourselves. As always we would love to hear your feedback, so try out the contact form that we’ve just put in as part of the Jetpack feature set and send us some feedback about your experience with Jetpack.

In the intervening time between our blog posts, we still have some work to do to fix the Responsive menu structure. More than one level deep in a menu and it isn’t too useful and on the mobile side, the mobile menu has a bug we know about that does not expand it beyond a certain length, making part of the menu not visible. That fix is in the works.

At this point, however, we want to give you the ability to take off with Jetpack.

One of the issues that had plagued EvalS (an evaluation performance application/portlet) from the beginning was a performance issue. EvalS was the first jsr 286 that we wrote for the Luminis portal. During the first several releases we worked hard to improve the performance by reducing the # of queries and caching whenever possible. In the past, whenever a person would first load the portal page containing EvalS it would take about 5-6 seconds for it to finish loading the page.

This EvalS performance defect affected all users, only after their initial login. This type of performance was not something we were proud of, so over time we worked on improving the code base, and performance of the backend code. A few months ago, we dedicated some resources to finally fix the problem once and for all.

Our initial assumptions were that the EvalS specific code was slow due to it not being optimized for the number of employees and jobs at OSU. This assumption proved to be incorrect once our development environment included enough random data to match the amount of records in production. After a careful analysis of EvalS and the differences between production & development, a small piece of code external to EvalS, but which EvalS relied on was the identified as the culprit.

The problem:
When a person first accesses EvalS, the application needs to figure out the ONID username of the person. It was this piece of code causing the problem and slowing down the application for the person when they first logged into the application. We never expected this piece of code to be a problem, that’s why we didn’t look into it at first.

The Luminis portal doesn’t store the ONID’s username in the User_ table of the portal. Instead it uses a random # and stores it in the “screenName” column. This is the column where the ONID username would usually be stored. We use an sql query to translate between the random Luminis # assigned to each user and their ONID username. One of the joins this query was using didn’t contain the necessary indexes. This was making the query slow.

The solution:
The fix was rather simple once the culprit was identified. The owner of the external query created a new table that we queried instead. This table contained the necessary data along with needed indexes. EvalS now queries this table and the speed has improved drastically.

We should have challenged our assumptions when we were troubleshooting this performance issue, but we have learned some valuable lessons from our mistakes, which will be helpful in the future. In current and future projects, we now test & analyze the performance of the application early during the development stages. Our development environment now includes enough random data to match the amount of data in production and allow for growth. Moving forward in this way allows us to demystify application behaviors.

It all started with a simple question, “Can CWS help us build a website that our student body can use to vote with in our April elections?”

The question, posed by ASOSU Organizing Coordinator, Drew Desilet, came to CWS in mid-February. “When it came time to look at building or buying a new voting system for the student government elections, it was clear we had two options. We could choose to buy an outside product that came pre-made to someone else’s standards and needs, or we could work with our own CWS partners on campus to build us something to suit our needs.” he explains.

It should be clearly understood that the delivery of a complex, finished website or web application within a two-month timespan is a mighty tall order. Additionally, there were a few tricky specifications that the site needed to meet, one of which includes the ability to limit the voting population to a specific segment of the OSU community, namely, Corvallis campus students.

Ultimately, the answer given to ASOSU was “Yes, we can.”

It did take a few extraordinary elements to get it up and running on such a short time-line, though:

Great customers who provided exceptionally clear specifications
A rockstar programmer who didn’t miss a step from the beginning to the end of the project
A diligent project manager who smoothly coordinated all those extra things that threaten to derail a web-development project
The OSU Drupal profile, combined with the Election module, a special contributed module that can be found at drupal.org

“We’re very pleased with the way this project played out.” states Jean Waters, CWS project manager. “Using the Election module really helped us get this project up and out in such a short time. In fact, there are still some really nice features that came with it that we haven’t even had a chance to fully examine yet.”

The Election module is based on a new Drupal 7 concept known as “Entity”. This is still a fairly new concept to the Drupal team here at CWS, but team member Ricky Middaugh was up to the task. “It was a unique challenge, having to work on something in Drupal that I didn’t know a lot about.” comments Middaugh. “But I’m really pleased that we were able to provide something useful to OSU.”

And the ASOSU provisioned gift just keeps on giving, explains Jos Accapadi, Associate Director of CWS. “Thanks to ASOSU’s willingness to experiment with us, the groundwork has been done, and now we’ll be able to quickly spin up sites for other political organizations here on campus.”

Desilet agrees. “We’re already working with CWS to make system improvements for future years – mobile capability, streamlined candidate entry, candidate profile pages, and a few other minor changes – the voting system has worked out very well for our needs in the ASOSU, and it’s our hope and plan to continue using it for years to come. It’s a system other groups on the OSU campus, or really even the entire Drupal user base, can use for a voting system in the future. It would be nice to see this used across the university for any type of voting, and make it as common to ONID users as BlackBoard is now, or Gmail is to come.”

The new voting site has already passed the Primary election test, during the week of April 9th – 12th. “So far we’ve had 2,118 voters run through the system without any hiccups of which to speak. Modifications for us between our first Primary election and our General election were minor, and largely administrative based. Therefore the tool the students will use will look and feel the same as the first time they used it just weeks before, however it will work even better for us as election administrators.” says Desilet.

The site will be ready for use for the General election, starting Sunday, April 21st, at 10 p.m. and running through April 26th. Voting will be open to Corvallis campus students. To get there, just go to http://asosu.oregonstate.edu/elections and click the big vote button.

You just put the finishing touch on your Drupal site, all the images are just right, the calendar feed has your events displayed and every bit of content is informative and engaging. It sounds great, but here are some things you should know about live sites and some checks you should do for your site before deployment.

Links, images and navigation, these are the cornerstones of a good site. We have some ‘best practices’ items you should check before pushing your site live.
Menus – part of the navigation system your visitors depend on in order to find relevant content on your site.
Brand Identity Guidelines for OSU web content. Does your site measure up to University expectations, we’ll show you how to find out.
Do you have contact information? It can be very aggravating if a user doesn’t have a way to reach out to someone in order to have a question or concern addressed.
What do you need to do after your site goes live? Yes there are things you should check after your site is moved to production.

All of these items and others are covered in detail at http://oregonstate.edu/cws/training/book/drupal-deep-dive/osu-drupal-site-procedures/drupal-deployment-checklist.

CWS is happy to present Doug Fir, the latest theme in the OSU Drupal 6 distribution.

the web, table, and phone views of doug fir — Doug Fir – What Responsive Looks Like

Designed by WebComm and engineered by Central Web Services, Doug Fir has been developed similarly to OSU Standard in regards to configurable theme options, integration with Google Analytics, and layout regions, but it sports a fresh, clean look which is consistent with the default theme that will be supplied in our upcoming OSU Drupal 7 distribution.

Using Doug Fir provides us with two distinct advantages:

It allows OSU Drupal 6 sites to look like OSU Drupal 7 ones from the front end. What this means is that you don’t have to panic if you’re not ready to roll into OSU Drupal7, instead you can just easily switch the theme out by following the Switching to Doug Fir instructions found in our CWS Training site. (We realize that sometimes these things can seem tricky. If, after reading over the instructions, you still feel nervous about making the switch, just submit a Help Ticket to us and we’ll be happy to lend a hand.)
The bigger advantage to using Doug Fir lies in the fact that the theme is responsive. What this means is that the display will automatically adjust, as needed, to fit the screens on your mobile devices. It doesn’t matter if your device is a tablet or smartphone, the responsiveness of Doug Fir will give you a nicely formatted appearance.

Want to see for yourself how a responsive theme works? It’s really easy to do. Just go to a site with a responsive theme and resize the width of your browser window. You’ll immediately see how the layout responds. Take a look at a couple of early adopter sites who so graciously assisted us in the development of this theme: OSU Admissions and TAC (Technology Across the Curriculum).

OSU Web Services

Adaptive Content: How Drupalcon 2013 Made Me Really Happy!

Take Aways from DrupalCon

We’re going to DrupalCon

Our Groups are Organic

Don’t Smiley At Me: A Jetpack Tip

Takeoff! with Jetpack by WordPress

EvalS Performance Mystery Solved

ASOSU Elects to Use Drupal!

Drupal Deployment

Say Hello to Doug Fir

Contact Info