Five years ago online functionality was a differentiator, the UI designer’s job was to throw paper prototypes over the wall to the backend JAVA programmers, and the end product was a happy (or not) accident of translation and pre-packaged technologies. But pre-packaged components don’t provide unique solutions and UI development requires a skill set very different from that of a classical JAVA programmer. The following is the epitome of a write-up delivered to non-technical business leaders that tries to make this case.
Rich Web UIs and JavaServer Faces (JSF)
Current Practices and Future Development
Web User Interfaces developed by our UI team are becoming more complex. At the same time, JAVA web development is migrating to the JSF framework, which abstracts low-level UI code into a set of pre-fabricated components. While our traditional UI development process produces static html prototypes geared for handoff to backend teams, an alternative approach for JSF-based projects is one where the UI developer becomes a JSF ‘page author,’ and develops the UI in JAVA .jsp pages using JSF components. Pros and Cons of the two approaches are outlined below. The rest of this write-up describes the basic dependencies of rich web UIs and aspects of the JSF model that can impact these for context, and offers a recommended direction for the future development of JSF front-ends.
Traditional UI Development Process
Pros
- Rapid prototyping.
- Prototypes are more easily shared (‘shoot me the link’).
- UI developers work directly in the browser (and don’t require an app server environment).
Cons
- Prototyped html and production html differ.
- Prototyped UI and production UI often differ.
- Richer UIs demand UI developer support and re-fitting hours after handoff.
Page Author Approach
Pros
- Html code upon which css and JavaScript are developed is the code that goes to production.
- Dead-end UI approaches are identified sooner in the development process.
- Extensive post-handoff JavaScript and CSS re-fits are avoided.
- Application development moves closer to the Model-View-Controller pattern where front- and back-end logic are isolated from one another and work can progress on either independent of the other.
Cons
- UI Developer requires an application server environment and associated support.
- Projects initially require more up-front time from UI Developers as they confront the learning curve.
- Custom rendering solutions may be required for UI elements such as grids, which depend on data sources for their content.
Rich UIs and the Document Object Model (DOM) – The Front End
The term ‘Rich Internet Application’ was introduced in the late 1990s by vendors such as Macromedia, who sought to address interface, content, and bandwidth limitations of the time with proprietary technologies and browser extensions. More recently, however, an explosion of open-source development activity has brought what can be achieved with the web browser’s native technologies very close to the output capabilities of the proprietary solutions. Most of the front-end richness of today’s web is developed using the browser’s native triad of html, CSS, and JavaScript.
Html serves as the bricks and mortar of any native web application. CSS and JavaScript applied on top of the html foundation provide visual styling and application interactivity respectively. Often, a user’s actions in a page will trigger a JavaScript call to modify specific CSS properties on specific html elements. User interfaces built on this model respond and give feedback to users’ actions.
Both the initial application of CSS styles to page elements and subsequent JavaScript requests to modify CSS or other page properties are heavily dependent on the structure of the page – its html foundation. Through knowledge of the html structure and use of the Document Object Model (DOM), which describes how to programmatically navigate hierarchical markup and target elements within, a UI developer programs event-driven stylistic or behavioral changes into an application’s interface.
Example
Initial State: A grid row containing info and options for an active configuration displays a selected checkbox and editable fields with values. Row hovers highlight the checkbox.
On Row or Checkbox Click: Checkbox is unselected to deactivate the configuration, field values are cleared, and fields are disabled with indicative styles.
The UI’s interactivity is programmed with logic that says, in effect, ‘if the user hovers over the second or third table cell in a parent row, find the checkbox in the first cell of the same parent row, highlight the background of the checkbox’s parent element, and listen for clicks so that we can modify the properties of any fields that are children of the parent row’s two last cells.’
JSF – Approaching the Front End from the Back
JavaServer Faces (JSF) is a web application framework focused on easing user interface development for Java apps. Key elements of the framework include:
- A set of prefabricated UI components and an API for managing their states, events, validations, conversions, and accessibility.
- An event-driven programming model that has server-side ‘listeners’ respond to user-initiated client-side actions.
- A framework and component model that allow developers to implement their own custom components.
From the UI standpoint, the components and API let developers render (to an html browser, in most cases) the inputs, outputs, and controls that allow users to interact with application databases. But on top of simple display capabilities (which are natively afforded by raw html), the components also provide an easy way for developers to wire backend functionality to the UI elements they render without including associated logic in the page itself. The promise of JSF is that it brings rapid user interface development to server-side Java while separating the domains of front-end (View) and back-end (Model and Controller) code.
Markup Examples
Html: A UI developer working with raw html will render a command button using the following page code, which is passed straight to the browser.
1: <input type="submit" name="button1" id="button1" value="Save">
JSF: A JAVA developer working with JSF might see the code above (or the screen rendering it) and interpret the following component and attributes for his page code (caveat emptor on exact syntax), which is passed to an application server.
1: <h:commandButton
2: id="button1"
3: action="#{dataHandler.saveData}"
4: value="Save" />
The application server in turn returns html markup (a close approximation of the UI developer’s code) to the browser for display, but also binds the command button to data and methods for backend functionality.
Meeting in the Middle
In the command button example above a single JSF tag, <h:commandButton>, corresponds to a single html element, <input>. Where one-to-one correlations such as this exist, it is fairly straightforward to translate an html prototype’s static elements to their JSF counterparts while retaining the integrity of the html foundation and any associated CSS or JavaScript dependencies. In certain cases, however, departures from the one-to-one paradigm can introduce significant discrepancies between the html delivered in a prototype and the markup rendered by the JAVA application server.
A Radio Buttons Example
Html: An html UI developer might use current markup and css practices to prototype a vertically-aligned set of three radio buttons with the following code.
1: <div id="radioButtonGroup">
2: <input id="sor1" name="sor" type="radio" value="11">
3: <label for="sor1">Button 1</label><br>
4: <input id="sor2" name="sor" type="radio" value="22">
5: <label for="sor2">Button 2</label><br>
6: <input id="sor3" name="sor" type="radio" value="33">
7: <label for="sor3">Button 3</label>
8: </div>
JSF: A JAVA developer tasked with rendering the three radio buttons using Core JSF will use the <h:selectOneRadio> and <f:selectItems> components to define the radio button group and its included items. On processing of these components, the JAVA application server returns the following html to the browser.
1: <table id="sor" border="1">
2: <tbody>
3: <tr><td>
4: <label><input name="sor" value="11" title="Select one" type="radio"> Button 1</label>
5: </td></tr>
6: <tr><td>
7: <label><input name="sor" value="22" title="Select one" type="radio"> Button 2</label>
8: </td></tr>
9: <tr><td>
10: <label><input name="sor" value="33" title=" Select one" type="radio"> Button 3</label>
11: </td></tr>
12: </tbody>
13: </table>
The html markup differs significantly. Where the UI developer employs pairings of <input> and <label> tags on the same level of the DOM, the JSF components use a table’s multiple levels of hierarchy to lay out and render the radio button group.
Grids
Grids and tables represent another area where Core JSF uses a select set of components to describe structures rendered with much larger sets of html elements. They also introduce a fundamental paradigm shift between the way that front-end developers working with html and their backend counterparts using JSF think about data structure and layout. Where front-end code addresses grids vertically, by row, JSF components describe grids and tables horizontally, in terms of their columns. And while consistently structured grids should be able to be approached from either direction, approaching them from both sides with different developers introduces the potential for losses in translation.
Implications
In the previous radio button example, contextual CSS styles and DOM manipulations dependent on the originally-prototyped html foundation are invalid when applied to the production-slated markup generated by the application server. At this point, to maintain prototyped styles and behaviors it may be necessary to revisit CSS and JavaScript code and re-fit it to the html that is generated with JSF components.
Grids are an example of where understanding the approach and capabilities of JSF components can be critical to designing feasible UI solutions. Rich prototypes can very quickly incorporate complex JavaScript dependent on html structures not replicable in the JSF environment. Resultant ‘re-fitting’ can be extensive.
Complete UI solutions designed on raw html foundations do not often translate to JSF in a plug-n-play manner. Supporting the translations, especially as UIs become richer, requires hours from UI developers.
Recommendation
The recommendation is that we move towards a Page Authoring approach that has UI developers building interfaces with the JSF components that will render them in production. This approach introduces new complexities to the UI development process, but it is believed that the long-term quality and efficiency gains to be had in having both front- and back-end teams working with the same technology outweigh the short-term learning-curve hit and inconvenience of the application server environment.
Nice article. This sounds exactly like my job except we’re in a .Net environment. We have finally gone to a “Page authoring” approach (a month ago) which has been pretty good overall but there has been a few side effects:
1) Business still expects a prototype which would be double work for our team (UI).
2) Development still has bad habits of doing what they want. They’ll remove controls we add and replace them with what they want. They’ll change style sheets or try to position things on their own.
3) There is still a fair amount of support and re-fitting on the UI side once the project gets close to testing (QA).
To me, for this approach to work flawlessly we would need to lock the front end and any change needed would have to be approved by us. In your experience, is their anyway to make a clean separation of front and back end development? Or is it more of a team discipline exercise?
Thanks for the comment, Andrew. In my experience, any time we start to use language like ‘lock down,’ ‘forbid,’ or ‘require,’ when sorting out the interactions between teams we inevitably engender some feelings that are counterproductive to what we’re trying to accomplish. The approach I’ve found works best is to keep a gentle hand on the tiller. Keep an eye on on the presentation layer as the backend guys go through their motions, and make sure you’re easily able to tweak its associated components (markup, CSS, JavaScript) as required. Code management systems (StarTeam, subversion, git…) and shared development environments (virtual machines or other…) are going to be invaluable here. Backenders are neither stupid nor malicious (usually quite the opposite on both counts); they just aren’t focused on what we are. Understand the reasons behind their alterations and I think you’ll usually be able to arrive at solutions that keep your designs near pixel-perfect.
Good points here. “Locking down” code would, to your point, be a bad idea. I also agree that the developers aren’t trying to be malicious when changing code or style sheets. One great side effect from this approach that we’ve noticed is that developers actually seek us out to help with UI issues now. Whereas before we were on “separate” teams.
Right! Silos aren’t usually a good thing…