Tag Archives: user interface

Speaking at Brussels JUG: User Experience for Business Process Applications

I’m glad to inform that I will speak at the next Brussels JUG‘s event about user experience thinking and design for business process applications. The event will take place at Hogeschool-Universiteit Brussel, Building Hermes, on Thursday, 30th of May, at 6:30 pm. Visit Brussels JUG website for more information: http://www.brussels-jug.be.

You won’t find a lot of information about this subject on this blog, but I have been doing research about it in parallel since 2006, in collaboration with Kênia Sousa, who would be happy to share the stage, but she had to decline due to family duties. You may find more information on the page Publications of this blog.

If you were assigned to design and implement a business process based application, You may find this session interesting. User interface design is the most time consuming task in a software development process. It is highly subjective and under heavy criticism by end-users. This presentation will help you better deal with this problem, exploring strategies to represent business processes in a way that end-users can easily understand what they see based on their business knowledge. We will discuss about a different approach for Business-IT traceability based on UX, an architecture and a methodology to support constant process changes, navigation approaches and the right widgets for the right actions.

See you there!

Easier Multi-Field Validation with JSF 2.0

One of the most frequent needs when developing application forms is multi-field validation (or cross-field, but I’m not using this term because when I put it on Google I actually got some post-war pictures). I’m talking about situations where we need to compare whether an initial date is earlier than an end date or a value is lower than another one. Isn’t it an obvious feature in every business-oriented framework? Not really. Unfortunately, the JSF specification doesn’t support it by default. Therefore, until its latest production release (JSR 245 – JSF 2.1), JSF did not offer an out-of-the-box multi-field validation feature.

We probably can hope for something coming in JSF 2.2, since the JSR 344 mentions “Multi-field validation”. Meanwhile, developers have used their fruitful creativity to implement their solutions. You can find plenty of working alternatives at Stackoverflow.com; people creating their own components; frameworks built on top of Java EE trying to cover this feature; and many other cases.

I didn’t like any solution I found. Some are complex, others are not so elegant. So, I decided to be creative as well and try a simpler solution, easy to understand and change when the time for refactoring comes. It doesn’t mean that I’m proposing something better than other proposals. I’m just proposing something simpler.

In the following example, I check whether an allocated budget is smaller than a budget limit. If not, then a message is shown to the user. The example considers only two fields, but it can scale to as many fields as you wish.

Step 1: create an attribute in the managed bean for each field to be validated:

The attributes below are exclusively used in the multi-field validation.

private BigDecimal validationAllocatedBudget;
private BigDecimal validationBudgetLimit;

In this example, I’m coding inside a class named MBean, annotated with @ManagedBean and @RequestScoped.

Step 2: create a validation method in the same managed bean for each field

This solution considers validation methods implemented in the managed bean instead of implementations of the interface javax.faces.validator.Validator.  You can give any name to validation methods as long as you define three standard parameters, which are the FacesContext, the UIComponent, and an Object representing the value input in the field. Only the value is useful for our validation. See the validation methods:

public void validateAllocatedBudget(FacesContext context, UIComponent component, Object value) {
this.validationAllocatedBudget = (BigDecimal) value;

public void validateBudgetLimit(FacesContext context, UIComponent component, Object value) {
this.validationBudgetLimit = (BigDecimal) value;
if(this.validationBudgetLimit.compareTo(this.validationAllocatedBudget) < 0) { throw new ValidatorException(new FacesMessage("Invalid allocated budget!");    } }

The method validateAllocatedBudget doesn't validate the allocated budget. It simply set the attribute validationAllocatedBudget to allow its value to be used afterwards. It is possible because the validation methods are called in the same sequence they are declared in the JSF code. So, you can create a simple method like that for each field involved in the validation. The effective validation occurs in the method validateBudgetLimit, which is the latest called validation method in the JSF file, thus the last one to execute.

It's a good idea to declare attributes and validation methods in the same order of the fields in the form. The order doesn't interfere the functioning of the algorithm, but it helps to understand the logic. On the other hand, the order of calls in the JSF file is important.

Step 3: use the parameter validator to reference the validation method

The methods described above are called from the fields below. Remember that the attributes and methods were implemented in the class MBean.

<h:outputLabel for="allocBudget" value="Allocated Budget"/>
<h:inputText id="allocBudget" label="Allocated Budget"

<h:outputLabel for="budgetLimit" value="Budget Limit"/>
<h:inputText id="budgetLimit" label="Budget Limit"

That's it! 🙂 Merry Christmas and Happy New Year! o/

JavaFX Must be a Joke

More than 3 years ago, I wrote the post “Has JavaFX a Strategy?” saying:

Don’t you think that the fastest way to spread the JavaFX adoption is allowing the improvement of existing applications? Why to spend a lot of resources to drag an applet from the browser to the desktop if we need the network anyway?

At that time, JavaFX Script was the only alternative to develop richer Java desktop applications. Guess what Oracle did right after Sun’s acquisition: they stopped evolving a pretty stupid new language which looked more like Json, which is designed for data; migrated the whole thing to a new Java library; and allowed the integration with legacy code (i.e. Swing applications). If they didn’t get inspired by my old blog post, then they just followed the sane common sense.

Meanwhile, Adobe gave up Flex and Microsoft gave up Silverlight. Strangely, Oracle kept insisting on JavaFX. We can see a lot of JavaFX demos out there, but not so much production-ready apps.  That’s a shame after all these years. The single example I have of a real world application is from a Belgian company called Health Connect. That’s all! Anybody else?! JavaFX evangelists would give a lot of confidence to Java developers if they promoted JavaFX applications in production. We have the impression that those evangelists are paid to have fun. This is really unexpected from Oracle, which looks like a very serious company. Take the example of Apple. They are very efficient on that. Every time they present their gadgets they also present outstanding apps developed for that device. It definitively makes developers excited!

Fake announcement of JavaFX for
the mobile world in 2009.  Since then
zero apps shipped so far!

I was about to be excited when Oracle announced JavaFX running on OS6 with an app called JavaFX Ensemble, but when I realised that the goal of the app was simply to add more demos to the shelf, I got immediately frustrated 🙁 Is it so difficult to convince a company out there to write a useful app in JavaFX and make it available on OS6?! Come on! We are tired of demos! In fact, this “alpha” project is not enough to convince us that Java is going mobile. In my previous post I made the following prediction:

“… in 3 or 4 years there will be no Java on devices, and the development community will have enough knowledge to live with that. Therefore, Java will be basically a server-side technology.”

Now, let’s imagine that JavaFX is a great technology and everybody is adopting it. Is everything ok now? Nooooooo! Even if everybody is convinced about JavaFX, there is no stable, reliable and easy to use JVM out there for the client side at the moment. Therefore, we cannot efficiently distribute JavaFX apps on desktops. We have to be within a company, with full control over the network, to manage the installation, security and upgrades of the JVM in all desktops in order to distribute the application. Well, that’s silly :-/

Error during my latest attempt to update my JVM.
Message: “Failure to download required files for installation.”

I’m quite confident to advise you to leave JavaFX aside and go for HTML5. Most of its features are already cross-browser compatible and it’s possible to build amazing user interfaces with that. Client-side Java is over, so get used to an exclusively java server-side world soon. Surprisingly, it doesn’t make me sad, but happier 🙂

Choosing Between Vaadin and JSF

With the recent release of Primefaces 3.0, JSF finally reaches an unprecedent level of maturity and utility that puts it face to face with other popular Rich Internet Applications (RIA) options, such as Google Web Toolkit (GWT), ExtJS, Vaadin, Flex and others. This open source project also proved to be very active and in a constant growing path.

I have been working with JSF + Primefaces since October 2010, when I started developing the project JUG Management, a web application conceived to manage user groups or communities focused on a certain domain of knowledge, whose members are constantly sharing information and attending social and educational events. JSF is a standard Java framework for building user interfaces for web applications with well-established development patterns and built upon the experience of many preexisting Java Web development frameworks. It is component-based and server-side user interface rendering, sending to clients (web browsers) pre-processed web based content such as HTML, JavaScript and CSS. My experience on this technology is openly available on java.net.

Meanwhile, I had the opportunity to create a Proof of Concept (PoC) to compare JSF and Vaadin in order to help developers and architects to decide between one of them. Vaadin is a web application framework for RIA that offers robust server-side architecture, in contrast to other Javascript libraries and browser plugin-based solutions. The business logic runs on the server while a richer user interface, based on Google Web Toolkit (GWT), is fully rendered by the web browser, ensuring a fluent user experience.

The result of the PoC was surprisingly interesting 🙂 It ended up proposing both technologies instead of eliminating one of them. I found out, exploring available books, articles, blogs and websites, that despite being able to implement all sorts of web applications, each technology has special characteristics, optimized to certain kinds of those applications. In practical terms, if we find out that JSF is better for a certain kind of application, that’s because it would take more time and code to do the same with Vaadin. The inverse logic is also true. In order to understand that, we have to visit two fundamental concepts that have direct impact on web applications:

  • Context of Use considers the user who will operate the application, the environment where the user is inserted, and the device the user is interacting with.
  • Information Architecture considers the user of the application again, the business domain in which he or she works on and the content managed in that domain.

Notice in the figure bellow that the user is always the center of attention in both concepts. That’s because we are evaluating two frameworks that have direct impact on the way users interact with web applications.

Visiting the concepts above we have:

Some applications are available for internal purpose only, such as the ones available on the intranet, other applications are used by external users, such as the company website.

Users of internal applications are more homogeneous and in limited number, which means that the UI can be a bit more complex to allow faster user interactions. That explains the fight Microsoft Office vs. Google Docs. The last one is not yet fully acceptable in the office environment because it has less functionalities than Microsoft Office. The latter is, on the other hand, more complex and more expensive. However, a limited number of users to a larger number of features makes acceptable to have some additional costs with training sessions to profit from the productivity features.

A company website targets heterogeneous users in unlimited environments. It is not possible to train all this people, thus simpler user interfaces with short and self-explanatory interactions are desirable.

Considering the environment, we would recommend Vaadin for homogeneous users in limited environments and JSF for heterogeneous users in unlimited environments.

Different devices demand multiple sets of UI components, designed to look great from small to large screens. Fortunately, both frameworks have components to support the full range of screen sizes from regular desktops to mobile devices. The problem is that different devices bring different connectivity capabilities and the application should be ready to deal with short band-width and reduced transfer rates. In this case, Vaadin seems to be more suitable for multiple devices, as long as the variety of devices is not so extensive, because the user interface is rendered locally, using JavaScript, and it has a richer Ajax support to optimize the exchange of application data with the server.

Business Domain
In principle, good quality UI frameworks such as JSF and Vaadin can implement any business domain. The problem is how experienced the team is with the technology or how small is the learning curve to master it. Business is about timing and the technology that offers the best productivity will certainly win. If your team has previous experience with Swing then Vaadin is the natural choice. If the previous experience was more web-oriented, manipulating HTML, CSS ans Scripts, then JSF is recommended.

Content is a very relevant criterion for choosing between Vaadin and JSF. In case the application needs to deal with volumous content of any type, such as long textual descriptions, videos, presentations, animations, graphics, charts and so on, then JSF is the recommended over Vaadin because JSF uses a web content rendering strategy to profit from all content-types supported by web browsers without the need for additional plugins or tags. The support for multiple content is only available on Vaadin through the use of plugins, which must be individually assessed before adoption.

Last, but not least, we have the user, who is the most important criterion when choosing a UI framework. We would emphasize two aspects:

  1. The user population: the largest is the target population the highest are the concerns about application compatibility. It must deal with several versions and types of browsers, operating systems, computers with different memory capacity and monitor resolution. All these without failures or security issues. For larger populations, the most appropriate technology is the most compatible one in a cross-platform environment, which is the case of JSF, since it uses a balanced combination of HTML, JavaScript and CSS, while Vaadin relies only on JavaScript and CSS. But shorter populations would have better profit with Vaadin because cross-browser compatibility is and will remain being a very hard work to be done by Vaadin’s development team behind the scene.
  2. User’s tasks: If the application is intensively operated by users then it is expected that it has more user’s tasks implemented. On the other hand, if the application is rarely used or has short intervals of intensive use, then there is a lower concentration of user’s tasks. According to the PoC, Vaadin is the technology that provides the best support on delivering user tasks with richer user interaction because of its fast visual response. JSF is less optimized on which concerns the user interaction.

In conclusion, instead of discarding one of these frameworks consider both on the shelf of the company’s architectural choices, but visit the criteria above to make sure that you are using the right technology to implement the expected solution. A simple way to apply those criteria would be to assign weights to each criterion, according to the project’s characteristics; set which technology is appropriate for each criterion; and sum the weights for each technology. The highest weight elects the technology to be used in the project.

Suggestions to Improve Texmaker

Texmaker is a Latex editor used to write well structured documents. Latex is a text processing language not so trivial, but once mastering it the writer gets very good results on the overall quality of his/her documents.

I have been using Texmaker for a while, but only recently I could experience most of its features. I spent a long time using it to write my thesis and I figured out some possible improvements that would make this tool more usable. The evaluated version was the 2.0 one, but the latest version is currently the 2.1 one. Maybe some of my suggestions are already available. I didn’t have time to check yet. Anyway, the improvements are:

  1. Restoring the previous session is really an interesting feature. I personally think that it is better than creating a project, as other tools do, because it preserves the simplicity of Texmaker. However, besides saving last opened files and the master document in the application session, I would suggest to save all bookmarks as well. It is useful because when we are working in a large document it is difficult to find exactly the point where we have stopped working last time and bookmarks were the first thing I thought that might be solving this problem.
  2. It think it is quite easy to detect which document is the master. It is basically about to find documentclass at the beginning of the document. So, if Texmaker would be able to set the master document automatically instead of forcing us to do so, it would be a great usability improvement. I understand that there is the case when more than one candidate for master is opened. In this case, I would suggest the following rules to decide which document is the master one before compiling the document:
    • only one file is open and this file can be a master: define it automatically as a master.
    • many files are open, but only one of them can be a master and others are just inclusions (include{}): define as a master the only one that can be a master.
    • many files are open and there are more than one candidate for master: select one of the candidates for master and compile it to define it as the master. If another candidate is selected and the compilation is invoked, then the current selection will become the new master. If the selected file is not a master and the compilation is invoked, then the last selected master is considered.
  3. The spell check works fine, but It would be nice to add new words to the dictionary in order to avoid red underlines in words that we are tired to know they are right. I can imagine how hard it could be to avoid verifying Latex keywords and parameters, so I got used to spell checks’ highlights there, but in my text it’s a bit annoying.
  4. Texmaker is doing a great job presenting the structure of the tex file. Clicking on any item brings the corresponding point in the text to the user, helping a lot on the navigation of long texts. The problem is: why doesn’t it do the same for “bib” files? bib files are as much structured as any other latex file, so Texmaker would implement the visualization of bib files on the structure view, simplifying the navigation through this file, which is usually long.

Hey! Wait a minute! Texmaker is open source. Why don’t I just make all these contributions to the project? For the moment I can’t. I wish I could, but to invest time in C++ might not be so strategic for my carrier right now. I’ve tried to find some Latex tool implemented in Java, but I found just some immature projects unfinished. Anyway, I’m quite confident that an usability evaluation can be also considered as a contribution to a open source project, don’t you think so? 😉