Open Xfolchf opened 6 years ago
We should add a new button to adhere apart from the current support button, right?
cc @decidim/product
@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:
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 ?
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.
Here's our proposal for the adhesion button:
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.
hi @javierarce I think your solution is interesting... but I am not sure it will serve the purpose.
We have three options here:
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).
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.
Let'sn include @decidim/lot-mods in this threat
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?
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?
@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?
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.
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.
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):
Our ideas with this design:
We are still looking for alternatives to the "adhere" term :)
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!
Maybe we could turn the adhere
button into a dropdown
in case you are an admin of one or more user groups?
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 ;)
@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)
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).
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:
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:
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.
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.
maybe actions 4 (follow), 5 (share) and 6 (embed) are more easy to find at the same level either:
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
more variants
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
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.
Nice work again @javierarce. Two brief comments about "Reivindicar" and "Seguir" buttons:
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:
@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!
Ok, let's use the one we already have, shall we?
Updated 5th Feb: added version with just support + comment actions.
@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?
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.)
@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
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:
My only cent:
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.
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?
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.
@javierarce I agree with @xabier Let's keep it with no toggle option. Just a counter and action to go direct to comment.
@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.
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)
Yes, I'm with this situation that text "Endorsements blocked" spans vertically although:
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.
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.
Hi @Crashillo , this is the PR with the new endorsements design applied.
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