In December of 2011, I started work at Washington University in St. Louis as a Programmer/Analyst II. After only 6 months of outstanding work, my supervisors began the process of promoting me to Programmer/Analyst III. I was a part of the Web Content Management team which manages all of the public facing websites operated by the University. These consist mostly of sites running on Microsoft’s SharePoint platform, so my work was mostly focused on branding and customizing SharePoint sites.
SharePoint is a platform originally built for internal use team collaboration sites, so getting it to work as a public facing website with a custom design is a bit of an ordeal. Through my time at WashU, and often from my direction, our sites became substantially cleaner, more maintainable, and more cutting-edge.
In addition to my achievements in front-end development, I also expanded substantially into building deployable server-side solutions using C# on the .NET platform to expand the functionality of our SharePoint sites. These solutions usually included manipulating list data, and have also included custom ribbon actions and workflow behaviors.
Admissions
The Admissions site is arguably the most important in the WashU catalog, as student admissions lead to the enrollment and tuition that drive the university. I headed up our team’s undertaking of simultaneously migrating the site from SharePoint 2007 to 2010 and implementing a brand new responsive design.
At the time of its deployment, the Admissions site was, from a front-end perspective, the most complex SharePoint site our team had ever created. Several top-level categories required their own custom page layout, the home page and Life @ WUSTL page each required an immense ammount of development time to perfect their responsive behaviors, and several custom layouts had to be made to accomodate web applications created by the Admissions dev team.
Newsroom
My first major project at WashU was Newsroom, and to say it was a hit-the-ground-running situation is probably an understatement. The project was migrating Newsroom from SharePoint 2007 to 2010, and our department had attempted it several times previously (Newsroom is a highly customized site, and it was also the first site we migrated from 2007 to 2010. Hindsight shows the wisdom of that decision was… questionable).
The bulk of my work in that migration involved reconciling the thousands of lines of custom CSS used in Newsroom with the 7500 line corev4.css file at the heart of SharePoint 2010. Because of my role in the Newsroom migration, I inherited the role of lead developer on the Newsroom site. Since that initial migration, I have spearheaded several functionality enhancements to the Newsroom site, usually focused on streamlining the writing and publishing process for the news writers.
Newsroom was also the impetus for creating most of the custom ribbon actions that are the focus of this blog post, including the generic embed tool that is one of the gems of my programming career thus far.
Research
The Research department at WashU is one of the most important pieces of the University, and their website plays an important role in their interaction with the public. The site contains a custom feature set similar in scope to that of Newsroom. Also similar to Newsroom, I began working on this project as it underwent the migration process from 2007 to 2010.
Much of the custom functionality built for the Research site broke almost immediately in the 2010 environment. I had to rebuild a custom cascading lookup fieldtype for the 2010 environment, and then rewrite several classes and event receivers dealing with workflows.
The need to change the cascading lookup fieldtype (detailed in this blog post) also kicked off the process in which I created a pair of user friendly console applications to migrate data from one column in a list (in this case the old, non-functioning cascading lookup column) to another (the new cascading lookup field). I wrote these console apps to be generic and easily reusable for any set of columns in any list on any site.
The Research site was also the first in which we encountered the “forced visual upgrade” problem with SharePoint 2007 sites that were migrated to 2010 without undergoing the visual upgrade. More details on that problem and the event receiver I wrote to fix it can be found in this blog post.
Student Health Services
Unlike the above two, the SHS project was a brand new launch into SharePoint. While the site doesn’t use much in the way of custom functionality, it is a highly customized design that has very little in common with other sites we’ve created.
I was the only developer involved in creating the SHS site in SharePoint, and I took our basic template site (which at the time looked something like this) and in a matter of a few weeks turned it into the custom design as it exists today.
Other examples of sites in which I’ve played a similar role, taking comps from our design department and turning them into functional SharePoint sites include Student Financial Services, Community Service Office, and soon the newly designed Undergraduate Admissions site.
Template Site/Responsive Design
As linked above, when I started at WashU our Template site (the site on which all new sites are based) looked like this. It took quite a bit of time and many, many meetings, but we finally got a new template site to work from. One that looks like this.
If you take the liberty of adjusting the size of your browser window (or if you’re reading this on a phone) you’ll notice that the site incorporates responsive design, one of the most important concepts in web design and development today. While you’re at it, adjust the size of your browser window on this site too and check out the responsiveness.
In addition to being made the lead developer for keeping our template site up to date, I have also taken on an important role in establishing a more coherent process for managing custom designs coming from the Public Affairs department and being implemented in our department. This involves, among other things, creating a stripped-down framework site making it easier to build a custom look on top of a working SharePoint site.
One of my rather lofty goals that I hope to accomplish in this project is to weed through the 7500 lines of CSS in the corev4.css file and remove everything that isn’t required for the ribbon and edit controls to function. Another lofty (and less likely to be accomplished) goal is to find out what JavaScript files aren’t required for anonymous users and make sure that those files aren’t loaded unless a user is logged in. This would hopefully cut down on what is currently an absurd number of HTTP requests made during every page load on a SharePoint site.