# A Morphological Box for Handling Temporal Data in B2C Systems

Gerhard F. Knolmayer, Alessandro Borean

► To cite this version:

Gerhard F. Knolmayer, Alessandro Borean. A Morphological Box for Handling Temporal Data in B2C Systems. 10th IFIP WG 6.11 Conference on e-Business, e-Services, and e-Society (I3E), Nov 2010, Buenos Aires, Argentina. pp.215-225, 10.1007/978-3-642-16283-1_25 . hal-01055018

HAL Id: hal-01055018

https://inria.hal.science/hal-01055018

Submitted on 11 Aug 2014

**HAL** is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# A Morphological Box for Handling Temporal Data in B2C Systems

Gerhard F. Knolmayer and Alessandro Borean

University of Bern, Institute of Information Systems, Engehaldenstrasse 8,
CH-3012 Bern, Switzerland
{gerhard.knolmayer, alessandro.borean}@iwi.unibe.ch

**Abstract.** User interfaces are key properties of Business-to-Consumer (B2C) systems, and Web-based reservation systems are an important class of B2C systems. In this paper we show that these systems use a surprisingly broad spectrum of different approaches to handling temporal data in their Web interfaces. Based on these observations and on a literature analysis we develop a Morphological Box to present the main options for handling temporal data and give examples. The results indicate that the present state of developing and maintaining B2C systems has not been much influenced by modern Web Engineering concepts and that there is considerable potential for improvement.

**Keywords:** B2C Systems, Reservation Systems, Usability, Temporal Data, Morphological Analysis.

## 1 Introduction

Business-to-Consumer (B2C) transactions involve a large number of users who are not willing to undergo site-specific learning processes and who should be able to use the system intuitively. Therefore, user interfaces are a key feature of B2C systems. Web-based reservation systems have become a highly relevant distribution channel in the travel industry [1]. Handling temporal data (HTD) in Web interfaces has a high relevance in these reservation systems, because each reservation is time related. Fabre and Howard [2] argue that “good practices” for HTD should find their way into style guides, screen design guidelines, and repositories of reusable interface designs.

In this paper we show that temporal data is handled by Web-based reservation systems very differently, sometimes in user-unfriendly ways and in contradiction to usability guidelines, and in some cases even erroneously. The remainder of this paper is organized as follows: In Section 2 we refer to previous work on usability issues of B2C systems and on handling time in information systems. In Section 3 we describe procedures used for HTD in airline and hotel reservation systems in a Morphological Box and discuss the characteristics of the features. Section 4 provides a summary and considers opportunities for further research.
## 2 Previous Research

Many publications report usability problems of B2C sites [3-8], and in particular of Web-based travel and reservation systems [9-14].

ISO 9241-110 specifies seven principles for designing dialogues between humans and information systems, which include self-descriptiveness, conformity with user expectations, and error tolerance [15]. Of special relevance in our context are 23 usability guidelines on data entry, recommending that data formats should be clearly indicated for inputs, text entry fields should indicate the format of data to be entered, dropdown menus should be used in preference to text entry fields, and forms should be validated before submission [16].

There is a huge body of time-related research. At least 13 bibliographies on HTD in information systems have been compiled [17-18], focusing on temporal databases and artificial intelligence topics. HTD gained broad public interest in connection with solving the Year 2000 (Y2K) problem; in early January 2000 some Websites displayed seriously wrong date representations [19].

Temporal aspects are often neglected in usability research [2]. In their comparison, among many other matters, Law et al. [20-21] consider whether such features as “Free entry of check-in/out date,” “Date/time available for booking,” and “Warning of incorrect date/time entry” are supported. Detailed recommendations for system developers are given by Bainbridge [22]. However, approaches to improving usability differ remarkably between academia and practice [23].

Information engineering concepts such as patterns and services can also be useful for HTD. Temporal patterns are discussed, e.g., in [24]; several temporal services are compiled in [25].

## 3 A Morphological Analysis of Handling Temporal Data

The perceived usability of a B2C site is often seen as an indicator of the quality of the product or service offered by the company. In this paper we focus on HTD and, thus, consider a single element of the user interface in more depth than previous analyses. Needless to say, HTD is only one aspect to be considered in the evaluation of a user interface. However, this feature seems to carry considerable potential for errors and demotivation if designed in a user-unfriendly way, and may result in higher transactions costs, loss of revenues, and lost customers.

Below we discuss reservations made on the sole basis of online information and directly by travelers via the Web and exclude communications via contact forms or e-mails. We consider interval-related dates for reservations; the scope of the paper does not extend to sequences of more than two dates (occurring, e.g., when multiple destinations are booked) or to intraday temporal data.
## 3.1 Methodology

A morphological analysis is characterized as an ordered way of looking at things [26-27]. The Morphological Box can be applied to provide a systematic overview of elementary courses of action and how they are combined in existing products and services. We develop a Morphological Box (Table 1) in which we show the elementary options for HTD in reservation systems. Each of the 10 rows describes a main feature of HTD in reservation systems and the corresponding table entries show the elementary options available for this feature. All reservation systems can be characterized by one marking in each row and a profile line which connects these markings. Multiplying the number of elementary options per feature results in almost 125,000 combinations; however, some of them are not feasible.

The following section is structured according to the Morphological Box (Table 1). We describe the main features of HTD and add comments and examples where necessary. The features were found by literature analysis and by a critical review of many reservation systems. In this phase of research we did not perform a quantitative analysis of a well-defined set of systems, because we first wanted to build a framework of approaches for HTD. Our examples primarily describe inadequate or user-unfriendly solutions to show the potential benefit of applying information engineering methods and tools for Web Engineering more rigidly in the future.

## 3.2 Ten Features in Handling Temporal Data

### 3.2.1 Definition of the Booking Interval

For a reservation the user has to define the corresponding time interval, which can be described by its starting day $t_s$, its duration $d$, and/or its end $t_e$. Two of these elements suffice to define the interval. Most systems expect the entry of $t_s$ and $t_e$. In a few cases $t_s$ and $d$ have to be entered and we are not aware of any system that expects the entry of $d$ and $t_e$.

In rare cases interfaces allow entry of all three values ($t_s$, $d$, and $t_e$). At first glance, this looks user-friendly and the third element can be determined automatically as soon as the user entered two elements. However, if the user is changing one of the three date elements after his original entry, the system does not know which of the remaining two date elements should be modified. The resulting temporal integrity problems are discussed in more detail in [28].
<table><caption>Table 1. Morphological Box for Handling Temporal Data.</caption><thead><tr><th>Sect.</th><th>Feature</th><th colspan="4">Characteristics</th></tr></thead><tbody><tr><td>3.2.1</td><td>Definition of the Booking Interval</td><td>t<sub>s</sub>, t<sub>e</sub></td><td>t<sub>s</sub>, d</td><td>d, t<sub>e</sub></td><td>t<sub>s</sub>, d, t<sub>e</sub></td></tr><tr><td>3.2.2</td><td>Display of Calendars</td><td>No calendar</td><td>After clicking in date entry field</td><td>After clicking on calendar icon</td><td>Without user action</td></tr><tr><td>3.2.3</td><td>Entry and Changes of Temporal Data</td><td>Keyboard</td><td colspan="2">Click in dropdowns</td><td>Click in calendar</td></tr><tr><td>3.2.4</td><td>Display of Date Format</td><td>Not indicated</td><td>Abstractly (e.g., mm/dd/yyyy)</td><td>Numerically (e.g., 11/03/2010)</td><td>With months shown as text</td></tr><tr><td>3.2.5</td><td>Representation of and Access to Temporal Data</td><td>No calendar</td><td colspan="2">Rectangle with sequential access to months</td><td>Rectangle with direct access to months</td></tr><tr><td>3.2.6</td><td>Default Values</td><td>No default values</td><td colspan="2">Default values set with warning</td><td>Default values set without warning</td></tr><tr><td>3.2.7</td><td>Temporal Integrity Constraints</td><td>Not supported</td><td colspan="2">Check t<sub>s</sub> and t<sub>e</sub> (and, if applicable, d) only individually</td><td>Check t<sub>s</sub> and t<sub>e</sub> (and, if applicable, d) individually and also their relationship(s)</td></tr><tr><td>3.2.8</td><td>Error Messages</td><td>Avoided by setting default values</td><td colspan="2">Immediate at data entry</td><td>Delayed until subsequent user action (e.g., Search)</td></tr><tr><td>3.2.9</td><td>Temporal Flexibility on Entry Page</td><td>No flexibility offered</td><td>Flexibility interval(s) &gt;0, but undefined</td><td>Flexibility with preset interval(s) (e.g., ± 3 days)</td><td>Flexibility with user-defined interval(s)</td></tr><tr><td>3.2.10</td><td>Temporal Data after “Major Changes”</td><td>Temporal data is lost</td><td colspan="3">Temporal data is kept</td></tr></tbody></table>

Legend:

t<sub>s</sub> ... Start of reservation interval; d ... Duration; t<sub>e</sub> ... End of reservation interval
### 3.2.2 Display of Calendars

We define a calendar as a rectangular structure displaying the days of a month; columns represent the weekdays and rows stand for weeks. Calendars can be displayed without user action or after the user requests it, e.g., as a calendar popup after a calendar icon or a date entry field has been clicked [22]. Some calendars already show whether a reservation is possible or not.

### 3.2.3 Entry and Changes of Temporal Data

Temporal data is typically entered via the keyboard or with a pointing device (“date picker”). The pointing device may be used to click in a dropdown element or in a calendar. Keyboard, dropdown, and calendar date entry can be combined; therefore one could also show all seven combinations in the Morphological Box. Some systems impede changes via the keyboard by positioning a pop-up calendar above the field that displays the date. Surprisingly, the behavior of some systems depends on how the date has been entered [28].

If only a single component of the date information (in particular days) is shown, it is mostly displayed linearly in a dropdown, which may show either numbers only or, more conveniently, the numbers together with (maybe abbreviated) names of days. Often only a subset of all days is displayed, and the user may have to scroll to other days. For a given Browser the subset may be static (e.g., days 1-20 are shown initially) or context specific (e.g., as a “rolling dropdown” [22], starting with the current day). The length of the month should be taken into account if the user has already entered his preferred month for travelling; for example, a dropdown for selection of the day should not offer the value 31 for November. However, many systems miss these requirements [28].

Shneiderman and Plaisant [29] argue that providing a “graphical calendar” will reduce the number of errors, and UserFocus [16] suggests avoiding text entry fields if possible. If calendars are used, the options presented can be restricted to feasible values. For instance, days that are already past or lie beyond the booking horizon should be suppressed, faded out, crossed out, or grayed out.

After a date has been entered via a pointing device, it can often be corrected via the keyboard. Such changes may result in errors, because temporal integrity checks are often missing in this case [28].

Displaying the (full or abbreviated) name of the weekday and month in or close to the date field may reduce errors [3, 22].
### 3.2.4 Display of Date Format

With respect to keyboard entry it must be borne in mind that dates are represented in different cultures in diverse formats and that this nasty problem without good solutions is a source of misunderstandings, confusion, and errors [29-31]. Although ISO 8601 defines YYYY-MM-DD as the standard representation of days, this standard is not widely accepted by the general public. W3C [32] discusses three possible solutions to this problem; other design guides for date display have also been proposed, primarily in a healthcare context [33-34].

Nonetheless, Web-based reservation systems use an astonishing variety of date representations; among the 37 (!) variants we detected for displaying, e.g., the day 2010-11-03 we found such displays as

10-11-3,

3. November 2010,

some with no reference to year, such as Nov 3,

Nov-03-2010,

<figure><img src="image_2.png" /></figure>

In particular if keyboard entry of dates is allowed, the user should be informed which date format is used by the system. This could be done in abstract form (e.g., MM/DD/YYYY) or with a numerical example, often displaying a default value in the entry field. However, if the example uses day numbers ≤ 12, the display will be ambiguous with respect whether the format is MM/DD or DD/MM. Although some reservation systems ask where the user is located, the date format used is typically not adjusted to this information.

### 3.2.5 Representation of and Access to Temporal Data

Many reservation systems provide some type of calendar information, usually with names or verbal abbreviations of months and a numerical representation of days. Information about and links to many calendar implementations are compiled in [25]. Typically no week numbers are displayed when showing calendars.

The user may see one or more (mostly <4) months on the same screen. Months that are not displayed can be selected either directly, by clicking on an element of a list or of a rectangular representation of months (cf. Figure 1), or via browsing the calendars by moving forward or backward one month at a time until the relevant month appears; in rare cases the moves jump several months forward or backward with a single click.

In different cultures weeks are assumed to start with either Sunday or Monday. This means it is essential that the user is paying attention, and although some reservation systems ask where the user is located, the representation of weeks typically is not adjusted to this information.
<figure><img src="image_3.png" /><figcaption>**Figure 1.** Direct access to months via a 2x7 rectangle (http://www.qantas.com.au/travel/airlines/home/au/en)</figcaption></figure>

### 3.2.6 Default Values

Many reservation systems assume default values for $t_s$, $d$, or $t_e$. When a user enters a site, the system often shows default values for $t_s$ and $t_e$. Popular default values for hotel reservations are $t_s$ = today and $t_e$ = $t_s$ + 1. One reason for showing default values may be that the systems want to show the date formats applied (cf. Section 3.2.4).

Some systems provide or adjust a default value for $t_e$ as soon as $t_s$ is entered. If default values are inserted, a distracted user may not recognize that the value has been set by the system. Therefore, setting default values could be accompanied by a warning message; however, we found very few warnings.

Owing to a limited booking horizon (cf. Table 2), in the early days of November 2010 many systems will not offer the option of booking a flight for late October 2011, as an example; however, if a user who is unaware of the limited booking horizon tries to book for December 2011, many systems will automatically switch to December 2010. This is a potential source of error, particularly if the system does not show the year of the reservation.

Some reservation systems avoid infeasible travelling dates $t_s > t_e$ by heuristically adjusting $t_s$ according to $t_e$, or vice versa. Problems of such adjustments and their sometimes strange results are discussed in the following section, and in more detail in [28].

In general, it is doubtful whether default date values inserted by reservation systems benefit the users, and we assume that they are a major source of error, which could be avoided by nullifying instead of defaulting inconsistent date entries.

### 3.2.7 Temporal Integrity Constraints

Several types of temporal integrity constraints have to be considered for defining valid reservation intervals. They check $t_s$ and/or $t_e$ and/or $d$ individually, or also the relationship(s) between these values. Of course no days that are already past and no inexistent days should be suggested to the user or accepted by the system. However, many systems offer, for instance, the day 31 also when the user already defined a month with less than 31 days.

The constraint $today \le t_s \le t_e$ looks highly plausible, but in some situations checking it becomes quite challenging and is not sufficient [28]: Systems should consider
the local time at the departure location for checking this constraint. For instance, a user staying in Sydney could want to make a reservation shortly after midnight for a traveler staying in Rio de Janeiro. In this case, the constraint may be violated if the system compares $t_s$ with the date in Sydney.

Minimal periods from today to $t_s$ and maximal time periods up to $t_e$ may have to be considered. Most systems do not make the booking horizon explicit. For booking flights, the horizon often lies between 320 and 365 days. Table 2 gives examples and shows the update behavior after 1 week and 1 month.

<table><caption>Table 2. Maximum intervals between booking day and day of service [YYYY-MM-DD].</caption><thead><tr><th rowspan="2">Reservation system</th><th rowspan="2">Address</th><th colspan="3">Number of days bookable at</th></tr><tr><th>2009-11-16</th><th>2009-11-23</th><th>2009-12-15</th></tr></thead><tbody><tr><td>Ebookers</td><td>www.ebookers.ch</td><td>330</td><td>330</td><td>330</td></tr><tr><td>Japan Airlines</td><td>www.ch.jal.com/en</td><td>330</td><td>330</td><td>330</td></tr><tr><td>Priceline</td><td>www.priceline.com</td><td>330</td><td>330</td><td>330</td></tr><tr><td>Singapore Airlines</td><td>www.singaporeair.com/saa/en_UK</td><td>350</td><td>350</td><td>350</td></tr><tr><td>Air Canada</td><td>www.aircanada.com/en</td><td>353</td><td>353</td><td>353</td></tr><tr><td>Lufthansa</td><td>www.lufthansa.com</td><td>361</td><td>361</td><td>361</td></tr><tr><td>SAS</td><td>www.flysas.com/en/us</td><td>361</td><td>361</td><td>361</td></tr><tr><td>SideStep.com</td><td>www sidestep.com</td><td>365</td><td>365</td><td>365</td></tr><tr><td>Southwest Airlines</td><td>www.southwest.com</td><td>172</td><td>165</td><td>143</td></tr><tr><td>American Airlines</td><td>www.aa.com</td><td>329</td><td>329</td><td>330</td></tr><tr><td>SWISS</td><td>www.swiss.com</td><td>344</td><td>339</td><td>339</td></tr><tr><td>Austrian Airlines</td><td>www.aua.com</td><td>349</td><td>342</td><td>361</td></tr><tr><td>Northwest Airlines</td><td>www.nwa.com</td><td>352</td><td>331</td><td>331</td></tr><tr><td>Hertz</td><td>www.hertz.ch</td><td>379</td><td>372</td><td>381</td></tr><tr><td>Avis</td><td>avis.ch</td><td>380</td><td>380</td><td>381</td></tr></tbody></table>

Often, the last bookable day is adjusted on a daily basis ("moving windows" of different lengths; cf. the upper part of Table 2). Southwest Airlines (www.southwest.com) fixed the last bookable day during our research period. No regular update behavior could be found at other Websites (cf. lower part of Table 2). Some systems show calendars relating to long periods but allow bookings only within a comparatively short horizon. For instance, Aban Air (www.abanair.com) offers year entries between 1910 and 2020. It is user-unfriendly if a system offers an option for clicking and rejects in a later step the entry of a date that has been offered.

If an intermediary admits a long booking horizon, there will be very few reservation systems of the final service providers (e.g., hotels) that also support this horizon. The user may be surprised to find that the number of options offered diminishes with increasing time from the day of the booking request. This behavior can be found, e.g., at http://www.hotel.de/Search.aspx?lng=EN.
In addition, many hotels restrict the length of a reservation to a maximum number of days [28].

If a user plans a reservation in September for a trip starting in November, the calendars for September and October should be suppressed when the calendar to be used for determination of $t_e$ is shown. More generally, no options for entering $t_e < t_s$ should be offered, and if the user entered $t_e$ first, the system should hide all $t_s > t_e$. Conformity expectations are violated if, for example, the SAS reservation system (www.flysas.com/en/ch) suppresses infeasible return days after entry of the outward day but does not suppress infeasible outward days after entry of the return date [28].

Special integrity issues arise when the user changes previously entered data. Many systems try to keep integrity by default adjustments if the user prepones $t_e$; however, not all of them react analogously if $t_s$ is postponed. This again infringes conformity expectations of users.

### 3.2.8 Error Messages

Temporal integrity can be checked either when the user enters the date in the form (Stage 1: “immediate method”) or when he submits the form and starts a request, which may be named as search, go, etc. (Stage 2: “delayed method”) [22, 35]. If the immediate method is applied, a user who wants to modify both $t_s$ and $t_e$ could receive an error message after the first change; however, this problem is typically avoided by a heuristic adjustment of the other date. Some systems ask for additional information in stage 2 even if the dates are infeasible because a check of temporal integrity constraints is postponed until the user provided additional, probably obsolete, entries.

Several Websites show bizarre and misleading error messages [29]. Examples of informative and misleading error messages in the case of violated temporal integrity constraints are given in [28]. Some systems avoid error messages generally by setting default values; however, this is an error-prone procedure (cf. Section 3.2.6).

### 3.2.9 Temporal Flexibility on Entry Page

Before deciding about a reservation, the user may consider several variants of destinations and temporal intervals. Some reservation systems allow temporal flexibility for $t_s$ and $t_e$ on the entry page. Intervals for temporal flexibility are typically preset by the systems; American Airlines used to allow a user-defined flexibility interval, which, however, seems to have disappeared in the meantime. Some systems show travel options for different days on the result page after executing the search, even without user request. This may be regarded as valuable information by some users and as information overload by others.

Options with respect to intraday flexibility may also exist. On some sites the user may enter favored hours for departure, while other systems use (sometimes imprecise) verbal paraphrases. For example, Continental Airlines (www.continental.com/web/en-US) offers the user a choice of such fuzzy data as “early morning,” “morning,” and “late morning.”
### 3.2.10 Temporal Data after “Major Changes”

If a user alters his potential destination, switches from a one-way or a multicity flight to a roundtrip, or clicks on the Browser’s “Return” button, we call his action a “major change.” Below we focus on destination changes and their impact on previously entered temporal data. On his way to a reservation decision, the user may tentatively want to receive information on traveling to another destination than the one originally considered. However, the time interval may be identical to the previous query, e.g., because of fixed holidays. In this situation it is inconvenient if the system forces the user to enter the temporal data again and again; the dates defined in the previous search could be used as temporal default values. Many systems save temporal data in case of major changes. Among the systems that lose temporal information when the user clicks the return button are those of United Airlines and Continental Airlines (www.united.com; www.continental.com/web/en-US for users applying the Firefox Browser).

## 4 Discussion and Outlook

This paper shows that reservation systems handle temporal data in surprisingly different and sometimes inadequate ways. Therefore, we developed a Morphological Box that presents the main features needed for handling temporal data and their characteristics in a systematic way.

System developers seem to reinvent the wheel over and over again, often without following guidelines and without using patterns or services. The ambiguity of today's implementations shows that many Web-based systems are still developed individually without (re)using existing services even for a basic functionality such as handling temporal data. From a Web Engineering viewpoint this finding is disappointing: Contrary to the broad consensus about the benefits of methodological approaches, the adherence of guidelines, the development and use of temporal patterns as a basis for implementations, and the reusability of services seem to be still in their infancy. Also Web sites of major travel intermediaries, which reduce the relevance of the reservation systems of the final service providers, handle temporal data not without flaws.

The Morphological Box presented in Table 1 and the issues discussed in Section 3 will be used in further work to evaluate B2C systems. We plan to have the features and characteristics defined in the Morphological Box evaluated by usability experts. The results will allow to weight the relevance of the features and to distinguish between more or less favorable characteristics. This allows to restructure the Morphological Box for an easier comparison of different profile lines. The empirical results will allow to develop a maturity model for handling temporal data and to assign existing reservation systems to maturity classes.

Another stream of research could evaluate the options described in the Morphological Box from the perspectives of users with disabilities or of elderly citizens.
References

1. Marcussen, C.H.: Trends in European Internet Distribution - of Travel and Tourism Services (2009), http://www.crt.dk/uk/staff/chm/trends.htm

2. Fabre, J., Howard, S.: Introduction to the Special Issue on Temporal Aspects of Usability. Interacting with Computers 11, 1--7 (1998)

3. Nielsen, J.: Designing Web Usability: The Practice of Simplicity. New Riders, Indianapolis (2000)

4. Green, D., Pearson, J.M.: Development of a Web site usability instrument based on ISO 9241-11. Journal of Computer Information Systems 47, 66--72 (2006)

5. Cappel, J.J., Huang, Z.: A Usability Analysis of Company Websites. Journal of Computer Information Systems 48, 117--123 (2007)

6. Hu, H.-J., Yen, J., Guan, S.-S.: A Study on the Interface Usability of B2C Hypermarket E-commerce Website. In: The 3rd IEEE Asia-Pacific Services Computing Conference. IEEE Computing Society, Los Alamitos, pp. 1202--1207 (2008)

7. Lituchy, T.R., Barra, R.A.: International issues of the design and usage of websites for e-commerce: Hotel and airline examples. Journal of Engineering and Technology Management 25, 93--111 (2008)

8. Tucker, S.-P.: E-commerce standard user interface: an E-menu system. Industrial Management & Data Systems 108, 1009--1028 (2008)

9. Selvidge, P.: How Usable are the Airline Websites? Usability News 1, (1999), http://www.surl.org/usabilitynews/11/Usability.airline.asp

10. Crichton, E., Frew, A.J.: Usability of Information and Reservations Systems: Theory or Practice? In: Fesenmaier, D.R., Klein, S., Buhalis, D. (Eds.) Information and Communication Technologies in Tourism 2000, pp. 408--417. Springer, Wien (2000)

11. Chariton, C., Choi, M.-H.: Enhancing Usability of Flight and Fare Search Functions for Airline and Travel Web Sites. In: Proceedings of the International Conference on Information Technology: Coding and Computing (ITCC'04), pp. 320--325. IEEE Computer Society, Los Alamitos (2004)

12. Malizia, A.: Adding flexibility to B2C booking systems using a virtual intermediate travel agent. In: Proceedings of the 2005 IEEE Symposium on Visual Languages and Human-Centric Computing, pp. 337--338. IEEE Computer Society, Los Alamitos (2005)

13. Zhou, Q., DeSantis, R.: Usability Issues in City Tourism Website Design: A Content Analysis. In: 2005 IEEE International Professional Communication Conference Proceedings, pp. 789--796. IEEE Press, Piscataway (2005)

14. Essawy, M.: Testing the Usability of Hotel Websites: The Springboard for Customer Relationship Building. Information Technology & Tourism 8, 47--70 (2006)

15. ISO 9241-110, Ergonomics of human-system interaction - Part 110: Dialogue principles (2006), http://www.iso.org/iso/catalogue_detail.htm?csnumber=38009

16. Userfocus: 23 forms and data entry usability guidelines (2009), http://www.userfocus.co.uk/resources/formschecklist.html

17. Grandi, F.: An Annotated Bibliography on Temporal and Evolution Aspects in the World Wide Web, TimeCenter Technical Report TR-75 (2003), http://timecenter.cs.aau.dk/TimeCenterPublications/TR-75.pdf

18. Grandi, F.: Introducing an Annotated Bibliography on Temporal and Evolution Aspects in the World Wide Web. SIGMOD Record 33, 84--86 (2004)

19. Knolmayer, G.: Endzeitstimmungen in einer hochtechnisierten Gesellschaft: Das Jahr 2000-Problem, seine Wahrnehmung und mögliche Konsequenzen. In: Moser, R., Zwahlen, S.M. (Eds.) Endzeiten – Wendezeiten, pp. 13--26. Lang, Bern (2004)
20.Law, R., Leung, R.: A Study of Airlines' Online Reservation Services on the Internet. Journal of Travel Research 39, 202--211 (2000)

21.Law, R., Leung, K., Au, N.: Evaluating Reservation Facilities for Hotels: A Study of Asian Based and North American Based Travel Web Sites. In: Wöber, K.W., Frew, A.J., Hitz, M. (Eds.) Information and Communication Technologies in Tourism, pp. 303--310. Springer, Wien (2002)

22.Bainbridge, A.: Hotel Date Entry: Design & Usability Report. Travel UCD (2002), http://www.tourcms.com/company/research/pdf/date_entry_hotel_july2002.pdf

23.Furniss, D., Blandford, A., Curzon, P: Usability Work in Professional Web Site Design: Insights from Practitioners' Perspectives. In: Law, E.L.-C., Hvannberg, E.T., Cockton, G. (Eds.) Maturing Usability: Quality in Software, Interaction and Value. Human-Computer Interaction Series, pp. 144-167. Springer, London (2008)

24.Fowler, M.: Temporal Patterns (2005), http://www.martinfowler.com/eaaDev/timeNarrative.html

25.Lennartz, S.: Online Calendars and Date Pickers. Smashing Magazine (2007), http://www.smashingmagazine.com/2007/10/23/online-calendars-and-date-pickers/

26.Zwicky, F.: Morphological Astronomy. The Observatory 68, 121--143 (1948)

27.Zwicky, F.: Discovery, Invention, Research Through the Morphological Approach. Macmillan, Toronto (1969)

28.Knolmayer, G.F., Helfenstein, L.E.: Usability Aspects of Ensuring Temporal Integrity Constraints: A Critical Appraisal. In: Proceedings of the Fifth International Conference on Human-Computer Interaction, Lahaina 2010.

29.Shneiderman, B., Plaisant, C.: Designing the User Interface: Strategies for Effective Human-Computer Interaction, 5th ed., Addison-Wesley, Upper Saddle River (2010)

30.Nielsen, J.: Usability Engineering. Morgan Kaufmann, San Francisco (1993)

31.Hanna, J.: Date & Time Formats on the Web, http://www.hackcraft.net/web/datetime/

32.W3C: Date formats (2007), http://www.w3.org/International/questions/qa-date-format

33.NHS: CUI CAPS Development Lifecycle (2008), http://www.isb.nhs.uk/docs/cui-1/cuideadraft/SubCUI.pdf

34.Microsoft: Design Guidance - Date Display, Version 3.0.0.0 (2010), http://www.mscui.net/DesignGuide/Pdfs/Design Guidance -- Date Display.pdf

35.Greene, S.L., Gould, J.D., Boies, S.J., Meluson, A., Rasamny, M.: Entry-based versus Selection-based Interaction Methods. In: Proceedings of the Human Factors Society - 32nd Annual Meeting, pp. 284--287. Human Factors and Ergonomics Society, Santa Monica (1988)