by Kevin Wilmeth
After a few years of being away from the conference circuit, I got the happy chance not only to present at the 2014 IBM Digital Experience conference in Anaheim, but also simply to attend it. I’ll fully admit to being a bit of a kid in a candy store with that sort of thing, but I still think there is a great deal of useful takeaway to discuss. Here, I’ll highlight some of that which should be of interest to developers.
The value of Portal is going up
One thing I had to keep in mind, personally, is that being away from conferences for a few years means that what others have been seeing incrementally, I got all at once. On one hand, I’d have to watch out not to confuse the revolutionary for the evolutionary, but on the other, having a bit of a gap does tend to illustrate more clearly which trends are lasting and which ones stall. And the one that seemed biggest and starkest to me is that the business value of using Portal is going up noticeably.
I took all this to mean that 1) Portal skills are going to become even more valuable than they are now, and also that 2) they are probably going to change in a few significant ways. Keep that in mind as we spin through a few of the development highlights.
Forms Experience Builder (FEB)
The new Web-based tool Forms Experience Builder 8.5 (wiki for both traditional IBM Forms and FEB is here) promises to be a very viable way to produce simple portlet apps centered around forms and built-in data capture, and its extension points (including a REST consumer interface) suggest that one could quickly get into non-trivial applications as well. I got to go through a lab and put hands on it, and was suitably impressed. I suspect that a whole lot of simple portlets are going to come from considered use of this resource.
Script Portlet – a new landscape for developers
FEB hints at this a bit, but Script Portlet veritably screams it: Portlet development is now simply and viably available to the mainstream Web developer. It’s a very clever and simple idea, really: in each instance of the Script Portlet, a “single-page” application is captured (as configuration) using a JSFiddle-style interface, the application source is stored as a content object in WCM, and the view mode of the portlet runs it. In coding, there are hooks and shortcuts for REST services known to Portal, and streamlined referencing to other WCM artifacts. And it is designed to be friendly to whatever JS framework(s) you may wish to use.
The implications here are potentially huge. Just consider, for starters, that the deployment model does not have to involve anything from administrators, other than allocating Script Portlet instances. With application source stored as WCM content, the upgrade/enhancement/versioning model is nearly a tabula rasa of creative possibility. The separation between (REST) service development and consumer development is a by-the-book illustration of functional independence on both sides. And the available universe of competent Web developers simply dwarfs the number of traditional, dedicated Java portlet developers. Along with the support for existing and future JS frameworks, all this is going to add up to be an enormous help to R&D, PoC and prototyping/demo efforts at the very least, but I’d be surprised if it stopped there. One could also envision a great deal of interest for mobile-Web apps as well, and others we haven’t even thought of yet.
WEF 8.5 and Liberty Profile
With all the excitement about everything else in the stable, there are still several significant things to report about WEF 8.5. The “client-side application” builders are more robust now than in their first release in 8.0, as is mobile and responsive design support. There are some significant new builders such as XSLT Transform, and even some (welcome) re-introduced builders from the old Dashboard Framework, now available in the core product. The Samples directory grows more robust. Updated Eclipse, of course, and now you can do WEF development on Mac!
The most significant change for everyone, though, is probably the switch from WASCE to Liberty Profile for the embedded development environment. It really is luxuriously fast to start up, and all in all is much more what an embedded dev environment should be. It’s definitely a bit different for someone long accustomed to WASCE, particularly in administration, and documentation can feel a bit sparse, but it certainly seems better aligned with where everything is going and should at least theoretically prove more migration-friendly to other WAS and Portal platforms.
One thing that really stuck out at me, and which I’m still on the fence about, was an important consideration for those of us who have settled in to certain WEF design patterns that deliberately avoid some of the highest-level builders such as View & Form, for their historic tendency to be inflexible when we need them to be flexible. In short, I got the distinct impression that the improvements being made to the builder set, especially on the client-application side, are now happening fast enough that continuing to avoid these patterns now seems to carry a measurable risk. (Nobody told me that–it just seemed obvious that a great deal of the new features seem to depend on some of the builders that have proven frustrating enough that we sometimes pattern around them.) And some of these new features do seem conspicuously powerful, especially in the mobile space. It’s something I intend to pay some close attention to for a while, and it may be that it is time to reassess some of what have become classic patterns.
WEF Script Application
New for WEF is a nifty builder called Script Application. Essentially, it uses the Script Portlet’s approach of encapsulating a “single-page Web application” (source references for HTML, JS, CSS and libraries) and integrates that with available WEF service providers. Especially given WEF’s profiling capabilities, this could be a very powerful way of integrating straight Web development into WEF projects, in much the same way that Script Portlet enables portlet development with basic Web skills. WEF is already fairly well recognized as an effective rapid prototyping environment; it can only be the moreso with the ability to integrate WEF services and function with framework-based front-ends.
What does all this mean for a developer?
In coming to grips with this “democratization of portlet development” idea, that Script Portlet so dramatically promises to achieve, I was strongly struck by a parallel I remember personally from (yeesh!) just about a generation ago. This moment in time, now, seems very much to me like the moment when Lotus Notes really took off as a development tool–which it did for exactly the same reason as we’re seeing here. Back then we talked about making application development available to the “power user”–folks that weren’t necessarily schooled in hard-core development, but who could assemble the patterns they needed and who also understood the business, and in the bargain they often turned out to be highly creative types as well. Lots of people were horrified at this idea, but it worked so well that things just exploded, and a surprisingly robust set of business apps popped up out of nowhere, many lasting far beyond their expected obsolescence. What’s happening now may be different in terms of the technology, but the mechanism for success seems just the same to me: the stage is now open to a new and untapped creative mass, and I suspect that we’ll see dramatic things from it again.
Of course, this is a little foreboding if you’re looking at these events as having suddenly to compete with every JS/HTML/CSS Web developer out there for work. Sure it is! Probably, you’ll have to change at least some of your attitude or approach, but I don’t think that the valuation of portlet development skills is going to go down so much as it’s going to change. One of the things I certainly hope happens with all this, is that Portal/portlet development actually starts to take off because of all the new possibilities. (That’s exactly what happened with Notes, and the boom lasted for some time.) In that event, I suspect that people who already understand traditional (or WEF) portlet development are going to become even more valuable than they are now, not only because they’ll need to advise and mentor this new group as they find ways and needs to tap further into Portal, but as applications get more complex and greater in number, there will actually be further need for complex portlets and apps that go beyond the limitations of Script Portlet, FEB, etc. The net effect may well be that you don’t do as many simple portlets as you used to, but you may do more complex and interesting ones instead.
I suspect, too, that WEF developers in particular may find that they spend more time working on the service providing end than on the consuming end. It may be that out of 100 apps that would previously have been done in WEF or RAD, now half of them (to pull a number out of the air) will migrate to Script Portlet (or WEF Script Application), or FEB, or something similar…but they’ll all still need service support.
Conferences are good for developers
Finally, I was reminded how much benefit there is for a developer to attend a conference. In my own case, three self-observations stuck out in this regard. First, I got specific information that will help me with my own work, and there is of course obvious value in this. Next, I got re-introduced to what I call the wide. It’s easy to get so involved with the specifics of what you’re doing, on a day-to-day basis, that for all the obvious and valuable expertise in that area, one can get lost in the deep at the expense of the wide. A conference such as Digital Experience can do wonders for re-establishing the right balance for that. Lastly, and perhaps because of the aforementioned, I also got recharged. For the kind of personality that gravitates toward development, it is important to see new and shiny things, and to get excited about them. Not only does it improve one’s general attitude, it also improves the creative process. In hindsight of course I recall this pattern in myself and many others from a number of years ago, but we are forgetful creatures, and it is useful to have reminders.
About the Author: Kevin Wilmeth has been working with IBM Web Experience Factory (WEF) since 2001 as a field developer, trainer, coursewriter, mentor, and architect. He came to the Factory from a prior career with Lotus Notes/Domino, where he served the same roles in much the same depth, and for a while specialized in integrating the two technologies. Kevin has also spent some time in the education technology industry, bringing both the technology and the education to people and places that just didn’t have it before. He lives on Alaska’s Kenai Peninsula, where the fish laugh at him and musical instruments shudder at his very approach.
This article is from our monthly resource e-Newsletter. Did you miss it in your inbox? Visit our eNewsletter archives for past editions or if you want to receive our monthly newsletter automatically, simply write to Ruth O’Keefe and request to be added to our E-Newsletter list. You can also view the Master Series Archives.