UI / UX agreements across apps

• improves overview
• it is difficult to know what the height of each list should be
• will vary, so no general criteria - status: set per app (where it makes sense)
• need to agree on a default behaviour
• there is conflict if we have more and more MCLs with check boxes
• in cases where we have check-boxes, freeze the first 2 columns?
• PO would agree with SIG on how many columns need to be freezed

• sorting of table headers should be available consistently across apps
• helpful to have a sort indicator, to indicate that a column is sortable
• pageable lists: some columns are not sortable
• all not pageable lists should have sortable headers
• Sara in chat: Just wondering--if not a MCL thing then for the future--just wondering: like in a spreadsheet can I sort on Column A and then on Column B in conjunction
  
• for paged lists: yes
• for non-paged lists: no
• would be great to have it for paged and non-pages lists

YES

• add line numbers to MCL result lists
• important to have in mind that numbers are usually independant from the line content
• first line will always be #1
• there should be an indicator that it is a row number; because there are some exceptions where it is not
• additionally, numbers could give an ancor for clicking to see more details → no, rather name, barcode (depending on the use case)
• anchored text instead of anchored rows; text that looks like a link
• therefore define columns with click ancor as never hide
• Kimie in chat: If we add line numbers, and then the user drags and drops a row, will the numbers be able to update at the moment of the drag and drop? → John: yes, they have to
  

• full search and sort for the sub-MCLs is needed
• An option to pop out a sub-MCL into its own full screen window with search and filter options
• make available at accordeon level

• export option helps as there is more functionality in Excel
• e.g. export is available for some MCLs in orders
• for multi-page lists there is a difference between export this page and export all
• idea:
  • start with exporting current page
  • and extend with option to select → add an intermediate step and open a modal where user can select
  • depending on how many lines it can be expensive

• Modals or other popups need to move
• should not be fixed in place on the screen
• In various Apps functional Modals be moved out of the way while in use but at the same time cover over information that is needed while using the Modal.
• Not all modals are "Look-up" modals, some are "Fill-out" modals and so info is on the screen now hidden
• e.g.: in the Receiving App, the Receiving Note.
• Additionally, I often want to copy and then paste into the pop-up modal info from the screen behind, but no longer can.
• I would hope that if I can move it out of the way, I then would also be able to copy off it to pate into fields in the popup
• my demo example would get be when I am creating a piece in the Receiving App.
• modals could be moved somewhere where user cannot see them anymore; should not happen
• To Do: collect use cases
  • creation modal:
    • receiving: creating receiving piece; information needed is hidden; creating somethin with modal
  • look up modal:
    • title look upinformation is variable
  • warning modal

• When I use keyboard shortcuts I need to view them separately from the screen I am working on
• maybe open in a separate window or pane
• Charlotte in chat: An extra pane, sounds a bit like Tags, when in the three pane layout