ShowTable of Contents
This article addresses the situation in which the look and feel of an IBM® WebSphere® Portal page is designed by a User Interface (UI) design expert, and the actual productization of these styles are done by the another developer.
The UI design expert prepares the styles---like Cascaded Style Sheets (CSS) or a sample HTML)--- per the UI specification and design, and these styles or sample HTML are then consumed by the developer to develop an actual, functional UI for a product.
The developer takes into account all the specific requirements of the product and important factors like namespacing, internationalization support, cross-browser support, accessibility support, and so on.
This article guides you through step-by-step checkpoints to productize the styles into a realtime UI. The intended audience is Portal developers with expertise in JavaServer Pages (JSPs) who want to develop a functional UI using the sample styles and HTML code written by an HTML and CSS expert.
UI experts can also use this article to deliver the sample CSS and HTML for an approved design. Readers of the article should have the functional requirement document of the expected UI.
Role of a UI design expert
The three basic things expected from a UI design expert are:
- Pictorial layout/design of the UI
- Pictorial layout with all the parameter values
- Sample HTML code and CSS written for the expected layout
Expected pictorial layout of the UI
The first thing expected by a developer on the UI design team is the approved design and layout of the expected page. The example in figure 1 shows all the text, images, and the final expected layout of the page. All the text content and images are ideally created and provided by the UI design experts, all of which the developer uses as is provided by the design team.
Figure 1. Example expected layout of a page
Expected pictorial layout with all parameter values
The second thing provided by the UI design team is the layout/design with the correct values for each parameter such as text font, text size, spacing between lines, padding, and so on. Figure 2 shows the values in pixels (px) for different attributes like text font, text color, and so on.
Figure 2. Parameter values
Sample HTML code and CSS
Once the layout with all the parameter values is ready, the UI design expert can work toward developing a sample CSS and sample HTML code. Listing 1 shows a portion of the sample HTML code written for the layout depicted in figure 2 above. This can also be developed by a developer with mutual inputs from the UI design expert.
Listing 1. Sample HTML code snippet
This sample HTML code is without any internationalization support, cross-browser support, accessibility support, etc., and will be modified by the developer to provide internationalization, cross-browser, and accessibility support, as well as namespacing, IBM Rational® Policy Tester™ violation-specific checkpoints, and so on.
Listing 2 shows the sample from the CSS written for the styles used in the HTML sample code (listing 1) for the layout depicted in figure 2.
Listing 2. Sample code from the CSS
: The styles in the above code are without any namespacing and will be modified by the developer to attach meaningful prefixes to achieve namespacing.
Role of the developer
After receiving the correct expected designs and sample HTML and CSS for the approved design from the UI team, the developer is responsible for consuming these samples and productizing them to work correctly in the production environment.
The developer must take extreme care to make the samples work correctly from the product's perspective, ensuring that there are no naming conflicts of styles, which will affect the behavior of other elements consuming them.
The other important factors a developer must consider are the internationalization of the text and images for various supported locales of the product, correct accessibility support of the various HTML elements, and cross-browser support.
Namespacing of the styles so that the names used in the styles do not interfere with any of the existing styles is quite important. Interference can create much confusion and can make other parts of the product behave differently.
So the first step after receiving the sample styles from the design expert, the developer must namespace them. For example:
After adding a meaningful prefix (oobsamplemw) , namespaced styles looks like:
Namespacing must be done for every style, to avoid conflicts.
The second important thing is to use the correct internationalization APIs to handle any translatable text or image. Developers must always put the translatable text in the properties file as key and value pairs for their native language. This properties file is translated by the translation team for the different locales.
The keys defined in the properties file can be used in the code with the help of the various tags and APIs available to fetch the correct translatable value in the selected locale; <fmt> is one such tag to fetch the value against the key.
For example, as depicted in listing 3, before internationalization support, all the text has been hardcoded in the code. In this case, no matter what the selected language is, the text always displays in the English language, which is not correct.
Listing 3. Text coded without internationalization support
Listing 4 shows how the code has been modified to include a properties file (oob.collaboration), and the <fmt> tag has been used to fetch the translated value for the key (welcometext1 and welcometext2) from the properties file.
Listing 4. Modified code with internationalization support
The properties file (oob.collaboration) contains the key-value pairs like that shown in listing 5.
Listing 5. Properties file with key-value pairs
To support accessibility for impaired users, the developer should add all the accessibility attributes applicable to the various elements used in the code. There is a complete IBM-internal Web checklist for IBM products for various HTML elements like forms, navigation features, and error identifications.
The developer must identify all the attributes applicable to the various elements in the code and implement them correctly, to make it accessibility compliant. The Job Access With Speech (JAWS) tool can be used for testing the accessibility attributes.
Finally, the developer must ensure that the code is consistent in the behavior across all the supported browsers of the product. Sometimes the styles behave differently across the different browsers and different versions so, to ensure consistency, the code must be tested across all the supported browsers and versions and, if necessary, be corrected.
You should now be familiar with how an approved UI design and layout can be used to develop a sample CSS or HTML code by the UI design expert. We've also taken you through the various checkpoints a developer must consider while productizing the sample styles and code into actual functional code in the product.
If these checkpoints are addressed correctly during the development phase, it will ensure a reduced defect count in the Functional Verification Test and Global Verification Test testing phases.
Tell us what you think
Please visit this link to take a one-question survey about this article:
developerWorks WebSphere Portal zone:
About the author
is the Junior Globalization Architect for WebSphere Portal at IBM India Software Labs. He is a member of WebSphere Portal team and specializes in Globalization. He has also worked on accessibility and User Interface development for WebSphere Portal. You can reach him at firstname.lastname@example.org