Delegation UI love

[davefrey]

Two things have been bothering me about our current support/delegation UI:

1. the two functions are not well delineated
2. we don't provide much info about the consequences of a delegation; we only report the delegate's name

To address the first one, I've moved Support above delegation, and introduced the Delegate select box and button with explicit text.

The second point above is a missed opportunity for LV. if I were delegating, I'd like to know if my delegate has voted in my stead, delegated to another, or not done anything yet (so my vote/delegation is not counted). I'd also like to know how much weight my delegate has...do they carry half the community votes, for example? If we present this information, we further differentiate our liquid voting approach from normal voting. Maybe there is some liquid philosophy around how opaque/transparent delegation should be; we could make it an admin config point.

There is of course a complication of cascading delegations: in the case the delegate themself delegates to another, we don't know the ultimate result of the original user's "vote": a downstream delegate may or may not have themselves voted.

There is a further nuance in the case of a deadline for voting: we could communicate if the delegate has not voted yet, vs didn't and can no longer vote (again a lost vote because the user delegated). It seems like useful feedback in a delegation mechanism. So maybe some styling to show if the weight and resolution are frozen, or subject to change.

The image below has the current interface, and a proposed one. The screenshots for the current UI show the three cases: the user has done nothing yet, or supported, or delegated. For the proposed UI: the user has done nothing, or supported, or delegated, which has three subcases: the delegate has voted, or themselves delegated, or done nothing yet. Additionally, the current weight for the delegate (the number of delegations they've received, +1 for themselves) is shown.

I propose we simply stop at the first degree of delegation: the original user's delegate has a weight, and a status (voted, delegated, neither). The three states should be styled, maybe with a disabled/selected button-like effect.

Aside from some UI styling work, we'd need an api change; I think it's a straightforward change to extend votingResult with the delegate weight and status.

(here's the edit link for the google doc if you want to add proposals)

[davefrey]

I briefly thought about just changing the color of the Delegate button but I really don't like that approach –– Decidim uses different button colors sometimes, but I haven't understood or found documentation for the semantics of color, and I don't think we should do something random. And a yellow button for example doesn't really help the UI much imo; we currently have red (supporting), teal (endorsing), and white (following); if we add a color it should somehow still correlate to Support rather than suggest a new thing.

[davefrey]

It also occurs to me that the current user has a weight (their own vote, plus any delegations), but is completely ignorant of it! It seems like important information for a user if they are voting only for themselves, or if they have some following or bloc that has delegated to her. It's an easy thing to calculate and return in our api results, and render in the UI, and again further shows the value of liquid voting (and our integration of it).

And now weight is getting more complicated. Both the current user (who is interacting with our UI), and their eventual delegate, have a weight. And the weight can be "direct" (just the delegations directly naming the user, plus the user themself), or "full" (reduces all delegations in the graph reaching the user).

So I'm showing how I don't know this domain, there is probably a shared language for this stuff. But both "direct" and "full" weights seem interesting, and have different utilities. If I am the current user, I'd like to know my direct weight, how much direct following or confidence do I have, and my full weight, what is the full impact of my vote/delegation/abstention.

[davefrey]

In the proposed UI, I now feel that "Delegate Support" and "Withdraw Delegation" buttons more strongly communicate their relationship with the Support button above them.

[oliverbarnes]

Will look at this next week with fresh eyes :) Lots to process here, thanks for taking the dive

[davefrey]

Looking this morning, this latest "direct" vs "full" weight, and how to present that ... it's probably too often something for powerusers.

So we could allow an admin to choose a kind of liquid for their installation; here's a dump of some possibilities:

• "basic delegation" (just the button, no weights or statuses)
• "delegate status" (visibility of the disposition of the user's delegation: did my delegate vote or delegate or abstain? is voting closed?)
• "delegations received" (show, for the user and their delegate, the "direct" weight = how many delegations each user has received. Wow I had 15 delegations? and my delegate now has 50?)
• "full delegation impact" (reduce the delegates graph for both the user and their delegate, showing their "full" weightings)
• "full stats" (support, both admin and user level, for statistics about delegation, bloc sizes and how static or dynamic... stuff admins or super engaged delegates might be interested in)

[jinjagit]

I really like @davefrey's UI idea to display vote weighting of delegate and if he/she has voted or delegated (or neither), shown in his images, above.

I'm not sure how much granularity we should give the admin, but again I like Dave's ideas.

I think we should give admin the ability to switch any info. about the delegate (vote weight, whether voted / delegated) on - with the default being off. Typically the 'support' proposal functionality is used for secret voting, thus the default should be no info about other participants. Endorsements, however, are typically public.

[oliverbarnes]

I love all the ideas brought up, so far I had only considered email notifications with similar info, and custom apps with some of it. But not yet in Decidim :)

How about breaking them up into issues that can be tackled incrementally? Flipping the position between support and delegation button seems like the easiest win.

This should definitely be configurable, and I agree with Simon that supports' anonymous aspect needs to be taken into account, though I'm not sure to what degree (whether no delegation info, or partial, etc). Something to be discussed.

I didn't really understand the full vs direct delegations count...

About literature, that'd be something to revisit on the liquidfeedback book.

[davefrey]

We now have the original #47 for distinguishing Support and Delegate, and #56, #57, #58 to "hash out" some of the ideas above.

[davefrey]

Re: "full vs direct delegation", I just posted another discussion with a schema

[oliverbarnes]

Thanks, I understand better now :)

Would you mind removing the prepended "Hash out delegation UI:" from the issue titles? It's clearer with just the second part of the titles.