Outreachy: Improve user guide documentation for Wagtail

[thibaudcolas]

🚧 This project idea is part of Wagtail’s participation in the Outreachy December 2022 cohort. We are sharing this publicly for everyone’s awareness, and to solicit feedback / questions / comments.

As a CMS, Wagtail features a very polished administration interface with lots of content management features, which we’re very proud of. Unfortunately our "editor guide" documentation for users hasn’t kept up with our more recent overhauls of the CMS. The documentation is there, it’s technically up-to-date, but it only covers parts of the features, and it could use a good refresh. We could use some help!

The main goal of the project will be to revamp our user guide documentation, which we’ve recently transferred onto a new site for ease of management. This would involve getting familiar with the CMS, liaising with our existing documentation authors, planning new content as well as rewrites of existing content. By the end of the project, we would ideally have produced a comprehensive user guide with didactic information about most / all features of the CMS.

Depending on the candidate’s interests and skillset, we’re also interested in considering one or multiple secondary goals:

• Translate the documentation into other languages – either doing the translation yourself, or coordinating with our existing translators.
• Introduce documentation directly in the CMS ("onboarding tour guide"), rather than only as a separate site
• Produce video content for documentation purposes. This could be either guided tutorials / how-to guide, or high-level "video tours" of major features.
• Improve our process for keeping documentation up to date, by making changes to the website or introducing more advanced tooling. This could for example involve automated screenshot taking, or CMS features to mark content as needing rework.

[phorlachady]

I look forward to working on this with you

[jadesola123]

Awesome, looking forward to contributing to this project🚀

[Quinterlozi]

Hey everyone lookin foward to participating in this project

[akotosheila28]

Great project, I look forward to make contributions.

[dameeolawuyi]

I noticed that an introduction paragraph (explaining what wagtail is about) seems to be omitted from the documentation index page, I would like to know if this was intentional or if I can come up with one.

Also, I am suggesting blog content on all of the new wagtail features OR everything one can do with Wagtail which can be added as an external link in the actual documentation. I would like to know if these are valid suggestions.

[DokuaAsiedu]

These are some suggestions I have for the Tutorials Section

• On the Getting Started page, I think it will enhance user experience if the hover state of the mouse when on the Getting Started button could become a pointer or maybe the background color of the button itself could change. Looks like the same issue exists on different pages with buttons that go to the next and previous page.
• Following the Diátaxis structure, on the Getting Started page, could this statement:
  "This guide is a collection of tutorials, how-to articles, reference guides, and walkthroughs that will help you ....."
  be changed to:
  "This guide is a collection of tutorials, how-to articles, reference guides, and explanations that will help you ....."
• This suggestion applies to all the other pages: I think it will help the layout of the page if the in-page navigation links were positioned on the right hand portion of the page. It will reduce the amount of scrolling the user will have to do when trying to jump to different sections of the page.
• Something that can apply to all pages is providing captions for all images

[VictoriaAjala]

@DokuaAsiedu could you update the links in your suggestion, I think a new site has been deployed and the old links are now offline.

[DokuaAsiedu]

Suggestions for the "Finding your way Around Page"

• In the Note area of The dashboard section, this statement: "Editors will have a dashboard view that is" has been cut off. It looks like it was giving a breakdown of what the dashboard will look like for different user roles.
• In the Search section, this phrase: "quickly search" appears to be a dead link.
• There seems to be a typo in this statement: "Click the arrows to reach sub-sctions of your website." which is in the Pages section.
• Another incomplete statement: "Snippets are" in the Snippets section.
• In the Explore pages section, this statement:
  "Clicking on any action will take you to a separate view with all the selected pages, for confirmation"
  can be completed with:
  "to execute the selected action"
• In the Explore pages section, in order for this statement to make more sense, this bullet point:
  "Similar buttons are available for each child page. These are made visible on hover."
  should come after this point:
  "Clicking on the Actions dropdown will show a list of actions for the parent page, like Move, Copy, Delete, Unpublish, History...."

[thibaudcolas]

👋 I’m looking for ideas for contributions for Outreachy participants, specifically contributions to the site’s contents.

• Content additions that could be done with beginner to intermediate-level knowledge of Wagtail
• Ideally only based on the bakerydemo site as-is, or only basic improvements we could get done on their behalf.
• Also rewordings / improvements to existing content that are clear-cut (such as the ones suggested by @DokuaAsiedu above)
• They should ideally be reviewable in Google Docs or similar so we don’t need to give everyone access to the site’s backend

I’d like to make a list of about 10 "beginner" contributions, and ideally 5-10 at the intermediate to advanced level.

Please add any suggestions by replying to this thread!

---

Outreachy participants – – at this stage please don’t pick up any of those ideas yet. I will be assigning them to contributors myself, based on everyone’s expertise and interest, and only for people who are interested in our User Guide project and have completed the Documentation contributor checklist.

[thibaudcolas]

Edit – assigned to @activus-d

From @allcaps on Slack – once we’ve made a decision on the content license (#164), it’d be great to write a quick page or section of a page about licensing:

We might ask an Outreachy contributor to write about the licences and why we choose them. I think it is a good fit for the explanation section.

The goals for a licence:

1. Clear to the contributor, their content won't be owned. It will be in the public domain.
2. Liability and warrantee, we do not accept any responsibility.
3. Free as in freedom to do whatever and free as in gratis beer. Anyone is free to do anything with the content for gratis.

---

Personally I think it’d be interesting to cover the user guide’s content licensing, and also maybe explain Wagtail’s license.

[lb-]

Some thoughts

• We should provide a direct link to a Demo site where you can log in and use Wagtail, maybe the nightly but maybe something fixed at the latest version. Linking to the bakerydemo repo is not super helpful.
• We could use something like Google Chrome's Recorder feature to manage small videos that can get regenerated or shown to the user in an IFrame for some common tasks. https://developer.chrome.com/docs/devtools/recorder/reference/
• Deep dive into some of the more complex field types we use; choosers, StreamField, InlinePanel, Embeds (maybe in the references section)
• Small thing - ensure that the Mozilla docs gets a PR to link to this guide instead. Request that Mozilla's 'How do I Wagtail' updates their link to the user guide  #174 raised
• Rich Text how tos, line break, new paragraph, non breaking space
• How to view the history of a page, workflow or snippet, understanding the difference between history and revisions, reverting to a previous version, drafts vs live things
• Explanation of Bulk actions, using shift plus click, where it's used and what it's for
• Explanation - tags
• Explanation - Collections
• Explanation (or reference) - Django, Wagtail, CRX?, python, Headless - a high level stack overview but not too technical
• How to work out your current Wagtail version

Sorry if some of these are covered in other discussion items.

[thibaudcolas]

Content ideas from #105:

• How-to
  • New content: Wagtail forms how-to #94 Wagtail forms
  • New content: ModelAdmin how-to #96 ModelAdmin
  • New content: Groups how-to #98 Groups
  • New content: account profile & notifications how-to #99 Account profile & notifications
• Explanation
  • Accessibility
  • Glossary
• Reference
  • New content: scheduled publishing reference #95 Scheduled publishing
  • New content: permissions reference #104 Permissions
  • New content: Reports reference #97 Reports
  • Proposed Sites
  • Proposed Site settings
  • Proposed Popular packages’ docs

[activus-d]

Edit – assigned to @activus-d

From @allcaps on Slack – once we’ve made a decision on the content license (#164), it’d be great to write a quick page or section of a page about licensing:

We might ask an Outreachy contributor to write about the licences and why we choose them. I think it is a good fit for the explanation section.
The goals for a licence:

1. Clear to the contributor, their content won't be owned. It will be in the public domain.
2. Liability and warrantee, we do not accept any responsibility.
3. Free as in freedom to do whatever and free as in gratis beer. Anyone is free to do anything with the content for gratis.

Personally I think it’d be interesting to cover the user guide’s content licensing, and also maybe explain Wagtail’s license.

@lb- @thibaudcolas please review this:

Copyright licensing

There are no rights reserved for this user guide documentation. There are no explicit permission requirements for using, distributing, remixing, adapting or building on its content. All of it is in the public domain and may be used, distributed, remixed, adapted, and built upon for private and commercial purposes to the fullest extent permitted by law.

Licensing grounds

The content of this user guide is not restricted in accordance with the principles of open source. The purpose of this is to facilitate innovation and encourage open collaboration that is flexible.

Liabilities

The contributors to this user guide documentation assume no responsibility or liability for any damages resulting from errors or omissions in the content. All content in this user guide documentation is provided on an "as-is" basis and no guarantee is provided as to its completeness, accuracy, or timeliness.

[Dev-Liz]

User Guide Documentation Review

UX Review

• While on the documentation page for the first time, users should be able to know what page they are on (i.e, an active nav or a tab on the document landing page).

• There is not enough contrast between the color on the sidebar hover state and the page background. This could cause some accessibility issues for users.

• There's a little bit of inconsistency on which comes first between Explanation and Reference, on the landing page and on the sidebar.

• The side navigation can be improved to fit the height of the page without having to scroll through. This could be managed by grouping each sub-sections (e.g subsections for How-To) into accordions.

• The first navigation Tutorial, should be an accordion that houses every other Getting started navigation. That way, there wouldn't be any need for a dedicated tutorial page with content

• The getting started page should go straight to the point in taking the users through what they need to know without a lengthy introduction. Every other introduction should be covered on the documentation landing page.

• The landing page should contain a brief overview of what the users will accomplish using the guide, and an overview of each section.

• Getting started should have a good visual hierarchy, With:
  - A Getting started header
  - A subheading or metadata...giving a brief overview of what the user would achieve at the end of the getting started guide.
  - Table of content
  - And finally, a step-by-step description, guiding the user on how the product works.

• Illustrations should be used to aid understanding and the content should be formatted for readability.

• Tutorial Content should be extensive for users to have a complete knowledge of what the product is about (without having to consult other resources), yet concise and straight to the point.

• The How to heading should be an accordion, grouping all its sub-navigations.

• Navigations on the how-to page should be more descriptive. example. Understanding wagtail's dashboard, instead of 'The dashboard.'

• Choose navigation names that go along with How-to e.g Find your way around instead of Finding your way around.

• White background images do not contrast well with the document background. The documentation page should have an off-white background for better contrast. Images with white backgrounds could be enhanced with shadows.

• How-to documentation could use steps or numbers to aid easy navigation. So the user can tell the difference between each step.

• Visual hierarchy should be rightly used.

Information Architechture

I don't think we have to explicitly use elements of the Diataxis framework as names for the side navigation

Suggested Navigations/Topics

Landing page (first-page user arrives on the documentation page)

• Brief overview of wagtail
• Featured elements of the documentation

Getting started (Tutorials)

• Wagtail demo/Quickstart
• Prerequisite
• Installation
• Setting up wagtail
• My first wagtail website

How to/Guides (Can be categorized Into beginner/ Intermediate and Advanced)

• Set up a simple page with wagtail
• Add new pages to wagtail
• Collaborate on wagtail
• Customize admin dashboard
• Integrate wagtail with other projects
• Use wagtail for complex projects.

Learn about wagtail (Explanations)

• Wagtail Versions
• Language support
• Wagtail Features
• Wagtail as a CMS (for designers and content creators)
• Wagtail as a framework (For developers)
• Speeding up projects with wagtail

References

• (Glossary)
• (Integrations)
• (Versions)
• (Resources)
• (FAQs)

Horizontal navigation on the top part of the page, to guide the user, wouldn't be a bad idea.

I'd be happy to further design a prototype for this hierarchy if need be :)

[thibaudcolas]

@Dev-Liz nice one! No need to prototype this hierarchy at this time, but we’ll definitely do this later. I have updated the Explanation / Reference order, and credited you on our new About page.

If you want to provide feedback about the site’s appearance / UX, I would suggest creating issues. This discussion is specifically about the content.

[Dev-Liz]

Alright, noted! @thibaudcolas

[softkeldozy]

Some Suggestions on Improving the User guide Documentation

• The search button should have a cursor pointer enabled on hover.
• Also the dark mode and light mode should be enabled, providing room for preference and comfortability .
• There is a typo in the Getting started under the tutorial guide section just before The Wagtail demo site heading that needs to be addressed. This can be found in the third paragraph "different aspect of Wagtail" and not "different aspect Wagtail"
• For the unordered list under the images, there should be a descriptive text stating what the list is for rather than just going straight to list the steps.

[thibaudcolas]

👍 thank you @softkeldozy. All noted! If you want to provide further feedback about the site’s appearance / UX, I would suggest creating issues. This discussion is specifically about the content.

Good catch about the typo, I’ve fixed and credited you on our new About page.

For the unordered list under the images, there should be a descriptive text stating what the list is for rather than just going straight to list the steps.

Not sure I understand this one?

[softkeldozy]

For the unordered list under the images, there should be a descriptive text stating what the list is for rather than just going straight to list the steps.

I'm going to use a picture to illustrate what I mean

Just above the marked area I was proposing for a small caption about the process going on

[thibaudcolas]

Good point! I’ve made that change (at least a simple version of it).

[softkeldozy]

Proper Organization of User Guide Documentation

All of the documentations are over the place, also needing help too navigating to where they are. There should be a reference to all the documentation from a single page so a user can always come back to a central place when lost or confused

[thibaudcolas]

@softkeldozy do you mean like a sitemap? Right now all pages are visible from… all pages, in the side navigation, so I’m not sure I understand your point.

[softkeldozy]

Ok.
Just saw how it was referenced in the latest User Guide, which is what I was hoping for.
What I was talking about was having access to the Development Guide from the new User Guide

[thibaudcolas]

Ah I see! Got it. I’d be interested to see a draft of this if you’re up for that, perhaps as a new page under our "Reference" section? Feels similar to our wagtail.org Developers page where we list resources – we could definitely have something similar on this site, where we list a lot of different resources for users of Wagtail.

LB shared a list of existing guides here: #105 (reply in thread)

Perhaps in addition to our official resources, we could also make some space to list those third-party resources?

[softkeldozy]

Ah I see! Got it. I’d be interested to see a draft of this if you’re up for that, perhaps as a new page under our "Reference" section? Feels similar to our wagtail.org Developers page where we list resources – we could definitely have something similar on this site, where we list a lot of different resources for users of Wagtail.

LB shared a list of existing guides here: #105 (reply in thread)

Perhaps in addition to our official resources, we could also make some space to list those third-party resources?

@thibaudcolas I just replied in the thread

[activus-d]

Suggestions on the User Guide Documentation

1. The introductory content of some of the main sections of the documentation needs improvements (i.e Tutorials, How-to, Explanation and reference). They are either too short to be given a whole page or are not explanatory enough to indicate the purpose or scope of the sub-sections in them.
2. The Getting started sub-section of the documentation is not user-friendly, especially for persons using wagtail for the first time. One way to improve it is to maybe include a live version of the bakeryDemo on the page instead of an absolute link to GitHub (as suggested earlier by @lb- ). The instructions provided on the link/page for bakerydemo might be somewhat complicated for our audience here since we can safely assume most won't be developers.
3. The title and structure of the Tutorial section should be given a second thought. This is because there are really no tutorials in it (maybe there isn't an obvious complete tutorial). It can just be a one-page section titled Getting Started.
4. The UI and position of the search functionality should be given second thought. My opinion is that instead of an icon, it should be an input bar. The position should also be the centre of the page just before the language change functionality. Also, both functionalities should assume a fixed position at the top of the page to make them visible while scrolling the page.
5. I do not see the need to make the sample root URL/HOMEPAGE (www.example.com) a clickable link since it is not a valid URL or at least it is not indicative of anything related to wagtail. My suggestion here is that if a live version of the bakeryDemo is used for the guide, then its base URL should replace www.example.com otherwise www.example.com can just be highlighted but not made a clickable link.
6. The content of the Focal Area of the sub-section Managing Images should be improved. My opinion is that it should be a block content with paragraph(s) instead of a list and if using a list is preferred, then it should have an introductory or opening paragraph/sentence.
7. Apart from the Focal Area topic there are some other topics that have lists in them without having an opening or introductory paragraph. In my opinion, most of these topics do not require their content to be in a list format and in instances where using a list is more appropriate, then they should be preceded by an opening or introductory paragraph or sentence.

[thibaudcolas]

Thank you @activus-d, I like all those suggestions. For lists, and the "Getting started" page as a tutorial, this is very much due to how the content was when we added it to the site. I’d expect us to re-shuffle this quite a lot as part of the internship.

[marv-tech]

Introduction

The current Wagtail user guide documentation is based on the diátaxis framework and is divided into four key areas, as shown below.

• Tutorials
• How-to
• Explanation
• References

As the name indicates, the user is at the core of the content when developing user documentation, and the four modes of content allude to the types of contents that should be generated to suit the needs of the user, according to the diátaxis framework. I will be evaluating this documentation in consideration of the diátaxis framework's requirements, semantics, and general improvements.

Tutorials

Tutorials, according to the diátaxis, are intended to provide the user with basic knowledge. This implies that while producing wagtail lessons, one must presume that the consumers have no prior experience with wagtail. This part should cater to the demands of the users by delivering a step-by-step lesson and creating an experience that is free of abstraction.
Following an evaluation of the present material, this is what it lacks and what it should have based on the framework.

What is currently available	What it should include
No available tutorial (probably still in progress)	A step-by-step tutorial on logging into wagtail, creating a page, creating categories, adding images, uploading a document, etc.
Getting started page is a sub-page of tutorials	The contents of the getting started page are explanation-oriented and not simplified enough to be classified as tutorials. The getting started page should be a separate category that provides basic introductions on how people may get started. We might also divide it into several lessons, such as getting started with the wagtail demo site and signing in to the wagtail demo site.

How-to

The How-to section of a document is straightforward and solution-oriented. It concentrates on specific tasks, allowing this solution to be directly utilised at work. It has clear goals and does not necessitate explanations. After reviewing the existing how-to documentation here are my conclusions;

What is currently available	What it should include
Direct naming style	Naming conventions is an important part of how-to guides, this can be improved by busing titles that says exactly what the specific guide is expected to offer. For example "The Wagtail sidebar" can be rephrased as "How to use the Wagtail sidebar"
There are multiple sub-topics on one page	How-to's are solution-oriented, so they describe the problem and then move straight to the solution, making it faster and simpler to reach. For example, instead of this page comprising multiple sub-topics with extensive explanations, creating a simpler version incorporating annotated photos that explain "how to navigate your way around" in the simplest way possible will make it more accessible. Other sub-topics, such as photos, documents, reports, and settings, might be regarded as different guides with titles such as "how to access the images page," "how to create a new document," "how to navigate settings," and so on.
Incomplete content	We could update this to contain what snippets are and how they can be accessed
The report section contains a sentence prompting the user to just click on "Report"	Based on the demo site, when the report button is clicked, it displays several sub-pages. This should be indicated in this section and the specific problem the section aims at solving.
Almost technical writing style and less hyperlinks	This documentation is aimed at users of various categories; using simple phrases or hyperlinking words that are likely to be misinterpreted creates excellent documentation.
The "About redirects" gives some explanations on redirects	Moving content that provides in-depth explanations to the "explanations category allows a user who is on the how-to page to focus on getting something done. There may be a prompt or pointer directing them to the explanations page if they wish to learn more about redirects.

Explanations

This section of documentation adds context, clarifies, and shows the user the big picture of everything. This part explains why everything is the way it is, gives history (if necessary), and delves into any other topics that may have been skipped in prior sections. Currently, I believe the page is still in the works, and writing lengthy articles that discuss each feature and their use cases will be an excellent addition to this portion of the documentation.

References

This section comprises the majority of the technical nitty gritty and gives accurate information about various items in the documentation. Users should be able to easily review the references to recollect what CMS means, what a child page implies, and so on. It should be a reliable section for all types of users (beginner, intermediate and experts).

Additional Information

This documentation's contents should also contain videos, particularly in the tutorial and how-to sections. Also, photos are effective in communicating content, and Including the required screenshots in the relevant sections will go a long way toward assisting users.. I checked all of the previously reported documentation issues, including this isssue was likewise about including screenshots to help new users.
Also, enough text padding, spacing, and picture captions should be used to make the content simple to read. A feature that will be useful in this documentation is the inclusion of a "page contents bar" by the right for easy navigation.

Finally, a navigation bar above the page will come in helpful to ensure a user can effortlessly switch pages.

[marv-tech]

That’s a good point. Would you be up for writing an updated version of this section, with a simple list with descriptions of each of the reports? Something very high-level.

Yes, I'd start working on it and get back to you as soon as I'm done.

Reports

Click on Reports to create new reports in wagtail and view the following pages:

• Locked pages: Access reports on locked pages that only you may update.
• Workflows: Receive reports on pages that have been submitted for moderation.
• Workflow tasks: Have access to reports on task orders in a certain workflow.
• Site history: View reports on your website's history.
• Aging page: Check out and download reports on aging pages.

@thibaudcolas what do you think?

[thibaudcolas]

Published! with a few tweaks https://guide.wagtail.org/en-latest/how-to/finding-your-way-around/#reports

If you want to improve this, I would suggest:

• Doing another version of the above, with a few more words about each report – in particular stating why each report is useful / how people might use it.
• Drafting a new "Reference" page with one section per report, explaining in more details what the report is for and how to use it

[marv-tech]

Published! with a few tweaks https://guide.wagtail.org/en-latest/how-to/finding-your-way-around/#reports

If you want to improve this, I would suggest:

• Doing another version of the above, with a few more words about each report – in particular stating why each report is useful / how people might use it.
• Drafting a new "Reference" page with one section per report, explaining in more details what the report is for and how to use it

Thank you for publishing the updates; I will begin working on these new tasks right now.

[marv-tech]

If you want to improve this, I would suggest:

• Doing another version of the above, with a few more words about each report – in particular stating why each report is useful / how people might use it.

@thibaudcolas kindly review

Reports

Locked pages: This report is very useful in providing information on your locked pages based on your chosen filter. A use case would be if you have many locked pages on your site and need to know who locked them or if it has been pushed live. This information allows you to keep track of the locked pages and stay up to date.

Workflows: Getting more information on pages that have been submitted for moderation can help you understand the current status of the page, who created it, the date it was created, and many other things. With this report, you can manage and gain valuable insights into all of your pages.

Workflow tasks: Workflows can have a varying number of tasks, so reports are the best way to find out which tasks are awaiting review, when they were created, which workflow they belong to, and their status. By downloading a report, you will be able to understand and see all the tasks on your site.

Site history: When you need to see the history of what you've done over time and filter these searches based on specific filters, go to site history.

Aging page: This is very useful for locating aging pages and learning about the type of page, its live status, and other information.

• Drafting a new "Reference" page with one section per report, explaining in more details what the report is for and how to use it

References

Locked pages

You have access to reports on locked pages that only you can update. Reports on locked pages allow you to filter and download reports based on various criteria;

• Locked by—who locked the page .
• Locked at—when the pages were locked and when they will be unlocked,
• Live—if the pages are active or not.

To access these reports, go to Reports and then click on Locked pages, which will display all locked pages as well as the available filters. Apply the relevant filters to get a report on locked pages and download the report in the format of your choice.

Workflows

You can view reports on all pages that have been submitted for moderation. Using the available filters, you can filter based on the following;

• Show—this displays all pages or those awaiting your review.
• Types of workflows
• The status of the page—pages in progress, approved, needs changes, and cancelled.
• Requested by—who is requesting for the report
• Started at—when the pages are created

Clicking on Reports, then Workflows, takes you to the page where you can get started in accessing these reports.
You can easily toggle between reports of workflows and the tasks of workflows reports by clicking on By Tasks.

Workflow tasks

These are specific tasks in a workflow. All workflows tasks are displayed and can be filtered by;

• Those awaiting review
• Workflows
• Tasks
• Dates
• Task status—In progress, Approved, Rejected, Skipped, and Cancelled.

These filters enable you to download reports on workflow tasks in the format of your choice. To access this, select Reports and then workflow tasks to get reports on the task orders in a specific workflow based on the filters you've chosen.

Site history

The changes made to your site over time are recorded in your site history. The following filters can be used to sort the site history:

• type
• name
• action
• user
• date

This page can be accessed by clicking on Reports, then Site history to view all history and filter based on your preferences.
You can also download these reports in the format of your choice and hide commenting actions.

Aging page

Aging pages are displayed here and can be filtered based on the page's

• live status
• date
• type

To view all history and filter based on your preferences, go to Reports, then Aging pages. The reports can also be downloaded in your preferred format.

[marv-tech]

@thibaudcolas
Have you had the time to go over these suggestions?

[Buraah]

Feedback And Suggestions from the New User Guide Website

1. On tutorials, there are no graphics or pictures that aid visual learners
2. On How-to under 'finding your way' the first note column seems to have incomplete information. The sentence 'Editors will have a dashboard view that is' is incomplete
3. On the same page there's no explanation as to what snippets are.
4. The translation to Icelandic language doesn't fully work, some things are still in English
   

A Few Suggestions to Improve the user guide

1. It will be nice to include a video content tutorial on how to install wagtail, in other to make the documentation more inclusive for visual learners who prefer seeing and observing.
2. On the 'How-to' page, the picture illustrations can be a bit confusing for a first time user, because it seemed like they were gotten from an already up and running account. I suggest showing these steps using a freshly opened account instead, supposing a new user is following through the guide to set up his or her site. so when they're trying to create a page and they go to 'creating and editing pages' for example, they are greeted with a fresh page that looks exactly like theirs and not a page that has a list of already created pages. I believe this will make the guide more beginner friendly
3. The guide only has 2 languages, English and Icelandic language. To have a wider reach and even better user experience, i will suggest translations in languages that are more widely spoken, for Example: Spanish and Mandarin.

[thibaudcolas]

Thank you for the suggestions :)

Note on translations this is a work in progress, and completely dependent on which languages our contributors speak. If you speak Spanish or Mandarin we’d love to have your help with those 😉

I think installing and setting up a Wagtail site for the first time is a bit out of scope to be honest – lots of this involves admin tasks that won’t be relevant for the majority of users.

I suggest showing these steps using a freshly opened account instead, supposing a new user is following through the guide to set up his or her site. so when they're trying to create a page and they go to 'creating and editing pages' for example, they are greeted with a fresh page that looks exactly like theirs and not a page that has a list of already created pages. I believe this will make the guide more beginner friendly

If you go through our tutorial you should realise this is impossible. The whole point of using Wagtail is that what a "page" is and what fields it has is heavily customisable. That’s why we demonstrate Wagtail functionality with a ready-made site, the bakery demo.

It will be nice to include a video content tutorial on how to install wagtail, in other to make the documentation more inclusive for visual learners who prefer seeing and observing.

Keep in mind we want to be keeping the guide up-to-date from version to version, and across multiple languages (Wagtail supports about 20). It doesn’t seem very realistic to me to produce 20 videos every 3 months! If you have suggestions on how to make that work better do let us know though, we’re always interested in better approaches.

[Buraah]

Thank you!
On Translations i don't speak neither of the languages, although i believe it will be an interesting challenge to take on by learning, seeking help from the internet and doing this in a team of people who might share the same interest or a team of people who already have their hands on deck. The knowledge won't only improve the user guide but can also be beneficial to wagtail as a whole. This is merely a suggestion and it was born out of my interest to learn a new language and use it for something absolutely worth it.

On aiding visual learners set up wagtail, i am one and it was a little bit difficult setting up on my own, also because i was doing this for the first time. But that been cleared, i agree it's out of scope for the majority of users.

I understand why a ready-made site is used to demonstrate wagtail functionality and not a site from scratch now, thank you for clarifying!

Producing 20 videos every 3 months is definitely unrealistic, but making 1 video in English and having it subtitled in the other 19 can be worth a little try. I'll also continue to think of better ways this might work.

Also the images on the user guide do not have an alt text. Someone using a screen reader might miss out on what the images are about, because a screen reader will only read it as 'image' or 'graphics' to them.

[thibaudcolas]

@Buraah 🙌 based on this here are tasks I’d like you to do if you’re up for it:

• For videos, LB suggested the following a few messages ago:

We could use something like Google Chrome's Recorder feature to manage small videos that can get regenerated or shown to the user in an IFrame for some common tasks. developer.chrome.com/docs/devtools/recorder/reference

Could you give this a go and report back? That might help a bit?

Also the images on the user guide do not have an alt text. Someone using a screen reader might miss out on what the images are about, because a screen reader will only read it as 'image' or 'graphics' to them.

All of the ones I’ve checked did – could you let us know which ones don’t have alt text, and draft the appropriate alt text for them?

[Temidayo32]

Suggestions on the User Guide Documentation

First before I make my suggestions, I would love to mention that balance is equally important in creating the user guide documentation: how much is enough?

A UI should be intuitive and suggestive in nature. What I am trying to say is a need to document certain elements on the UI might hints more at a faulty UI than a need for documentation. So this is something to also consider as we ponder on what elements of the admin UI to include in the documentation. Alternatively, we could have UI writing instead( documentation in the UI).I think this was one of the secondary goals for the project. So in cases where some elements can just be explained directly in the UI, then this would be a better option than writing them in the documentation. And besides, most users are less inclined to check the documentation to understand every UI element. It is stressful. They rather just tickle with it until they gain enough understanding of it to do what they want to do. Most users today expect some pop up doing the explanation without them leaving the page.

For my suggestions, I will cover it inline with the diataxis framework. So now, let me talk about the tutorial section.

Tutorials

As @activus-d have suggested, the getting started can't be considered a tutorial content, and I would suggested it be treated separately. What I would think is more appropriate for the tutorials section would include:

Usecases: I don't know if anyone is paying attention to this, but this statement--"Wagtail is an open source content management system"--is repeated severally across the Wagtail's documentation sites, but on no instance was there a specific reference to what CMSs Wagtail can be used to build. Just simply mentioning that Wagtail is a CMS is not enough. We need explicit references to really strike a cord with the audience on what Wagtail is capable of!

I think this is very important. The only thing that suggests a usecase of Wagtail currently is the Bakerydemo, which demonstrate mostly, using Wagtail for building blogs. I think, at this point, it is important to interact with the broader Wagtail community to know what they are using Wagtail to build: Ecommerce? Health websites? Travel websites? Some days ago, I was searching online for a tutorial on using Wagtail to build an Ecommerce store, and the only content I could find on Google (at least on the first few SERP pages) was this Snipcart ecommerce. In fact, several websites duplicated this same tutorial! This looks to me a content gap.

My suggestion: The only way to demonstrate the robustness of the usecases of Wagtail is by providing actually examples of what is being currently built with Wagtail. This could be achieved through tutorials. The Tutorial section of the User guide could be populated with these type of content that demonstrate Wagtail usecases.

A potential problem that might crop up with these tutorials is that actual coding may be involved. In this case, I would suggest a clear separation of the coding aspects of each usecase from the admin interface. The main developer documentation could handle the coding aspect, while the admin interface for each of the usecases can be handled in the user guide. Secondly, I am also sure there would be nuances to managing content peculiar to each usecase. For instance, managing content for an ecommerce would be different from managing content for a blog site. Ecommerce might demand more demonstrations of the Wagtail Image and Collections features than a blog site would; while a blog site might demand more demonstrations of the Wagtail Richtext feature than a Ecommerce would. Tutorials can be used for demonstrating handling the nuances specific to each of the usecases.

Alternatively, you can also consider publishing these usecase tutorials as Community tutorials as a separate section of it own. This might be a consideration if the tutorials is intended to focus strictly on Wagtail without delving into other tools or stuff.

How-tos

I think this section have been heavily covered by previous commenters in this page, so I will pass on this.

Explanation

I believe content on the Zen of Wagtail and the entirety of the idea upon which Wagtail is built also belongs in the user guide too. This knowledge is equally important for editors too to help them gain a better understanding of Wagtail and their place in the CMS process.

Secondly, Wagtail terminologies need to be also explained: Child page, Parent page, and so on. A content editor with no knowledge of coding might have trouble understanding this, so providing detailed explanations on these terminologies as well as other Wagtail-specific terminologies would be suitable for this section.

There is also need to explain why Wagtail was built technically the way it is built: Why a Page tree system?

Reference

This was a suggestion by @lb-

Deep dive into some of the more complex field types we use; choosers, StreamField, InlinePanel, Embeds (maybe in the references section)

This looks an interesting addition to the user guide documentation, but I don't know from what perspective this should be written about in the reference section. I would think that explaining these field types to a developer would be different from how they would be explained to a content editor or an administrator. So I think the perspective on how these field types should be explained in the user guide should also be considered.

[thibaudcolas]

Thank you! I really like your suggestion to have a version of the "zen of Wagtail" on this site too, and it also makes a lot of sense to me that we’d consider inline documentation within the admin interface as part of this project.

If you’re interested, here are recent improvements we made / ideas discussed on documentation inside the CMS:

• User onboarding: Wagtail tour guides wagtail#9474
• User onboarding: Help menu and dismissible UI elements wagtail#9351

Based on your experience in Wagtail so far, if there is a specific UI element you’d want to use as an example, I think this would further validate your feedback quite a bit.

[Temidayo32]

@thibaudcolas thanks for the review of my feedback.

I agree on the point (customizable admin interface) given for why a tour guide would be unfit for Wagtail as given in the discussion on the idea User onboarding. So I agree that the Help menu and dismissible elements idea is a better fit. In addition to this, as I have suggested, we could have inline documentation: little pop-ups on hover over a UI element.

This could be particularly important when there are menu items of the same name, which could be confusing. For instance, the report menu and settings menu both have a Workflows and Workflow tasks sub-menus.

A pop-up that explains each of these sub-menus would surely help clarify their purposes and immediately eliminate any potential confusion on the purpose of the sub-menus.

[thibaudcolas]

I’m not sure there’s really a confusion in this case to be honest. "Workflows" and "Workflow tasks" aren’t the same name, and this is an admin feature where we do expect relatively expert-level knowledge.

[Sophyia7]

Suggestions on the User Guide Documentation

Here are my suggestion to improve the Explanation section of the User guide.

• Wagtail as a productive tool for content editors: This will explain how wagtail is the best tool for content editors; the key features, etc. It will also talk about wagtail's admin interface which is focused on creating content.
• The difference between Wagtail and X: This will discuss the superior features of wagtail and other editors.
• The best way to contribute to the guide (For non-developers): This will a guide on how to contribute to the Wagtail user guide.

These are my suggestion, I am hoping to get a feedback on this soon. Let me know if there are things I got wrong or if the suggestions doesn't fit the Explanation section.

[thibaudcolas]

@Sophyia7 thank you for the suggestions! Can you expand on why you think those three things are needed? I think the ideas have merit but you have to state why you make the case for us to do this (are we sorely lacking this currently? do other projects do this in their docs that you know of?)

[Sophyia7]

Alright.
I believe Wagtail as a productive tool for content editors could give a sense of why wagtail focuses on an admin interface. Similar to the Ghost CMS For Creators section that explains how to utilize Ghost as a creator. Wagtail could do something similar and highlight content editors' key features to create, manage and maintain content.

Most platforms have a comparison article explaining why users should choose their platform over others. That is where The difference between Wagtail and X comes into play. It will give users a space to compare and contrast CMS platforms and why they should use wagtail.

An open-source project is the best project because users can use the platform and understand how it works under the hood. The best way to contribute to the guide (For non-developers) will be specifically for those who love wagtail and wants to contribute to its growth. Most open-source projects focus on the developer contribution guide but having a developer, and non-developer guide could put a wagtail on top. Non-developers could easily explore wagtail.

[Sophyia7]

@thibaudcolas I am yet to get feedback regarding this.

[thibaudcolas]

@Sophyia7 for the first two points, these seem to me like marketing content rather than documentation? Ghost’s "For creators" page is nice but is very much not documentation to understand Ghost.

[lb-]

Another key improvement, not particularly content, is to think through and improve the workflow of those who can contribyti the content in the future.

Here is a rough bunch of thoughts on this.

1. Awareness

• Links to this project on the Wagtail main site, Wagtail project readme
• Link to this project on the new translations page in the Wagtail docs (that page is about contributing translations for Wagtail's admin but might be good to add a note about this guide page) https://docs.wagtail.org/en/latest/contributing/translations.html
• Blog post
• Find any Links online and see if we can get them updated
• Some semi-automated way to ensure the This Week in Wagtail channel on Slack can easily get info about added & significantly updated pages. This keeps things on the radar for the community.

2. Easy registration as a user & joining the community

Once a potential contributor arrives at either the public guide site or this project's readme, it should be as easy as possible to join the site as a read only admin. Some kind of one click join feature would be great, pretty sure that's doable.

Then when they join the admin, their dashboard page should be useful and show recent updates and maybe some helpful links.

We should also promote a Slack channel (I assume #editor-guide) to also join to be a part of the conversation.

Additionally it would be great to be able to get some kind of emails regularly regarding key changes if you are a user in the Wagtail admin.

Permissions groups are really important to consider here before setting up these kinds of things. We also need to be really careful about people's emails and names being available and to what extent to what user types.

Finally, we need to consider what happens when someone wants to leave this project. Can they / should they delete their account? Or just request it gets deactivated?

3.Get access to submit suggested changes via comments only

This might be a good next step for contributing, users cannot edit but just add comments.

It's important to think about the notification process here and also how these comments get resolved or addressed.

Maybe a list of comments needing to be resolved can be on the dashboard for users with more permissions level.

4. Getting access to being able to update some parts or some translations only

After this, users may have access to submit changes but not publish them.

This gets a bit tricky with multiple people maybe wanting to update the same page.

5. Permission to approve content changes & recognise contributors

Finally, changes being published and also the ability to update the contributors listing.

A great part of the Wagtail community is acknowledgement of those that play a part. We want to ensure we don't forget to add names to this list.

---

There could.be a lot more steps here but just some thoughts to get us going.

[activus-d]

@lb- @thibaudcolas

Links to this project on the Wagtail main site, Wagtail project readme
Link to this project on the new translations page in the Wagtail docs (that page is about >contributing translations for Wagtail's admin but might be good to add a note about this guide >page) https://docs.wagtail.org/en/latest/contributing/translations.html
Blog post
Find any Links online and see if we can get them updated
Some semi-automated way to ensure the This Week in Wagtail channel on Slack can easily get info >about added & significantly updated pages. This keeps things on the radar for the community.

I will like to work on some of the items in the Awareness list here. I believe they will really help in making the existence of the user guide well-known to contributors and users of Wagtail.

For instance, as regards the last item in the list, a GitHub label can be created specifically to identify significant changes on the pages. Then the github\slack integration can be made to make notifications in the Week in Wagtail channel on Slack based on this filter. To be clear, what I'm saying is that once a PR has been designated to be a significant improvement on the user guide pages, a label can be added to such PRs and then the Github\Slack integration can be configured to make notifications by whitelisting this label only.

[EigegeIce]

Suggestions for the Wagtail User Guide.

1. I suggest that the tutorials should be supported by demonstration videos as pictures would not give a clear picture of the process and it aids with new users finding their way around easier than reading and looking at pictures for guidance and direction.

2. There should be a clear-cut guide for the non-developer users who are not conversant with programming languages so that they too can make use of Wagtail efficiently to create content.

3. Awareness of Wagtail should be made more
   prominent to pull more users into it and make it more popular for content management, advertising and promotion through giveaways help to put the brand name in people's minds.

4. The language used to write the User Guide is a bit hostile and unfamiliar to non-developers/programmers, and to widen the reach of Wagtail we need to tone it down and use more relatable terms for the mass users.

[thibaudcolas]

Thank you for the feedback @EigegeIce. Videos would be nice but I’m worried they would be hard for us to keep up-to-date (screenshots are hard to keep up to date as it is).

Note this guide is definitely the one that’s not meant for developers, but we do assume awareness of Wagtail. Keep in mind this is a documentation site for Wagtail users – it’s important it’s a compelling site, but completely irrelevant for us to market Wagtail via this.

[jadesola123]

Suggestions on the User Guide Documentation

The Landing Page.

For the landing page or the footer, I think it'll be good to add Wagtail's social links, like Twitter, slack, and Torch Box's YouTube channel. It can be titled as a h3 and be called "Stay Updated" or "Join Us Online".

Tutorials

With tutorials, we can help editors/users gain competence in using wagtail for various purposes.

Some ideas include:

• Building your first form.
• Building your content team in wagtail (I'm aware that this is sort of discussed in the "Managing Users and Roles"), but I think in this tutorial, it can be discussed extensively. Like, how the other members of the teams can gain access to the site and how to make custom groups, etc.

How-TOs

Some ideas I have include;

• Working with forms or Managing Form Data
• Managing Aging Pages

Reference

For the reference section, I think we can add the meaning of different actions that occur while managing revisions. E.g., revert, what is an alias page, and more.
What's a help text when building a form?

We can also go through Reddit threads or forums to understand if there are any pain points editors may have while using the CMS and address them in the documentation.

Like here

[thibaudcolas]

@jadesola123 thank you for the feedback!

• On the landing page – keep in mind our Twitter / Slack / YouTube content is primarily for developers, while this site is for users of the CMS. Do you think it still makes sense to cross-link?
• I like your suggestions for tutorials
• And How-tos

Also great call to look at people’s existing feedback to inform what we cover in our docs!

[jadesola123]

Hi @thibaudcolas

Thank you for the feedback. Since the Twitter / Slack / YouTube content is primarily for developers, I think it's alright to leave the landing page as it is

[BeeC00des]

Suggestion on user guide documentation.

1. A demo video about wagtail product on the get started page to inform the user what wagtail cms can do.
2. The get started page should also have a video on the setup or installation process, user are relate better with visuals than text. under each video should be text that describes the above process. (how to )

Observation on the UI

The font is equal throughout the page, compared to the developer documentation.
the search input should be fixed instead of clicking the icon, users are not patient.... let's note that
the navigation should be improved, the spacing at the top is too much and the alignment of the content can be improved then make it fixed.
the footer should have a link leading to the developer documentation because some user developers too, and contact information should be added
Dark mode, users love this feature, so we can add it.
using list items ... that are instructive help user than long paragraphs

How to

How to integrate wagtail in Cpanel
How to create e-commerce with wagtail
How to get your blog website up with wagtail

Explanation

wagtail vs WordPress
wagtail vs Joomla

Reference

Glossary

[thibaudcolas]

Thank you for the feedback @bolarinwa-ajayi1. Quite a few people have suggested videos already, and the reality is that those are really hard for us to keep up to date, which is one of the issues we have even with just text content. So this doesn’t seem compelling to me, unless you have ideas on how to make videos in a way that we can redo them every 3 months across 10+ languages.

Good suggestions about the UI!

On the how-tos – Cpanel, e-commerce with Wagtail, blog website setup – all of those sound irrelevant to me for someone who is a user of a Wagtail site? Those sound like topics for developers, not relevant for this site.

[Dev-Liz]

Hello everyone, I created a list of what the (editor guide) Glossary might look like. It's not an extensive list though. But I'd like to hear your feedback on it.

https://docs.google.com/document/d/1YqZ5EjD5FxEWXvtfE_rYumR-TjY6hJP9Q1okJFHyMU8/edit?usp=sharing

[BeeC00des]

Hi dear, can I add to this glossary, when it's many? it can be added to user guide documentation.
Great work.

[Dev-Liz]

Sure! @bolarinwa-ajayi1i'll make the file editable so you can add to it. Please dm me on slack.

[BeeC00des]

Thanks, dear.

[thibaudcolas]

Thank you @Dev-Liz! I’d be keen to hear how you picked those specific terms.

[Dev-Liz]

Hello, @thibaudcolas. They are mostly terms from the Admin dashboard and a few from installing wagtail as a non-developer.

I thought to pick from those, as it concerns the editors only.

[PreciousArinda]

Hello everyone,
Unfortunately, I have just discovered this channel but its never too late. I am seeing amazing contributions from everyone and I am happy to help anytime.
I am Precious and I am happy to meet everyone.

[softkeldozy]

Later today, the thread will be closed to new contributors. Therefore, please feel free to immediately share any ideas you may have.

[thibaudcolas]

👋 the thread won’t be closed, but yep it’ll no longer be possible for people to record a first contribution in Outreachy.

[Cess-Uyi]

Tutorials - Getting Started:

https://guide.wagtail.org/en-latest/tutorials/getting-started/

Details

• A brief introduction explaining what wagtail is could be added to the documentation. It should be one of the first things the users see.

• For clarity, we can add a link to what a CMS is. According to the Diátaxis documentation, “Don’t ever be embarrassed to start right at the beginning: a user can skim rapidly over what’s unnecessary, but if they need something and it’s not there, you risk losing them altogether.”

Welcome to Wagtail User Guide! If you’re here, you probably already know that Wagtail is an open source content management system (CMS)

This becomes

Wagtail is an open source content management system (CMS). Here, we have added link to a website explaining what CMS ia

• Slight text modification

If you’re an editor, administrator, or general user of Wagtail, this guide is for you. If you’re a developer, you might find our developer documentation more useful.

This becomes

If you are a developer, you might find our developer documentation more useful. However, if you are an editor, administrator, or any other category of user of Wagtail, this guide is for you.

• Slight text modification

If you're brand new to Wagtail…

This becomes

If you are entirely new to Wagtail

---

Explanation

https://guide.wagtail.org/en-latest/explanation/

Details

According to Diátaxis, “Explanation clarifies, deepens and broadens the reader’s understanding of a subject.”
I think the Explanation section of the wagtail docs should answer the Whats and Whys. It can largely talk about;

• open source content management system(CMS)
• Wagtail’s background
• The idea behind Wagtail (Wagtail’s concepts)
• Discussing and weighing alternatives to Wagtail
• Opinions on Wagtail

[PreciousArinda]

Thank you

[thibaudcolas]

Thank you for the feedback @Cess-Uyi. I think this is a tricky format for us to look at specific wording of a page so I’d suggest focusing on high-level content outlines / formats for the site.

I don’t really understand how Wagtail’s background or alternatives are relevant to our documentation. Could you expand on that or share examples of other projects doing this in their docs?

[softkeldozy]

@thibaudcolas some ideas about the concept of a new contributor-level suggestion. I was thinking of adding all the third-party installations that one might need before proceeding with any Wagtail installation. Make Utility Program is just one of them.

We had to install it before we could use it to start any make commands after the errors we encountered on the first try, a problem that some of the outreachy contributors here, ran into (though we were able to solve it). It felt like a Python-Django utility program because of the documentation's style, but that is not the case. I know from experience that someone who is a backend dev will spot this on the fly but this is for someone new to the platform and is looking at giving Wagtail a short.

I did a small search and found that this program (make) does not come bundled in any OS (I stand to be corrected) and is one of the many third-party programs that the user needs to have in their local machine before going ahead with any other command, so it doesn't seem like something is breaking the moment one starts any Wagtail installations.

Another is the setup and installation of virtual environments, which must be done consistently throughout all documentation in order for all creation patterns to be up-to-date with the latest Python versions. I did bring up this issue here.

Last but not least, Windows users on Wagtail (Open-Source in general if I may) currently experience more blockers than Mac and Linux users.
Making the documentation offer more Windows OS options would be nice.
In the browser issues (new User guide) IE11 section, there is a typo..... the first bullet point.

[thibaudcolas]

@softkeldozy this thread is about the user guide documentation project so isn’t really the right place to provide feedback on our contributor / developer docs

[softkeldozy]

Ok @thibaudcolas
I'm sorry for this

[zobbs-git]

SUGGESTIONS TO THE USER GUIDE DOCUMENTATION

The documentation does not highlight the subsection you're operating on. I think it will be nice to have a feature for that. Possibly, if there can be a navigation on the right-hand side to indicate the subsection, it will be easier to follow and be identified.

In the How-to>Managing documents> it only explains how to add and remove documents. It doesn't explain how to use the document you added to your web page, for example, if you have to contact your web master to use it. I think an explanation of how the document can be used is needed in the user guide.

There is a typo in the Finding your way around>The dashboard. In the 2nd line, "you can can" and not "you can" 

[lb-]

Feature idea - quick review question on how-to pages

Some documentation pages have a nice approach to the whole previous/next buttons where they also include a simple multi-choice question at the bottom of the page.

This isn't anything fancy (no cookies, not account sign up, resets on refresh etc). But just one question about something on the page with a way to submit and get feedback while still on the page.

Some of our pages are quite long and cover a lot of things, but it would still be nice to help get a sense of progress and also it's a good way for some to learn.

Example

A good example of this is Next.js' learning resources.

https://nextjs.org/learn/seo/introduction-to-seo/importance-of-seo

Once you submit...

[VictoriaAjala]

This is great @lb- , I believe getting useful customer feedback would help us improve the documentation further.

Question:

1. The multiple choice questions pops up after the initial feedback right?

PS: I love the nextjs websites UI.

So I think I got it mixed up, the multiple choice is to test the readers on what they have learnt after reading the documentation which is a great feature.

[lb-]

Hey Victoria. Sorry this idea is not about feedback but rather a mini 'quiz' on each page. I guess the submitted values could be used to see how many people get it wrong but then we need to store that data.

Maybe that's useful but my main thinking is that this helps people get another way to double check they have understood the content.

[ayedhd]

wagtail user guide: improvements

1. The 'On this Page' section for each page within the guide provides a list of contents that can be found on the current page. I think these should be linked to the respective section so it jumps down to that segment when clicked. This is present on some pages but not on all, for example, the 'Reference' section.
2. The guide encompasses links to various sites (Gitpod or Microsoft, for example), however to offer convenience to users, these links should open in a new tab (or window) rather than replacing the present tutorial page, which most if not all currently do. It is arguably better that the user guide remains open for reference while the user explores the newly opened editing interface or secondary link.
3. I do not believe the Wagtail tutorial extensively conveys instructions for Gitpod users to operate via the browser version as opposed to the local copy or opening via VS code. For example, when following the Wagtail tutorial, many elements do not apply to Gitpod browser users and references are made to ways you can check the success of your previous steps that are not present on the Gitpod browser. Maybe worth including a mini disclaimer saying 'This won't be applicable for Gitpod browser users', or users may feel they're way off course.
4. Review of typos here and there. I see some have been mentioned in the thread previously. e.g. 'sub-sctions' on https://guide.wagtail.org/en-latest/how-to/finding-your-way-around/
5. The integrated user feedback tools (smileys at the bottom) should register when someone gives a response to confirm they were submitted ("Thank you for your feedback" or simply "Thank You") and you might consider a pop-up prompt underneath for additional comments if the user is willing, particularly if a negative response is recorded. Currently, nothing happens when pressed.

also massive props for the dark/light mode

[lb-]

Ability to subscribe to changes / updates

It would be great to be able to have, at minimum, an RSS feed of content changes somehow. Alternatively, some other way to subscribe or be notified of main updates to the page's content on a regular basis.

This is useful for the following;

• This Week in Wagtail newsletter updates (similar to how we update with key changes to the Wagtail code)
• Slack posts for general updates so the community can be aware of what's happening
• Others who want to be kept in the loop with this project but as it's not code we cannot subscribe to GitHub changes.

It may be that this can and should be done in the admin UI, but I'm not aware of a general 'watch changes' feature in Wagtail.

[allcaps]

We might create a Slack hook on page publish.

Revisions hold the history. We might use them to create the diffs. I'm wondering if we could bring diffs of the published revisions to the public site 🤔.

Wagtail Localize has a database tables that we might use to create reports about outdated translations. It would be nice to notify translators of 'source language' changes.

[zobbs-git]

DOCUMENTATION ON HOW TO EXPORT REDIRECT

EXPORT REDIRECT

You can export a redirect file. To export redirects, click on the drop-down arrow on the ‘Import redirects’ button in the Redirects page.

Fill in the necessary filter fields to match the redirect(s) you want.

Click on Download XLSX to download the file. You can also download the file as a csv file by clicking on the drop-down arrow in the Download XLSX button.
You have now successfully downloaded your redirect file.

[thibaudcolas]

👋 for people interested in following updates on the Outreachy internship, I’ve created a separate thread: Outreachy: Editor Guide internship updates #282.