If you blinked, then you most likely missed it, and that was completely by design. Wednesday morning our office, in conjunction with the IATS CMS staff, re-launched the MU homepage except this time it was in CascadeServer, our Content Management System. There are a few things I learned that I'd like to pass on to all of the new kiddos joining the CMS crew.
Firstly, I found that it's imperative to have a working knowledge of your entire site...and not just where everything is. The fine details are integral in making a changeover of a site in the system smooth. For instance, knowing how you link to other items in your site is very important. Personally, if I'm linking internally I prefer relative linking (/blah/index.htm). I understand that some people advocate absolute linking (http://www.blah.com/blah/index.htm) whenever possible to optimize search engine rankings, but within the system it causes some issues whenever you're testing. Because there's the development server available for testing, you won't want to be hard-linking to www-dev.blah.com because you'll have to go back and change all of those links whenever your site goes live at it's actual address. Also, it keeps the development server available after launch as a sort of "proving grounds" for any additions to your site.
On the usability front, my goal in moving the site into the system was to keep it as simple as possible so that the daily upkeep of the site could be accomplished by the content holders in an intuitive way. I didn't want the edit screens to get too convoluted so I ultimately tried to stick totally to simple text editors on simple pages. Hopefully this will allow for an easy learning curve for non-technical users in the system. The news feed we use for the homepage links was originally an XML file that Josh or I had to edit manually. Within the system I was able to turn that into a page and then output it to the Web as XML. Making it a page in the system allowed for me to be able to add a custom set of form fields, much like a Web form on the edit screen, so anyone in our office with, at the least, basic Web skills can go in and edit the News feed. This frees up Josh, Niki and I from having to make menial updates to code.
I've also utilized the Expiration Date feature for the first time. If you've noticed in the past, sometimes we haven't been able to get certain featured events down off the site over weekends or immediately after they expire. This is bad for many reasons but mostly because it makes us look like lazy Web developers...and no one wants that! We're lazy enough as it is.
So what I did was make each event into a page in the system that doesn't publish. Their sole purpose is to allow for an index to be pulled into each page that has events listed. A user goes into the system, creates a "New Event," chooses an expiration date, and adds the event info which usually amounts to the date(s) of the event, a short description, and a link to an off-site page for the user to get additional information. Once the event is created the page(s) that need that event get published and the event is live. Now the beauty of it all. Once the event is expired it automatically gets pulled from the folder that's being indexed into an "expired events" folder where it no longer is indexed. The site's pages that have events are set to publish twice a day: at 6:30 in the evening and 1:30 in the a.m. Vóila! No more out-dated events! Now we have more time to be lazy. Hooray!
These are just a few of the little tweaks I've made, and I'm sure there will be more, to help streamline the MU Homepage in the system and free up us developers to do other more develop-y things in the future.
Leave a comment
Note: Comments are moderated. If published, comments may be edited for length, style and clarity.