Using a field with `type="tel"` causes most mobile phone browsers to
show a numeric keyboard which makes it easy to enter phone numbers.
We aren't using a number field because some browsers show "spinners" to
increment/decrement numbers (which doesn't make much sense in a phone
number) and because they don't allow characters like spaces. Phone
numbers can have characters like spaces, dashes, parenthesis, asterisks,
the plus sign, ...
Since phone number formats vary depending on the region, and sometimes
even within the same region several different formats can be used, for
now we aren't offering any kind of format validation. We could offer a
format validation that rejects just letters (although there are cases
where letters are actually allowed). However, this causes issues at both
the server side and the client side.
We could use a client-side validation adding a `pattern` attribute to
the field, but that would be something unlike anything else we use in
the application, and we would need to to write some JavaScript in order
to use a proper error message.
On the other hand, if we add a server-side validation, we might find out
existing users are invalid, and it would be impossible to update them in
the many places where we update users assuming they were valid in the
first place. We'd have to add a rake task to update existing user
records and make sure they contain a valid phone number or create a
setting so this validation only applies to new CONSUL installations.
Another option would be to add a per-form validation, so the phone
number is only validated in pages where it is introduced.
All the mentioned scenarios offer certain complexities. So, for now,
we're keeping things simple.
Co-Authored-By: decabeza <alberto@decabeza.es>
Now that we also have the "go back to CONSUL" link, the layouts are so
similar that it isn't worth it maintaining both of them separately.
With this change, people using small screens also get the "menu" button
in the management section, just like they do everywhere else.
We're adding the `namespace != "management"` condition so the menu still
shows up in the officing namespace.
Originally there was a link pointing to the FAQ page but it was removed
in commit e14b7b67fb because by default the FAQ page in CONSUL only
contains a placeholder text.
We aren't sure where this link should point:
* FAQ page, only if the FAQ page is published
* Help page, only when the help feature is enabled
* CONSUL technical documentation page
So, for now, we're choosing the easiest solution which is removing the
text completely.
The `commentable_url` method wasn't updated when we added legislation
proposals.
Back when we first created this method, we couldn't pass budget
investments or topics directly to `polymorphic_url` because they are
nested resources. That isn't the case since commit ff93f5a59, so now we
can simplify this method.
We're keeping the `commentable_url` method for now in order to keep
compatibility with custom changes that might use it, although this
method isn't consistent with the `commentable_path` method (which
receives a comment, and not a commentable), and so we might have to
revisit this code in the future.
So now:
* In the first few phases, no filters are shown (just like before)
* During the valuation phase, we show "Active" and "Unfeasible"
* During the final voting, we show "Active" (which now refers to the
selected investments), "Not selected for the final voting" and
"Unfeasible"
* When the budget is finished, we show "Winners", "Not selected for the
final voting" and "Unfeasible"
Now each investment is shown in one (and only one) of the filters
(except when the budget is finished; in this case we don't show selected
investments which didn't win), and we remove the confusing "Not
unfeasible" filter by only showing it during the valuation phase (before
filters are selected) and renaming it to "Active". We also rearrange the
filters so the default one for each phase is shown first.
The idea of using the "Active" text for investments which can be
selected during the selection phase and voted during the final voting is
experimental. Right now, for simplicity, since we assume filters will
always use the same text, we're removing the "Active" filter when the
budget is finished, since having both "Winners" and "Active" filters
would be confusing.
As mentioned in commit 36d795f69, investment filters aren't that
important; actually, most citizens won't use them at all, and are there
mainly for transparency purposes.
So we're moving them to the bottom of the sidebar, just like the links
for selected/archived/retired proposals in the proposals section.
In commit 5a4921a1a we replaced `URI.parse` with `URI.open` due to some
issues during our tests with S3.
However, there are some security issues with `URI.open` [1], since it
might allow some users to execute code on the server.
So we're using `URI.parse#open` instead.
[1] https://docs.rubocop.org/rubocop/cops_security.html#securityopen
I'm not sure whether it now looks worse on extra large screens, but I'm
positive it looks much better on medium and large screens, particularly
when investments have images.
We're starting to use buttons instead of submit inputs where possible
because buttons are easier to style; for instance, buttons allow
pseudoelements. Rails has also changed the `button_to` helper to always
generate a <button> tag in recent versions [1].
In this case, buttons get on better with flex layouts, since by default
some browsers display submit inputs with `white-space: pre`, meaning
some of the text isn't visible on small screens.
[1] See pull request 40747 in https://github.com/rails/rails
Placeholders are hard to read due to their low contrast, and users might
want to read them after they're already gone, and so they cause both
accessibility and usability issues.
The link to "See all investments" didn't have the `heading_id`
parameter, which resulted in the ballot information not being displayed
when in the voting phase.
We could modify the link to include the `heading_id` parameter, but IMHO
it's more robust to select the heading automatically when there's only
one heading. That way manually accessing the page without a `heading_id`
parameter will still work as if the heading had been selected.
There's no real point in linking to a page offering users to choose a
heading when there's only one heading to choose.
So we're linking to the investments index instead.
The interface was a bit confusing, since after clicking on "See
unfeasible investments" (or similar), we were on a page where no
investments were shown.
Besides, since commit 7e3dd47d5, the group page is only linked from the
"my ballot" page, through a link inviting the user to vote in that
group, and it's only possible to vote selected investments (which is the
default filter during the final voting phase).
The only reason we had these links here was these links weren't present
in the investments page. But they're present there since commit
04605d5d5, so we don't need them in the group page anymore.
Before the "valuating" phase, all investments have undecided feasibility
and none have been selected, so the filters would return no results
(except the "not_unfeasible" one, which would return everything).
We removed it in commit c322b2c4a because it was hard to know the
difference between "Feasible" and "Not unfeasible". We're renaming the
"Not unfeasible" filter instead.
We're also moving the "selected" filter so it appears before the
"unselected" filter, just like the "feasible" filter appears before the
"unfeasible" filter.
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.
Many CONSUL installations struggle when trying to define their own
settings or trying to overwrite the default ones. Particularly because
tests assume the default settings are used, so changing them breaks the
test suite in many cases.
So we're adding a custom setting model in order to make it easier to
change the default settings and define new ones, while making sure doing
so won't break the tests.
While these settings can also be changed by administrators, defining
custom settings in the code is useful in come cases. For example, when
certain default settings have been decided while using staging
environments and there's interest in using the same settings on
production, when institutions would like to use the same custom settings
across several CONSUL installations, or (when we implement multitenancy)
when defining the same default settings for each new tenant.
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.
The "enabled" column was aligned to the center, which looked weird when
seen on small screens because the `table-for-mobile` class (which I
think was added by accident) shows `th` and `td` elements using
`display: block`. Besides, using `display: block` on these elements
means browsers don't identify them as table headings/cells anymore,
causing accessibility issues.
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")
There was an edge case where we could access the headings index without
sending the mode parameter in the URL. That meant when sending the
headings form we could send a form with the mode hidden field set to an
empty string. When that happened, the returned text was
`t("admin.budgets.help.#{i18n_namespace}.`, which returned a hash.
Using `multiple` when an empty strin is received solves the issue.
Since the message might appear several times on the same page, it's
useful to give a bit more context. Besides, usability tests show that
when there's a group with no headings, there's no clear indication on
the page that the group is actually a group and not a heading.
We're also adding some emphasis to the group name in the "Showing
headings" message, to be consistent with the emphasis we've
added the the group name in the "No headings" message.
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 population field is optional and only used for statistic purposes,
and the content block feature is also secondary, so IMHO it's OK if we
don't display it in the index; if administrators need this information,
they can see it by going to the "edit heading" page.
With this change it's easier to navigate the table on small and medium
screens. Actually, the whole page is easier to navigate, since we
greatly reduce the cases where a horizontal scrollbar is present.
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.
