cmsgui: ui/ux master issue

[ta-lind]

Ref: @alexlyp @lukebp @vctt94 @marcopeereboom @behindtext I've summed up a master uiux issue to get the cmsgui to the same state as pigui since this now was released. Can use this issue for gathering up any discussion and considerations around getting a first design release worked out and implemented. Also regarding the views from admin perspective, these need a testing environment to be setup before can be addressed.

Comms: DCR UIUX Ops

Assigned for: @MariaPleshkova & @harlovski Repo: https://github.com/decred/cmsgui CMS stands for Contractor Management System and enables Decred Contractors to submit their invoices for the monthly work + proposals. It uses politeia as its backend. The interactions revolve around the invoices, which is essentially the same mechanic as proposals but used in a different context. Users (Decred contractors) can create and submit invoices. Administrators can approve and pay them or decline them.

Tasks to address: 1. Create desktop and mobile examples of all present views. CMS currently uses a UI based off the old Pigui, all design updates should be made in sync with the newly created components for Pigui in order to streamline the work. While likely a bulk of the components are a 1-1 match in Pi and CMS, there will obviously be some components and interactions that are quite different and therefor should be designed with the use case in mind. If some components or aspects are in question whether to be kept the same or not, please provide a list of trade-offs for either case.

2. Design a functional dashboard for logged in users. Currently the first view upon logging contains only a single component, the reminder component which notifies the user whether the monthly invoice has been submitted.

Instead the starting view could be based off the current invoices view; with addition of the reminder component as well option to submit a new invoice. Makes sense here to explore whether to combine these two into a single component, which has several states or consider using the notification component for the reminder.

3. Design a functional dashboard for admins. Blocked: A test environment is needed in order to get a good understanding before this can be addressed.

3. Improving the navigation.
To keep things simple, I propose the navigation to be revolved around invoices and user account (account settings + logout) as only two high level items. Meaning there's not much need to include a dropdown navigation but have all the items visible with a header area.

4. Invoice components + single invoice view. These should be looked as a uniform component in compact and expanded state (in principle). When in a compact mode (invoices in the invoice list) the invoice shows: 1) A fixed title "Invoice from Contractorname- 00/00/2019 Could this use the contractor name field, rather than cmsgui user name? 2) User it was submitted by Same as in Pi proposals 3) Time 4) Status Needs to be way clearer for better feedback on quick glance 5) Additionally, if the invoice has any comments left, these could be highlighted on the invoice card (if none, then nothing is shown) 6) Differences from admin perspective

When expanded, A single submitted invoice view: 1) The focus in this view should go towards refining the hierarchies and grouping of the larger layout. 2) Currently the use of space is impractical – elements like invoice details are overly spread out, making it difficult to track what's what. Ie. invoice details as a group could be tightened up and clearly placed on the top of the hierarchy.

• Key elements are: invoice header; invoice details; shortened breakdown + expanded breakdown; attachments; comments 3) There is little differentiation on shortened and expanded breakdowns. Potentially the expanded one could be hidden by default. 4) Attachments should use thumbnails which can be expanded for 100% viewing. Please consider tradeoffs on how to do this, as there's various methods. The problem here is when there's several attachments or even a single A4 on decent resolution then it will be a huge image in the bottom of the invoice – thus making anything below, like the comments drown under it.

When expanded, Submit Invoice view: 1) Take into consideration how the items listed above are effected in submitted state. 2) The descriptions should take up less space. Consider several options for solving these. Off the bat I would recommend grouping character limitations as a single item. Some of the items can be attempted to be clearly worked as part of the field or having icon+tooltip in close proximity of the affected field. Essentially the goal should be of getting rid of or minimizing the size of the description block that's constantly visible and rather integrate those cleverly across the UI where most needed.

5. Account Seems mostly the same as in Pi.

6. Admin views Blocked: A test environment is needed in order to get a good understanding before this can be addressed. There's likely some clear differences to highlight, such the interaction for approving and declining invoices; any other steps that are worth taking a thorough look at during the invoice reviewing process; looking at larger nr of invoices from various contractors together. @behindtext best to give some insight on this.

7. Relevant issues in /cmsgui: https://github.com/decred/cmsgui/issues/17 https://github.com/decred/cmsgui/issues/16 https://github.com/decred/cmsgui/issues/13 https://github.com/decred/cmsgui/issues/4 https://github.com/decred/cmsgui/issues/3 https://github.com/decred/cmsgui/issues/9

Assets: Derivate logo for CMS

dcr - cms logo - positive.zip

[ta-lind]

Marked this as on hold – as discussed better to combine the ui/ux efforts when the DCC part of the product is released.

[xaur]

Repo: https://github.com/decred/cmsgui

FYI cmsgui repo was abandoned, CMS UI code lives in https://github.com/decred/politeiagui and you can see some issues, PRs and issues marked with [cms]