What a long and wonderful Christmas break. It felt like I was on a cruise without leaving my house. I ate everything in sight, and sleep 12 hours a day. Since January 5th, I am back at work and it is driving me insane.
I feel like I am approaching a stalemate in what is possible with our Portal. We have gotten most of the internal plumbing worked out, and for the most part we are now limited by outside factors. I constantly review the state of our Portal, and try and eliminate the outside factors barring our success. Let me define success:
- Positive feedback from constituents
- Strong buy-in from departments and other content contributors
- Tight integration into our workflow
- Exclusive ability to solve business needs
Positive feedback from constituents:
Feedback is essential to have – positive or negative. I have heard some people report that the single-sign on functionality is nice, but I have heard many more people complain about various issues. I suppose I need to build a survey channel and back end to properly gather metrics on what needs to change.
Strong buy-in from departments and other content contributors:
We have the traffic to show people are using it – but it is because we force them to. We have a captive audience, and a difference of opinions about what that means. A captive audience to me is a bad thing. If I am forced to use something, I am overly critical about that thing simply because I didn’t have a choice. The higher ups see a captive audience as a good thing. It forces traffic in, which is the “dangling carrot” to get people to update their content and use the features of the Portal. We have statistics to prove that this approach is not working. 10,000 hits a day, and practically zero buy-in from other departments, and authorities on campus. Without buy-in, the content inside the Portal never changes. Instead of being a dynamic, exciting “marketplace” of ideas and information, it looks like a static webpage.
Tight integration into our workflow:
Lets assume that departments wanted to update their content. The technical knowledge required to perform this action has been demonstrated to be too high to make it worthwhile to do so. This is a problem with our choice in Portals – the features that count are lacking. To mitigate this factor, we provide a website that streamlines the process of updating a channel, and have even offered to update channels if we are just sent the information. We still have little buy-in from departments.
But I have a feeling that departments do have information they want disbursed, but outside of the Portal on the main website. Here we have conflicting information systems. Currently, almost all of the content for the school resides in external websites. Without a content-management-system, this information is hard-coded into HTML files. This means that the data cannot be extracted and used inside the Portal, because all of the layout, and design is combined with the information. This means that updating channels in the Portal boils down into a duplication of efforts.
Exclusive ability to solve business needs:
Our Portal should be a ble to provide services to students in a way that is exclusively possible thought the Portal’s framework. There are several crippling limitations to doing developing inside a Portal environment.
The first is the nature of the HTTP request model. You click a link, and the entire page refreshes. Each channel is supposed to be its own system, so this is no good. Immediately you are reliant on exclusively AJAX to make partial updates to your channels. This increases the complexity of your application tremendously.
Second, is the issue of real-estate. If you are looking at say nine channels on the screen, you are have a maximum width and height of no more than 300 pixels. This is like using a cellphone screen to navigate your application.
Third, the Portal is already bloated. With multiple stylesheets, external javascript files, and nine channels rendering on a screen at every page-click, not much room is left for any further overhead.
Business needs solved are consolidation of system credentials by providing single-sign on into applications. Also, the location of these systems is consolidated since the Portal is the entry point.
Where does this leave us?
How many Portal’s do you use in a day? It isn’t a popular web model, with the notable exception of iGoogle. I would like to add more single-sign in functionality, and slowly replace “dead channels” with feeds consumed from the rest of our information sources. Of course, our sources aren’t database driven, which would be the most positive change that can be made for the external website and for the Portal.
Zone of Mr. Frosti 