Monday, June 26, 2006

How UE designers can help with uPortal

Someone recently emailed me to ask about getting involved with uPortal. I answer here in the interest of transparency and getting word out that your involvement is welcome.

Hi, I'm a Graphic Designer/Developer. I currently create Web Based Training for [a large organization]. I came across uPortal and noted the need for UE designers. I would like to know more about what the project needs and see if I can help at all.


Welcome! I'm sure you can help.

The case for englightened self interest:

I'll address the question of what the project needs, but let me first articulate this: the project needs what you need. We're not looking for martyrs to do a lot of work out of the goodness of their hearts (any would-be martyrs are welcome, but you're not what we're building this project on). What is needed, what is sustainable and what works, is for people to do work that makes sense from their own perspective.

It's a matter of a community of collaborators acting under an approach of enlightened self-interest, rather than a centrally organized commune.

So, for instance, you might need a portal. And you might need that portal to not look brown and drab, you might need it to support drag and drop user experiences for portal customization, you might need it to use nested divs instead of nested tables, and you might need it to support interesting ajax callbacks. Or maybe you just need it to have a little spiffier documentation. It turns out, there are lots of other people who need these things too. And if you speak up on the list and find some of them, they may be available to collaborate and help design/work on/QA these enhancements. Or you may develop them all on your own but then seek to re-integrate them with the core uPortal so that others will help maintain them and you'll experience a lower total cost of ownership of your portal.

Or maybe you don't immediately need a portal, but you're looking for some interesting projects and an opportunity to collaborate with the smart, fun, and good-looking JA-SIG community. It's a little harder to tell collaboration stories that work when you're not looking to yourself put the portal into production, but this can work.

So, as you read through some descriptions of what uPortal needs, be sure to think about what you need, what needs you think are shared between you and other uPortal deployers, because really, uPortal doesn't need from you anything more than the intersection of what you need and what our current and would-be deployers need.

What uPortal needs from User Experience developers:

uPortal needs a more attractive out of the box skin. Jason Shao and others have worked on this for uPortal 2.6 (the current HEAD of the portal CVS project) -- that work needs engagement and validation by additional developers and the issue of whether and what to do about the default skin in uPortal 2.5 is certainly still open for discussion. For the right skin, I think it absolutely would be worth the pain of a skin upgrade in the patches branch. A modern skin would improve the marketabilty of uPortal.

uPortal needs more attractive optional additional example skins, ideally with good instructions and an easy migration path to turn them on. More showcasing of what can be done with uPortal.

uPortal needs to close the gap between DLM and ALM and SLM theme transforms and more generally improve the pluggability and re-usability of skins. It would be oh so awesome if skins were modularized such that we could just pass them around, at least for the 80% most modest theme transform needs. There will always be the opportunity for advanced hacks to produce cooler user experiences, and that's a good thing, but the majority of sites should be able to settle on a common set of user experience functionality and share neat skins.

uPortal needs more and better how-tos and documentation for producing these awesome skins. It needs UE people to come to our conferences and developer meetings en-masse and form a more visible and active presence in our community.

The uPortal project itself needs improvements to its web presence, and there's a jasig-webpresence email list for discussing and working on just this topic. We need User Experience exports to join in those dicussions and pick up some of that work. What would a compelling and inviting developer.ja-sig.org homepage look like? While I appreciate the efforts of those who have set up what we've got, what we've got isn't it. We need User Experience experts to help us make our Wiki more usable and our website more compelling.

We have a new and growing process for accumulating, prioritizing, and matchmaking around requirements, and we need articulate, thoughtful, excellent User Experience requirements to go into that process. Yes, we all know we need Drag and Drop. Now what does it really look like? How does it feel? What really neat user experience stories could go into this process that would get people excited?

And in the meantime, are there pokey corners we can easily round to ease the user experience of our product? We need bugs fixed and minor enhancement requests worked on, and while many of the bugs are Java bugs that require java developers, some of them can be addressed in XSLT, which is sometimes the domain of UE developers, and many of the issues could benefit by the input of UE designers to ensure that what is produced is not only functionally complete but also usable.

One of the tragedies of our project is that we standardized on a layout manager that fails to showcase some of our best features. User experience designer input could have brought about implementing a UI for configuring those pesky restrictions and prioritizations of fragments, for subscribe time parameter value solicitation from end users. Let's not make that mistake again: user experience experts can help the project put its best foot forward in showing off the powerful capabilities that lie beneath.

We need user experience input and work both in uPortal 2 and in uPortal 3.

But mostly, we need what you user experience designers need: a flexible and powerful portal platform in which the shared problems are solved via collaboration and the extension points and support is there for you to fly free in solving your local problems and adding your branding and local value-add. We need your help to be the portal that you love to use. And you need to help because you'll love to have a better portal.

A reminder that uPortal is best discussed on the uPortal project lists:

While I try to be available off-list and politely and usefully answer questions sent my way (trying to get better at this), really the very best place to discuss uPortal is on the project lists. We have a list jasig-portal for general discussion of using uPortal, and a list jasig-dev for discussion of active development on the uPortal project itself. We also have a cluster of fringe lists for discussing user expereince, the JA-SIG web presence, uPortal 3 as it exists in the sandbox, and JA-SIG operational issues. If there's a niche for discussion that we don't yet have a list for, let's make one and start discussing and building an archive that can be valuable to others even after the discussions conclude.

While off-list discussions are often useful, they are a tool to be soberly considered because they often miss opportunities for wider involvement, transparency, and archival for future interest.

No comments: