The previous version worked fine when using Capistrano to deploy a new
release, but it did not work for other commands, like `cap npm install`
or `cap puma:start`, as they do not create a release. Therefore, the
`git:create_release` was never called, and the `map_node_bins` was not
invoked.
Since we need node binaries available to the deploy user when executing
any process that runs the application, like puma, delayed_job, and rake
tasks, among others, it makes sense to load FNM to use the correct Node
version in the same places where Capistrano loads RVM to load the correct
Ruby version.
With dynamic loading of the `fnm_setup_command`, we get the correct path
when deploying a new release and also when running any other capistrano
command that does not deploy a new release.
Most screen readers don't notify when a link is about to open in a new
window [1], so we're indicating it, like we were already doing in most
places with similar links.
We could also add a visual indicator, but since links inside labels
already have accessibility issues, giving more attention to these links
might make matters worse.
[1] https://www.powermapper.com/tests/screen-readers/navigation/a-target-blank/
We used to open these links in new tabs, but accidentally stopped doing
so in commit 75a28fafc.
While, in general, automatically opening a link in a new tab/window is a
bad idea, the exception comes when people are filling in a form and
there are links to pages that contain information which will help them
fill in a form.
There are mainly two advantages of this approach. First, it makes less
likely for people to accidentally lose the information they were filling
in. And, second, having both the form and a help page open at the same
time can make it easier to fill in the form.
However, opening these links in new tabs also has disadvantages, like
taking control away from people or making it harder to navigate through
pages when using a mobile phone.
So this is a compromise solution.
IMHO the best solution would be to completely remove this checkbox on
forms that require registration. Other than the fact that people have
already agreed with these terms when registering (although I guess these
terms might have changed since then) and that approximately 0% of the
population will read the conditions every time they agree with them,
there's the fact that these links are inside a label and people might
accidentally click on them while trying to click on the label in order
to check the checkbox.
I guess the idea is that these conditions might have changed since the
moment people registered. In a fair world, checking "I agree" would have
no legal meaning because it's unreasonable to expect that people will
read these conditions every time they fill in a form, so whatever we're
trying to do here would be pointless.
But, since I'm not sure about the legal implications of removing this
field in a world where you have to inform people that websites requiring
identification use cookies, for now the field will stay where it is.
In some places, we were using `blank` instead of `_blank`. Most browsers
treat `blank` like `_blank`, though, so most people didn't experience
any difference.
In another place, we were incorrectly passing the `target` option inside
an `options:` hash, resulting in invalid HTML.
Quoting usability experts Jakob Nielsen and Anna Kaley [1]:
> [Opening PDF files in new tabs] is problematic, because it assumes
> users will always do the exact same things with certain file formats,
> which isn’t always the case.
There are many examples of this situation. For example, some people
(myself included) configure their browser so it downloads PDF files
instead of opening them in the browser. In this situation, a new tab is
opened, a blank page is displayed, the file is downloaded, and then
either the tab is closed or the blank page needs to be manually closed.
The end result is really annoying.
Other situations include people who use a mobile phone browser, where
navigating through tabs is generally much harder than doing so on a
desktop browser.
But IMHO the most important point is: every browser already provides a
way to open "regular" links in a new tab, so people can choose what to
do, but if we decide to open the link in a new tab, we take control away
from them, and people who'd like to open the link in the same tab might
feel frustrated.
In these cases, the links either say "download" or include the word
"PDF", so people know in advance that they're going to download/open a
PDF file, and so we're giving them information and, by removing the
`target` attribute, we're giving them control over their browser so they
can choose what's convenient for them.
[1] https://www.nngroup.com/articles/new-browser-windows-and-tabs
We were displaying documents in five places, and in five different ways.
Sometimes with the metadata in parenthesis after the title, sometimes
with the metadata below the title, sometimes without metadata, sometimes
with an icon in front of the document, and sometimes with a separate
link to download the file.
So we're now displaying the same thing everywhere. Not sure whether this
is the best solution, but at least it's consistent.
We aren't unifying the way we display a list of documents, though, since
different sections look pretty different and I'm not sure whether the
same style would look well everywhere.
Note that we're renaming the `document` HTML class in the documents
table to `document-row` so the styles for the `document` class don't
apply here.
This way it'll be easier to change them.
Note that there were two `.document-link` elements which aren't part of
a `.documents` element. We're renaming the HTML class of the link in
investments because it didn't contain links to download documents and
are slightly duplicating the CSS in the poll answer documents in order
to keep the `word-wrap` property.
While in unit tests it's great to have different tests for different
expectations, system tests are slow, and so it's better to have just one
test for all the expectations related to the same actions.
Using the `document` or `documents` classes meant styles defined for the
public list of documents conflict with these ones.
So now we're using HTML classes that match the name of the Ruby
component classes, as we usually do.
We were adding <div> tags with the `images` or `documents` HTML class
prettly much every time we rendered a NestedComponent. We're now
including the HTML class inside the component, as we usually do.
We're also rendering the nested components directly, since it's been a
while since the partials were changed to simply render the components.
We aren't using <hr> tags on any forms containing fields to add/edit
documents, so using this in the dashboard actions form and the
legislation process form was inconsistent.
We were using a "Download file" link in one place, while in another
place we had an additional column where the name of the document was a
link to download it.
There's a link next to it that does the exact same thing and includes
the word "download", which was confusing in some cases since people
might think that links with different texts lead to different pages.
In order to comply with the security measure for the
ENS: "[op.acc.5.r5.2] The user shall be informed of
the last access made with his identity".
We have added a new secret to display the last
access made to the user on the "My account" page.
Even if pretty much nobody uses a browser with JavaScript disabled when
navigating our sites, there might be times where JavaScript isn't loaded
for reasons like a slow internet connections not getting the JavaScript
files or a technical issue.
So we're making it possible to still use the like/unlike buttons in
these cases.
We added the feature to undo a vote and made it obvious for people using
screen readers using the `aria-pressed` attribute. However, for sighted
people, the only way to know a button can be unpressed is to try to
press it again and see what happens.
The most obvious way to indicate it would be to add a text indicating
that you can undo your vote. However, that'd require changing the design
quite a bit.
So, after trying a few techniques, we're using a classic approach
browsers have used by default for years: using an inset border for
pressed buttons and an outset border for unpressed ones. It might now be
enough, though; we haven't done usability tests to confirm this point.
Since icons to like/unlike comments don't have a border, I'm not sure
what to do in this case; the icons are small and that makes it hard to
style them in a distinct way. So for now we're not changing these icons.
Since we were styling pressed buttons the same way as buttons on hover,
a person hovering on the button and then clicking it wouldn't notice
that the buttons had been pressed unless they noticed that the number
and percentages of votes had changes. They wouldn't notice the changes
when unpressing the buttons either, since, after clicking the button,
the cursor would still be over it, and so the hover styles would apply.
Furthermore, it was hard for mouse users to realize that a button could
be unpressed, since the style of pressed buttons didn't change on hover.
So we're now changing the icons on hover without changing the
background. This way all four states (unpressed, unpressed on hover,
pressed, pressed on hover) are styled in a different way.
The colors we were using (gray for unpressed buttons and green or red
for pressed buttons) didn't contrast well against a white background, so
we're now using darker colors.
However, with darker colors, using solid icons for the unpressed buttons
makes it harder to differentiate when a button is pressed and when it
isn't, particularly for color-blind people.
So we're now using regular icons for the unpressed buttons and solid
icons for the pressed ones.
We were using the same selectors three times. Since we're going to
change that part of the code, we're simplifying it so we don't have to
do the same changes three times.
Debian Bullseye was released in 2021 and Debian Buster only receives
security updates.
Note that the libindicator7 package is no longer available in this
distribution. However, we were only installing it in order to install
chromedriver, which we don't do since commit 59b625a5f, so we don't need
it anymore.
Other packages depend on jQuery, so that's why these are the first one
we move from the Gemfile to the package.json file.
This way we can also test whether dependabot correctly opens pull
requests to update Node packages.
I've tried several configuration options for the asset pipeline in order
to be able to include images referenced in jQuery UI CSS files. So far,
adding the `node_modules/jquery-ui/themes/base` folder to the assets
paths is the only way I've found to make it work. Hopefully we can find
a better solution in the future so we don't have to study the internals
of every Node package in order to integrate it with the assets pipeline.
Note that, even if we're excluding the `node_modules/` folder from
version control, we aren't adding it to Capistrano's shared folders
because, when `node_modules` is a symbolic link, NPM removes it when
running `npm install`.
