Entries Tagged 'xml' ↓

Drop the Mouse. Put Your Hands in the Air. Back Away From the UI.

Our intrepid CIO, Justin Webb, has far too much common sense for his own good. He’ll never make it in this town.

Seriously, Justin and I were here together in 2008 for the coming of Sharepoint (before he was CIO). He and I slogged through the implementation of that baby over an 18-month period that felt like it would never end. It gave birth to a bouncing baby EagleNet.

Since November of 2009, EagleNet has been our University’s portal. “Portal” is one of those words that sounded SO sexy in 2003, but by the time we got to Sharepoint, we had seen the communications, training, and maintenance headaches that portals can bring. The dream of aggregating communications based on ERP data about a person’s role is a good one. The problem is, the companies that deal with data should be told to, “Drop the mouse. Put your hands in the air. Back away from the UI.” (and no one will get hurt).

Sharepoint is one of those nifty all-in-one tools that aggregates, collaborates, authenticates, productivity-ates, and gets-us-cute-prom-dates. It’s another of those motherships that promises all things wonderful.

The best thing about motherships is that they are, out of the box, pretty robust and sturdy. The trouble with motherships is that they are very, very hard to steer. That makes them GREAT for corporate environments with few differentiating factors within internal audiences. A single, sturdy, homely UI works okay in that mediocre kinda way when you stick with a vanilla installation and provision using the delivered tools.

But higher ed audiences are nothing if not idiosyncratic — not just within a University, but between universities. Student populations can be undergraduate, residential, international, non-traditional, in any number of major programs. And that is just one audience group. Throughout the year, each of these many audiences requires a clear way to get to information.

So the object was to use Sharepoint as a layer of targeted communications over the portal, essentially mimicking what we had with Luminis, providing single sign-on to our Banner SSB for students in the bargain. This involved a LOT of customization, including some pretty complicated code for maintaining a Banner session within the Sharepoint authentication scheme. The developer who did this (no longer with UMW) was truly a genius in getting this to work. But, not everyone has a genius on staff.

Bottom line: We twisted Sharepoint into a pretzel to make it do what it’s doing. And here’s what it’s doing:

  • Complicating getting directly to Banner SSB,
  • Delivering 3 widgets of targeted/authenticated information for the new incoming student, useful for 3 months out of the year, and too complicated to manage to allow for distributed content authorship, so content management stays within IT.
  • Delivering about 9 widgets of personalized information from Banner SSB to all audiences.
  • Hosting unused personal pages, called “MySites,” for all students, faculty, and staff.
  • Delivering a collection of about 80 or so collaboration sites, of which a handful are being used actively.
  • Serving as a pretty spiffy scalable reporting tools platform.

Other than the last two bullet points (in bold above), EagleNet doing very little for all the development and maintenance costs, not to mention the development and testing work involved every time Banner or Sharepoint is upgraded. Well, Banner SSB has an all new interface called Cascade, and Sharepoint is moving from 2007 to 2010. Time to commit to hiring more .NET programming skill for more customization and retooling of this enormously complicated environment for little UI benefit, or cut bait.

Then there is mobile. Delivering itty-bitty widgets of information just doesn’t cut it in a mobile UI. On mobile, you want to get the info, and get out, because, let’s face it, you’re driving.

Snide remarks aside, I would argue that this notion of having a web-based UI that provides pertinent GROUP and PERSONAL messages and data is a viable one. So, how to extricate that essentially sound idea from a UI that was developed in service to the infrastructure, rather than the user? I thought you’d NEVER ask.

Enter the work Curtiss and I have been doing on Banner and Active Directory data in WordPress, using Banner Web services. It is a lightweight infrastructure, without all the vendor lockin nonsense of a “systems-based” delivered UI. It is the notion of small pieces, loosely joined, coming to fruition in a very big and profound way. Here’s what we are going to begin developing (implementation quite a ways down the road, so don’t panic!):

  • Use WordPress for the UI.
  • Aggregate targeted web content from posts throughout the university Multi-network environment using RSS feeds, FeedWordPress, and our own Cross-Site Featured Posts plugin.
  • Deliver Banner Web Services (already doing that) to WordPress based on AD authentication (already doing that, too). That allows the viewing of targeted (WordPress aggregated) and personal (Banner Web Services) content upon login.
  • Implement a Central Authentication Service (CAS) server to maintain a session between authenticated WordPress and Banner SSB.

Here is what you get at the end:

  • A flexible, accessible, responsive, mobile-friendly UI that leverages skills on staff AND within a broad WordPress community
  • No more Rube Goldberg authentication code in .NET that needs to be retooled every time Microsoft or Ellucian decides to improve on their products, dragging their clunky, afterthought UI’s along for the ride.
  • Banner screens break out from frames and use standard form layout, minimizing re-styling and customization.
  • IT concentrates on security, authentication, hosting and data delivery.
  • The Web team concentrates on aggregation and UI.
  • University Relations and the rest of the University continue to deliver content to their stakeholders through WordPress, as they are already.
  • Open standards, application-agnostic methods for authentication and session maintenance that could potentially apply to any number of apps and aggregation layers in the future.
  • Complex, compulsory, EagleNet portal layer is replaced by an opt-in Sharepoint installation that continues to support its core functionality: internal collaboration and reporting tools.
  • No more supporting thousands of abandoned, hard to manage “MySites”. UMW Blogs and a Domain of One’s Own are, after all, the most useful personal web publishing platforms we have in-house, and the internet is lousy with cheap or free personal web publishing environments that people can share with the WORLD, not just internally, as MySites do.
I know this is a lot to swallow in words. I have a way to illustrate these changes in simple pictures but, for now, I’ll leave it at the above. I’m pretty jazzed — it’s so nice to be around so long that you can break the stuff you helped to build, and build it better. Also nice to have Justin Webb as a CIO who is interested in solving problems, minimizing costs, being willing to kill a darling or two in  support of the UMW mission in the bargain. Justin Webb (IT champion of the Domain of One’s Own) is an unsung hero — oh, and a Mary Washington alum, by the way.

Man, We Were Good

I know we are all looking forward to saying goodbye to our Contribute environment at UMW. But, before its imminent demise, I want to point out a few really good things about it.

Over 7 years ago, we put our hearts and souls into investigating and standing up a web environment that would be easier to manage than our previous environment was. At the time, Macromedia (now Adobe) Contribute was pretty much revolutionary: a low cost content management system that provided users with an easy interface to edit Web pages. It was a barrier remover in its time.

The unfortunate thing throughout the life of our “Contribute” environment was that Contribute wasn’t the amazing part of it. Calling it “in Contribute” is a misnomer. Our Web development team Blaine Donley,  Edward Gray, and myself created a PHP application on the backend that filled in the blanks that Contribute could not. Our application stored all the urls, their relationships, and their structure, in a database. It allowed people to create new pages and arrange them through a Web interface, something that Contribute could not do natively. Something that no one else was doing with Contribute at the time.

Then, the content itself lived within the familiar notion of a “page” which our highly distributed team of Web managers could understand and manipulate.

The result was a really fast-performing CMS that only had to retrieve urls instead of delivering and parsing all the content. Considering the speed of servers at the time, this was a great decision that allowed us to scale up to the creation of over 22,000 Web pages, with 8,000 active at any point in time, and very rarely has there been a performance issue. As a matter of fact, I can’t recall one time when performance was an issue.

But the interwebs have moved on from directory structures and stored collections of html files. I knew this was coming, but I also knew, back then, that the technology to deploy a real CMS was too expensive, immature, clunky, and overpromising. I knew that this system we were building would be an intermediate step while the Web got its act together, Web standards settled in a bit, XML grew up, browsers got a clue, and our folks became more Web savvy.

I chose Contribute because, unlike its predecessor Dreamweaver, it could lock out the user from marking up text with font tags, sizes, colors, and other non-standards-compliant markup that was just beginning its deprecation as CSS2 was looming on the horizon. A few people did not like that they couldn’t put big, green, ugly text on their home pages. But, it was a decision that had to be made to ensure the integrity of the markup. Always, in the back of my mind, was some notion of an XML dump of everything in the system, and that had to include standards-compliant markup or we’d be in a world of hurt with manual editing, copying, and pasting.

I think that I was a lot smarter back then than I remember being. Now, folks are able to import their content from our old environment to our new, amazing, beautiful, multi-network WordPress installation, with the click of a button. And only a few error messages in the bunch, which were easily addressed.

It wasn’t simply a script that I wrote that did this, although I wrote a script. It was all the thinking and foresight that we had years ago when we built that now ghastly Contribute system. I’ve always been fond of building and creating systems — it’s why I’m not very good as a one-off designer or Web developer. I like the larger context, the longer view, the seeing what’s around the corner, solving problems on a larger scale. It’s part of my narcissistic grandiosity.

So, before we say goodbye to Contribute, I’m patting myself, and my two former colleagues on the backs. Our system may be on the way out, but by thinking through the larger implications, we created the basis to enable an import thousands of standards-compliant Web pages into a state-of-the-art CMS so painlessly that all folks asked after training is “Now how do I make my site look good.” They are jazzed up, rather than overwhelmed, wanting more rather than less.

Part of that is the power of WordPress. But a big part of getting there is the power of our team back then. Blaine and Edward, we did good.