University of Colorado Denver – Episode #325

Site Scores:

Site Visual Information Code Overall
University of Colorado Denver 91 87 68 (246/300) 82% B-

Show Notes

Like what you see? Subscribe to the video blog through RSS, iTunes or sign up to receive email updates when new episodes are posted.


4 Responses to “University of Colorado Denver – Episode #325”

  1. Kevin Sherman Says:

    Hey Nick,

    Question about audience menus… At my current university, we don’t use audience menus, we’ve stuck to just the typical Admissions/Academics/etc. I’ve always been concerned about using audience menus because most sites tend to hide the Academics/Admissions/etc. menu, as theirs is all the way at the top and not very obvious. All those Noel-Levitz papers show that academics is the place students are typically browsing to first, so why not put it in your primary nav?

    But I really like the idea of a long-form home page serving as the audience menu. It seems to flow very well, but I can imagine my fellow Communications/Marketing team wondering where their news stories would go. All the way at the bottom seems silly (like the social media icons).

  2. Nick DeNardis Says:

    I think the audience menus really depend on the school. I don’t think it is a yes or no recommendation. I know personally at my school from our internal computer the “Directory” and “Current Students” menu items are the most used. But from the outside the “Academics” menu item is the most clicked. In our re-architecture we are going to keep them, but not make them the primary nav.

    I would love to see some analytics, heatmaps or clicktales from this site.

  3. Scott DeMers Says:

    Hello, I’m Scott DeMers, Web Production Manager for University Web Services at UC Denver. I wanted to provide an explanation (or rebuttal as the case may be) for the code portion of our site review. My purpose is not debate the reviewer so much as to provide useful info for other U web folks, particularly those considering SharePoint as a CMS.
    The blame (or my excuse, anyway :-)) for much of the code sloppiness can be placed at the feet of a CMS that was clearly intended by Microsoft as an internal knowledge management tool first and a web publishing system second. I won’t go into the details of why we chose SharePoint for managing a public website, but suffice to say that from a project perspective (time, budget, political pressure, established culture), my team was left with SP as the only realistic option for a CMS. The specific client-side code problems we deal w/ daily were touched on in the review:

    1.Log-in prompts for lists at 9:45. SharePoint uses lists as a foundation for data management, and this feature does always play nicely when used anonymously (not authenticated). Despite the headaches and drawbacks, our content managers feel this tool is too valuable not to be used in this capacity.

    2. Server-side redirect for mobile @ 14:39. Definitely not the best way of doing it. Server-side device detection is far superior, but our sys admin was unwilling to commit to the management overhead of some pretty straight-forward mods to IIS, mostly due to the complexities of managing SharePoint on top of IIS. Word-to-the-wise – if you are coming from Apache and find yourself in SP/IIS land managing multiple site collections, you may find it to be a bit of 3rd world country. As for the placement of the JS, this particular script will not operate any other way because of how our assets load (further down the doc and you get a partial load before the redirect happens – not ideal for the mobile experience). This was only supposed to be a temp solution until our responsive redesign happened, but now that that has been delayed, I’m going to have to resume this battle up again with the IT dragons.

    3.As for the incredibly craptatstic CMS generated code sprinkled throughout our HTML 5 (tables, mashed up inline stuff), from a client-side perspective, this is maybe the biggest draw-back to SP publishing. MS has done a terrible job of hiding the code anonymous users never need to see. There are ways you can optimize, and Waldek Mastykarz is maybe the best resource on the web for this, but the at the end of the day, you’re going to live with a certain about of ungodly cruft being shoveled at the client.

    4. The suggestion for the placement of the Google asynch code is spot on. Where we have it was proper for the traditional snippet, and we overlooked that. Thanks.

    5. I take issue with the statement we don’t know what we’re doing. We know exactly what we’re doing. What we are *not* doing is trying to produce the most pristinely front-end coded website known to man, because in this CMS it is impossible. What we are doing is pushing the envelope as far as we can for SharePoint 2010 publishing sites, and in that regard I believe we’ve succeeded. MicroSoft has recently published a case study of our efforts, and on the Redmond campus, our site is quite popular amongst the SharePoint team, particularly for demonstration purposes to clients (or so we’ve been told at conferences).

    Anyway, if anyone has questions, I can be reached at scott dot demers at ucdenver dot edu. Cheers.

  4. Nick DeNardis Says:

    Thanks for all the detail and insight in to the decisions on the site.

    I completely understand the constraints that the website is under and commend your effort. You provided yet another strong example to anyone considering Sharepoint as a CMS.