Web(2.0)Facing
Posted: April 21, 2008 Filed under: Abe Batthish, HATS, Web 2.0, WebFacing | Tags: Ajax, community, Content Assist, ENPTUI, feedback, HATS, RIA, Subfile, user experience, user interface, Web 2.0, WebFacing 5 CommentsWhen providing a UI Modernization solution, ultimately it’s all about the resulting UI (User Interface) and UX (User Experience).
These are areas that have endless opportunities for improvements, and for WebFacing this is no exception. In fact, it’s been lower on the priority list for too long.
ENPTUI support? Better Subfile UI? Content Assist (e.g. Calendar widget for date fields)?
What UI enhancements are highest on your list to directly improve end user usability, enhance their experience, or enable the development of richer WebFacing applications?
I’m open to rants as well. Feedback is valuable in any form.
IBM i Rational Team Blog 
We evaluated HATS and WebFacing. Although it looks like WebFacing is the better fit stylistically, HATS seems to have more up-to-date support for creating true web applications. By that, I mean it seems to require less work to make a solution that works across browsers. HATS also uses Java Server Faces for extensions, while WebFacing still uses Struts.
So, my backward-looking wish list is:
– Support for using JSF for extensions
– Support for more browsers
and my forward-looking wish list is:
– Web 2.0 support (AJAX support for break messages
would solve a problem we’re having with locks
right now)
– Support for using EGL for extensions
Thanks Robert. I appreciate the feedback.
The good news is both HATS and WF are available as a single offering now, and with interoperability support you can take advantage of either technology’s strengths within a single project.
In 7.1 WebFacing does provide a new feature called “Application Bridge” which enables generic web extensions if I understand your term correctly. The bridge allows you to identify a DDS record as a linkage record. Fields within the record are sent to the specified Web app (or EGL app) URL in the related Web Setting via request attribute. This provides a two way bridge from WebFacing (or HATS through interoperability) to the sibling Web app and back, allowing extension of the application at the business logic level.
More browsers, specifically Firefox, is on a lot of people’s WebFacing wish list. Probably the #1 requested item for WebFacing. That fact will obviously have an influence on our prioritization.
BTW, this discussion is open to HATS requests as well. Just thought Web(2.0)Facing was a clever title. :)
Where do I start? I’m in the middle of a large Webfacing project at the moment (a year in and counting) and could probably write a book on what I’d like to see changed!
There are marked unpleasantries in the Webfacing UI such as the subfile with its scrollbar that doesn’t scroll and the upside-down error message drop down. The use of a table for the layout is a real, real PITA. This really should be replaced with CSS positioning.
The absence of simple support for common UI components is also a problem – features that users expect such as drop down boxes and checkboxes require the programmer to bend the tool (something I have become well versed in doing).
The lack of simple widgets to enhance the UI is another annoyance – such as the inability (out of the box) to simply add a button that sends a function key press. This again requires far more intervention than should really be necessary. I’ve written quite a few ‘widgets’ like this that have to be dropped in using JSP code… and because we can’t inject code at the right point to insert a taglib declaration in the generated JSPs, we can’t use our own JSP tag library to do that. This isn’t great from a design point of view and means that we have to plonk JSP scriptlets into the DDS. Yuck on so many levels.
However these are only relatively minor quibbles – there are fundamental problems with the WebFacing design that really need to be addressed – and if corrected they would allow the above points to be solved much more easily.
For example, I would rather be able to change the way that subfiles appear myself than have a new release with a slightly improved subfile in. To do that at the moment would require me to write Eclipse plug-ins that basically changed the way that Webfacing generated the JSPs. It would be much better if Webfacing simply exposed beans that described the properties of the subfile. A template could then be applied to those beans which controls how the subfile is displayed. It would also improve productivity of developers using the tool. If the DDS itself hasn’t changed, I don’t want to to have to run a conversion again just to move fields about or change their appearance. I just want to be able to change a template file. Yes, we can change the JSPs that are generated at the moment but that isn’t a good choice because it means that if a DDS file needs to be reconverted then those changes need to be reapplied. Far better that the conversion process simply produces objects that describe the components on the screen and allow their appearance and behaviour etc. to be controlled by completely separate components…
Probably the most requested feature from users is to be able to retain the type ahead buffer from their terminals. The way that the page interacts with the back end – by submitting entire pages – prohibits this. Again it would be a fundamental change to the application design to move from this model to a complete AJAX model that would allow this to be done.
That’s probably a bit of a ramble – one day I’ll put my thoughts together in a coherent form and put them on a blog or something of my own!
Another thing I should probably mention is that with WebFacing and HATS, the default UI is very clunky. This fact has led us into the position where we have to do a lot of work to get something that looks good. Unfortunately, we don’t have this much time to spend on the current project, so we have done just the most basic transforms.
btw, WebFacing V7.5 now supports Firefox.