Add a help text on admin budget show page and improve text from Admin::Budgets::HelpComponent in order to
clarify its functionality when we are using the wizard.
We are use a display: block style for labels containing check boxes inside
them, and the label has a width of 100%.
This means that clicking on the blank space on the right of the label text
will check/uncheck the checkbox. To avoid this behaviour we modify the
"display" attribute of the labels.
In order to prevent unexpected behaviour in terms_of_service form labels,
we add specific css for this case when define a checkbox within the
.actions class.
Defining a behavior on hover means making it different for people using
a keyboard or a touchscreen (most of the population, nowadays).
In this case, we had an accessibility issue where the message wouldn't
disappear once it appeared. That meant that, after tabbing through all
the links and buttons in, for instance, the debates index, the page
would be filled with "participation not allowed" messages, and in order
to see the information about how many people have voted, reloading the
page was required.
For touchscreen users the behavior was similar to what we get on hover,
although we've found some inconsistencies when trying to support several
elements on the same page.
We think in proposals it makes sense to hide the "support" button when
users click on it, and the same applies to the buttonsto support and
vote investment projects. However, we aren't hiding the buttons to
agree/disagree with a debate in order to keep the information about the
current number of people agreeing and disagreeing visible.
Note we're removing some support spec methods because after these
changes the duplication isn't as obvious as it was in the past.
Hovering over the votes showed a "participation not allowed" message
which was annoying when scrolling with the browser or simply moving the
mouse around the page. Furthermore, it hid the information about the
number of votes, links to show/collapse replies, ...
We're planning to change the behavior of all the "participation not
allowed" messages in order to show them on click instead of showing them
on hover (just like it's done on touchscreens). In the case of comments,
supports, however, there's very limited space in the part showing the
number of supports for comments, so adding this message without breaking
the layout is challenging.
So, for now, we're simply redirecting unauthenticated users to the login
page. If find an easy way to implement a better user interface in the
future to display the "participation not allowed" message, we might
change this behaviour.
This message is only shown in the `show` action, so it's shown at most
once in the whole page, so it doesn't take up too much space and it
isn't as overwhelming as if we were showing it on the index page, once
per debate.
We're only showing it when there are closed options, though, since
there's already a message to sign in to comment when the question
accepts open answers.
Note we're using the in-favor HTML class instead of the in_favor class
so we're consistent with our conventions for HTML classes and because we
use the in-favor class in similar places.
Also note the styles of the legislation process annotations/comments
buttons is now similar to the styles in the other sections. Previously,
the colors didn't have enough contrast and there was a very strange
margin between the "thumbs up" icon and the number of people agreeing
(that margin wasn't present between the "thumbs down" icon and the
number of people disagreeing).
Using the `flex-with-gap` mixin we avoid the left margin in the second
element when the screen space isn't wide enough to show both buttons.
Setting the margins with CSS also allows as to simplify the view and
makes it easier to customize styles.
Having buttons (previously links) with the text "I agree 75%" is
confusing; people might believe they're saying they only partially agree
with the content. Besides, the results percentages is a different piece
of information which shouldn't be related to whether one person
agrees/disagrees with the content.
This problem might be solved for people using screen readers since we
added the aria-label attribute. However, for sighted keyboard users, the
percentage was being outlined on focus as part of the button, which
might be confusing.
We were using the same code to render links to agree and disagree, so we
can extract a new component for this code.
We're also adding component tests to make it easier to test whether
we're breaking anything while refactoring, although the code is probably
already covered by system tests.
Since the votes mixin was only used in one place, we're removing it and
moving most of its code to a new CSS file for the shared component.
When there isn't a current user, the links can't be clicked, so there's
no real point in them being links.
When there's a current user and they cannot vote (for example, an
organization), having a link/button to an action they can't perform
isn't that useful IMHO. They get a message saying they aren't allowed to
vote but the message doesn't say why. However, in this case, many people
might try to click/touch the link/button and will wonder why nothing
happens, so we'll revisit this issue when we change the way we display
the "participation not allowed" messages.
Now the behavior is more similar to the one we get when voting
proposals/debates.
The action and the views were almost identical, with the supports
progress and the HTML classes of the success message element being the
only exceptions; we can use CSS for the styles instead.
The user can access this page without being logged in.
We identify the user through the "subscriptions_token" parameter and
show a list of the notifications that can be enable/disable.
We will return a 404 error in case someone accesses the page with a
non-existent token.
We also control the case that some anonymous user tries to access the
page without any token, by returning the CanCan::AccessDenied exception.
In commit 905ac48bb we mentioned:
> Since we don't use `asset_path` to reference assets in the public
> folder, we can safely disable the `unknown_asset_fallback` option.
However, `asset_path` is used by the wicked_pdf gem when calling the
`wicked_pdf_stylesheet_link_tag` method. This method also checks the CSS
files, searching for `url()` calls and converting any relative URLs
referenced there to absolute URLs.
However, when compiling assets on production, our `application.css` file
contains the following line imported from Leaflet which says:
```
behavior: url(#default#VML);
```
When passing this URL to `asset_path` (which is something the wicked_pdf
gem does automatically), it doesn't find the URL, and so this call
crashes unless we enable then `unknown_asset_fallback` option.
Since the dashboard poster is a feature we might remove in the future,
we're avoiding changing a Rails global configuration just for this
feature. So, instead of enabling the `unknown_asset_fallback` option,
we're changing the `poster.pdf` view so it doesn't load all the CSS of
the application but only the CSS it needs.
Note we aren't adding a test case because this bug is only present on
production environments when assets have been precompiled.
This is useful for people using screen readers, since the character used
as a separator won't be read aloud.
Since many screen readers also read content generated via CSS
pseudoelements, we aren't using `content: "|";` or similar but using
elements with a very small width instead.
We're continuing to replace links with buttons, for the reasons
explained in commit 5311daadf.
Since we're using the admin action component, we can also simplify the
logic handling the confirmation message.
In order to avoid duplicate IDs when generating buttons to block the
same author more than once in a page, we're including the record dom_id
in the ID of the button to block an author.
The `hide` action was calling the `block` method while the `soft_block`
action was calling the `hide` method.
Combined with the fact that we also have a `block` permission which is
used in `ModerateActions` the logic was hard to follow.
Note that in proposal notifications we're writing the call to
render the component in the same line as the <div class="reply">
definition in order to be able to use the `:empty` selector when the
component renders nothing. No browser matches whitespace with the
`:empty` selector, so we can't add newline characters inside the tag. A
more elegant solution would be extracting the proposal notification
actions to a component and only rendering it if the moderation actions
component is rendered.
Having proper headers makes it more accessible.
We're also using the table actions component because we're going to add
another action. Since table actions use a flex layout, we have to tweak
the styles a little bit. For that, I'm adding a <main> element which
will make it possible to style just this table while also providing an
extra shortcut for people using screen readers.
As mentioned in commit bc0f04075, a <select> field which submits its
form on change causes many accessibility and usability issues. In this
case there was also an incompatibility with the advanced search filter
which caused a bug solved in commit 541a5fa89.
So the question is where to position the filters and how to display
them. One factor to take into the account is how relevant these filters
are, particularly compared to the links to select the prefered order,
since we don't usually give users the choice of both filters and orders.
Our filters don't really make sense until the valuation phase starts,
since before that phase investments aren't selected nor their
feasibility is decided.
After that phase, the only phase where citizens are really involved
is the final voting; the rest of the phases are done by valuators and
administrators. In the final voting, citizens can only vote on selected
projects, and that's the default filter during that phase.
So these filters are mainly there for information purposes, and not to
help citizens in the phases where they're actually involved (accepting
projects, selecting projects and balloting).
Orders, on the other hand, play a crucial role during the final voting
phase. Since citizens might have already voted for a few projects and
have, let's say, 100,000€ left, ordering by price allows them to find
which projects are within their remaining budget.
In conclusion, orders are more important than filters, and so they
should have a more prominent place.
For consistency with the proposals section, where we've got some links
in the sidebar (bottom part of the page on small screens) providing a
similar funcionality, like accessing selected proposals or archived or
retired proposals, we're moving the investments filters to the sidebar
(bottom part of the page on small screens) as well.
A <div> can't be a direct child of a <ul>. In this case the <ul> tag
didn't make much sense because there isn't a list; just a map.
Note the `z-index` rule which was added in commit 25e1afea48 is ignored
because the map element is statically positioned. I'm not sure why it
was added; can't reproduce the rendering problem both that commit and
commit c5a749212 mention. Maybe back then the element had a `position:
relative` rule or similar somewhere.
This way the curve will still work as intended on very large screens.
We're not taking into account the padding of the <main> element in the
SDG goals index for simplicity, since adding it barely has any effect.
When running `scss-lint`, we were getting the following message:
DEPRECATION WARNING: #{} interpolation near operators will be simplified
in a future version of Sass. To preserve the current behavior, use
quotes:
unquote("#{$global-width / 2} - 50vw")
Captions benefit blind screen reader users who navigate through tables,
particularly in this case because we potentially have several tables
with headings (one table per group), so when navigating through tables
it might be hard to know which group the headings belong to.
In this case they also benefit sighted users. Usability tests have shown
the "Groups and headings" section is a bit confusing, so adding a
caption like "Headings in Districts" helps clarifying Districts is a
group and the table refers to headings in that group.
The very same table is rendered in the "headings" step of the budget
creation wizard. However, in that case the information of the caption is
redundant because the page is specific for headings belonging to a
certain group. We're making the element invisible but still keeping it
for screen reader users in order to ease their navigation through
tables.
The problem of having actions next to the title is that, when there are
titles of very different lenghts, at certain resolutions some actions
will be next to their titles (because there'll be space for everything)
but some actions will be below their titles. This makes it hard for
people to follow where the actions are.
The buttons to create polls associated with a budget were too prominent,
appearing on the table as if they were as used as the link to manage
investments. Most CONSUL installations don't use physical booths, and
would probably wonder what that button is about.
We're moving it to a more discrete place, at the bottom of the budget
page. This way we can also split the action in two: on budgets not
having a poll, we display the button in a not-so-accessible position (at
the bottom of the page), since this button will only be used once per
budget at most. Once the poll has been created, it means this feature is
going to be used, so we display a link to manage ballots more
prominently at the top of the page. If the budget has finished the final
voting stage without creating a poll, we don't show either the link or
the button because this feature can no longer be used.
We're also adding some texts indicating what this feature is about,
since it's probably one of the least understood features in CONSUL
(probably because the interface is very confusing... but that's a
different story).
Since now from the budget page we can access every feature related to
the budget, we can remove the "preview" action from the budgets index
table, since this feature isn't that useful for budgets once they're
published.
Now the budgets table doesn't take as much space as it used to, although
it's still too wide to be handled properly on devices with a small
screen.
Since managing investments is a very common action, with this link
administrators won't have to go back to the index page to manage
investments; they can access it from either the budgets index page or
the budget page.
Since now the links we've got on the budget page are similar to the ones
we've got in the index page table, we're styling them in a similar way.
We're also fixing a small typo en the investments path; it works exactly
the same way as it used to, but passing `budget` instead of `budget_id:
budget.id` is shorter and more consistent with what we do in other
places.
Both the calculate winners and delete actions benefit from some kind of
hint.
The "calculate winners" hint informs administrators that results won't
be publicly available unless the "show results" option is enabled.
The delete action was redirecting with an error message when the budget
couldn't be deleted; IMHO it's better to disable it and inform
administrators why it's disabled. Alternatively we could remove the
button completely; however, users might be looking for a way to delete a
budget and wouldn't find any hint about it.
We're now removing the "Delete" action from the budgets index table,
since most of the time it isn't possible to delete a budget and so the
action takes up space and we get little gain in return. We could keep
the "Delete" icon just for budgets which can be deleted; however, the
alignment of the table rows would suffer, making it harder to find the
intended action.
Before, users needed to navigate to the list of groups in order to
add, edit or delete a group.
Also, they need to navigate to the list of groups first, and then to
the list of headings for that group in order to add, edit or delete a
heading.
Now, it's possible to do all these actions for any group or heading
from the participatory budget view to bring simplicity and to reduce
the number of clicks from a user perspective.
Co-Authored-By: Javi Martín <javim@elretirao.net>
In the past it would have been confusing to add a way to directly
enable/disable a phase in the phases table because it was in the middle
of the form. So we would have had next to each other controls that don't
do anything until the form is sent and controls which modify the
database immediately. That's why we couldn't add the checkboxes we used
when using the wizard.
Now the phases aren't on the same page as the budget form, so we can
edit them independently. We're using a switch, so it's consistent with
the way we enable/disable features. We could have used checkboxes, but
with checkboxes, users expect they aren't changing anything until they
click on a button to send the form, so we'd have to add a button, and it
might be missed since we're going to add "buttons" for headings and
groups to this page which won't send a form but will be links.
Since we're changing the element with JavaScript after an AJAX call, we
need a way to find the button we're changing. The easiest way is adding
an ID attribute to all admin actions buttons/links.
Having links in the middle of a form distracts users from the task of
filling in the form, and following a link before submitting the form
will mean whatever has been filled in is lost.
And the budgets form is already very long and hard to fill in. Having
the phases table in the middle of it made it even harder. And, since
we're planning to add the option to manage groups and headings from the
same page, it's better to have a dedicated page for the form.
Since we aren't very consistent in the styles for submit buttons in the
admin section, it was possible to accidentally press the "Calculate
Winner Investments" link after filling in the form. This wouldn't submit
the form and so the changes wouldn't be saved.
It's also a bit confusing for users. After filling in a form, users
expect a submit button. When finding two buttons, they've got to stop to
think which one is the one they've got to press.
Furthermore, the "Calculate Winner Investments" link would work better
as a button instead of a link, for the reasons mentioned in commit
5311daadf. Since HTML forms can't be nested, that would mean treating
this button in a different way than the rest of the buttons in the
application.
Moving the link before the form solves the issue.
Since now we've got the budget actions before the budget form, we're
grouping these actions together with the "Preview" action. We're not
adding the "Publish budget" button as well to this group because it's
got an associated message.
Even if it was looking OK using `margin-left`, there were probably edge
cases where it wouldn't behave as we expected.
As mentioned in the previous commit, this won't be necessary once
everyone uses browsers supporting the `gap` property in flexbox layouts,
but this won't happen for a few years.
In a few months we might also consider using the `margin-inline-start`
property, which is currently supported by about 97% of the browsers [1].
[1] https://caniuse.com/css-logical-props
This way we remove duplication and it'll be easier to add better support
for RTL languages.
In a few years this might not be necessary since support for the `gap`
property in a flexbox layout will improve. At the time of writing,
however, only 86.5% of the browsers support it [1].
[1] https://caniuse.com/flexbox-gap
