Politeia UI/UX coordination - master issue

[ta-lind]

Creating this as a master issue to help coordinate Politeia related UX/UI design work. This includes a higher level perspective on what's what, an ordered list of tasks as well cross-references to open issues and requests worth covering in the /politeiagui repo.

For bit of background information – although I've not been involved with Pi developments presently, i've helped with desiging the initial reddit based prototype version of Pi. Keeping in mind an important aspect that any large scale design updates are likely not worth the wrestle for now (with reddit's framework). For that reason the current product should be treated as a hi-fi prototype that assures: keeping up a general visual hygiene; logical and simple interaction solutions for Politeias features. Both of these aspects should keep in mind Reddits framework constraints and be approached in a way feasible to implement. Any feedback from front-end devs currently working on this is much welcomed.

I will not cover any issues that to my knowledge require completely replaying any larger interaction flows, structural designs or implementing a full set of new assets/patterns. Rather the goal is to tweak up this current builds UI design to a bit more consistent and improved quality levels.

Regarding these limitations, would like to hear perspectives from @sndurkin and @marcopeereboom around the development plans. Last time I brought this topic up it wasn't clear when this reddit-based build could be dropped and the design and front-end to be re-created from the ground up. Asking this as it's worth to notice this will serve as an excellent new project for growing the design discipline. I would expect the scope for ground-up work to require involvement of at least 2-3 interaction and visual designers as well the front-end developers. This is either opportunity to b42 to get more involved in DCR as well for new individuals or a small UI/UX studio to get involved.

Tasks:
If not present, please create separate issues to the new tasks when taken on.

Identity: define and implement color scheme (@saender, @MariaPleshkova)
Politeia as a product has it's own iterated logo that relates strongly (ambigram construction) to DCR brands ecosystem. Similarly the color scheme should have it's own take. I think it shouldn't be too far off from Decred color scheme, but with some clear distinguishability and potentially a new key colour. This needs input from @saender or should be collaborated with him, as he authored the Pi logo and is most relevant person on the identity subject.

Once a color scheme is established, all non-relevant colors should be replaced in the UI. This will create a cleaner and more consistent template overall. At the moment there is no consistency between the DCR color scheme and various reddit framework colors.
Deliverable: color applied to key views; element-, or view-based design examples prepared for front-end implementation.

Onboarding illustrations (EETER, Kyle, 30000fps)
There are some illustration and motion design assets in the pipeline to improve Pi's onboarding and communications. These are essentially character designs, adding more meaning to the current textual bits. Temporarily on-hold.

Map out spacing and layout issues (@MariaPleshkova)
Fundamental visual design task to improve general visibility and design quality. First goal should be ironing out any really obvious spacing and positioning related issues.

Map out typography issues (@MariaPleshkova)
This should aim to establish a good baseline type practice, improve legibility and communicate hierarchies.

Map out relevant locations for icons (@MariaPleshkova)
Where it helps to communicate meaning and feedback and guide the user. Use Decred's extensive iconography, no reason to develop new.

Map out interaction issues (@MariaPleshkova, @linnutee )
Larger task that requires some testing, either done by the designer/researcher or small scale qualitative user tests to locate any critical issues. I'd recommend limiting the scope to the following (or less): discoverability related issues, feedback and signifiers, patterns similarities and consistency, relations between controls mappings and constraints.

Map out copywriting issues (…)
Similarily as other design items, the copy needs to be consistent through-out various touchpoints. Function related copy items needs to be clear, considerate and useful for the user. Write them short, then cut in half and remove jargon.

Improve visual design of proposal cards (@MariaPleshkova)
This is one key element that can be further refined. Recently there was a PR that implemented displaying quorum decred/politeiagui#821, so the progress bars, way quorum is displayed and other related elements can be in better relation to Decrediton. Also should keep in mind how to distinguish the different proposal states as well #611 below.

Open issues in Pi repo:

Clearly indicate proposal vote success or failure (@MariaPleshkova)
decred/politeiagui#611
Important issue addressing feedback aspect. Should be kept somewhat similar as how the function is solved in Decrediton (https://xd.adobe.com/view/9fdb7614-cff0-4972-6e72-2ab1d40b5482-e9ea/screen/dbfcc3cf-27c2-4b5d-935c-d825ded80fff/Governance-Proposals-Under-Vote) and voting.decred.org

Feature request: Notifications (@MariaPleshkova)
decred/politeiagui#728
Comes down to setting up a baseline notifications system. Both UI and in mail. Concept design examples.

Feature Request: Highlight new comments since last visit (@MariaPleshkova)
decred/politeiagui#732
Should have some relation to reddit.

Minor: improve formatting of Marketing example in the proposal guidelines tab (@MariaPleshkova)
decred/politeiagui#689
Relates to typography in general.

Display live Treasury wallet data (@MariaPleshkova)
decred/politeiagui#672
Can consider displaying this content within the footer.

Pagination for proposal credit table (@MariaPleshkova)
decred/politeiagui#615
Less important, enhancement.

Global Activity page (feed) #783 (@MariaPleshkova)
decred/politeiagui#783
Not sure if this is technically feasible, feedback from devs needed. If it is, certainly good UX enhancement, would need quick design prototype to start with.

The work will be mostly covered by @MariaPleshkova and @nick7000 from b42 and assisted by EETER when needed.

[sndurkin]

@marcopeereboom would have to weigh in on the future development plans as he's managing the project. I personally would like to scrap the reddit design and start from the ground up, but I'm not sure if Marco wants to refactor and improve the server-side first, or if he even wants to move in that direction.

[fernandoabolafio]

I think this is a much valuable discussion and Pi deserves this UI/UX attention to keep the high quality of Decred products design.
While I think the most important enhancements were covered in the issue description, IMO we should be targeting make Pi mobile friendly if we're going to have a major change on it's design. We have an old issue written for that:

Mobile-friendly version #162
decred/politeiagui#162

[sndurkin]

Here's an outline of major flows, and also pages and elements currently in Politeia:

Flows

• New user registration
  1. On the register page, populate the email, username and password fields. The email and username must be unique.
  2. Click Sign up, then click the button to accept the warning.
  3. Wait for the registration email and click the verification link.
  4. Log in.
  5. Click the "Pay the registration fee" link in the sidebar.
  6. Follow the instructions on the modal that opens and send the amount of DCR to the address. Users on the testnet instance can pay in the UI with the available button.
  7. Wait a few minutes for the UI to find the transaction then mark the account as paid.
• Submit a proposal
  1. Submitting a proposal requires a proposal credit, so click the top-right area to open the Proposal Credits modal.
  2. Click the Purchase Credits button, then set the number of credits to purchase and click Next.
  3. Follow the instructions and send the amount of DCR to the address. Users on the testnet instance can pay in the UI with the available button.
  4. Wait a few minutes for the UI to find the transaction then award the proposal credits.
  5. Navigate to the Submit Proposal page.
  6. Populate the Proposal Title and Proposal Description fields, then click Submit.
  7. On the next page, you can download the "Proposal Bundle" which is a JSON file that includes the entire proposal and metadata for the user and the server. It allows other users to confirm that the server received the proposal. Its purpose is to help the user claim that he was unfairly censored.

Pages

• Public Proposals / User Proposals / Admin Proposals: Lists of proposals. Each list has tabs for filtering by proposal type or state. Admins have special actions for proposals in certain states (e.g. "Publish" or "Spam" for unreviewed proposals).
• Register / Login: Allows the user to register or login. When the user clicks the Sign up button, it displays a warning that the user must open the registration link in the same browser used to register. This is a current restriction on Politeia; an "identity" is generated and saved within the browser and is used for actions, like submitting a proposal.
• Reset Password: Allows the user to reset his password via an email link.
• Resend Verification Email: Resends a new registration email, in case the user did not receive one originally.
• Your Proposals: Lists all the user's proposals, both those submitted and drafts. Drafts, like the identity, are stored locally on the browser and won't be available if the user switches to another browser.
• Account: Allows the user to configure his account (or an admin to configure other accounts). Other users do not have access to a user's General tab, except for admins, who have some special options for configuring the user account.
  • Change Username: Opens a modal which allows the user to change his username.
  • General tab
    • Rescan address for proposal credits: Requests the user to scan his payment address for new transactions to award more proposal credits.
    • Change Password: Opens a modal which allows the user to change his password.
    • Mark user as paid: Only available to admins. Allows them to automatically mark a user as paid in the database, without that user having to pay the registration fee.
    • Unlock user account: Only available to admins. Allows them to unlock an account that was automatically locked due to incorrect login attempts.
    • Deactivate / Reactivate user account: Only available to admins. Allows them to completely deactivate/ban an account from logging in.
    • Manage Identity: A section which allows the user to manage his identity and tries to explain what the identity is.
      • Create New Identity: Creates a new identity within the browser and then sends an email which has a verification link to establish it.
      • Download Identity: Downloads the current identity as a JSON file.
      • Import Identity: Uploads a downloaded JSON identity file to replace the existing identity.
  • Proposals tab: List of user proposals.
  • Comments tab: (not yet implemented)
• Submit Proposal
  • Proposal Name field: Displays an error while typing when the proposal name doesn't pass validation
  • Proposal Description field: Editor which uses Markdown with a live preview. When the user only uses a single newline to separate 2 lines, a warning is displayed below telling the user to press Enter twice to create separate paragraphs of text.
  • Attach file: Allows attaching up to 5 files, only certain MIME types are accepted and they are outlined in the box next to the button.
  • Markdown formatting section: Table of simple formatting options for the Markdown editor
• Proposal detail: Displays a proposal name and description and the comments. If the proposal is being voted on, vote statistics are displayed under the proposal name.
  • Edit button: This is only displayed to the proposal author, and it takes him to the Submit Page (with the fields pre-populated) to make changes and submit a new version.

Page-Independent UI Elements

• Viewable by all users
  • Privacy Policy (not currently its own page)
• Viewable by logged in users
  • "Action needed" popup: persistent message display on the top of the page
    notifying the user to visit his Account page; usually it means he needs to
    fix his Identity
  • Icon in the sidebar which shows the state of user's registration payment
  • Welcome to Politeia modal: This is displayed when the user logs into Politeia for the first time with several tabs describing Politeia concepts. It's accessible at any time from the "Learn more about Politeia" link in the sidebar.

[nick7000]

@linnutee we will get on top of it following Monday and try to add more people from our side to work on this issue.

[saender]

Pi logo in color: #83

[MariaPleshkova]

Proposal cards' visual design improvement+indicating proposal vote success/failure
decred/politeiagui#946

XD files: Proposal cards. 15.01.19.zip

[MariaPleshkova]

Display live Treasury wallet data
decred/politeiagui#672

XD file: Treasure wallet data.zip

[MariaPleshkova]

Main redesigned Pi pages
decred/politeiagui#989

XD file: Politeia_18.01.19.zip

[MariaPleshkova]

Highlight comments since last visit
decred/politeiagui#732

XD file: Comments 15.09.19.zip

[MariaPleshkova]

Pagination for proposal credit table
decred/politeiagui#615

XD file: Account history_18.01.19.zip

[crypto-rizzo]

This master issue looks pretty good in regards to covering all the different workflows / UI views. I went through the GUI issues and found this one was the only one missing from the list

decred/politeiagui#865

[MariaPleshkova]

Draft placeholder for onboarding visuals
XD file: Onboarding tutorial_23.01.19.zip

[MariaPleshkova]

Show history for single proposal
decred/politeiagui#820

XD file: Actions history_24.01.19.zip

[ta-lind]

decred/politeiagui#1124

[marcopeereboom]

I really liked the slides I saw with the redesign and I see no reason not to move forward with it. CMS is getting to a point that it works well enough which will free up some front-end guys.

I believe that the way we should develop this is by having two teams. Team one deals with maintaining current Pi and we will focus on actual issues only and not develop any new GUI things. Team two starts the work on the redesigned website.

I also believe that the newly designed website needs to be put up as quickly as possible in case the backend has to support additional things. As it stands the API is a bit too big IMO and I would like to deprecate several routes. The one thing I think we need to do with the new site is to make it responsive. I wrote a websocket framework and we should articulate what needs to be handled using REST and what needs to be handled using websockets.

If everyone agrees I will formally assign people and start driving this effort.

[tiagoalvesdulce]

I have a repo to create a library for the new design (it will replace snew-classic-ui components with a more loose coupling approach).

[fernandoabolafio]

Expanding the idea of having two teams to get the new design out of the paper, I propose the following if everyone agrees:

• Team redesign (@tiagoalvesdulce @fernandoabolafio ): @tiagoalvesdulce keep on delivering the new components while I go integrating them and setting a solid base in politeiagui. This integration will require the decoupling of snew and some other code refactors.
• Team politeiagui (@camus-code @thi4go @victorgcramos): keep working on the currently opened issues and making sure that we don't fix or change things that will be done through the redesign.

Once the new design work has evolved we start migrating ppl from Team politeiagui to help Team redesign to wrap up the website and delivery it to the first testnet try. This is the first sketch, of course, can be reviewed at any time.

[crypto-rizzo]

I really like this approach for the redesign. Splitting us into teams will make everything flow a lot smoother as we won't be having to bounce back and forth between projects.

I agree with @fernandoabolafio's proposed teams as well unless @marcopeereboom or anyone else has issues with it. Among other things, the decoupling of snew is going to require some extensive experience with the library which I think Tiago and Fernando have the most of

My only suggestion for now would be to go through all the issues and label them by team accordingly

[marcopeereboom]

I think we need at least one more experienced person on team pigui.

[thi4go]

I like the approach of having two teams to kickstart the new design. @fernandoabolafio's suggestion makes sense to me, since integrating the new ui and decoupling from snew will need more experienced eyes on the task. I think we in the proposed team pgui can handle the upcoming bugs and maintenance of the code, since we recently knocked out more important issues.

@marcopeereboom did a great cleanup on the issue list already, but it would be nice to go with @camus-code suggestion and go through it one more time and label them by team as well.

[fernandoabolafio]

I think we need at least one more experienced person on team pigui.

I won't abandon team pgui, I will be reviewing PRs, managing issues, etc. Just for coding, I will be more devoted to the new design. This integration requires lots of code tweaks to make sure will have not only a new design but as well a better code structure to speed up the development of new features after it.

[marcopeereboom]

If we have something that is ready enough to be seen we need to get this up. @dajohi can add a beta-testnetproposals.decred.org vm for this. We should probably automate deployment on it so that it is always current.

[marcopeereboom]

Part of the redesign is that we are going to replace all pages that don't strictly require JS with server-side rendered HTML. @linnutee I wanted to make sure that you are aware of this.

decred/politeia#839

[go1dfish]

From the UI's perspective, we can build the JS/Non-JS versions in JS and add a component to specifically exclude parts of the app that are not applicable for non-js users (like login and other forms)

So from @linnutee we mostly will need highlighting of what elements should be excluded when JS is not available, and any additional messaging we want to show when that is the case.

[MariaPleshkova]

Well, formed the new list of tasks concerning Pi redesign:

Desktop views

• Add filter with categories to proposals

• Add categories to create proposal screen

• Show only a few comments by default (the latest ones, for example) and add "Show more comments" link. There was a suggestion to hide all comments by default, but maybe it's better to show at least some of them.

• Hide all of the replies under "n replies" link

• If we show comments under the proposal by default (as it is now), I think there's no need in comments icon (this one that is in a line with gh,search icons under the proposal). And also no need in permalink for opened proposal, as it's already opened

• Add grid to all layouts

• Change font sizes to more readable ones

Responsive views

• Create tablet views for main screens (768px width)

• Create mobile views for main screens (360px width)

[fernandoabolafio]

@MariaPleshkova can you add a few more items to that list?

• Signalize how errors must be displayed

  • Global errors (ex failed fetching proposals list)
  • Form errors: some validation errors from the API cannot be assigned directly to each field. So we need to display an error regarding the validation of the entire form. (e.g a banner at the top or at the bottom of the form)
  • Non-main context errors (ex failed fetching treasure balance). This is the kind of error that needs to be signalized but should not affect the overall UX.

• Loading

  • In the current UI, we use the same Spinner for pretty much everything. Would be nice to include in the design how we should indicate the loading of contents.

Update:

• Not found pages
• Dropdown (when clicking in the username in the header)
• Admin pages: list proposals and search users (and also where to click to reach the admin page)
• Proposal actions:
  There are a variety of actions available regarding a proposal. Those can be:
  • Admin actions: Censor/Approve/Start Vote/Abandon
  • User actions: Authorize Voting to Start
    The following screenshot shows how it currently looks:

[xaur]

In continuation of decred/politeiagui#843, I realized I can just nuke the sidebar with a simple CSS filter and it feels so much better.

[tiagoalvesdulce]

@MariaPleshkova I noticed that there isn't a Manage Identity interface yet. Can you add it to the list?

Edit1:

• I think that tokens and keys like the public key in the screenshot above should be monospaced. What do you think?

[MariaPleshkova]

Preview for redesigned Pi screens: https://xd.adobe.com/view/a6a62142-18c9-4d0c-4ebd-0fcdec0390ad-d097/

Specs: https://xd.adobe.com/spec/25f9f648-8d13-446f-75aa-242b21116f87-53c8/

I've updated some things there (added filter with categories to proposals, added categories to create proposal screen, some updates to comments view (name in replies highlighted with yellow is the name of proposal's author) ), changed font sizes (now they are 28,24,16,13 px), removed Segoe font (it was a bug), added some icons in front of titles, added grid to all the pages and created responsive screens.
Also we decided to shorten the sign up text as @lukebp suggested under User authentication pages, it will be done later.

@tiagoalvesdulce 's and @fernandoabolafio 's above comments are in process. I'll send an updated preview as soon as they are done.

[fernandoabolafio]

@MariaPleshkova after reviewing the new preview I have a few comments:

1. Improve Proposal tabs visualization for mobile screens: to me look very odd to keep the horizontal flow of tabs on mobile views. Normally the tabs look better if replaced by a Selector or a Collapsable vertical Menu. Examples:

Selector:

• desktop view:
  

• mobile view:
  

Collapsable menu:
https://codepen.io/chriscoyier/pen/gHnGD

2. The categories could use a "filter like" component. Having a bunch of tabs (categories) under a bunch of tabs (proposal status) are very confusing to me. For example, this is the filter currently used on Decrediton:

3. What do you think about setting the modals to use the full viewport available on mobile screens? I tested it in the current website and IMO it looks cleaner. This is how it looks:
   

[tiagoalvesdulce]

@MariaPleshkova we also need a tab for the user preferences in the user details page. Here is how it looks in pi right now:

[MariaPleshkova]

@fernandoabolafio

1. ok, agree. It looks way much better, just need to think how to deal with it when there are 2 tabs one under another (if we leave this concept)

2. hm, not sure it will be so clear if we put all these categories under the filter icon. @linnutee what do you think?

3. from the 1st sight looks nice

@tiagoalvesdulce ok, got you

[fernandoabolafio]

@MariaPleshkova
1: If we replace the component for the categories (see comment below) it won't be a problem. I wouldn't worry that much about the categories at this very moment because we don't have the backend support for categories yet. So the priority is on getting the status tabs right.

2: I am very convinced that we can find a better component than tabs to represent the categories filter. Especially because they are filters, so you should be able, for example, to combine "Development" and "Marketing", tabs are more suited to situations where the options are mutually exclusive.

3: since you like it the 1st sight, we will proceed using the "full view" modal for mobile screens for now. You can test in a variety of screens and see how it feels to you. It's easier to reduce its size later on if you think it's better.

[ta-lind]

1 + 2. Rule of thumb for the tabs could be that if they can fit in mobile – do show all of them. Ie. under user profile, there's only three – so it's more clearer to show all. User can tell right off that we're dealing with navigation.

Do agree on the proposals page (and other instances if there's any) where we got the dual filtering (by proposal status + category/type) basically. In that instance the adapted component can be some sort of a drop-down or expandable element.

Rough example, do improve the visual design – maybe can find some way to make it more relatable to the desktop navigation … e.g. using the yellow underline differently.

[ta-lind]

Closing this one down. @MariaPleshkova please note down any referred outstanding issues to the Board when addressing. I will do the same.

https://github.com/decred/dcrdesign/projects/4 can be the main source for tracking those then.

[xaur]

Several of my issues to improve UX were closed as "part of redesign". I suggest to close such issues only when the redesign is released. For devs and designers, it's easier to miss things when they are not in open issues. For the submitter, it cuts the way to follow when his issue will be really resolved.

Specific example: #840 was closed with "part of #77". Ok I open #77... it is now closed. Where should I follow next? I hope it illustrates my point.

[lukebp]

Issues are closed as they merged into master, not when they are deployed to production.