Cascade Server Publishing Queue
Despite positive results from stress testing the publishing queue when using the hosted solution through Hannon Hill, we were hit by numerous problems when we moved the service off Tarleton's physical site. Hannon Hill has been very helpful assisting us and our server team in troubleshooting the issues. While there are a few bugs that still need to be fixed on Cascade, we also found that many of the problems were user error. Moving forward, these are the things all web maintainers need to keep in mind:
- Unless you have made changes to the left navigation, footer information, or multiple changes across the website, you should avoid publishing entire folders. If you are publishing entire folders, please select only one destination: WWW/Full Site/WWW - main
- Make sure all files are named appropriately (i.e., no spaces, dates) and with common file extensions (i.e., filename.jpg, file-name.docx, name-of-file.xls, the-filename.pdf). Please use ZIP files for content that does not use common file extensions.
- Please remove all unnecessary files from Cascade, or we will remove them when they block the publishing processes from completing successfully. Cascade is not storage, and the web server cannot handle non-Windows based file extensions (i.e., files only used on Macs).
Presenting Our Experiences at the Technology Summit
Many members of The Texas A&M University System have not made the inevitable leap to responsive design, so the System invited us to present our experiences of going responsive, completely in-house with a full-time staff of only four people. Our entire full-time Web Services team will be there to present on the topic. The below mentioned Project Management process change will be a part of our Lessons Learned as we present to our fellow System members our timeline for converting to responsive.
No conversion should be done without serious thought and understanding of this complex technical process. As we compiled our timeline, we also looked at how many training sessions, webinars and conferences we've attended to get to this point. During the last several years, we've participated in at least 57 total training sessions: 19 with topics more focused on accessibility, 26 on content strategy, 27 on web development, 18 on marketing, 32 on strategic planning, and 12 on responsive web design. We feel like we never left college... literally and figuratively.
Daphne Hunt will speak with TAMU colleagues at an additional session on our experiences working with Hannon Hill's Cascade Server. Tarleton is one of the oldest members in the System to be using Cascade having started in the spring of 2009. That's right, we are in year six!
Project Management
We receive numerous tasks via emails, walk-ins, phone calls, and committee requests every day, and with our growing staff, it was becoming more challenging to track all these processes as well as keep everyone informed of what project was being done by whom. We are working on multiple solutions to improve this process.
New Request Web Updates Form
Located on the Web Services website, the new Request Web Updates page explains what updates and web development can be requested or needs to go through a different process. Once you've read through and become familiarized with the process, you can directly request web updates or development. Web Services may contact you for further clarification or instructions on how you can make certain updates.
These requests are automatically placed in our project queue maintained by Morgan Hammond who delegates these tasks to our student interns or office staff where needed based on the priority and due date provided in the request.
For the month of January, Web Services has completed at least 85 requests, including the design of numerous digital ads. We also started training two new student interns, Colton Sheffield and Yaritza Corrales, and we provided 4 Cascade Server training sessions in the Library Training Center.
Getting Sass-y Behind the Scenes With Process Changes to Web Development
While we make updates to the old website, we are still in the arduous process of building the new responsive web pages for departments to use. This is a very technical task and requires more than one set of hands (or creative minds) to accomplish, however, the way we've been approaching development has been quite old school and needs a millennial facelift.
For example, the web developer and web programmer in our office receive numerous requests all the time to make adjustments to our single CSS file which controls the look, feel, and behavior of our website. Let's say theoretically (though events like this really do occur) the University Digital Advisory Committee wanted to do AB testing of a module while we are fixing a problem with the latest operating system for iPhones while we are working on new responsive modules for departmental webpages while we are fixing the search engine results look due to a different bug. *deep breath* This is a time consuming process to compare all copies of our CSS for all the above solutions and implement a single CSS file with all the proper corrections. Without making any mistakes. *exhale*
Most web developers nowadays approach the CSS through a "preprocesser" (before compiling into a single file) script. CSS is a programming script for all the aesthetics and interactions you see on the browser, however, using an extension like Sass (Syntactically Awesome Style Sheets) or Less (commonly known as LESS) allows multiple developers to work on different aspects of the style without stepping on each other's toes and do so with programmers' favorite tools, like variables and functions, to repeat common processes without as much work.
This allows us to do proper AB testing where we can adjust a single aspect of the CSS file by compiling only certain Sass files and inserting them on test pages without breaking other parts of our CSS that we may be fixing on another set of Sass files. We control which pieces are available where we need them, moving large blocks of code instead of very small, delicate lines of code.
We go back and forth on when we should have started using Sass. Our plan in Project Squishy was to roll out the new responsive design during a time when the students could get used to it before classes started up again. We were more comfortable working directly with CSS, knowing that converting to Sass would be a huge learning curve and slow down that process. That being said, there are numerous instances, like the theoretical set above, that could have been resolved faster had we moved slower with the roll out of Homepage 1.0. Having many of the new modules in place behind the scenes for the departmental pages even before Homepage 2.0 was implemented, we are having to go back and convert everything to Sass to make the process faster in general. To be honest, it was going to slow development down at the front end or back end of the development process no matter what. Good? Bad? You can't learn without making a few mistakes. We think these will be good for everyone in the end.
