We use order links in many places in the web. However, in the comments section and the list of community topics, we were displaying a `<select>` element, and changing the location when users select an option. This has several disadvantages. First, and most important, it's terrible for keyboard users. `<select>` fields allow using the arrow keys to navigate through their options, and typing a letter will select the first option starting with that letter. This will trigger the "change" event and so users will navigate through a new page while they were probably just checking the available options [1]. For these reasons, WCAG Success Criterion 3.2.2 [2] states: > Changing the setting of any user interface component does not > automatically cause a change of context unless the user has been > advised of the behavior before using the component. Second, the form didn't have a submit button. This might confuse screen reader users, who might not know how that form is supposed to be submitted. Finally, dropdowns have usability issues of their own [3], particularly on mobile phones [4] The easiest solution is to use the same links we generally use to allow users select an order, so using them here we make the user experience more consistent. They offer one disadvantage, though; on small screens and certain languages, these links might take too much space and not look that great. This issue affects pretty much every place where we use order or filter links, so we might revisit it in the future. Note we're moving the links to order comments after the form to add a new comment. In my opinion, having an element such as a form to add a new comment between the element to select the desired order of the comments and the comments themselves is a bit confusing. [1] https://webaim.org/techniques/forms/controls#javascript [2] https://www.w3.org/WAI/WCAG21/Understanding/on-input.html [3] https://www.youtube.com/watch?v=CUkMCQR4TpY [4] https://www.lukew.com/ff/entry.asp?1950
CONSUL
Citizen Participation and Open Government Application
This is the opensource code repository of the eParticipation website CONSUL, originally developed for the Madrid City government eParticipation website
Documentation
Check the ongoing documentation at https://docs.consulproject.org to learn more about how to start your own CONSUL fork, install it, customize it and learn to use it from an administrator/maintainer perspective.
CONSUL Project main website
You can access the main website of the project at http://consulproject.org where you can find documentation about the use of the platform, videos, and links to the community space.
Configuration for development and test environments
NOTE: For more detailed instructions check the docs
Prerequisites: install git, Ruby 2.6.7, CMake, pkg-config, shared-mime-info, Node.js and PostgreSQL (>=9.5).
git clone https://github.com/consul/consul.git
cd consul
bundle install
cp config/database.yml.example config/database.yml
cp config/secrets.yml.example config/secrets.yml
bin/rake db:create
bin/rake db:migrate
bin/rake db:dev_seed
RAILS_ENV=test rake db:setup
Run the app locally:
bin/rails s
Run the tests with:
bin/rspec
You can use the default admin user from the seeds file:
user: admin@consul.dev pass: 12345678
But for some actions like voting, you will need a verified user, the seeds file also includes one:
user: verified@consul.dev pass: 12345678
Configuration for production environments
See installer
Current state
Development started on 2015 July 15th. Code was deployed to production on 2015 september 7th to decide.madrid.es. Since then new features are added often. You can take a look at the current features at the project's website and future features at the Roadmap and open issues list.
License
Code published under AFFERO GPL v3 (see LICENSE-AGPLv3.txt)
Contributions
See CONTRIBUTING.md
