This site and all its helpful, fun content is moving…
…It’s true; we are moving! All of this content here is migrating to the website support area of the regular Lewis & Clark site.
Latest Updates RSS
-
Morgan Grether
-
Morgan Grether
Now View the Event Screens Info Through Your Browser
After a little update to our node.js server last week, you can now view on your browser the same information displaying on the event screens around campus.
There are three main channels of data, relating to our three schools here at Lewis & Clark:
- Undergraduate: http://on.lclark.edu/channel/undergraduate
- Graduate: http://on.lclark.edu/channel/graduate
- Law: http://on.lclark.edu/channel/law
The event screens have been here for almost a year now, and I for one think they have been a great addition to our campuses.
As always your feedback and suggestions matter, so please share them with me.
-
Morgan Grether
Improving the Righthand Navigation Menus
As previously mentioned, this summer we have been testing menu enhancements for Lewis & Clark. Today I am happy to announce we are launching these enhancements site-wide.
For instance:
- A “box-arrow” icon showing that a menu item will be taking you to an external site
- A triangle icon showing that a menu item has sublinks. This triangle turns 90 degrees when you open the page, and then back when you leave. (Note that LiveWhale “separator text” items in a menu will behave slightly differently.)
-
Lawrence Siulagi
Bulleted and Numbered List change
Cosmetic changes happen on a website throughout its lifetime. Some major, others so small they are sometimes unnoticeable. You may notice when you created a bulleted or numbered list using the LiveWhale tools, the indent has shifted a little to the right. This helps differentiate from the preceding paragraph content to let the user know that this is, indeed, a list.
-
nickshobe
Template Speed Optimizations!
The Results
On Monday I was able to add some significant improvements to our frontend CSS and JS aggregator script that allows us most of the same flexibility we had before, but adds both server and client side caching improvements. So far our average page load(full DOM load) time has dropped from a range of 2.3-2.5 seconds to one of 1.4-1.6. It’s always exciting when a simple improvement yields immediate results, but to shave off an entire second on an already fast website is difficult to achieve.
Combined with our earlier spring Apache changes we have shaved off two seconds from our fall average page-load time. For the most part we owe most of this to our new-relic performance monitoring for showing us where we needed to improve as well as providing almost immediate feedback that our changes where working the way we intended.
The Fix
The main change was to send 304 not modified when the various CSS and JS files haven’t changed. This tells the browser that it may use the cached version of it’s file rather then download the 30-40Kb of needed code on every page load. For comparison, a normal CSS file is about 30Kb(compressed) while the headers are only 298bytes. At first it was just caching and not sending the response, but now it even caches the aggregated files for five minutes because it seemed to save an additional 10th of a second on the server.
-
Morgan Grether
Improving the Righthand Menus
We have been testing out several improvements to the Lewis & Clark righthand menu system. For instance:
- A “arrow” icon showing that a menu item will be taking you out of the current area
- A triangle icon showing that a menu item has sublinks. This triangle turns 90 degrees when you open the page, and then back when you leave.
You can see the tests live on the following sites:
Feedback is welcome, as always.
-
Lawrence Siulagi
Printer love
When was the last time you printed out a page on the website and ended up with a lot of content you didn’t need (like navigation links and footers)? Well, now we’ve rolled out a stylesheet that prints out the essential content. Of course, this doesn’t include links to files like PDFs or Microsoft documents.
Word of warning: depending on your browser, the results may not be what you expect. We’re still in testing mode but your feedback is appreciated.
-
David McKelvey
IDATI, the road ahead
I have just completed a extensive roadmap document for the IDATI project and this, my last post to weblab, will serve as a update on the project. First of all, even before my departure delayed the schedule until a replacement is hired, we’d already altered the dates as part of the discovery during our initial tasks, so the schedule outlined in the introduction to the project is now being reordered and rewritten.
With that, I’d rather refine what’s coming as far as the roadmap suggests and that is largely based upon the evolution of the industry since our 2009 redesign.
At redesign launch, we’d used cutting-edge technology, content strategies and navigation designed to unify our previously siloed website, all wrapped up in a brand new content management system (CMS) LiveWhale. However, altering the underlying infrastructure, be it design, or navigation and content strategy, or the technical underpinnings is never easy for a site the scale and depth of the Lewis & Clark site, and so we’ve held off, being busy growing the site and its editors among other projects in the meantime.
However, we are now at a key period where it is exactly the right time to make major updates in the website. IDATI does this by (in no order):
- responding to navigational and content changes initiated with the merger of the institutional and undergraduate home pages,
- making significant changes to the top-level navigation and content,
- integrating space for the coming results of the strategic planning process,
- changing the website design to be mobile-friendly and more easily utilized by site editors,
- switching to newer LiveWhale built-in modules for a reduction in code maintenance and increased benefit as the system matures, and
- further centralizing the management of the website.
I have left my extensive roadmap in the hands of New Media, PubCom and key acting stakeholders of the website with the strict instructions that they should adapt it in the process of executing it. While posts will no longer be made by me, continue to watch this space for ongoing updates as to the process of IDATI.
-
David McKelvey
Built to Last
As many of you know, I am leaving Lewis & Clark at the end of this week to join White Whale on the first of May. (You might remember them from our redesign in 2009.) This is not necessarily a goodbye, since my task there will be to build the community of LiveWhale — the web content management system that Lewis & Clark uses — and I expect to be visiting from time to time, as I’ll be based in Portland.
This is a huge opportunity for me and I am happy to be joining the web-geek-whales. However, this does leave a hole in PubCom/NewMedia to fill. I’ll spend the the rest of this post giving you some basic information on the transition.
Tom is forming a search committee composed of major stakeholders of the website. Naturally, all three schools are represented along with IT and a few PubCom members as well. The director position was posted late last week to the HR website and it is being advertised. And as part of my departure, I am posting it to UWebD — the university web developers list — a bunch of people like me all over the U.S.
During this transition, Morgan Grether has stepped up to manage New Media. You all know him — he’s been my stalwart New Media colleague for years so I know you’re in good hands. Morgan is of course aided by Nick, our inventive coder, and both of them will be there to keep everything moving on the right path. Even so, during the transition please understand that the overall demands on New Media are unlikely to relent, especially with IDATI now in full swing, so be as patient as possible.
And with that I’d like to say thank you. I’ve worked with so many of you (the nature of our work touches so many) and enjoyed it all — I hope you feel the same. Now don’t be a stranger, if you give me a buzz, maybe we can meet up for picklebacks at the Woodsman.
-
nickshobe
“Agile” applied to our search re-design
See our search engine at: http://search.apps.lclark.edu
Design Strategy
From the begining of the search redesign project, we have focused our design efforts on keeping things simple and clean. Instead of trying to get everything perfect in the first release, we have smaller releases with improvements and feature additions over time. This process is usually a Rapid Application Development (RAD) cycle with agile coding practices. We primarily base our RAD development off a system called “build measure learn” and use a web application called “pivotal tracker” to track and manage our progress. This type of design methodology basically enables our team to quickly design, deploy and learn from our previous cycles. We then take what we learn and “pivot” or change our tactics to better address what we learned from previous cycles. What this means is most of the improvements we make are based on feedback from our users, bugs we find, or feedback from our web monitoring service. As our design improves, the frequency of needed improvement and feature requests continue to drop and we have a more stable search application.
Strategy applied
When we began the design process we had numerous ideas and features that we needed to analyze. We knew many of them would not make the cut, but we still wanted to have an awesome product that was easy to use with a clean concise interface.
At first we ran with a few crazy cool ideas about cutting edge interfaces, but we soon realized we needed to reduce our set of functionalities to the “minimum viable product” or the features that we just couldn’t live without. We tossed out several dynamic embedded designs for a more traditional one and moved some design elements to a future release iteration.
The initial release has a clean tabbed interface. The tabs make it easy to switch between having combined results and filtering by specific content types. Additionally we decided to integrate a Google site search in a separate Google tab.
Throughout the initial release phase we did a lot of “learning” about our design. One thing that we quickly discovered was our “recommended links” where often seen as as adds. Using our Pivot strategy we tried a couple of design variations, pivoted and tried another and finally found one that seems to work for most people.
Almost as soon as we deploy a change we are able to see it reflected in our feedback both for good and bad and then pivot to address those issues. Using an agile design and development strategy lets our small team respond quickly to issues and increase the quality of our products without sacrificing our sanity… Well what we have left anyhow
– Nick Shobe
