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
We were executing SQL queries searching for translations even for
records which were not persisted in the database and therefore had no
translations.
So we're now only looking for translations when the record is persisted.
Note that, when the record isn't persisted, we're using `I18n.translate`
instead of the `t` method. That's because the `t` method would also
perform database queries since we overwrite the `t` method in the
`i18n_translation` initializer.
On tabs with many records, like the proposals tab, requests are now up
to three times faster on production environments.
Tests related to this part of the application were failing sometimes
because requests took longer than `Capybara.default_max_wait_time`.
After these changes, the custom information texts pages load about 30%
faster when running the tests.
This way it's easier to test; changing it will also be easier.
During my experiments I made a mistake which wasn't covered by the test
suite. We're adding a test for this case.
Note we're using `i18n_content` in the component instead of `content`
because there's already a `content` method provided by ViewComponent.
When we try to register with omniauth and the email or username already exists,
we use the finish_signup and do_finish_signup actions to allow the user to choose
another email or username.
The do_finish_signup action of the registration controller calls the
send_oauth_confirmation_instructions method which is responsible for sending the
confirmation email.
In this method we were only validating the case that the email is duplicated. Now
we add one more condition that allows us to send the instructions for the case in
which we have had to change our username.
We weren't showing the details of answers without a description, even if
they had images, videos or documents. Some users found that behavior
unexpected since the description isn't a mandatory field and so they
left it blank, but they added images to that answer and they didn't
appear on the poll page.
Note we had a condition not to show the title of an answer when it had
no description. I think that condition was redundant because answers
without a description weren't loaded in the first place. Anyway, that
condition doesn't make sense anymore because we're displaying answers
with images but no description.
Adding the error to the translation means Rails will automatically show
the error message in the view.
We're also adding a test to make sure the error message is correctly
displayed.
We now have duplication in the validation rules, however. Validating
translatable attributes is still a bit of mess.
As mentioned in commit b7f6c4c43:
> [In Internet Explorer] the `flex: 1` property doesn't work so well
> when `flex-direction` is set to `column`. We're replacing it with
> `flex-grow: 1`. No need to set other `flex-basis` nor `flex-shrink`
> since in this case the default values will work just fine.
We were already doing so for debates and investments.
We probably never noticed because this is an edge case that requires
enabling a feature, people adding comments, and then disabling the
feature.
It could be argued that seeing which proposals a user follows is a good
indicator of which proposals a user has supported, since we're
automatically creating follows for supported proposals since commit
74fbde09f. So now, we're extending the `public_interests` funcionality,
so it only shows elements users are following if they've enabled it.
This is an improvement over using the `public_activity` attribute in two
ways:
* The `public_interests` attribute is disabled by default, so by default
other users won't be able to see what a user is following
* Who has created proposals/debates/investments/comments is public
information, while who is following which elements is not; so enabling
`public_activity` shouldn't imply potentially private information should
be displayed as well
We've considered removing the `public_interests` attribute completely
and just hiding the "following" page for everyone except its owner, but
keeping it provides more compatibility with existing installations.
We had similar conditions many times and some duplication, particularly
between the code getting records and the code counting records. We can
remove it by returning a generic scope and calling the `count` method to
count the records and the `order` and `page` methods when we want to
pass the records to the view. And, since we only display one partial per
request, we can simplify the code to render all the partials. There's
one minor disadvantage to this approach: searching the code for the
place where these partials are rendered is now a bit harder since
searching the code for something like "render (.+) budget_investments"
won't return any results.
We're also writing conditions about a certain filter just once, by
setting `valid_filters`. This greatly simplifies the logic, although
again there's one minor disadvantage: we have to implement the
`current_filter` method, duplicating the logic already defined in the
`HasFilters` concern.
Its value is difficult to read due to the low contrast between the color
of the field and the color of the placeholder text, and we already have
the same information in the hint above it.
Since targets didn't have a title but only a long description, every
form allowing to select targets was pretty much unusable: we either
displayed just the code or the whole description.
Now, with a concise title, it's easier to find and select the desired
target.
The titles have been copied from The Global Goals page [1].
Note we're using the `short_title` I18n key for the `title` method and
the `long_title` I18n key for the `long_title` method. We can't use
`title` as I18n key instead of `short_title` because it would affect
existing translations.
[1] https://www.globalgoals.org/
The same way we don't render empty regular tags since commit 4d27bbeba.
This way we avoid adding an empty `<div class="sdg-tag-list">` tag,
which might have associated styles (in custom CONSUL installation
styles, for instance) and thus break the layout
The icons were a bit hard to click on small screens, even for people
without any motion disabilities.
We might increase the size or the space between icons again in the
future; right now it's hard for users with certain motion disabilities
to click on the right icon.
Coincidentally, the minimum size of the icon is now barely over the 44px
established as minimum required size by the WCAG guideline 2.5.5 (level
AAA) [1].
Also coincidentally, at a screen 320px wide (the minimum screen size we
support), six icons appear on each row, just like in the UN logo.
[1] https://www.w3.org/TR/WCAG21/#target-size
SVG files are smaller than PNG files, can be compressed, and are
scalable.
We're choosing to render SVG files as images instead of inline because
inline SVGs aren't cached nor compressed, and they might appear several
times on the same page, making the generated HTML much larger.
We could also load them with an SVG sprite, using `<use>`, which would
reduce the number of HTTP requests when several icons are present on the
page (like in the index of most sections). However, using SVG inside an
`<img>` tag is universally supported, while the `<use>` tag doesn't
work in Internet Explorer when using an external URI and support in
Opera Mini and UC Browser is unknown.
We didn't enable it by default in commit 676adfcb3 so existing
installations didn't suddenly get a new section without expecting it.
But since the setting already exists for installations using version
CONSUL 1.3, now it will only be enabled for new installations.
On very large screens, the admin menu had a lot of blank space for
languages where all sections had short names (like English). This was
inconvenient because the icon to open a submenu was far from its
associated menu item.
Using the `max-content` value for the `max-width` property, we reduce
the amount of blank space in these cases.
Since the icon was absolutely positioned, in some languages it
overlapped with the text.
Using a flex layout solves this issue. It also improves the appearance
of elements whose text spans over multiple lines; previously the second
line would go under their section icon.
We're also using the `$global-left` variable so the icon is properly
displayed in languages written from right to left. We could use the
`margin-inline-start` property instead, but it isn't universally
supported in every browser yet.
Since the layout is now incompatible with the old (and obsolete) way to
add icons to the menu (using classes which would use the
`[class^="icon-"]` selector), we're removing this code.
When items went over multiple lines, the distance between their lines
was the same as the distance between one element and another one. This
made it hard to differentiate how many elements there were.
Using a padding to separate the contents of one element and the contents
of the next one solves the issue.
We were having issues with cached attachments and external services.
A `Tempfile` is returned by `URI.open` when using S3, so we're dealing
with this case as well.
In order to migrate existing files from Paperclip to ActiveStorage, we
need Paperclip to find out the files associated to existing database
records. So we can't simply replace Paperclip with ActiveStorage.
That's why it's usually recommended [1] to first run the migration and
then replace Paperclip with ActiveStorage using two consecutive
deployments.
However, in our case we can't rely on two consecutive deployments
because we have to make an easy process so existing CONSUL installations
don't run into any issues. We can't just release version 1.4.0 and 1.5.0
and day and ask everyone to upgrade twice on the same day.
Instead, we're following a different plan:
* We're going to provide a Rake task (which will require Paperclip) to
migrate existing files
* We still use Paperclip to generate link and image tags
* New files are handled using both Paperclip and ActiveStorage; that
way, when we make the switch, we won't have to migrate them, and in
the meantime they'll be accessible thanks to Paperclip
* After we make the switch, we'll update the `name` column in the active
storage attachments tables in order to remove the `storage_` prefix
Regarding our handling of new files, the exception are cached
attachments. Since those attachments are temporary files used while
submitting a form and we have to delete them afterwards, we're only
handling them with Paperclip. We'll handle these ones in version 1.5.0.
Note the task creating the dev seeds was failing after these changes
with an `ActiveStorage::IntegrityError` exception because we were
opening some files without closing them. If the same file was attached
twice, it failed the second time.
We're solving it by closing the files with `File.open` and a block. Even
though we didn't get any errors, we're doing the same thing in the
`Attachable` concern because it's a good practice to close files after
we're done with them.
Also note we have to change the CKEditor Active Storage code so it's
compatible with Paperclip. In this case, I haven't been able to write a
test to confirm the attachment exists; I was getting the same
`ActiveStorage::IntegrityError` mentioned above.
Finally, we're updating the site customization image controller to use
`update` so the image and the attachment are updated within the same
transaction. This is also what we do in most controllers.
[1] https://www.youtube.com/watch?v=tZ_WNUytO9o
These fields have no label associated to them. While it's more or less
obvious for sighted users that these fields are associated with the
table cell next to them, visually impaired users might not get that
association when using the screen reader in forms mode.
Note we're using `aria-label` instead of `aria-labelledby`. IMHO in this
case `aria-labelledby` is the superior method because it guarantees the
text is present for both sighted and visually impaired users. However,
testing for fields with no label other than the one provided by
`aria-labelledby` is hard since Capybara has no support for this
attribute.
So we're using `aria-label` and testing the presence of the text on the
page (with the `within "tr", text:` statements) as well as the ARIA
label (with the `fill_in` statements).
Having to wait for a whole page refresh after updating each setting was
painful when modifying several settings.
Even though the navigation is updated immediately to reflect which
sections have been enabled/disabled, there's one gotcha. Changing the
"SDG" setting will not update the user menu (which contains a link to
SDG content) nor the "SDG Configuration" tab; refreshing the page will
be necessary to check these changes. The same happens with the map and
remote census tabs. So in these cases we're making an exception and
sending the form. We might find a better solution in the future.
For this reason, we aren't using the `switch` ARIA role. Some users
might not expect a switch control to refresh the page, just like they
usually don't expect checkboxes to refresh the page. Furthermore, screen
reader support for the `switch` role seems to be inconsistent. For
instance, NVDA with Chrome announces the control as a checkbox instead
of a switch.
Note AJAX is only used for feature settings. Other settings are still
updated with regular HTTP requests.
Since we're now using AJAX requests, we have to make sure to add an
expectation in the homepage tests in order to make sure the request has
finished before starting a new one.
We were using buttons with the "Enable" and "Disable" texts to
enable/disable settings. However, when machine learning settings were
introduced in commit 4d27bbeba, a switch control was introduced to
enable/disable them.
In order to keep the interface consistent, we're now using switch
controls in other sections where settings are enabled/disabled. We can
even use the same code in the machine learning settings as well.
We're also removing the confirmation dialog to enable/disable a setting,
since the dialog is really annoying when changing several settings and
this action can be undone immediately. The only setting which might need
a confirmation is the "Skip user verification" one; we might add it in
the future. Removing the confirmation here doesn't make things worse,
though; the "Are you sure?" confirmation dialog was also pretty useless
and users would most likely blindly accept it.
Note Capybara doesn't support finding a button by its `aria-labelledby`
atrribute. Ideally we'd write `click_button "Participatory budgeting"`
instead of `click_button "Yes"`, since from the user's point of view the
"Yes" or "No" texts aren't button labels but indicators of the status of
the setting. This makes the code a little brittle since tests would pass
even if the element referenced by `aria-labelledby` didn't exist.
