Project:
| View Issue Details[ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||
| ID | ||||||||
| 0016883 | ||||||||
| Type | Category | Severity | Reproducibility | Date Submitted | Last Update | |||
| defect | [Openbravo ERP] A. Platform | major | have not tried | 2011-04-25 15:53 | 2011-05-26 15:00 | |||
| Reporter | pjuvara | View Status | public | |||||
| Assigned To | mtaal | |||||||
| Priority | normal | Resolution | fixed | Fixed in Version | ||||
| Status | closed | Fix in branch | Fixed in SCM revision | 972652c1e7c2 | ||||
| Projection | none | ETA | none | Target Version | 3.0MP0 | |||
| OS | Any | Database | Any | Java version | ||||
| OS Version | Database version | Ant version | ||||||
| Product Version | SCM revision | |||||||
| Review Assigned To | ||||||||
| Web browser | ||||||||
| Modules | Core | |||||||
| Regression level | ||||||||
| Regression date | ||||||||
| Regression introduced in release | ||||||||
| Regression introduced by commit | ||||||||
| Triggers an Emergency Pack | No | |||||||
| 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 | |||||||
| Tags | No tags attached. | |||||||
| Attached Files | ||||||||
 Relationships [ Relation Graph ]
[ Dependency Graph ]
|
||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||
 Relationships |
|
Notes |
|
|
(0036148) rgoris (developer) 2011-04-28 11:13 |
I fully agree with both severity of the issue and the proposed solution. This is a must for GA, hence the update to "defect" for RC7. The essence lies in formatting the date after leaving the field. There are a number of other related issues pending: It is best to solve the whole date-field/picker/filter issue set at once to guarantee consistent behavior across all widgets and situations. In form view: behavior as described above In grid view: same behavior As column filter: also allow direct date entry in the field with same behavior as in the form. Now when clicking the field, you get the data range lightbox. |
|
(0036155) mtaal (manager) 2011-04-28 12:14 |
I totally agree with this issue, the current behavior was technically complex to develop and it would be great to change it to something as described above, this could mean that we can make use of the standard Smartclient masked entry instead of our very custom parsing logic we have now. I have one remark though... This dateformat can be complex to handle: 22 Apr 2011 As people can use language specific month names and abbreviated names. So for GA my proposal is to just support numeric date values. I hope that's fine to... gr. Martin |
|
(0036162) rgoris (developer) 2011-04-28 14:38 |
Martin, great to hear that we can use standard Smartclient behavior. Do not worry about the "22 Apr 2011" or "Apr 22 2011" date formats, I deem them nice-to-haves and by no means worth the additional effort, also because of localization. |
|
(0036168) pjuvara (reporter) 2011-04-28 16:13 |
Guys... if you can fix this by RC7, you far exceed my expectations. Handling months spelled in words (i.e. 22 Apr 2011) is a nice to have but I agree with Rob: we can live without it. The rest of the changes might improve usability so much that it might not even be needed. If in the process we can also eliminate some complex custom code and move to standard Smartclient functionality, even better. This would be a great win. Paolo |
|
(0037446) hgbot (developer) 2011-05-25 17:46 |
Repository: erp/devel/pi Changeset: 972652c1e7c2963f1e7a273fdbd96b266a3aa91e Author: Martin Taal <martin.taal <at> openbravo.com> Date: Wed May 25 17:46:18 2011 +0200 URL: http://code.openbravo.com/erp/devel/pi/rev/972652c1e7c2963f1e7a273fdbd96b266a3aa91e [^] Fixes issue 16883: Flexible interaction with date fields --- M modules/org.openbravo.client.application/web/org.openbravo.client.application/js/ob-formitem-widgets.js --- |
|
(0037562) hudsonbot (developer) 2011-05-26 07:47 |
A changeset related to this issue has been promoted main and to the Central Repository, after passing a series of tests. Promotion changeset: https://code.openbravo.com/erp/devel/main/rev/728387046be6 [^] Maturity status: Test |
|
(0037601) pjuvara (reporter) 2011-05-26 14:59 |
I tested the new behavior. Very nice: great job! Although not all the requested behaviors have been implemented, entering a date is now a very agile experience and I believe no further improvements are needed. The only missing piece is the support for shortcuts (t for today) which we should not forget. I will log a separate feature request. |
|
Notes |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2011-04-25 15:53 | pjuvara | New Issue | |
| 2011-04-25 15:53 | pjuvara | Assigned To | => rgoris |
| 2011-04-25 15:53 | pjuvara | Modules | => Core |
| 2011-04-28 11:13 | rgoris | Note Added: 0036148 | |
| 2011-04-28 11:13 | rgoris | Assigned To | rgoris => mtaal |
| 2011-04-28 11:13 | rgoris | Priority | normal => high |
| 2011-04-28 11:13 | rgoris | Category | B. User interface => A. Platform |
| 2011-04-28 11:13 | rgoris | Type | feature request => defect |
| 2011-04-28 11:13 | rgoris | Target Version | 3.0 => 3.0RC7 |
| 2011-04-28 11:16 | rgoris | Relationship added | depends on 0016303 |
| 2011-04-28 11:21 | rgoris | Relationship added | depends on 0016314 |
| 2011-04-28 11:24 | rgoris | Relationship added | depends on 0016302 |
| 2011-04-28 11:25 | rgoris | Relationship added | depends on 0016297 |
| 2011-04-28 12:14 | mtaal | Note Added: 0036155 | |
| 2011-04-28 14:38 | rgoris | Note Added: 0036162 | |
| 2011-04-28 16:13 | pjuvara | Note Added: 0036168 | |
| 2011-05-02 10:50 | alostale | Status | new => scheduled |
| 2011-05-02 10:50 | alostale | fix_in_branch | => pi |
| 2011-05-06 17:58 | dmitry_mezentsev | Target Version | 3.0RC7 => 3.0MP0 |
| 2011-05-06 17:58 | dmitry_mezentsev | fix_in_branch | pi => |
| 2011-05-17 09:15 | iperdomo | Priority | high => normal |
| 2011-05-25 17:46 | hgbot | Checkin | |
| 2011-05-25 17:46 | hgbot | Note Added: 0037446 | |
| 2011-05-25 17:46 | hgbot | Status | scheduled => resolved |
| 2011-05-25 17:46 | hgbot | Resolution | open => fixed |
| 2011-05-25 17:46 | hgbot | Fixed in SCM revision | => http://code.openbravo.com/erp/devel/pi/rev/972652c1e7c2963f1e7a273fdbd96b266a3aa91e [^] |
| 2011-05-26 07:47 | hudsonbot | Checkin | |
| 2011-05-26 07:47 | hudsonbot | Note Added: 0037562 | |
| 2011-05-26 14:59 | pjuvara | Note Added: 0037601 | |
| 2011-05-26 15:00 | pjuvara | Status | resolved => closed |
| 2011-05-26 15:08 | pjuvara | Relationship added | related to 0017381 |
|
Issue History |
| Copyright © 2000 - 2009 MantisBT Group |
 |