Web Application UI(三):Web Application Input Form: Design Guidelines

Web Application Input Form: Design Guidelines

Before designing our UI components, we investigated many examples. We researched the samples of many UI design books for a better input form design. Many UI books are somewhat misleading for application developers because they focus on web site usability. If you are a web developer most of the things I mention will not be new for you but I hope this post may give some new clues.

Input forms are the primary elements of a web application. A standard application has 3 standard application types; parameters, transactions (data entry), and reporting. Transactions are generally occurs via data entry screens. Data entry may occur in many forms like user data entry, data importing, device input, or pulling data. In a typical application, user data entry builds the most of data. Input forms are the medium for that task. Because of that reality, input forms are very important in web application design.

In web applications, we have some drawbacks compared with standard desktop applications. For instance, UI event handling is not as easy as it is in desktop applications. Although, UI events can be executed via AJAX server calls, that kind of development is still expensive.

Let’s see the functions of a standard input form:
1- Providing input controls for data entry; input texts, check boxes, combo boxes, calendar popup, reference record lookup popup, list boxes, hidden fields etc.

2- Presenting new or existing data; user input fields should have formatting ability in both client-side and server-side. For example, numeric field should format the numbers same as the server-side Java formatting. Required fields should be distinguishable.

3- Execution of some codes upon user UI events. For example we may lock an input text field according to some events. Or we may pull some data via an AJAX call.

4- Posting and validation of data; user submits form. Client or server-side validation should be done. Validation or transaction errors should be user-friendly presented back to user. Server objects (EJB-DAO-POJO-DTO?) associated with form input should have appropriate states on failures and retry.

Here is a typical input form snapshot:
InputForm

1. Don’t forget to put form title. It should say if this is a new entry or update. We placed it here. Other places of the page may be used. One important design lesson we learned is that use the same JSP page for insert and update of record. Otherwise there will be many pages that mean code duplication.

2. A master record may have relational detail records. Details are placed in other tabs. This example is not in one-page master-detail form, we split them. Master-detail form design is not easy in web applications compared with desktop applications, I’ll mention it later.

3. You may need some summary reports quickly (On-record reporting). These pages serve this purpose. When user clicks these tabs, it is easily reported.

4. Record navigator enables us to iterate the records. This is a common control in Windows forms. Our navigator doesn’t have delete-add-update-save buttons because these commands are located in other places (see my Web List Component post).

5. Reference lookup input controls are the most difficult control to develop. Why? It has many functions. First question how do you open lookup popup? In new window or dialog control or layer? How to return selection to page? How do you execute some codes upon selection? After completing popup dialog problem, user comes and says “I changed reference data but associated text at the bottom didn’t change!”. That text should be fetched via AJAX call both on data changes and page load with the same mechanism.

LookupPopup

6. Numbers should be right-aligned. We used coloring in required fields, as you can see its background color is different than other input texts. At first, we had used ”*” but coloring is nicer.

7. One important usability rule is that you should separate data and label text. We used “Bold” font for data. Some uses colors but I think this is more elegant.

8. This is also an important feature that you should highlight the cursor position on page. Otherwise user has to look around to find it. We use an attractive background color for focused-active elements.

9. Don’t forget to format numbers, money, dates, times and timestamps. Some custom data type may need also special formatting on the screen. If it is editable, we have to format data both server-side and client-side. Users may change data and after focus lost we should format again (Or format on the fly but users may go crazy if it is not coded appropriately).

10. Finally, it is time to submit data to start a new journey, server-side processing. Command buttons should be big enough to click and grouped within the same region of page. You may do some client validation or leave that job for server-side. After validation errors, you may report it field-level like below.

FormErrors


Our forms have following extra functions:
1- User can navigate active input forms by entering enter key or navigation (Up-Down) keys.
2- User’s previous data entry is saved and if user press F3 key on any input text, previous entry is restored there.
3- Focused input element is remembered in the next visit.
4- We have bulk-update forms that provide users update many records at the same time.
5- Printing is possible within form pages.

No comments:

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章