0016883: Flexible interaction with date fields - Openbravo Issue Tracking System

Openbravo Issue Tracking System - Openbravo ERP

View Issue Details

Project

Category

View Status

Date Submitted

Last Update

0016883

Openbravo ERP

A. Platform

public

2011-04-25 15:53

2011-05-26 15:00

Reporter

pjuvara

Assigned To

mtaal

Priority

normal

Severity

major

Reproducibility

have not tried

Status

closed

Resolution

fixed

Platform

OS Version

Product Version

Target Version

3.0MP0

Fixed in Version

Merge Request Status

Review Assigned To

OBNetwork customer

Web browser

Modules

Core

Support ticket

Regression level

Regression date

Regression introduced in release

Regression introduced by commit

Triggers an Emergency Pack

Summary

0016883: Flexible interaction with date fields

Description

I find the interaction with date fields in Openbravo to still be very difficult, inflexible and overall annoying. The behavior that we have in 3.0 is reproducing the same behavior that you have in 2.50 which expects users to work in only a predefined way.

If for example you want to enter 22-04-2011, you can type either

'2' '2' '-' '0' '4' '-' '2' '0' '1' '1'
or

'2' '2' '0' '4' '2' '0' '1' '1'
If everything goes fine and you know what you do, this is efficient. If you make a mistake while typing, things starts getting confusing.

For instance, if you type: '2' '3' '-' 0' '4' (you press 3 instead of 2) and you want to correct it, your natural reaction is to press the back key 4 times (delete 4, 0, -, and 3, change 3 with 2 and continue). The system however automatically deletes the '-' (even if you had entered it manually) so you end up with deleting an extra character.

Also, if you just type an incorrect date and move out of the field, the field is highlighted as incorrect but you can continue, obliging you to return to it later on (a lot of extra clicks in many cases).

I would suggest that:

The application should not attempt to format the field as you type but wait for the user to move out of the field to apply formatting.
If the data entered is not valid, the user should not be able to proceed.
In addition to that, I would also argue that the application should be a lot smarter and be able to complete dates automatically. For instance:

If you only type a number, it should autocomplete with the current month and day (typing '2' '2' and tabbing out should result in 22-04-2011)
If you only type a day and month, the year should autocomplete (typing '2' '2' '0' '5' and tabbing out should result in 22-05-2011)
The application should make a reasonable attempt at interpreting various formats (in the same way that spreadsheets do), considering common variations of separators ('-', '/', ' ' or none), usage of digits versus character representation of months, usage of 2 versus 4 digits for years, position of months, usage of leading zeros for dates and month (i.e. 4 or 04 for April):

22 04 2011
22/04/2011
22042011
22/04/11
22 Apr 2011
Apr 22 2011
22-4-2011
2242011
04222011
4222011
should all be interpreted as 22-04-2011.

NOTE: like in spreadsheet, it is not always possible to interpret dates without ambiguity (for example 4-5-2011 could be interpreted as both the 4th of May 2011 and the 5th of April 2011). In this case, the default date format can help in removing the ambiguity (if your date format is DD-MM-YYYY, 4-5-2011 should be interpreted as the 4th of May 2011).
In any case, the productivity gain of a flexible date interpretation far outweigh the occasional incorrect interpretation.

Finally, considering that people do not always know what date is today, it should be possible to leverage 't' as a shortcut for today:

't' should be converted to the current date (25-04-2011 at the time of this writing)
t+N should be converted to the current date plus N days (t+7 is 02-05-2011 at the time of this writing)
t-N should be converted to the current date minus N days

Steps To Reproduce

Proposed Solution

Additional Information