The development of the graphical interface of an application, because of its importance, is a subject studied in various areas of computer science.
The Human-Computer Interaction (HCI) or Human-Machine Interface (HMI) is a compulsory subject in some undergraduate or specialization and is exactly this subject.
The concept of HCI shows us that there are several requirements for the creation, well-defined interface between the application and the user such as: usability, simplicity, ergonomics and accessibility. Also, we realize that as technology advances, these requirements may increase or modify. In the early days of computing, the user interface was determined by the machine architecture (eg punch cards and magnetic tapes) and shortly after the operating system (eg, command line and cartridges).
Who had the "privilege" of seeing running a computer whose user interface was a punch card reader, you may remember something nothing intuitive or even understanding by most people. At the beginning of the computer age, the manner and form of the machine interface the man was in order to meet the requirements and the computer needs, and human beings should adapt to it. With the evolution of computing, this concept was reversed and it was the computer systems that began to try to meet the needs of users. Thus, the own operating systems have changed their interfaces to the visual modes, and instead of command lines or menus, came into existence icons and windows, that are much more intuitive interfaces for most users.
Note: The concept of ubiquitous computing says that an application can run on any kind of computer equipment and is therefore not possible to predict exactly what kind of device is accessing our systems and, in many cases, much less the user profile.
When we treat the development of Java applications for the web environment, we start with the famous Applets, which are almost a version of Desktop model (Swing) running through the browser. These emerged as the first alternative for such development and there are today.
The main use of Applets is currently to provide access to connected devices in the user equipment such as readers cryptographic cards, something that is not only making use of resources offered by the browser for security reasons. In the current state of Java technology, we reached an almost symbiotic integration with browsers, which is enabled by components and frameworks that implement the specifications of the Java Enterprise Edition platform.
The user profile
When we compare the way human-computer interaction in the early days of computing was done with the one made today, we can see a great evolution in the characteristics of these interfaces. In the beginning, the focus of the relationship (man-machine) was the characteristics of the equipment and the currently recommended is to focus on the user profile. At the beginning of the computer age, as already mentioned, the man was forced to adapt to the machine, and thus, to use the computers, users need to have technical knowledge or undergo training to understand and know how to use this type of interface. In recent years, it is noticeable a great increase in the number of computer system users, primarily through available on the internet environment, which provides a number of access facilities that were not possible in the client-server model or purely desktop.
There is also a change in the profile of those who were already the same system users before the advent of the internet, while greater diversification in the profile of new users. Despite this clear change in the profile of users, it is noticeable that the technology and the way of the systems interface development still seem to be geared to specialized users, predominant user profile in the pre-internet era. This highlights, in many cases, little concern for developers to identify what your user. It seems to be quite common that decides the form and presentation of the interface systems are only the systems analysts and or designers, instead of the user himself, or at least with its participation. Of course we must not allow to the user to decide everything, but you also need to consider cases where there should be greater participation. Some agile technical systems development has even advocated greater customer participation in all stages of building a computerized system and therefore the definition of the interface.
There are also cases where the customer is not explicitly known, as the case of a service or software that would like to offer the market. Applications for mobile devices are the most recent examples. It is a major risk factor initiate the development of any interface, following the HCI concepts, without even considering what type of user application will have, and this is true regardless of the device that will be used, and also it seems strange that the opinion or the user's taste is not considered.
You must understand that each user characteristic influence on your profile, such as age, occupation, physical condition, among others, and with this profile can identify the type of user that will use the application. Only then is it possible to know if the user is skilled or not. Note that if you do not know what the user profile of your application, so do not know exactly what it is for. Therefore, the worst option is to try to put in place the user, because it seems obvious to you may not be for those who use the application.
Finally, whenever possible, in addition to carrying out research with potential users, introduce prototypes, or at least an outline of some alternatives. Always remember that the maximum sales world: "The customer is always right", especially when it comes to the system interface.
The interface types
For the Java EE platform, the standard technology for the development of interfaces for web systems is the JavaServer Faces. One of the JSF differential at the time of its release, it was precisely to bring the web interface behaviors and appearances of the most advanced desktop interfaces of the time, as the movement of "drag and drop". With this, the libraries that implement the JSF specification decreased enough differences that were between the desktop type system interfaces to those for web.
With the advent of mobile devices such as palmtops and handhelds, initially interfaces of the systems developed in Java that met this kind of equipment were designed to be accessed via web browsers or by creating native applications to be installed on the device.
However, these had very limited visuals showing, again, a cyclical process of backward and forward in interface types. More recently, with the arrival of smartphones and tablets, it strengthened the use of native applications, representing almost a return to the desktop interface model, but with own behavior, because of the "new" data entry mechanism, touchscreen.
We know that the Java language is the basis of kit for the development of applications in the operating system most commonly used in mobile devices, Android. So it's with little effort a developer that dominates this language can create solutions for this type of equipment. However, many cases will not be resolved only with native applications, they may have complex requirements (use of cryptographic tokens, for example) to be solved only with the resources often limited smartphones, which may require a mixed approach. Thus, it is quite likely that many web systems continue to be created by traditional means, from standard technologies of the Java EE specification, and accessed from different platforms, including mobile.
To improve visualization and usability of Java EE applications for mobile devices, some technology implementations as JSF started to offer components that simulate an interface similar to that of native applications. This type of interface that makes use of specialized JSF components for display on mobile devices, is known as WEB-Mobile. In this type of interface the web application is run through the browser, but mimicking their appearance to become suitable for the device screen size.
Obviously, being a resource that aims to be common to various screen sizes, can not meet with the same precision of a specialized component features you want to achieve a good performance, such as usability, appearance and accessibility, as these features in general are quite platform dependent. For example, a button with an icon may be distorted if the image is the same for multiple screen sizes. On the other hand, may be a way to avoid repetitive development of a same interface according to the device that accesses. So, meet the requirements for identifying which types of interfaces that the application will offer, as well as trace the user's profile, greatly influence the choice of technology to be adopted for building the view layer. And depending on the type of interface that is identified as the standard for the application, sometimes quite simple, it may not even be necessary to adopt an accessory library, thus using only the basic features of the Java EE or even pure HTML.
If we look at the HTML5 specification, we will notice that it has several features that are integrated directly into the browser, which was previously not possible without the help of specialized frameworks, and that can be enough to develop an interface that does not have many action requirements user.
The various alternatives available in the market
Currently, there are several implementations that can be used on an ancillary basis to develop interfaces for Java EE applications. The following are listed some of the most known and used in the market. This listing will be used to establish a comparison between these technologies, which in turn form the basis for defining a strategic plan for adoption of the ideal solution for the development of the interface.
First we will mention the libraries that implement the JSF specification, to be the standard of the Java EE platform interface:
- ICEfaces: They are on the official website of this project about 70 basic components (adhering to the specification) as well as a subproject called ACE Components (ICEfaces Advanced Components), which offers a few more sets of components grouped by features such as, accessibility.
This product has two types of versions: a free, call ICEfaces, and other pay, the ICEfaces EE. As a differential, ICEfaces EE version offers a package of services that provides technical support for the use of components and also allows the user to ask for the customization of any component or creating a new one.
The free version, despite having a good set of components, does not have some pretty important, how responsive designer;
- MyFaces: It is a project of the umbrella type, maintained by the Apache foundation and divided into four sub-projects: Core, Trinidad, Tobago and Tomahawk. The core contains an implementation of which is defined in the JSF specification.
Trinidad, beyond the basics contained in the core, has components that include accessibility requirements. The Tobago, in turn, brings components based on JSF specification, but not using the design pattern policies (such tags ) of a web page (or XHTML, such as the JSF), but by replacing a specific syntax defined by the sub-project aiming to provide a responsive design, but with a similar mode of development with the JSF. And the Tomahawk, which is a set of accessory components, and is an implementation with an approach according to the JSF specification, i.e., makes use of HTML design guidelines (tags) together with those provided by the component, thus creating the XHTML pages of type.
The MyFaces still has some extension packages to support the integrations JSF has the specifications Bean Validation and CDI, namely Orchestra Extensions Validator and CDI Extensions. Being an Apache project, it is totally free;
- RichFaces: The project showcase page are presented 39 basic components. The RichFaces was created and is maintained by JBoss, which in April 2006 was acquired by Red Hat. Just like the Apache project, is open source and has no subscription. In addition to the implementation of the JSF specification, has extra components designed for mobile device interfaces, called WEB-Mobile components, and also components to meet accessibility requirements;
- PrimeFaces: In the Project showcase page are presented 117 components. Because of its maturity, it was adopted as the standard implementation of the Java EE platform 6. The code PrimeFaces is created under open license, but the company that develops offers commercial versions called Elite/Case/PRO and a free version called COMMUNITY. Users of the free version have access to major releases (eg 4.1, 5.0, 5.1), while commercial license holders are entitled to minor corrections (eg 5.0.1).
In practice, those who use the COMMUNITY license must wait for more release to gain access to corrections that occurred in smaller versions. Unlike the ICEfaces project, where the so-called ICEfaces EE has a set of components greater than the free version, in PrimeFaces despite COMMUNITY version does not provide, temporarily, the latest code, which is released to the community is a full release that It contains all components of the larger version and improvements.
The paid version (Elite Case or PRO) is entitled, in addition to access to the latest version, some support options that include up to the request for development of custom components (PRO subscription).
As all these solutions implement the JSF specification, such libraries meet various requirements in a similar fashion and often have a similar performance. What differs each, in general, is the amount of components that are available.
- Bootstrap: Maintained by the creators of Twitter, it has a lot of attention among developers of web applications. Since version 2 has been a reference in responsive design and therefore has several third-party extensions. There are even national extensions to this solution as, for example, the Bootstrap Globo-established by the globo.com site staff;
- AngularJS: Maintained by Google, adopts the strategy to link with the Java application using REST services, currently being considered one of the major players of this type of approach. The latest stable version is 1.3.10 and there is provision for a new version (1.4) even for 2015. According to what has been published on some blogs of experts, there is enough difference between the two versions. So if you start a project with this framework, you may want to wait for the launch of the new version, not to run the risk of creating an application that will soon be making a legacy;
- Vaadin: It is a solution based on GWT, however, as GWT "pure works only on the client side," the Vaadin acts as a server-side architecture. The interesting Vaadin, and GWT is that it is not necessary to work editing HTML or XML pages. The entire coding is done using the Java language, much the same way with programming with Swing. Thus, the learning curve for developers who know Java, but not yet work with the web environment is greatly reduced;
- Crux Framework: Probably the least known of the reader. Nevertheless, it is a national solution developed by the company Triggo Labs and also uses the GWT as a base. Unlike Vaadin, chose to bring the processing to the client side through the use of HTML5.
The communication with the control layer is made from REST services. Being a national product, contact with the solution developers can be more direct. However, it is common in our culture to give more credit to foreign products to the detriment of national production, which consequently discourages local creation. Still, it has stood out from the available options and deserves to be explored and our support.
However, this feature is still overlooked by many developers, it is rare to find a web system (especially in e-commerce) to present these resources.
One must also consider the cases in which the research to define the user profile is not able to explain the accessibility needs, because although no obvious physical characteristics, is quite common some users have a preference for more accessible interfaces.
The interaction with the system via the keyboard (hotkeys) rather than just with the mouse, in the case of desktop systems, is an example of this type of preference. So it is important to check that the library meets the accessibility requirements necessary for the system to be developed, even before coding.
Identify a technology and a library available on the market as a candidate to be adopted in a project means to evaluate the resources available in it and what the developer's knowledge level (or development team) in each of the possible options. An important practical to mark defining the choice of technology and the library is to prepare a prototype of the same application on each of listed libraries, making the performance tests a homologation environment and, finally, request the evaluation of the interface by the user or one significant set. These results may indicate the main strengths and weaknesses of each solution in the user's view, beyond the result of the performance of each.
Cost X benefit
One of the most important issues in any project, be it software or not, it is the cost x benefit ratio. The ideal is to have a low cost combined with a high benefit, but this is not always possible. The user profile requirements and interface type must signal the use of one or some alternative libraries available in the market.
The set of features that each alternative has, or a single alternative, will provide us with a measure of the benefit factor. When analyzing these requirements indicate that there is more than one library option, you need to consider the total cost of application with the benefits that each alternative will bring.
In software projects, development time is impacting the total cost and is usually what defines the choice, but we must also consider the cost of operation and maintenance. The development time depends on the knowledge and developer experience with the technology to be adopted. The smaller the higher intellectual baggage will be the time of construction. But the operation cost is linked to the consumption of resources that the application will do. Memory, disk space, processing, etc., all this adds to the operating value. And despite this cost present a downward trend in recent years, the advent of cloud computing services makes the cost of operation has an important weight in the total cost of the application.
After development comes the cost of maintenance, which can involve both changes in the code as in the operating environment as a new requirement can lead to the development of demand and an increase in consumption may require changing operational resources. Depending on the technology used, the balancing factor in cost x benefit ratio can not meet the ideal goal: that is the low cost and high benefit. Sometimes, technology has reduced costs in development for longer be used by developers to more time, but can not offer some interesting benefits for the user, as a responsive interface.
On the other hand, newer technologies can take more development time, increasing the cost, but often offer more benefits, such as lower consumption of operating resources. Thus, it is in each case identify what impact more in the relationship. If a balance is not possible, the alternative must meet whichever is more appropriate to the general scenario of application development, which involves: time, financial resources, human resources and customer interest. For example: if there is a shortage of financial resources, the option is the lower cost alternative. If there is a user defined, or a client who will pay the bill, it will be the one who pays decide whether to invest in the benefits or to conform the project at a cost.
Therefore, knowing how to analyze this relationship (cost-benefit) may be an important argument when there is resistance in relation to the adoption of any alternative. In general, resistance to change is a natural human behavior, and so it is important to present the right arguments to promote successful change.
Defining a strategy for adoption of a technology
There are some basic requirements to define a strategy for adoption of a technology for the development of a system interface. In this article, we are citing the main ones, namely: user profile, interface type, cost-effective and developer knowledge level. Among them we elect the two most important, analyzed below. The first is the user profile, which must be properly deciphered and can indirectly indicate a technology. Therefore, it is important to create interface prototypes in every possible technology.
The profile analysis should not only be used to identify which type of interface is appropriate to the user, but also so that we can present the benefits that interest him and negatives of each solution. Often a alterative may be refused by the user because the resources that were presented were not focused on the points that interested him. Hence the importance of identifying the profile and choose a more appropriate technology for your needs.
The second is the level of knowledge about the technology that the developer, or team holds. Venturing into a more attractive technological wave may not lead to the best results.
Therefore, it is important to try to develop with current and innovative technologies, but we also need to recognize the limitations of the developer, or team so that the technology itself does not become a risk factor for the project.
If the system is being developed using an agile methodology like Scrum, we as one of the main features of this method one to constant and rapid delivery. Thus, if the technology influence at this time, it may jeopardize the process.
Also consider sources of support that will during development. Latest technologies in general, have less support material, but this is not the essential requirement. The most important is the quality of the material. In solutions that offer an alternative to a web-mobile layer, as is the case PrimeFaces, the layer must be developed specifically for mobile access and another for access by the browser, the desktop.
Of course, nowadays, it is possible to use the mobile interface in the desktop browser, and vice versa, but this will limit some visuals. Typically, however, when there is access to the system for different types of equipment (desktop and mobile), it is necessary to implement two separate interfaces, and that means more coding.
Libraries that have components to meet the so-called responsive design offer an alternative "Polymorphic" for the interface, and is not therefore necessary to implement an interface for desktop and one for mobile. Thus, the same interface implementation will behave in adaptive mode the device screen size that access.
What transpires in responsive interface implementations is that the visual result in mobile devices is not as close to a screen of a traditional mobile application (those that need to be installed). Already at interfaces with components produced web-mobile type, such as offers PrimeFaces (together with jQuery), the result is a bit similar, but as already mentioned, requires more code.
Of course, all interfaces can be improved and, as the components used and the developer experience with each library, could produce different results. Also, remember that each of the examples may have a different cost x benefit, which depend on the user profile and the technical capacity of the developer. The advantage of creating functional prototypes is that the customer can test the application of visual and ergonomic point of view on the device of your choice (mobile or desktop) and at the same time can be made comparative performance tests and consumption of computing resources from visual components on the server side and the response time of the presentation of the screens on the client side (browser).
On the other hand, the non also has development with the amount of components and enablers that exist in JSF libraries that despite consuming a little more server resources, offer more options of items such as templates, and subjects to build the interface, probably are the most time on the market.
This may reflect productivity and visual quality of the screens, taking into considering the question of layout of the screens may depend on the preferences and user profile, which may require the implementation of a visual feature that is not available in the libraries.
A determining factor for the adoption of a technology that is common to any application layer is the developer's ability, and when it comes to a development team, this factor may be even more impactful, as the ability of each member influences directly in the results of all. In the case of teams, if the predominant profile developers with enough experience with the Java language and good ability to absorb new knowledge, the choice of latest technologies and therefore with some more modern features is recommended. However, if the profile is little experience or resistance to change, it is better to opt for technology that is already dominated by the team.
There are cases that the adoption of a new technology can be quite quickly and with a positive result and there are others that in addition to impact the delay of the total development time, also do not generate good results. Probably the reader has already read or heard a phrase like: "The best language (or technology) to develop a system is that you have mastered."
A less restrictive construction of this phrase would say that the best language is that you can master; or depending on the situation, that you have a knowledge base and have time to learn enough. It is important to note that we should never limit ourselves to the knowledge we already have, but we must also be able to discern when it is not feasible risk.
Finally, it is necessary to prepare a report that point each positive and negative point in adopting each of the available options, and also contains the greatest impact requirements in development, such as the schedule with the amount of time planned for implementation and the volume Estimated financial resources available for the project. Look out the points that are most important, according to the user profile.
There is no silver bullet
Most IT professionals also must have already read or heard the term "silver bullet", an expression to denote a fictional magic solution that would solve all problems.
Until recently it was common dissemination of advertisements showing new products to be fantastic and definitive. Today no longer appeals to both. But it is still possible to find mentions of particular technology as one that would be the final or the other as obsolete. In the area of information technology, we know that does not exist and probably never will be something that is definitive, perfect and unchanging.
In this context, what often seems to be the "state of the art" at any given time, you can pass unless recommended and something already considered obsolete can return with force.
Java itself, which has emerged as one of the first alternatives for the development for internet around the year 90, came to be considered outdated for this type of environment in the mid-2000s, but after some changes in the specification and the evolution of technology, Java has returned to one of the best options for creating web applications.
On that basis, instead of believing only what we read or hear of others, we must consider our own ability to learn and evaluate any technology or knowledge, and concomitantly terms discernment so that we are not precipitated in the adoption of new or, other extreme, we stay stuck in time.
Thus, this article ends without indicating or suggesting a particular technology, as this conclusion should be reached in accordance with the actual developer or team, if applicable, and also considering the scenario / context and requirements for system construction.
The most important goal here was enable the reader an initial knowledge that is sufficient so that it can structure and present a study in order to propose the adoption of the most appropriate technology for the project.
PrimeFaces project page.
Crux of the Framework website.