Sign in Subscribe
uportal

Follow up on Open Apereo 2015 uPortal BoF

Andrew Petro

• 7 min read
Follow up on Open Apereo 2015 uPortal BoF

In which I follow up on the Open Apereo 2015 conference as regards uPortal project and product vision.

Lead-in

At the Open Apereo 2015 conference, I facilitated a couple of birds-of-a-feather sessions on uPortal project and product vision.

Face-to-face discussion is a wonderful thing for its high bandwidth. It is, however, terrible for its exclusivity. To mitigate that aspect I started an email list thread in preparation for the conference and, as promised, am now following up on it.

Discussions at the conference

The conference included a lot of uPortal discussion, both in the BoFs and in other sessions.

BoF discussion

Participants spent the first BoF session on a listening-and-speaking exercise, in which each person briefly re-stated what the previous person said and then added the one thought that they thought was most important to add. The exercise has some nice properties in encouraging focus, wide participation, close listening to others. It reduces the tendency of people like me to dominate the discussion and increases hearing from and really listening to participants the project might routinely hear less from.

I thought it worked pretty well. Notes are available from the session; some themes emerged.

There were strategic thoughts about keeping uPortal relevant, about why a campus would add or retain uPortal in their IT portfolio, and about why it would be worth upgrading to latest uPortal.

There were thoughts about productization and lowering barriers to entry, and improving the usability of the product, making it simpler to use.

Some session participants were concerned about the product moving too fast, with change being undertaken at a pace too quick to keep up. Some adopters are still on old versions of uPortal 2 or 3, with a difficult upgrade path to uPortal 4 as it is and concerns that the upgrade path and keeping up gets harder rather than easier with change.

There were thoughts about a more tactical vision of cleaning up the server-side of the product we already have, going after Spring Security as an evolution from ad-hoc groups and permissions, going after Java 8 language support and running in the Tomcat 8 servlet container, working with later Oracle RDBMS versions, and the like. Improving back-end performance and focusing in general on the back-end. Thoughts about things the product can do to make deployment more manageable, enabling promoting static artifacts between tiers rather than building for a specific tier.

There were thoughts about improving the scalability and modularity of the product by adopting a microservices architecture, and about modernizing what it means to develop in uPortal, getting away from developers having to create formal JSR standard Portlets in favor of more modern web development approaches. Thoughts about a more API-driven client-server model, delivering better user-centered experiences, and about pursuing multi-tenancy capabilities within the portal product.

The second BoF followed up on these thoughts in light of the conference, identifying some tactical next steps in terms of spiffing up uPortal's server-side supports (Java 8 language, Tomcat 8, later Spring version, etc.) and some strategic next steps in terms of e.g. exploring adopting more of a microservices architecture.

State of the uPortal 2015

The uPortal - State of the Project: Responsive and Native presentation (video) included some thoughts on what's next, with the bit at 19:49 particularly speaking to this.

Beyond portlets

Tim Levett and I gave a talk Beyond Portlets about what the MyUW team is doing exploring delivering more modern experiences and development frameworks alongside traditional Java Portlets in MyUW. All of this is real working code in production at UW-Madison today. All of this is free and open source software that you can directly inspect and adapt for use with your uPortal, and that largely will just work with your uPortal, as validated by non-Wisconsin uPortal adopters trying it out.

When I say MyUW is exploring delivering more modern experiences and development frameworks, what I mean is that MyUW is exploring these things by doing them.

Single-page application for 80% of the portal framework experience

There is a responsive, single-page-application alternative landing page front end for uPortal, implementing the landing page, favorites, dashboard, and app directory ("Marketplace") use cases. Going after that 80-20 rule where 80% of what you do in the portal is delivered using a modern snappy client-side experience, with all of the existing developed-in-portlets functionality available if you need it and click far enough in to get it.

Screenshots:

That new landing page experience, 80% of the portal that users care about, is implemented in a modern way using AngularJS, which improves the MyUW team's ability to deliver a great user experience and to be responsive to feedback in updating it. Largely, no DLM, no XSLT, no heavy server-side stuff.

This component is called "home".

Framework for developing applications in the new single-page application way

That "home" component is implemented building upon a framework called "frame", which is a usage of AngularJS. Frame is also the starting point for applications other than "home", applications that end up looking and feeling like they are part of the portal but that aren't JSR-286 portlets, they're modern AngularJS web applications instead.

Adoption of frame is eased by an app seed starting point.

Widgets

Okay, so one use case JSR-286 is fulfilling is building rich, complex, interactive Web applications. Frame-apps is our beyond-portlets answer to that.

Another use case JSR-286 is fulfilling is building dashboard components, little views that appear alongside others on a page. Widgets are our answer to that.

Widgets are also implemented using AngularJS. They're the combination of a template (AngularJS templating is quite fun) with an optional JSON feed feeding down dynamic data to that template.

Widgets also have a much stronger design aesthetic than Portlets tended to have. A problem with Portlets is that the world is wide open to do anything, and a problem with that vision of grabbing off-the-shelf portlets from disparate sources is they all have different design, different sizes and shapes. They tend to look jarringly different when juxtaposed on a page.

Widgets come with a much stronger design aesthetic. They are responsive but only across a narrow range of sizes. There are some patterns for how they ought to look. They look a very minimal way when they have nothing interesting to say.

They are also quite feasible, technically, to implement. All of the work is in design and in whatever you have to do to lay hands on worthwhile JSON data to feed them.

Screenshots:

Resources:

My take

The visions for the future of uPortal align more than it may seem.

It is interesting to observe from discussions the perceived conflict between enabling alternative front-ends for uPortal such as UW-Madison is implementing, and improving the included-with-product experiences and server-side implementations. The perceived conflict between pursuing a micro-services architecture and shoring up the existing server-side implementation.

I do not see these visions as in conflict. I see them as complementary.

Achieving Java 8 language support and Tomcat 8 support and better performance and Spring Security and more ability to promote selfsame artifacts across tiers and so forth will be more feasible in less monolithic architectures. Part of the challenge today is that the technical implementation of the product is just too complected.

Improvements and APIs that enable developing alternative components for a uPortal implementation are improvements and APIs that will drive better default components for a uPortal implementation.

Better modularity and architectures and especially closer attention to versioning APIs will improve the feasibility of upgrade tooling. Productization will improve adopters' keeping up with upgrades and finding value in doing so.

We are talking about some of the same things and same needs in different ways and thinking we are at odds when we are not.

So what’s next?

Tactical technical maintenance

I agree that the existing product back-end needs maintenance and attention, and I see it happening.

  • Java language 8 support
  • Tomcat 8 support
  • Better performance
  • Better and more adoptable analytics
  • More mainstream approaches to widely adopted security frameworks (Spring Security) and less ad-hoc access control stuff

All of this is important and worth doing.

uPortal as product but not as monolith

uPortal needs to become both more productized and less monolithic. These concepts are not at odds. The evolution away from the monolith is essential to the successful move towards better productization.

Enabling alternative front-ends and more modern ways of developing content beyond JSR Portlets is not at odds with making the out of the box code and experience better -- it is the way to make the out of the box code and experience better.

uPortal must stop being one giant Git repo and one giant uportal-war artifact, and for goodness sake adopters need to stop having to fork the entire source code and build the whole thing from source (and build it custom for each deployment tier no less) just to implement the product.

The path forward is to de-couple, extract, refactor, and re-bundle more cleanly.

uPortal the product should be a bundle of more and better things. The way that bundle is developed and built together should be from more, smaller, better factored pieces.

This is the path to more sustainable development of a more compelling product that is more adoptable and more feasible to upgrade, and so a product for the next fifteen years of the uPortal story.

Resources

About uPortal vision:

About microservices architecture and beyond portlets:

Acknowledgement

Post image Little chicken via CC-BY-NC-ND-2.0

Sign up for more like this.

Enter your email
Subscribe