Targeting (who) and formats of publication (how)

[noraferreiros]

#This is the most essential of the discussions because it will shape the entire project: how we are going to publish the guidelines and who are we going to talk to. After some meetings, we have clear that one conditions the other, so we will keep the discussion together until we organically need different issues (if that is the case).

Here is a summary of what we have so far:

👥 TARGETING
Some thoughts that have come up on this.

• How will each profile find the information, and can we ensure that all will access it?
• Should the format, location, or structure of the content be different for each profile?
• Should we start with one user group and expand to others later to avoid slowing down the project?
• Is it necessary to have different content for developers and designers, or can they be combined under a single “professional users” profile?
• Which group stands to benefit the most from web sustainability practices?
• Should we avoid segmenting users and focus on providing generalist information that is useful to everyone?

Proposed approaches.

• Three different levels for different expertises: basic user (non-professionals), independent user (professionals non-developers) and proficient user (basically, developers). Variation: Limiting it to two approaches: basic users and professionals.
• Divide the information not according to types of users, but by subject matter, and then establish actions from less to more complex.
• Let the formats decide the targeting.

🗒️ FORMAT
Format proposals so far.

• A traditional handbook, similar to what we’ve created for more sustainable WordPress events.
• More intuitive and hands-on formats like “101s” and tutorials.
• A referential format that points to existing documentation on web sustainability.
• Courses or tutorials for Learn WordPress.
• A format that provides the Sustainability plugin users with specific information for issues as they arise.
• A format adaptable for publishing on the Developer Blog.
• Include a “not-fun-facts” introduction section, similar to this example.

🧠 TO KEEP IN MIND
It's more important to do this project real than perfect. The priority is to choose an approach that is suitable to the resources we currently have. Projects evolve and we expect this one to do so. So, drop your feedback taking into account that the objective of this discussion is to lay the groundwork for the project so that it can grow from there and scale over time as more contributors join.

📚 Check where this info comes from here, here, here and here.

[CeliGaroe]

Hi! After considering the options, I think I vote for the second approach: Divide the information not according to types of users, but by subject matter, and then establish actions from less to more complex. But with a clear division, so people can pay attention only to things they can do.

Regarding the format, I would go for a format that provides the Sustainability plugin users with specific information for issues as they arise. But of course, this is not an exact answer, just what I think we should have in mind when formatting the info. Perhaps we should go for what we can do easier/faster with the resources (including human resources) we have and then moving that information to a more intuitive format when we have the opportunity.

[LittleBigThing]

I think it has been mentioned once during a team chat but we have looked at the structure of the accessibility handbook during Yoast’s contributor day with @marinakoleva, @YellowlimeNL and @nahuai and its structure is interesting: hands on, not really based on type of user, more on theme, so I'd like to mention it here.

It is split up into:

• (Basic)
• Development
• Design
• Content

These seem to be understandable categories that different users can easily associate with. They relate to the categories made in the Web Sustainability guidelines as well:

• (Basic) = rest? :-)
• Development = Web Development (and Hosting and Infrastructure)
• Design = UX Design
• Content = Business Strategy & Product Management?

[noraferreiros]

With the purpose of unifying topics, I leave here what has been written in the Yoast Contributor Day document in this regard in order to discuss it all together.

Ways how we can structure information:

Guidelines

Apply same format as https://make.wordpress.org/accessibility/handbook/best-practices/ What’s very smart: per topic an introduction, best practices and reference to additional resources. (we could use similar structure but differentiating the task by levels -easy, medium..-).
Same structure as Web Sustainability Guidelines including impact and effort needed to apply a change

Plugin

Ideally, we show suggestions of next steps to take inside WP-Admin, based on a predefined list of actionable steps. (those are defined based on minimal effort, huge impact, 10 steps maybe to color your website score from grey to green)
Yoast’s premium plugin takes the user by hand to perform changes step by step.

Lear WordPress

Featuring ‘it’ on https://learn.wordpress.org/

[noraferreiros]

I'm totally in with taking Accessibility Team Handbook as a reference, even more if it matches with the Web Sustainability Guidelines. Everything will be easier this way.

About the plugin, it depends more on technical aspects but, as a designer, I can tell that the best way is to give the information in the exact moment the user will need it. Not in a general way like "look here" but "do you want to know exactly how to resolve this? Here you have the exact answer". This is the utopian way of doing it. If possible, great. If not, we'll do as better as we can.

And, after that, I agree with the idea of taking specifics parts of the guidelines and use it to create content for Learn.

[noraferreiros]

Ok, I'm working on a GDoc to start to put the information as in the Best Practices chapter in the Accessibility Handbook. But we need to decide our own sections. They have:

• Development
• Content
• Design
• Testing for web accessibility
• Training and resources

Taking into account the first information collected here I'm not 100% sure which sections should we use, but we can begin with the same ones and change it later:

• Development
• Content
• Design
• Monitoring and Analysis
• Training and resources

There's a suggestion about differentiating tasks by difficulty levels (and we discuss about this in Slack). In the Accessibility Handbook the main sections are divided into topics, like this.

I think it's ok to do it by topics as in the Accessibility Handbook to keep things simple, at least at the beginning.

[YellowlimeNL]

Sounds to me as the right approach @noraferreiros. I in particular like the way the Accessibility Handbook touches the various topics by:

• Introduction
• Best practices
• Examples
• Additional resources

In our case the best practices section can contain low-hanging fruit or those actions that need a minimum of time to implement but have a big impact. For more advanced or more difficult practices, we can link to external resources (for the moment).

[noraferreiros]

Good point here, @YellowlimeNL! I fully agree with you on this.

[CeliGaroe]

Sounds good, @noraferreiros. And also @YellowlimeNL suggestion. I wonder though if those sections are easy to understand to a plain user... If the content is for all (included not professionals), I suppose we need to ask ourselves if someone that doesn't know anything about development or design is going to know which section interest them the most. Perhaps the best sections are still those ones, I don't have a better suggestion, but maybe development is something a plain user would never check out, because it sounds too far away from their skills. Rethinking naming could be a solution to this?

[YellowlimeNL]

That makes sense too @CeliGaroe. A different approach can be: We mention 10 actions to make your website more sustainable (e.g. 1. Optimizing images, 2 Caching, 3, Disabling what's not needed (like cleaning up unused plugins, improving settings for indexation by bots etc). and so on.

[noraferreiros]

Also good point, @CeliGaroe . I thought quite the same when I wrote my comment in relation to the profile that in Spanish we call “implementers” —not developers, not designers, just WordPress sites builders—. And @YellowlimeNL proposal seems a user-friendly one (focused in the action, not in tagging the users). In order to move this forward, and if nobody has another idea, I'll try my best to do a first section proposal based on the resources and information collected at Yoast Contributor Day. If anybody wants to make it too, feel free, obviously.