canada-ca / digital-playbook-guide-numerique Goto Github PK

Government of Canada Digital Playbook / Guide numérique du gouvernement du Canada

Home Page: https://canada-ca.github.io/digital-playbook-guide-numerique/

License: Other

HTML 82.49% Ruby 3.10% JavaScript 14.41%

digital-playbook gouvernement digital-standards government canada collaboration user-experience accessibility open-standard data

digital-playbook-guide-numerique's Introduction

Français

Government of Canada Digital Playbook (draft)

(Website version of the Digital Playbook overview)

Provides practical and detailed guidance to assist the Government of Canada in digital transformation and augmented service delivery, including becoming more agile, open and user-focused. Includes task-specific views and interactive features to make it easier to find relevant guidance and to apply it to day-to-day work.

The Digital Playbook is also an opportunity to experiment with new approaches while reusing as much as possible and contributing back reusable components for others to use (see Experimental approaches and reusable components).

Digital Playbook views

Digital Playbook views are generated from the Digital Playbook dataset and can make the Digital Playbook more relevant and easier to use for certain tasks by providing only the information that is relevant to the task and ordering it in a way that makes sense for the user.

Agile views

Is Agile Right for My Project? (draft)

Artificial Intelligence (AI) views

Digital Standards views

Development stage views

Other views

Government of Canada Digital Playbook comparison table

About the Digital Playbook

Improving government services in the Digital Age

Our goal is to provide public services to Canadians which are simple to use and trustworthy. This Digital Playbook, and the Government of Canada's Digital Standards it is built upon, form the foundation of the Government of Canada’s shift to becoming more agile, open, and user-focused. They will guide teams in designing digital services in a way that best serves Canadians.

The digital standards were co-created with the public and key stakeholder groups and the goal is to co-create this Digital Playbook with the same groups. They are living standards and guidance and they will continue to evolve over time as we better understand the complexities involved in putting them into practice.

The Government of Canada Digital Playbook is available under the Open Government Licence - Canada, except where otherwise stated.

Structure of the Digital Playbook (draft)

The Digital Playbook is composed of multiple different views which are designed for certain tasks by providing only the information that is relevant to the task and ordering it in a way that makes sense for the user. Each of these views could be composed of one or more of the following:

Standards are strategic and describe the expected behaviour.
Guidelines are tactical and describe in general terms how to behave according to the standards.
Checklists include items that are operational and describe in specific terms how to meet the guideline.
Implementation guides provide additional, detailed information on specific sub-topics to assist with implementing the guideline.
Reusable solutions include templates, tools and other solutions to assist with implementing the guideline.
Similar resources are sources of information (e.g., standards from other jurisdictions) that are similar to the guideline.

Implementation approach

The approach to developing and releasing the Digital Playbook will be similar to the Web Experience Toolkit and HTML5, where the Digital Playbook continuously evolves on GitHub and stable snapshots of that work are released as formal versions through Canada.ca. This enables the Digital Playbook to be both agile and ever-improving on GitHub while also providing a stable version through Canada.ca that can be relied upon for guidance.

Community feedback and contributions to the Digital Playbook are encouraged, with designated reviewers for each part of the Digital Playbook being responsible for reviewing, responding to, requesting changes (as needed) and eventually approving or declining the feedback and contributions. The primary reviewers are individuals from the related policy areas and areas of expertise, and are also responsible for contributing content and engaging with their respective communities.

To ensure that the Digital Playbook is as easy to use as possible, contributors/reviewers would work with their respective communities to determine how to make the Digital Playbook more applicable to their day-to-day work, including for which tasks/scenarios personalized Digital Playbook views should be provided.

Guide numérique du gouvernement du Canada (ébauche)

(Version du site web de l'aperçu du guide numérique)

Fournit des conseils pratiques et détaillés pour aider le gouvernement du Canada dans la transformation numérique et la prestation de services accrue, y compris en devenant plus agile, ouvert et axé sur l'utilisateur. Inclut des vues spécifiques aux tâches et des fonctions interactives pour faciliter la recherche des conseils pertinents et pour les appliquer au travail quotidien.

Le guide numérique est également l’occasion d’expérimenter avec de nouvelles approches tout en réutilisant le plus que possible et en fournissant des composants réutilisables pour que les autres puissent les utiliser (voir Approches expérimentales et composants réutilisables).

Vues du guide numérique

Les vues du guide numérique sont générés à partir du jeu de données du guide numérique et peuvent rendre le guide numérique plus pertinent et plus facile à utiliser pour certaines tâches en fournissant uniquement les informations pertinentes à la tâche et en les ordonnant d'une manière logique pour l'utilisateur.

Vues basées sur Agile

Est-ce que Agile est juste pour mon projet? (ébauche)

Vues basées sur l'intelligence artificielle (IA)

Vues basées sur l'informatique en nuage

Outil décisionnel du nuage approprié (ébauche)

Vues basées sur le gouvernement ouvert

Comment puis-je décider de publier du contenu dans le Portail du gouvernement ouvert? (ébauche)

Vues basées sur le sécurité

Outil de categorisation de sécurité (ébauche)

Vues basées sur les normes architecturales sur le numérique

Vues basées sur les normes numériques

Vues basées sur les stages de développement

Autres vues

Tableau comparatif du guide numérique du gouvernement du Canada

À propos du guide numérique

Améliorer les services gouvernementaux à l’ère numérique

Notre objectif est de fournir aux Canadiens des services publics faciles à utiliser et dignes de confiance. Ce guide numérique, ainsi que les normes numériques du gouvernement du Canada sur lequels ce guide est fondé, constituent le fondement du virage du gouvernement du Canada vers une plus grande souplesse, une plus grande ouverture et une plus grande attention sur l’utilisateur. Elles guideront les équipes dans la conception de services numériques, d’une façon qui servira le mieux les Canadiens.

Ces normes numériques ont été créées conjointement avec le public et des groupes d’intervenants clés l'objectif est de co-créer ce guide numérique avec les mêmes groupes. Ce sont là des normes et conseils vivantes, et elles continueront d’évoluer au fil du temps à mesure que nous comprendrons mieux les complexités de leur mise en pratique.

Le Guide numérique du gouvernement du Canada est disponible sous la licence du gouvernement ouvert du Canada, sauf indication contraire.

Structure du guide numérique (ébauche)

Le guide numérique est composé de plusieurs vues différentes qui sont conçues pour certaines tâches en fournissant uniquement les informations pertinentes à la tâche et en les ordonnant d'une manière logique pour l'utilisateur. Chacune de ces vues pourrait être composée d'un ou plusieurs des éléments suivants :

Normes sont stratégiques et décrivent le comportement attendu.
Lignes directrices sont tactiques et décrivent en termes généraux comment se passant selon les normes.
Listes de contrôle comprennent des éléments qui sont opérationnels et décrivent en termes spécifiques comment satisfaire la ligne directrice.
Guides de mise en œuvre fournissent des informations supplémentaires et détaillées sur des sous-thèmes spécifiques pour faciliter la mise en œuvre de la ligne directrice.
Solutions réutilisables comprennent des modèles, des outils et d'autres solutions pour faciliter la mise en œuvre de la ligne directrice.
Ressources similaires sont des sources d'informations (par exemple, des normes d'autres juridictions) qui sont similaires à la ligne directrice.

Approche de mise en œuvre

L'approche du développement et de la diffusion du guide numérique sera similaire à celle de la Boîte à outils de l'expérience Web et de HTML5, où le guide numérique évolue constamment sur GitHub et où des clichés stables de ce travail sont publiés sous forme de versions officielles sur Canada.ca. Cela permet au guide numérique d'être agile et de s'améliorer constamment sur GitHub tout en offrant une version stable à travers Canada.ca sur laquelle on peut compter pour obtenir des conseils.

Les réactions de la communauté et les contributions au guide numérique sont encouragées, les réviseurs désignés pour chaque partie du guide numérique étant chargés d'examiner, de répondre, de demander des changements (au besoin) et d'approuver ou de refuser les commentaires et les contributions. Les examinateurs principaux sont des personnes provenant des secteurs de politiques connexes et des domaines d'expertise, et sont également chargés de contribuer au contenu et de s'engager auprès de leurs communautés respectives.

Pour s'assurer que le guide numérique soit aussi facile à utiliser que possible, les contributeurs / réviseurs travailleront avec leurs communautés respectives pour déterminer comment rendre le guide numérique plus applicable à leur travail quotidien, y compris pour quelles tâches / scénarios personnalisés les vues du guide numérique doivent être fournies.

digital-playbook-guide-numerique's People

Contributors

Stargazers

Watchers

digital-playbook-guide-numerique's Issues

Whitespace in Liquid tags

https://shopify.github.io/liquid/basics/whitespace/ seems that you can trim the whitespace from output tags using {%- ... -%} to make sure blank lines don't get added

Another resource for Similar resources of "5. Work in the open by default (draft)"

In 5. Work in the open by default (draft)

https://canada-ca.github.io/digital-playbook-guide-numerique/views-vues/standards-normes/en/5-work-in-open-by-default.html

I think it is worth adding https://sourcecode.cio.gov/

How to deal with common playbook strings in the dataset

How should common strings in the playbook, such as "Checklist", "Implementation guides" and "Similar resources", be dealt with in the dataset?

Currently they are being dealt with separately but that likely isn't much help for dataset (and eventually API) users.

Should these common strings be embedded in the dataset or continue to be managed separately? If embedded in the dataset, should they be in a global section (so have a global section for guideline common strings) or repeated in each guideline instance? Having a global section would avoid duplication/sync issues and help to keep the file size down but would be less convenient for dataset users (would have to look in two different places in the dataset when outputting the guidelines). On the flip side, repeating the strings in each guideline instance would make it easier to use dataset (only have to look in one place) but would result in duplication, possible sync issues (one instance of the string could be made to be different than another instance) and likely a significant increase in dataset size (due to all the duplication).

Which approach is better and why? If the global approach is better, how should it be implemented? Should it mimic the dataset structure for the common parts (e.g., section headings in the rendered document) but just have a title property for the common string?

Missing question label

While testing the form I found there is no label for question 22 - see image:

Should there be next/previous buttons to go between pages?

Currently for the user to go from Standard 1 to Standard 2 they would either need to hit the back button or click in the breadcrumb link to go back to the overview page and then click the link for Standard 2.

Should we be providing next/previous buttons to allow users to go forward and back between pages? If so, should they be at the top and bottom?

Checklist for applying an Open Source License to Crown Copyright.

I'm doing some work on getting approval to open source my work at ESDC, it would be nice to have a data-driven checklist/guideline for each Department to fill out and follow.

In my research it looks like while there are a lot of similarities in what needs to happen to apply a license there are differences.

For instance the authority to apply a license can sit at the Deputy Minister level in some departments it might be delegate down to a specific level such as the Director Level at ESDC. It might even be specific positions in other departments.

It'd be really handy to codify that for each department and possibly link to the documentation that states that (i.e. Policy, Legislation, Tweet, Whatever...).

I could see lots of other uses too like needed security controls per Department|Platform|Whatever, Stakeholders who need to sign off, anything really needed.

I think this would be pretty useful for supporting the Work in the open by default principle. As I found it pretty time consuming to figure this stuff out myself.

Work in the open by default
Share evidence, research and decision making openly. Make all non-sensitive data, information, and new code developed in delivery of services open to the outside world for sharing and reuse under an open licence.

I could contribute my work towards this, since I plan on doing this at ESDC anyway.

How to approach a playbook API

With the dataset approach under development (generating views from a JSON dataset using Kramdown and Jekyll/Liquid), the next logical step could be providing an actual API for the playbook.

How should such an API be approached and where should it be hosted? Can an API be provided through GitHub for drafts of the playbook? How can the API be approached to make it as portable as possible (i.e., easily ported to other platforms such as AEM and Drupal)?

What API technologies should be used (e.g., REST, GraphQL)? What methods/requests should be supported through the API?

How to document the dataset

How and where should the dataset that is under development be documented? Should it be part of the playbook itself in the form of Markdown pages or should it be provided elsewhere (e.g., GitHub wiki, Gitbook, or something else)?

Should it be auto-generated (using the latest dataset as the source) or manually maintained to give more detail/tailored documentation (or a combination of both)? How should it be set up/maintained?

(Page: Is Agile Right for My Project? (draft))

A mention or reference to Jeff Sutherland and/or his book, "Scrum: The Art of Doing Twice the Work in Half the Time", might be worthwhile. He is considered one of the founders or Agile methodology.

ATAG & Accessibility

Worth specifically mentioning ATAG 2.0 in "For authoring tools such as content management systems (CMS), blog software, and WYSIWYG editors, follow Authoring Tool Accessibility Guidelines (ATAG)."

ATAG 2.0 is in 2 parts. It should be clear that you want both parts addressed. Most stumble over Part A and barely look at Part B.

Also useful to highlight those systems that have already started addressing this such as Drupal.
https://www.drupal.org/project/issues/search?issue_tags=atag

This should also be held up as a great example of a standard that is Built in Canada:
https://www.w3.org/TR/ATAG20/

Jutta Treviranus & Jan Richards of the Inclusive Design Institute at OCAD University really lead this.

This should also be seen as a cost savings issue for both accommodation & post-publishing remediation is the most expensive way to address the system.

2. Build in accessibility from the start (draft)

This is often referred to as "accessibility by default" - most tech teams aren't starting from scratch.

Addressing accessibility early & often is key. It needs to be thought through the whole process.

The tie into open source thought is that there are existing open source libraries that are used. All libraries have accessibility problems in them. Government should be looking at the accessibility of all software projects to begin the process of selecting which stacks to develop on.

Whatever software is chosen, it is critical that government find ways to contribute back. Even if it is just submitting a bug report or a patch. Government needs to get involved in fixing the problem at the root.

Drupal is used heavily in government around the world. Contributions from all of them on web accessibility to Drupal 8 Core is still less than one blind Italian student. Government techies & vendors are not encouraged to actively contribute back, but they need to be.

Add filtering of content according to what is relevant to the reader

Since it is likely that the playbook will become very long when all the content is added, it will be important to find a way to personalize the content to make it easier to consume (only show what is relevant to the reader). One way of doing that is giving the reader filtering options using checkbox groups. Here is a possible jQuery-based approach to this:

https://gist.github.com/pjackson28/5c5e135ada0413f4ddba01f42b2dc1bb

Filter: Add option to display tags (dpgn- classes)

To make it easier to tell what has already been tagged for filtering and what those tags are (dpgn- classes) there should be an option in the filtering interface to display them onscreen.

The way of doing this is probably to use ::after and content CSS properties to display the contents of the class attribute. This could be done with CSS like the following (untested):

.show-dpgn-tags [class*="dpgn-"]::after {
  content: "<code>[" attr(class) "]</code>";
}

This could then be enabled/disable by adding/removing the show-dpgn-tags class higher up in the DOM.

Now the problem with the above approach is it would show non-dpgn classes if they are in the same class attribute and would also display dpgn- classes that are not filtering options (don't know if there are any yet). This may not be an issue at all, particularly for the separate div/section elements which wouldn't have any classes, but there could be risk when we start tagging individual list items (although this is just a theoretical risk at the moment and may not come to pass).

So probably best to initially go with the simple approach above, and only add more complexity if needed. If we are careful with how things are tagged then we may not need the extra complexity.

The links to wiki.ic.gc.ca are unavailable to other departments

The link under https://github.com/canada-ca/digital-playbook-guide-numerique/blob/085a41397de9a378bfea79a8c252e2a4308b10a8/en/4-empower-staff-deliver-better-services.md#implementation-guides-2 doesn't appear to work for people in other departments.

If this gets replaced, the check-links.js can also be updated to not exclude those links from failing the build.

How to publish the playbook to another site

Currently the playbook is being output to GitHub pages, but what about when it is time to officially publish the playbook to Canada.ca? The dataset could be made available through open.canada.ca but what about the web-based version, including the alternate views? How can it be ported to another hosting platform (e.g., AEM, Drupal, etc)? Currently it is being built with Kramdown and Jekyll/Liquid (with a JSON dataset) but what format should be ported to be portable to other platforms? Rendered HTML and a JSON dataset? Something else?

(Page: Design with Users)

https://canada-ca.github.io/digital-playbook-guide-numerique/views-vues/standards-normes/en/1-design-with-users.html
Has a section called "reusable solutions" It links to an 18F page where every single link brings up a 404 Error. May want to consider removing the link to that page from the GoC playbook as it adds zero value.

Filter: Enable pre-configured set of filter choices to be chosen through a link, button or other trigger

Should provide a mechanism to allow choosing a preconfigured set of filter choices through simply clicking a link, a button or some other triggering.

Enable setting filters through the query string
Enable setting filters through a JS call or event (e.g., passing an array or JSON of filter choices)

Provide digital playbook API

To make it easier to support other clients/devices and to enable the development of other frontends, the digital playbook should be made available through an API, including providing the ability to query/filter the content (supporting at minimum what the filtering interface supports).

6.2.1 - Does "in excess of $5,000,000?" refer to program size or individual payment

The question, " 6.2.1 Is this grant, contribution, or transfer payment in excess of $5,000,000?", makes it sound like the screening criteria is whether the grant or payment is $5M each, a threshold which few programs would meet.

If the intent is $5M total, I recommend the following text:
6.2.1 Does this program issue grants, contributions, or transfer payments in excess of $5,000,000 annually?"

Should same-page links be auto-generated using ToC?

For example, the "Guidelines" section is manually maintained which is prone to error. Since we use Kramdown, we could use {:toc}. For this to work, we would need set "parse_block_html" to "true". Should also set "toc_levels" option to "2..2" or "2..3" so that not all heading levels are displayed ("2..2" would match what is displayed now). Should also apply the "list-unstyled" class so it most closely resembles what we have now (apply to the "- TOC").

So would be something like the following in the .md file:

- TOC
{: .list-unstyled}
{:toc}

Pros:

Less maintenance since the "Guidelines" links would be auto-generated
Prevents human error breaking the links or typing in the wrong link text

Cons:

Clickable same-page links would no longer be available in the GitHub preview (not as big of a deal when the gh-pages are available)

Enable auto-deploy to gh-pages

Currently this is a manual process and would reduce effort if Travis could deploy to gh-pages automatically after each merge to master.

Instructions can be found here: https://docs.travis-ci.com/user/deployment/pages/

Provide other views?

Currently the view that is being provided is the following:

Standard
- Guideline
  - Checklist
    - Phases/Stages (e.g., Alpha, Beta, Live)
  - Implementation guides
  - Similar ressources

So everything is grouped by Standards. Should we provide alternate views where everything is group by phases (e.g., Alpha, Design or Planning)? So You would go to an Alpha, Design or Planning page and in that page would then be Standards -> Guidelines -> etc. structure. That would probably be more intuitive for readers but would mean automating the creation of these other views since it wouldn't be reasonable to do it manually.

I'm assuming it would be better for the user to have these other views (ISED toolkit divides it into four phases) but then how do we go about doing this? Can we make this a generic process to make it easy to create other views (since odds are there are other views that haven't been thought of that would help users).

Open Source Watered Down?

It really sounds like in
"6. Use open standards and solutions"

That open source is being marginalized.

Maybe the D5 Charter has changed since Canada & Uruguay became a part, but this sounds pretty clear & direct to me:
https://en.wikipedia.org/wiki/Digital_5#D5_Charter

There's another wishy washy statement in 6.1:
"6.1 Leverage open standards and embrace leading practices"

"leading practices" are the type of management speak that gave us Phoenix.

The "Using open standards and common government platforms will help the government:" also sounds like, the same old nonsense that brought us Canada.ca. 'Select & outsource our IT concerns to the right vendor and we'd have gotten it right' - that kinda thinking isn't useful.

I'm not saying that there isn't a role for common government platforms, but it just falls really short of the 2014 vision of the OGP - https://www.opengovpartnership.org/stories/open-source-and-open-government-challenges-ahead

Also, comparing with the USA playbook:
https://playbook.cio.gov/

It's like it's barely mentioned in this document.

Likewise with the UK:
https://www.gov.uk/guidance/government-design-principles

The whole "common government platform" thinking under the last government really killed web innovation in the government.

Can't we strive for a higher bar than this?

(Page: Is Agile Right for My Project? (draft))

It might be prudent to define terms such as "Product Owner". While many of us that are well versed and experienced in Agile methods understand these terms others might not. A tool-tip or perhaps a glossary is sufficient in my view. This wouldn't necessitate the requirement for one to be well educated on Agile methods prior to using the tool.

Scope of the dataset

What should be part of the playbook dataset and what should be separate? Should alternate views (e.g., comparison table) be part of the dataset, referenced from the dataset or maintained separately (although still generated using the dataset)? In the case of the comparison table, it will be sourced from the Similar resources part of the dataset, but should the introduction and/or references to the rendering of the comparison table be included in the dataset?

What about documentation for the dataset, should it be part of the dataset, referenced from it or maintained separately?

Build failing because link check is having problems with URIs passed through Kramdown attributes

@nschonni The link checker is getting tripped up by URIs passed through Kramdown attributes (e.g., data-content-source-uri="someurl"). The link check seems to escape the last quotation mark and include any characters after it when checking the URL. There can be no space between the last attribute and the curly bracket, otherwise the last attribute will be ignored. Will try changing the order of attributes but is there some way to prevent the link checker from getting tripped up?

Here is an example of the link checking failing:
https://travis-ci.org/canada-ca/digital-playbook-guide-numerique/builds/397012941?utm_source=github_status&utm_medium=notification

Filter: Clicking a sub-checkbox on should check the parent checkbox as well

Encountered a problem where a sub-checkbox was checked but the parent was not. When the filters were applied, nothing showed up because the parent wasn't checked.

Clicking a sub-checkbox on should check the parent checkbox as well so that something is displayed when the filters are applied.

Single page view of digital standards missing French

The French version of
https://canada-ca.github.io/digital-playbook-guide-numerique/views-vues/single-page-seule/en/digital-standards.html

Shows a 404
https://canada-ca.github.io/digital-playbook-guide-numerique/views-vues/single-page-seule/fr/guide-numerique.html

Restoring from json file not possible

Steps to reproduce:

Fill in form
Download JSON
Refresh page
Load JSON file from 'restore progress from a file'

Expected: Form loads with previously filled information.

Instead: Nothing happens in browser. Console shows:

Same behavior in Chrome 73.0.3683.75 and Safari 12.0.3.

Filter: Add filter choice persistence between pages and sessions

Update filter script to:

Remember the filter choices between pages (writing choices to HTML5 sessionstorage on every Apply filters button click and reading from sessionstorage and setting the choices on every page load)
Remember the filter choices between sessions (writing choices to HTML5 localstorage on every Apply filters button click and reading from localstorage and setting the choices and sessionstorage on first page load of a new session)

Length of the sections

I think there's lots of good stuff here, but it needs to be trimmed down a bit. Some of those resources should be put elsewhere. Lots of good 101 things, but that should probably live somewhere else.

There are a few that are of a similar length. Ultimately the playbook should be punchy & readable. Supporting links and material should be housed and possibly maintained elsewhere.

Also, I hope there are images, colors or visuals going ahead.

How to automate related guidelines links

Currently the links in the related guidelines section are manually maintained. The links point to sections in other pages. Would be ideal if there was a way to automate these links to avoid human error/sync issues.

View source on GitHub

Links in:
https://canada-ca.github.io/digital-playbook-guide-numerique/views-vues/standards-normes/en/2-build-in-accessibility-from-start.html

to "View source on GitHub"

go to https://github.com/canada-ca/digital-playbook-guide-numerique/blob/master/views-vues/standards-normes/en/2-build-in-accessibility-from-start.md

Which isn't actually markdown. Not clear where that text actually is.

Usually the view the source would go to the raw document where you can see either the markdown or HTML. This goes to neither of them.

Add link checking functionality

Provide single page view

There should be the option of a single page view. This should be done by combining the separate pages into one.

Suggested work items:

Combine content from the overview page and standards 1 to 10 (possibly through Jekyll includes)
Increment levels of headings in existing content (one possible way is to make copy of .md files and in those copies replace "##" with "###"; afterwards including the copies in the single page)
Add Overview title as an h1 and titles for standards 1 to 10 as h2s (since all the titles are current being externally added as h1s)
Fix related guideline links (strip file reference from the URL, leaving just the URL hash)
Fix links to the standards in the Overview page, changing the links to the pages to URL hashes (so same page links meaning each target heading must have to an id to target)

Data sources?

I'm very curious to know where the statistics came from. 14% of people perceiving themselves as having a disability is clearly from census data.

But 38% of people with invisible disabilities and 50% of people with age-related disabilities are pretty strong statements to make, and without citing a source, or explaning a method to arrive at these numbers, it will be very difficult for a lot of people to trust these numbers.

How to deal with images and videos through the dataset

The dataset approach that is under development is primarily text-centric, but how should it deal with images and videos? It is likely that the playbook content will include images (and possibly videos), so how should they be dealt with?

Should they just be referenced in the content (e.g., img elements that point to images hosted somewhere) or should they be embedded in the dataset itself (e.g., base-64 encoded)?
Should we go with just one approach or provide separate datasets for each approach?
For the reference approach, where should the images and videos be hosted? What about when the dataset is hosted elsewhere? Should the the images and videos alwats follow the dataset or should they be hosted separately?

Automated checks for the dataset?

What type of automated checks should be set up for the dataset and the authoring methods that feed the dataset? There will be alternate views that are dependent upon the dataset so how do we automate the checks for new/updated data within the data structure, and and changes to the data structure itself? Ideally the automated checks could flag any changes that could cause issues in alternate views (e.g., automatically test run the changes on all the views and run a series of test cases covering the common usage sxenarios, flagging warning/errors for issues that may arise.

Filter: Show active filters outside of filter interface

Currently you have to go into the filter panel to tell which filters are active (use "Show filters" button). It would be helpful to have the active filters visible outside of the panel (just as text) so the user is aware how the content is being filtered. This becomes even more useful when filter persistence between pages and session is added since the user may not remember which filters are enabled, or even that filters are enabled.

Provide digital playbook as a dataset

All the digital playbook content should be made available as a dataset (e.g., JSON, XML), so it could be used in non-HTML scenarios (and even for HTML scenarios such as API output to an HTML page). The build process should be configured to generate this dataset automatically.

Filter: Should look into contributing the filter functionality into WET in the future

Should build it so it is compatible with WET4 (built like a plugin) and then later contribute it if there is interest.