NNS dapp - UI design upgrade and public proposals

ok, but I think that at least once you click on the iD of the neuron you want to view on the next screen, it is not necessary for the neuron id to appear 2 times practically next to it. also the redundant id in the neuron description header is right next to the NNS log out icon, causing confusion.

Great addition for transparency!

Please add back the Manage Neuron topic. Please. Pretty Please?

1 Like

Yep, I am aware of it.

1 Like

Great to hear that, thx!

Just to avoid confusion, it’s a bug - i.e. something isn’t ok in the release - or it’s a request idea I’ll share with the team?

Hey @peterparker, et all,

This is sweet! As a novice techno user, here are some of the things I noticed:

  1. Login screen changed from “Fetching Delegation” (Not easily understandable for end-user) to “Finalizing Authentication” - Much better!
  2. Tabulated boxes that mimic sort of an windows-esque vibe (for nuerons). Still need to vibe with this UI a bit more - not sure If I liked the line item view more. Need to use the interface for another few days and will reply back. Interested in what the rest of the community thinks?

Truly appreciate Your/Dfinity’s persistent efforts to make the UI more user intuitive and cleaned-up. Considering where we were ~1 YR ago, sweeping improvements!

Well…I think it is a bug…There is no way for NNS neurons to use an important feature of liquid democracy, but I don’t think the team thinks it is a bug.:grimacing:

Oh I see, the one we discussed in https://forum.dfinity.org/t/the-goodwill-icp-distribution-framework. Indeed there seems to be some divergent opinion about it so unfortunatelly I cannot really help to move the situation. I’ve to also be honest you and admit that I don’t understand all the subtility of the discussion.

Hey David,

Wonderful job, as usual. The app is becoming terrific. Thank you for this.

To avoid the redundancy, we could erase the first displaying of the Neuron ID, and just put “neuron” (at the singular) a little like I did in the example above.

By doing this, the informations are being displayed logically :

  1. Neuron (We are exploring a neuron, in the neurons section)
  2. Above : ID of the neuron that we are exploring
  3. Above again : The other informations

Otherwise, the only sign of the fact that we are exploring a neuron is “neurons” on the left.

So, the “Neuron” apparition is a remembrance of what we are exploring, without implying the redundancy of the ID.

Thanks again @peterparker :pray:

1 Like

Thanks for the feedback @Roman, really happy to hear that :pray:.

Yep agree with you and aware of it. I was hesitant to remove it because it is handy when the page is scrolled, notably on mobile devices but since you and @esquivada mention it, it seems that it annoys the users so well noted!

2 Likes

Ho ! I understand now ! I admit that keeping it during the scroll is a very good point ! There is a real choice to do here, maybe by removing the second line rather than the first one.

Maybe we can keep things like they are. The scrolling is an important argument. Keep the first line seems necessary. So if we have to choose between keeping the both lines or remove the first rather than the second, let us keep the both lines.

1 Like

If that works for your, for sure that works for us :+1:.

Technically I can make the title dynamic by using an IntersectionObserver to detect when the neuron id (in the content) leave or enter the viewport. Not that overengineered (:wink:). The designer are still activelly improving the design, so I should also check that I would not implement such as thing that ultimately would not be used anymore.

I’ll discuss with my colleagues designer and UX experts.

2 Likes

Perfect set up I think. But, yes, It will depend on the designers work too.
Thanks again !

1 Like

@Roman @esquivada there you go (PR #1573)

gif

3 Likes

:star_struck::heart_eyes:. It is WONDERFUL ! So clear and elegant. Just perfect.

Thank you so much for your incredible work David :pray:

5 Likes

Happy to hear that! Thank you for the feedback and brainstorming Roman :+1:

3 Likes

And thank you for always genuinely considering the community’s opinions. It is invaluable and unique.

2 Likes

Super, very nice job :ok_hand:

1 Like

Also, @peterparker. To add my 2 cents :
The colors of these buttons is problematic imho, but maybe it is just me :

I feel them as problematic, because the difference of color make people assume a difference of “availability”, I mean of “pushability”. For example, it looks like a lot to the “merge neurons” function when it is unavailable :

But once the user clicked on each one of them and see that they are as pushable as the purple one, they fell like there is none obvious reason for the button to be “empty” rather than full of purple. So there is a problem of readability here. Some users, to guess what will be the difference of reaction, even go to the neuron tab to compare the color of this button :
Capture d’écran 2022-11-27 à 11.58.51

And this one :
Capture d’écran 2022-11-27 à 11.59.18

As we are in a blockchain where – even if it is not the case of these buttons – some decisions imply a long commitment (8 years), I think we need unequivocal readability of the NNS buttons.

A good example is here :


People will think “why “disburse” is not purple here, can’t I disburse ? But what if I click and the disbursal is done whereas I was just curious ? etc.” The newcomers could be confused here.

According to me, 2 solutions here :
– choose the same color for all these buttons ;
– OR, if you want to keep a color gradation color, the buttons can gather together a unique continuity of purple : I mean that the left button starts deep purple and becomes clearer like you did, but the right button begins with the same clear purple and becomes clearer again (“square clear”, to say it so).
So, you have :

  1. a first button : Deep purple/Clear purple
  2. a second one : Clear purple/Clearer purple
  3. a third one in some cases : previous Clearer purple/Clearer purple than the previous clearer purple

So, to recap :
Buttons equally pushable should have the same color or at least the same form of color gradation. Another difference will make people ask what is the rationale behind such a difference and won’t be able to understand the equal pushability before pressing the equivocal button and won’t understand, once pressed it, why its color is so different whereas the pushability is equal

Look forward to hearing your feedback about this.
Have a nice weekend.

Kind regards
Roman

2 Likes

Thanks for the feedback Roman. When it comes to the footer, to be honest with you, none of us - developer, designer and ux - are fan of it. Our ultimate goal is actually to get rid of the footer and integrate the actions more gracefuly within the overall user journey. So, no footer, no colors issue :wink:.

Being said, it might be that it is well defined in Figma and that the (my :sweat_smile:) implementation is not yet on point or that even the design itself is not contrasting enough. Long story short, I forward your feedback to the designers.

1 Like

I get it ! Good to know ! Thanks David :pray:

1 Like