Mainly start section.

More often than not, multiple elections take place at the same time or voters have multiple voices in the same election (e.g. one for a party and one for a candidate). In cases where those "types" can be asked the same questions, it makes sense to consolidate them in the same election compass. Otherwise users would have to either a) use two election compasses with the same questions or b) receive results of mixed types. To improve this situation, party "types" should be introduced.

Implementation

• Add party types as a top-level configuration option besides parties, theses, etc.
  • Types should have a singular, a plural and an alias (slug)
  • Types should be optional
• Add support for types to the configuration editor
  • It should be possible to add multiple types, before adding parties
  • If there are any types set, a party needs to have a type
• Document the changes to the configuration file format
• Add support for types in the client
  • The party store should store types
  • The party store should return a list of parties by type
  • The party section should show parties by type, if any
  • The party section should allow selection of all parties of a given type
  • The match section should display results by type, if any
  • The match section should display positions by type, if any
  • The match section should only display the positions of the first X parties by default

To improve discoverability of parties, the match section should show the results of all parties while still highlighting the results of the selected parties. This behavior should not be extended to the positions, however. It would also be helpful to be able to quickly select parties from the list of results.

When parties decide to not participate, it should be possible to at least add them as an "empty" option. And provide some context as to why they didn't participate.

Because that would be way more semantic and maybe even more accessible. It was stupid not to do this in the first place.

Add footer to the bottom of the page.

This should come with a safeguard. A minimum limit or maybe a way to visualize the impact.

See: https://spectrum.chat/openelectioncompass/org-support/kreistag-und-stadtrat~9313e951-7a73-4168-9a7b-7cca938b9a4e

Maybe integrate it with the configurator?

Allow users to generate links that can be shared with friends for combinated results.

When selecting a locale that is not supported by OEC, in most places, it falls back to the English language as expected. However, the green guide buttons that usually appears at the bottom of several sections is no longer shown in this case.

To fight user laziness and allow for a more customized experience, the OpenElectionCompass should support sorting theses in categories.

There is always at least one implicit category, the required category. Theses in this category will be asked first and it is required to answer them. After these, if more categories (e.g. 'Environment', 'Education', 'International Affairs', 'European Union', etc) are present, the user will be asked to either choose the next category or proceed to the next section (selection of the parties). A user can choose to answer as many categories as he/*/she likes.

This feature will allow use cases where it is desireable for "lazy" users to be able to move to the results more quickly, while at the same time give users the choice to customize their selection fo theses to their personal interests.

Implementation

• Add categories as a top-level configuration option besides parties, theses, etc.
  • Categories should have a name, an alias (slug) and an optional emoticon (unicode character)
  • Categories should be optional.
• Add support for categories to the configuration editor
  • It should be possible to add multiple categories, after adding parties and before adding theses
  • It should be possible to add a thesis to multiple categories using a select field
  • A thesis with no categories selected implicitly belongs to the default (required) category
• Document the changes to the configuration file format
• Add support for categories in the client
  • The thesis store should store the selected categories in order of selection and allow mutation accordingly
  • The thesis store should return a list of theses, based on the selected categories and in the order of selection, but always with the default category
  • The thesis store should have a boolean value called done
  • The thesis section should be adapted to be able to ask questions in between theses
  • The thesis section should contain a component to be inserted at the end when there are more theses that could be answered, given that the user chooses a category that contains them
    • This component should render a short explanation and the categories as a list of buttons, as well as an option to proceed to the next section (selection of parties)
    • The categories that have been chosen or only contain theses that have been answered should be disabled, slightly transparent and greyed
    • Clicking on such a button will select the category and thereby automatically add it's theses to the list of available theses and make the component disappear
    • Clicking the button to proceed to the next section will set the done flag in the theses store which will allow the user to proceed to the next section
  • The statement component should display the (first, custom) category a thesis belongs to as a badge with the emoticon in place of an font-icon
  • The main navigation component should display all theses of selected categories in the correct order
  • The GuideButton should continue to work as expected

Optionally

• The Match component should be able to display the results differently when not all theses have been answered
  • The theses store should calculate not only the result of every party, but also (given that not all theses/categories have been answered), the maximum number of points (and percentage) a party could have lost or gained had more theses been answered
  • Instead of the simple bar chart, a box plot like visualization should be used. This will render a white area from the minimum to the maximum number of points a party could have had. The text will show the actual percentage with an added "+/- X %"
  • Below the normal results will be another chart that shows the "winners" and "losers" in every category selected, i.e. the parties with the most loss/gain of points in the respective category
  • Should contain a button that opens the category selection again to improve the accuracy of the results by answering more theses

Makes it easier to add more languages and will also allow for other use cases.

Idea: https://spectrum.chat/openelectioncompass/tech-support/erklarung-fur-statements~da11f23d-d409-4f8b-8956-ec4511a9938c

Highlight words in theses and provide short explanations on tap / hover with a short character limit.

Some elections have parties, some candidates and some both.

Random collection of relevant design inspiration.

• raise awareness
• talk to people
• organize election parties
• et cetera

• What is the difference between neutral and skip?
• How are the results calculated?
• In what order do the parties appear?
• In what order do the statements appear?
• About OpenElectionCompass

Fix flash of unstyled content and implement two modes:

• button / modal mode
• no button / instant full viewport mode

• Generate posters as PDFs
• Generate PNGs for social media marketing

In that case all parties will automatically be selected for comparison.

What would be needed, so that the OEC can also be used to match users to things like: sport clubs, volunteering, group activities, charity, etc.?

• More customizability for colors, shapes, icons, etc. #30
• Make party selection optional #33
• Terms like "theses" and "parties" need to be customizable #35
• Explanatory texts need to be customizable #35
• The matching results need to shift focus from percentage to rank
• Possibly combine result and comparison section – statements to every question ("thesis") is most likely not needed in this scenario
• Groups ("parties") need more possibilities to represent themselves, like pictures, contact details and links
• Footer needs to be adapted
• Dedicated matching algorithm (mostly for appropriate buttons)