You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I propose that we re-factor the complex vouchers module to use typeaheads to select accounts. This would be similar in funcionality to the patient invoice module where inventory items can be searched for and then 'locked in' by selecting the item or pressing enter.
Pros:
The current ui-select that is used is too tall for our grid rows. This is a bad user experience with some of the select missing from the bottom. A typeahead avoids this by being used on a simple native input.
The DOM for the ui-select is much larger and more complex. This means that if there are a large number of rows in a voucher every row will have to render this complex element. It will also have to be rendered and removed when scrolling with ui-grid. A typeahead would simply be an input and it would be removed once the user has 'locked in' their choice.
A uniform ui-grid entity selection (accounts, inventory items).
ui-select overrides the tab key and forces you to tab through all of the options, in this case this is not helpful as it is just a small element on a complex page.
If there are many accounts it can be much more convenient to just type in the number vs. given the display options in the first place.
Cons:
ui-select is used for account select throughout the application, this would be a different experience however it would be inline with how selects work in grids.
If you have completely forgotten an account, both the name and the account number you will have to go and look it up in the chart of accounts.
The text was updated successfully, but these errors were encountered:
sfount
changed the title
(proposal) use typeahead for defining an account in complex vouchers
(proposal) use typeahead for defining row account(s) in complex vouchers
Feb 28, 2017
I can't imagine a case that anyone will have forgotten an account ... even with a ui-select, what would you do? Scan the accounts list? Usually you make a voucher with a defined transaction between each account (plus, if you aren't sure, people usually put it in an "autre" account).
It sound also be noted that a typeahead's performance is much higher than the ui-selects. So is should be easier on our client's computers.
This commit adds the bhAccountTypeaheadInlineComponent for use in grids,
such as the Complex Voucher grid. It is prototyped and demonstrated in
the Complex Vouchers module.
ClosesIMA-WorldHealth#1289.
2226: Inline an account typeahead for Complex Vouchers r=jniles a=jniles
This commit adds the bhAccountTypeaheadInlineComponent for use in grids,
such as the Complex Voucher grid. It is prototyped and demonstrated in
the Complex Vouchers module.
Closes#1289.
I propose that we re-factor the complex vouchers module to use typeaheads to select accounts. This would be similar in funcionality to the patient invoice module where inventory items can be searched for and then 'locked in' by selecting the item or pressing enter.
Pros:
The current
ui-select
that is used is too tall for our grid rows. This is a bad user experience with some of the select missing from the bottom. A typeahead avoids this by being used on a simple native input.The DOM for the
ui-select
is much larger and more complex. This means that if there are a large number of rows in a voucher every row will have to render this complex element. It will also have to be rendered and removed when scrolling withui-grid
. A typeahead would simply be an input and it would be removed once the user has 'locked in' their choice.A uniform
ui-grid
entity selection (accounts, inventory items).ui-select
overrides the tab key and forces you to tab through all of the options, in this case this is not helpful as it is just a small element on a complex page.If there are many accounts it can be much more convenient to just type in the number vs. given the display options in the first place.
Cons:
ui-select
is used for account select throughout the application, this would be a different experience however it would be inline with how selects work in grids.The text was updated successfully, but these errors were encountered: