title: Restructure our support page
Parent ticket: tails#15130
Some support channels are put forward too much and might not be helpful for the average user seeking help (training organization, Redmine, feature request)
The difference between our different support content is not clear enough (known issues, documentation, FAQ).
During the expert review (tails#14548), the person would have gone to:
- FAQ: which wouldn't help
- Chat: which would have been very complicated to setup and might not have helped
- Email: which would have helped
But she should instead have been pointed to:
- Better troubleshooting instructions for Mac
- Known issues on Mac hardware
Our support page is a hub that points to other support content but currently the user has to change page and scan each one of them. Instead our support page should help people know which support content will solve their issue, without trial and error.
Some requests are very frequent on our help desk (and they change over time). Our support page should help filter these frequent issues quickly.
Issues for the current release are only listed in the release notes, which is probably not where people facing these issues would look for.
Restructure the page to help differently people who either cannot start Tails or are in Tails already.
Troubles starting Tails
- Inline troubleshooting sections from the installation instructions
- List or inline known issues that prevent Tails from starting 
Troubles inside Tails
Improve a bit the upgrade instructions "Make sure you are using the latest version".
Like we're doing on wiki/src/install/inc/steps/verify up-to-date.inline.mdwn
List hot topics on help desk
The help desk could maintain a list of the most popular issues reported, for example updating it after each shift (two weeks).
This list would be:
- Inlined on the support page
- Copied in the monthly reports
Inline issues from latest release
We could have inline files listing issues for each release.
For example: wiki/src/news/version 3.3/issues.inline.mdwn
This file would be inlined from both:
- The support page
- The release notes for this version
When writing the release notes for a new version:
- Review the issues from the latest version and see if they are still relevant.
- Create an empty file for the next version, copying parts from the previous version whenever relevant.
- Update /support to inline the file for the next version.
List or point to known issues that don't prevent Tails from starting 
Embed more information about the documentation in the support page
We could reuse the index pages that we already have for the different documentation sections (wiki/src/doc/first steps.index.mdwn) and display them in accordions (toggles).
See how Chrome does that: https://support.google.com/chrome/?topic=7438008
Link to FAQ after documentation and explain what kind of information is in there
Our FAQ almost exclusively contains general interest questions that are not about how to start Tails or issues affecting Tails. All-in-all, they should be way less relevant to people visit the support page than our known issues and documentation.
Contact and misc
Decide what to do with training organizations
Ask the organizations if they are being contacted for support and, if so, find out what issues are being reported.
Rephrase and restructure Redmine and feature requests for a technical audience only
The support page currently refers users to Redmine to find out if an issue is already known which is probably a dead end for less technical users.
Advertise "Report an error" as a option to contact us
Right now, it is advertised outside of the ways to "get in touch with us".
Could we go even further and say that people who cannot start Tails should write us an email and people who can start Tails should send us a WhisperBack report?
Remove the instructions to connect to the chat
There is very little happening on the chat actually. Very few users with a good understanding of Tails help others. Most core Tails people connect either rarely or never.
Make it less visible until it's easy to connect and get answers?
- Ask feedback from:
- Help desk
- Expert who did the review
- Release managers
- Create wireframes of the final page
- Organize incremental work to implement all this