summaryrefslogtreecommitdiffstats
path: root/wiki/src/blueprint/support_page.mdwn
diff options
context:
space:
mode:
authorsajolida <sajolida@pimienta.org>2017-12-28 01:22:35 +0000
committersajolida <sajolida@pimienta.org>2017-12-28 01:22:35 +0000
commitcac905b69b97ce74ac70e30774e03552abba16d0 (patch)
tree4437e1047e84851a7ba209d7f8770ffdfe39d1c0 /wiki/src/blueprint/support_page.mdwn
parentd1e9650c4b5ab9a0030ebe5ea387f0956def733e (diff)
Add blueprint about restructuring our support page
Diffstat (limited to 'wiki/src/blueprint/support_page.mdwn')
-rw-r--r--wiki/src/blueprint/support_page.mdwn157
1 files changed, 157 insertions, 0 deletions
diff --git a/wiki/src/blueprint/support_page.mdwn b/wiki/src/blueprint/support_page.mdwn
new file mode 100644
index 0000000..5b263e8
--- /dev/null
+++ b/wiki/src/blueprint/support_page.mdwn
@@ -0,0 +1,157 @@
+[[!meta title="Restructure our support page"]]
+
+Parent ticket: [[!tails_ticket 15130]]
+
+Current problems
+================
+
+- 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_ticket 14548]]), the person would
+ have gone to:
+
+ 1. FAQ: which wouldn't help
+ 2. Chat: which would have been very complicated to setup and might
+ not have helped
+ 3. 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.
+
+Ideas
+=====
+
+- Restructure the page to help differently people who either cannot
+ start Tails or are in Tails already.
+
+ - Split [[!tails_gitweb wiki/src/support/known_issues.mdwn]] into two:
+
+ - Issues that prevent Tails from starting: [[!tails_gitweb
+ wiki/src/support/known_issues/starting.mdwn]] [1]
+ - Issues that don't: [[!tails_gitweb
+ wiki/src/support/known_issues.mdwn]] [2]
+ - Cross-reference these two pages
+
+Troubles starting Tails
+-----------------------
+
+- Create a page dedicated to issues starting Tails and link it from
+ [[!tails_gitweb wiki/src/support.mdwn]]:
+
+ - Inline troubleshooting sections from the installation instructions
+ - List or inline known issues that prevent Tails from starting [1]
+
+Troubles inside Tails
+---------------------
+
+- Improve a bit the upgrade instructions "*Make sure you are using the
+ latest version*".
+
+ Like we're doing on [[!tails_gitweb
+ 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: [[!tails_gitweb
+ 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:
+
+ 1. Review the issues from the latest version and see if they are
+ still relevant.
+ 2. Create an empty file for the next version, copying parts from the
+ previous version whenever relevant.
+ 3. Update /support to inline the file for the next version.
+
+- List or point to known issues that don't prevent Tails from starting [2]
+
+- 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 ([[!tails_gitweb
+ 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.
+
+- Move "Report an error" as a option to contact 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?
+
+- Improve instructions to connect to the chat
+
+ - Do we really want to advertise the chat that much?
+ - Do we want to make it less visible until it's easy to connect and
+ get answers?
+ - Is the chat helpful for people who can't start Tails? They would
+ have to install XMPP!
+
+Next steps
+==========
+
+* 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