decidim-archive / design

⚠️ [DEPRECATED] Design of the Decidim framework
1 stars 3 forks source link

Adhesion to proposals #156

Open Xfolchf opened 6 years ago

Xfolchf commented 6 years ago

This issue started as the design of a button to express endorsement, it is now turning into redesign of the actions that a proposal can hold.

Related: https://github.com/decidim/decidim/issues/2287

furilo commented 6 years ago

We should add a new button to adhere apart from the current support button, right?

cc @decidim/product

carolromero commented 6 years ago

@furilo correct, both actions can be performed by a user or organization. We must re-think also the counter for adhesions. Here's the current design for Initiatives:

imatge

furilo commented 6 years ago

After reading https://github.com/decidim/decidim/issues/2287#issuecomment-348155994 I doubt if the adhesion button will be just a simple action, or if some other interaction will arise.

Can you confirm the user flow @decidim/product ?

arnaumonty commented 6 years ago

We should consider that the adhesion is subsequent action taking into account the primary action is the support. There are no other actions related to this. But we should attend if adhesions are configurable in the admin panel (you can choose if you want it or not), we should think how is showed (the "adhesion" button) if we have supports active and if we have it inactive.

javierarce commented 6 years ago

Here's our proposal for the adhesion button:

adhere

Instead of creating a new box to hold the CTA and the data, we could integrate a toggle button inside of the current data definition section. Another added benefit is that if the administrator doesn't want to allow the action but still wants to show the info, the layout won't change significantly.

xabier commented 6 years ago

hi @javierarce I think your solution is interesting... but I am not sure it will serve the purpose.

We have three options here:

  1. To add the adhere button together with the support/vote button
  2. To include the adhere action as a suggestion after giving support, unless you are an entity that doesn't have voting/support authorization in which case it would have to substitute voting/support button
  3. To add the adhere button elsewhere in a secondary space as you suggested.

I am tempted to go for option 1 myself. Option 2 is too complex for an MVP, and option 3 has the following problem: it does not contemplate the different card views of proposals and it will only be displayed on the XL (full screen) view of a proposal. This will reduce very considerable the functionality.

@carolromero @furilo @arnaumonty how do you see this? I think it is worth traying to include adhesion somewhere on the main action box (together with vote and follow).

arnaumonty commented 6 years ago

Hi @javierarce, the problem of the proposal is that the table fo adhesions, comments, meetings,... is only displayed in the initiative and results but not in the proposals (Maybe we need a general solution for this including proposals, but we should differentiate between metadata of the proposals (comments, meetings,...) and the actions). I like the solution as a secondary information more than add other actions to the support box. This would be the 3rd option of @xabier but requires to think how can be displayed.

arnaumonty commented 6 years ago

Let'sn include @decidim/lot-mods in this threat

javierarce commented 6 years ago

Thanks for the feedback @xabier & @arnaumonty!

I think the approach #2 (a suggestion after supporting/voting) will be easier to understand by the users than presenting two different options at the same time.

What if we use a checkbox instead of a button? By doing this we could a) reduce the space required to present the new element b) indicate that it's a choice that users can make on top of voting and c) explain that the vote is private by default?

screen shot 2017-12-04 at 16 35 49

I've also moved away from the "adhere" term, because I find it difficult to understand (the first time I read this issue I couldn't see the differences between support, vote, and adhere right away). If we opted to maintain the term I'd suggest to say "adhere publicly" to indicate that the action will be broadcasted.

The little (i) icon besides the text would open a popup explaining that, upon checking the box, the user's followers will be notified (and that, although it's possible to make the vote private again, it won't be possible to undo the notification).

What do you think?

tramuntanal commented 6 years ago

@xabier @arnaumonty @javierarce I may like to adhere to a proposal before it can be voted. Imagine phase1 is legal validation, phase2 economic viability and phase 3 voting. Should it be possible to adhere to the proposal before phase 3?

javierarce commented 6 years ago

Oh, ok, I interpreted @arnaumonty's comment ("We should consider that the adhesion is subsequent" and #2 option from @xabier list) as an indicator that adhesion would come after a vote.

xabier commented 6 years ago

We should not use the term Vote, but Suport (Voting requieres other guarantees). Right now Suport and Adhere are going to operate independently. Sometimes they will operate simultaneously. Sometimes only Adhere. For example. Entities (organizations inside the main organization) cannot give support but can Adhere.

We were talking today about this at Decidim Team and a recurrent example to illustrate was twitter's reply and like actions. Like is analogous to support, retweet analogous to adhere.

You are right that Adhere is all but self explanatory, the name sucks so we better think on something different.

javierarce commented 6 years ago

Ok, here's another proposal taking into account the last comments. Don't take it as the final design, it's just a quick solution to present the idea (we've also used the support with progress bar to show the more complex interface):

support_adhere

adhere_support2

Our ideas with this design:

We are still looking for alternatives to the "adhere" term :)

josepjaume commented 6 years ago

Hi! Nice proposals!

Take into account that when adhering, one should be able to choose what to adhere. A user might belong to multiple User Groups, so we should find a way to adhere either you or one of the groups. The UX for this might be tricky!

josepjaume commented 6 years ago

Maybe we could turn the adhere button into a dropdown in case you are an admin of one or more user groups?

furilo commented 6 years ago

Oh, a new bit of vital information! ;) Is there any place where we have this feature documented with soe detail? I feel we are just designing with parcial info, and new bits appear as we progress ;)

xabier commented 6 years ago

@josepjaume @furilo Adhesion has already being implemented in Iniciatives , where this problemas of multiple adhesions by groups is already solved (although can improve considerably from UX point of view)

josepjaume commented 6 years ago

Yeah, I'm sorry about this. There's no specific documentation for the issue, but you can see how this works when creating proposals, for example: In case a user belongs to multiple user groups, a dropdown is shown asking on behalf of whom it's creating that proposal (you or any of your groups).

xabier commented 6 years ago

We have been discussing this in length today...

There are plenty of option and the types of actions, their names, icons, and visibility need careful discussion.

These are the actions, in order of priority:

  1. Vote, sign, support, push: in all cases they have the same properties and all have the same nature, they push a proposal to reach its goal, being the push non-public to avoid cohertion. It is possible to unvote, unsupport etc. And this is the main action we want to promote. Numbers are displayed (either as a continuum, with our without threshold, but numbers might be hidden). Promotes direct democracy.
  2. Claim, reclaim, adhere, spread, endorse: it is a "public support with the intention to spread and campaign in favor of it. Numbers are always visible. Promotes communicative democracy.
  3. Comment, deliberate, discuss, respond: it is a public opinion to discuss the proposal. Promotes deliberative democracy.
  4. Watch, follow: keeps the participant informed about the future and activity of the proposal. Promotes transparency, traceability and accountability
  5. External share: this is only required to spread decidim content outside de platform to other social-networks.

Here is a mockup with all these actions, not that I particularly like it, but I did it, and I wanted to share, maybe something useful comes out of this:

image

Since this discussion might take really long, I don't know if it would be better to solve it quickly with a solution to the Adhere/endorse button, and keep an open discussion for mid terms elsewhere.

arnaumonty commented 6 years ago

It seems good to me systematization and hierarchy of the actions. The design should reflect this. I should try to keep inside the support box the actions 2 and 3 (as an action button) and leave outside the actions 4 (follow), 5 (share) and add the action 6 (embed) at the same level.

tramuntanal commented 6 years ago

maybe actions 4 (follow), 5 (share) and 6 (embed) are more easy to find at the same level either:

tramuntanal commented 6 years ago

Hi @decidim/lot-px @decidim/lot-core I also need to know if there will be adhesion related stuff in the Proposal list view. Thanks

xabier commented 6 years ago

more variants

image

image

javierarce commented 6 years ago

Here's a new version of the adhesion to proposals interface following the ideas you suggested in your previous design, @xabier: https://marvelapp.com/5cafcd1

adhesion to proposal interfaces

And here's the card with the adhesion counter. I'm posting more detailed image of the card redesign over this issue https://github.com/decidim/design/issues/155.

adhesion_card

arnaumonty commented 6 years ago

Nice work again @javierarce. Two brief comments about "Reivindicar" and "Seguir" buttons:

javierarce commented 6 years ago

Ok, what about using a similar solution to the current style of the follow button. This way, the button will still work fine when there are no other main actions in the same page:

adhesion to proposal interfaces

xabier commented 6 years ago

@javierarce How about adding an icon to follow? This would latter help simplifying and can also be useful to use for small size cards. Great job!

javierarce commented 6 years ago

Ok, let's use the one we already have, shall we?

interfaces

Updated 5th Feb: added version with just support + comment actions.

mrcasals commented 6 years ago

@javierarce what happens if the text for "REIVINDICAR" is too long (for other languages)? How should the comments button fall?

Maybe moving the button to a new line by default would solve this?

javierarce commented 6 years ago

I would prefer not to add more lines inside that box, so I'd say let's collect the words in other languages and see if we encounter the problem, and if that's the case we could reduce the font size or make the counters in both sides smaller.

We could also limit the length of the counters when the number is too big (instead of 5000 we could say 5k, etc.)

xabier commented 6 years ago

@javierarce what happens if the text for "REIVINDICAR" is too long (for other languages)? How should the comments button fall?

good point @mrcasals ! The name of this buttons is very important, so translations need to be carefully thought. They have to be relative short names, in English "reclaim" or "endorse", action names are usually short in all languages, so let follow @javierarce strategy

mrcasals commented 6 years ago

I don't know any Russian, but "adhere", which is suggested as a synonym for "claim" or "endorse" in https://github.com/decidim/design/issues/156#issuecomment-350895617, translates to a really long word (we already have Russian in Decidim):

Translators using Crowdin have a metric showing how long is their new word compared to the original string in English, so we can leave that as it is, but I think that's something to take into account anyway.

Just my two cents :wink:

xabier commented 6 years ago

My only cent:

image

arnaumonty commented 6 years ago

Hi @javierarce Checking this design we have noticed that we need the design when we have "endorsements" active but supports inactive, then we should show just "endorsements" and "comments" in the support box.

javierarce commented 6 years ago

Hi, @arnaumonty. I've updated the design in my previous comment and here.

I've a doubt now regarding the comment button. Originally, I decided it was a toggle button (so when a user comments, the button will be highlighted). But from a technical standpoint (complexity of the implementation) and usefulness for users I'm not sure that's a good decision. I'm now more inclined to not use the highlighted state for that comment button.

What do you all think?

xabier commented 6 years ago

I'm now more inclined to not use the highlighted state for that comment button.

Hi, we want to promote deliberation, there is no need to make it a toggle button if it is technically complex, but we want to make it visible and actuable.

In any case @javierarce we need to move fast with this issue, it is taking too long. We can iterate in a few months time. Let's move on.

arnaumonty commented 6 years ago

@javierarce I agree with @xabier Let's keep it with no toggle option. Just a counter and action to go direct to comment.

tramuntanal commented 6 years ago

@decidim/lot-px I'm setting the layout for endorsements and I think there is no desgin for the case when endorsements are blocked. In this case the user can see the number of endorsements but can not un/endorse anymore.

Also, I see that http://localhost:3001/public/proposals/proposal-view-login is raising an exception.

javierarce commented 6 years ago

I'd say that in the disable state the endorsement button would have 50% opacity and the cursor would be the default one (so to indicate that there's no action possible)

tramuntanal commented 6 years ago

Yes, I'm with this situation that text "Endorsements blocked" spans vertically although:

imatge

javierarce commented 6 years ago

I wouldn't change the text inside the button. If we need to explain that the endorsement has been blocked, I'd say to use a tooltip, but I think with the opacity and the cursor change is enough.

Crashillo commented 6 years ago

Also, I see that http://localhost:3001/public/proposals/proposal-view-login is raising an exception.

I've figure it out. It's a silly thing, push your new branch, and I'll fix it quickly.

tramuntanal commented 6 years ago

Hi @Crashillo , this is the PR with the new endorsements design applied.