Projects:Editable multi-record grid widget/Specifications

Contents 1 Editable multi-record grid widget - Functional Specifications 1.1 Overview 1.1.1 Purpose 1.1.2 Scope 1.1.3 References 1.2 Design Considerations 1.2.1 Best practices 1.2.2 Keyboard Operation 1.2.3 Mouse Operation 1.2.4 The Visual Appearance Of Grid Elements 1.2.5 The Saving 1.2.6 Currently used widget types 1.2.7 Assumptions 1.2.8 Dependencies 1.2.9 Constraints 1.3 Glossary 1.4 Functional Requirements 1.4.1 User roles & profiles 1.4.2 Business process definition 1.4.3 User stories 1.4.4 Design Elements 1.4.5 Functional requirements based on business processes 1.4.6 Use Cases 1.4.6.1 Use case: Editing cell(s) in grid 1.4.6.2 Use case: Duplicating rows 1.4.6.3 Use case: Manipulating column settings 1.4.6.4 Use case: Multi record edit 1.4.7 User Interface Mockups 1.5 Technical Requirements 1.6 Data Requirements 1.7 Non-Functional Requirements 1.8 Open Discussion Items 1.9 Closed Discussion Items 1.10 Appendix

Editable multi-record grid widget - Functional Specifications

Overview

A version of the data grid that allows to edit values in the grid. It is referred to in Openbravo Issues by Editable Grid Issue and related to Movable columns in a grid and Save grid layout. The three features should be combined into one. Additional functionality that should be considered is duplication of rows (records). This whole set of features is henceforth referred to as in-grid editing.

Purpose

The purpose of this project is to add an editable grid to Openbravo ERP plus a set of related additional features in order to facilitate more rapid record entry and manipulation resulting in an increased user satisfaction.

Scope

References

Design Considerations

Best practices

Datatable showing in-grid editing using all most common widgets. Example 1

More of the same. Note that a double click is needed here to start editing and changes are marked on cell level with red corners. Example 2

Datatable in grid-edit-mode. Plenty of products make use of this principle. Note the EDIT button in the left column that takes the user to a form view. Example 3

Image 1: An example of a visual cue after saving.

Image 2 (left): Type-ahead speeds up entry.. (right): Adding values "on the fly".

Keyboard Operation

The grid is managed as any other page control. The focus is obtained by pressing the tab key coming from a control and by pressing the F6 key coming from a pane.

Once the grid is focused, the movement between cells is done with the cursor keys. When F2 or any other key except for the keys mentioned below is pressed, the selected cell becomes editable. When the enter key is pressed, the entered value is stored but not saved and the focus moves down to the cell below. The F6 key is used to move the focus away from the grid to the next pane.

An entire row or column is selected when the cursor is moved to the top or left border of the grid.

A guideline for other standard keyboard shortcuts is the following list:

Tab, Shift+Tab: Moves keyboard focus to next/previous control

F6, Shift+F6: Give focus to next/previous pane in a paned window

F8: Give focus to splitter bar in paned window. Please note that this sometimes interferes with OS or hardware specific software keyboard shortcuts.

F10: Give focus to browser's menu bar

Shift+F10: Pop up contextual menu for currently-selected objects

Space: Toggle selected state of focused check box, radio button, or toggle button

Return: Activate focused button, menu item etc.

Home, End: Select/move to first item in selected widget PageUp, Ctrl+PageUp, PageDown, Ctrl+PageDown: Scroll selected view by one page up/left/down/right

Mouse Operation

When there is a click inside the grid, the grid gets the focus.

When a header column is pressed, the behaviour is the same as described in Movable columns in a grid.

When any number of the first column is pressed, the corresponding edition window will be opened.

When any other cell is clicked, the cell becomes editable.

When there is an active editable cell and another cell is clicked, the changes of the active editable cell will be saved and the clicked cell will become editable.

Introduction of right-mouse-click functionality should be considered for actions such as copy, paste, delete and column properties.

The Visual Appearance Of Grid Elements

A cell that is being edited and needs a visual cue. Selection of one or multiple editable cells, rows, visible and non-visible columns should also be clearly indicated.

The Saving

The cell saving is made with an asynchronous call after the focus moved out of the row. The entire row is saved.

Currently used widget types

Openbravo ERP 2.40 uses the following widget types for data entry that will need a grid-edit variant:

1. Text field: a single row field allowing free text entry. At the moment there is no field validation in real time.
2. Text area: a multiple row text area allowing free text entry, mostly used for descriptions.
3. Dropdown: list box containing predefined values. The number of values should be limited to avoid long page loads. For in-grid editing it is convenient to have a type-ahead (auto fill) feature.
4. Selector: invokes a filter popup where queries can be executed. This behavior can be reused for in-grid editing and should be extended with the possibility to enter a value directly into the field.
5. Date picker: date can be picked using the widget or via keyboard entry. Currently the tolerance for date format input is not very high: only DD-MM-YY(YY) is accepted or DDMMYY(YY). This needs to be extended to at least DD/MM/YY(YY) and DD.MM.YY(YY).
6. Calculator: numerical value can be generated using a calculator widget. This behavior can be reused for in-grid editing.
7. Checkbox: can be considered as a binary choice on field level (Y/N) but can also reflect multiple values ("select all colors that you like").
8. Radio button: can be considered as a binary choice that is mutually exclusive with one or more others. It might be good to use a dropdown in case more than two radiobuttons are used on the form.

Assumptions

Dependencies

Constraints

Glossary

In-grid editing: ability to edit values in a table on cell level without having to edit the form itself. This is especially useful for mass entries or in cases where lots of data needs to be duplicated.

Functional Requirements

User roles & profiles

The target users for this project are:

• Administrators: these users have a good knowledge of Openbravo ERP and they are in charge of defining the roles and permissions of the users. For this specific task, in-grid editing and duplication is useful.
• Users: common users of the application. This is the most important user group as they are performing repetitive tasks where bulk editing and duplication is common.

Business process definition

This project is related to all processes that require record editing. Emphasis is placed on processes that require bulk record editing and processes that require creation of multiple similar records.

User stories

User Story 1: Filling out weekly time sheets Fiona is a senior business consultant at a medium sized consulting firm. Once a week she has to enter her time sheet in the ERP system. She always hated it. In the old days, without the in-grid editing feature, this was a tedious process. As a consultant she normally worked on more than one project at the same time, sometimes up to 4 different activities per day. This can result in filling out 20 entries per week. Rough estimate for time spent doing this per window: 90 seconds including load and save. Total time spent is 20 x 90 = 1800 seconds = 30 minutes per week. With the new in-grid editing feature the time she spends on this task is reduced to 15 seconds which results in total time of 300 seconds = 5 minutes per week. This saves her 25 minutes per week!

User Story 2: Bulk changes and duplication of products Marcelo is responsible for product entries. He needs to change the product category from standard to average for 50 products for a certain business partner. On top of that, he needs to add 20 similar products to the product list for this business partner using the same form data except for the name and key. Using the in-grid editing feature, Marcelo now can filter the grid for the business partner and start editing away in the cells of the table, as he would do it in a spreadsheet. He doesn't even need to use the mouse: just navigate to the cell with the arrow keys, hit the F2 key, select the value from the dropdown using the arrow keys again and hit enter to keep the new cell value. With similar ease he adds 20 products to the list by using the copy/duplicate feature. This will take an existing product and duplicates it, creating an additional row in the table. He only has to change the product name and key.

Design Elements

This feature can be split in chunks of functionality. In order of importance:

1. In-grid-editing
2. Duplication of records of rows (records)
3. Manipulate column settings

Functional requirements based on business processes

The following table lists all requirement candidates.

Number	Requirement	Importance	Description	Comments	User Value	Business Value	Technical Ease
1.1	Fields are editable in the grid	Must have	This is the core functionality.		High	High	High
1.2	It is possible to switch the in-grid edit mode off	Must have	This helps the user avoid making undesired changes. This could be role based but if we choose to do so then the same must be applied to the windows view.		Low	High	Low
1.3	Column width can be modified and will be saved	Must have	An nuisance since long as current column settings are lost the moment the user moves away from the view.		High	Medium	Low
1.4	Column order can be modified and will be saved	Must have	An nuisance since long as current column settings are lost the moment the user moves away from the view.		High	Medium	High
1.5	Column visibility can be modified and will be saved	Must have	An nuisance since long as current column settings are lost the moment the user moves away from the view.		High	Medium	Medium
1.6	Column visibility display logic: show column depending on row values	Must have	In some cases certain values are too important not too show.		High	Medium	TBD
1.7	Copying of rows (records) in the table.	Must have	It needs to be decided whether there is a need to include the lines within (or this could be an option). It should even be possible to copy multiple rows. Choice for placement on row above or below could be an option.		High	Medium	Toolbar operated: medium, context menu: medium-high
1.8	Inserting rows	Must have	Very similar to duplicate but now all values are empty or defaults.CTRL-N could be the keyboard shortcut.		Medium	Medium	Low-medium, especially in combination with copy feature
1.9	All in-grid editing can be done using the keyboard	Must have	This serves both order entry speed and accessibility compliance reasons.		High	Medium	High (breaks current shortcuts and needs to work with all the insert widgets etc.)
1.10	Saving on record level, not cell level. A record is saved the moment another record is selected.	Must have	This is a best practice comparable to editing of spreadsheets.	From technical point of view it is quite hard to save on cell level. Agreement on that it is best to save on record level.	High	High	High (all saving requires lots of server changes)
1.11	Error handling should be in place	Must have	Ismael has more details on the requirements for this.		High	Medium	Validation, return to defaults etc.: high
1.12	Copying and pasting of single cell values is possible. CTRL-C and CTRL-V keyboard shortcuts can be used to do so.	Should have	Serves rapid order entry.		High	Medium	Same column: medium, across columns: high
1.13	Copying and pasting of multiple cell values is possible. CTRL-C and CTRL-V keyboard shortcuts can be used to do so.	Nice to have	Serves rapid order entry.	ICI: This is very difficult to implement	Medium	Medium	Very very high
1.14	There is a clear distinction between editable and non editable fields / columns.	Must have	This saves the users clicking to no avail.		Medium	Low	Low
1.15	The order in which the rows appear can be changed.	Nice to have	Currently the rows are numbered and order cannot be controlled. Using something like up and down arrows instead could be handy. Request by user azuledu. This should also change the ID internally.		Medium	Low	Very high
1.16	Conditional defaulting	Must have	Example: entering a product will automatically calculate and add the line price. Support current definition of default values, validations and callouts. On line record refreshing after changes in values that fires validations and callouts. On line record refreshing after saving with back-end changes in the record (triggers).		High	High	High
1.17	Changing all values in a column.	Should have	User selects a column and changes all cell values in that column in one go.	This is related to multi-record edit.	High	High	Low Medium
1.18	Switch to form view from the grid in the middle of an edit action	Must have	When user changes her mind and still prefers window view for editing.		Medium	Medium	High to remember focus switching views
1.19	Auto save can be switched On and Off.	Must have	Similar to the window view.	Open item as there is still discussion on the behavior for in-grid edit mode.	Medium	Medium	Medium high
1.20	Changes to the values in the cells of the grid show a visible cue when the table is not saved yet, for example a change of colour.	Nice to have	This helps the user understand what the impact of saving is.	ICI/PJU do not see much value here if we choose to (auto) save on record level. So when user navigates to the next record, the record will be saved.	Medium	Low	Low-medium
1.21	Changes to the values in the cells of the grid show a visible cue when the table is saved, for example an "Updated" callout.	Nice to have	The added value of this feature needs to be investigated. Perhaps in a multi user environment it is handy to verify what other users have modified.	ICI/PJU do not see much value here.	Medium	Low	Low-medium

Use Cases

Use case: Editing cell(s) in grid

Precondition: grid view is active

Steps

1. User toggles in-grid-editing on
2. User selects an editable cell
3. User changes value
4. User navigates to other cells in the same row and changes more values
5. User navigates to another row
6. System saves the new values

Alternative paths:

1. User navigates to any other window: user is prompted to either save or lose changes

Use case: Duplicating rows

Precondition: grid view is active

Steps

1. User selects a row (record)
2. User starts the duplication
3. System copies mandatory fields
4. System generates a unique identifier based on sequence
5. The row is duplicated and added to the grid

Image 1: Example of child-parent relations

Use case: Manipulating column settings

Precondition: grid view is active

Steps

1. User changes column order
2. User changes column widths
3. User choose which columns to display
4. System saves the new column settigs

Use case: Multi record edit

Precondition: grid view is active

Steps

1. User selects multiple rows
2. System shows a set of values that can be edited for all the selected records
3. User changes the values
4. User saves the new values

User Interface Mockups

Mock 1: Buttons grouped by “reach” and addition of Copy and Process buttons

Technical Requirements

{{{Technical Requirements}}}

Data Requirements

{{{Data Requirements}}}

Non-Functional Requirements

{{{Non-Functional Requirements}}}

Open Discussion Items

1. Scope: Common agreement is that we should aim to build functionality that is reusable on the longer term when we plan to redesign the master-detail display and interaction. Therefore the scope for this feature is still under discussion.

Closed Discussion Items

{{{Closed Discussion Items}}}

Appendix

{{{Appendix}}}

PDF