Revamp https://webcompat.com/contributors

[miketaylr]

I think the content can be improved, and likely the design as well.

@adamopenweb would you like to do a review of the content? I think your work on onboarding might give you some good insight here.

[miketaylr]

(Also we should be able to link to each section individually....)

[adamopenweb]

Oops just realized I didn't respond here, I'm on it though.

[adamopenweb]

I think we need a better introduction to this and description. I would like to make small videos that compliment each section which should make the site seem more personal. Also for language, I think the introduction should be much less technical.
Edit: The language should also show web compatibility in a positive light.
The content on the page already is good at describing the process and most can be used again.

Here's a rough draft of the introduction.

[adamopenweb]

Welcome aboard! You can make a real difference for others on the web.

The web is for everyone to create, explore and discover. Every day people are building new websites while imagining new ways for others to consume content. This is exciting for us because we love to understand how websites work. There are many venues to browse the internet: on computers, phones, tablets, TV’s and more. People expect websites to work regardless of the device or browser they are using. Sometimes it can be challenging for website developers to make that happen with every possible combination. This challenge is what we are passionate about. We want to make the web accessible to everyone regardless of the device or browser they choose. We need your help to make this a reality.

At Webcompat.com we strive to:

• Discover
  • Website issues in any browser.
• Understand
  • The problem with the website and how to correct it.
• Communicate
  • The problem and resolution to the right person at a company or website.
• Improve
  • Processes and tools to make the experience better for the community.

{{ Why you should contribute - _Needs more work_ }}

You can make a huge difference in less than 5 minutes. Anyone can get involved.

• This is an open invitation to participate in the web compatibility effort.
• It’s OK to try and make mistakes, this is an opportunity to grow personally and professionally.
• Learn web development and standards from a different perspective.
• It's challenging, engaging, fun and social.
• Make new contacts in the community and with companies all over the world.

How to contribute
There are many different ways to contribute and they can be grouped in to three categories:

Web bugs
{{ each point will have a link to the section with more detail }}

• The easiest way to get started is to learn how to identify a web compatibility issue and file a bug report.
• When you’re looking for more of a challenge you can try triaging new bug reports.
• If you’re looking to flex your web development muscles you can try diagnosing verified issues.
• For those who like to search online you can find contacts at companies and websites.
• Another easy way to get started is to contact companies and websites.

Developing webcompat.com and tools

• Great design doesn’t come easy, help to mold the identity of webcompat.com.
• Thousands of people use our website, help them by writing code for webcompat.com.
• Communicating with regions across the world is difficult, help with localization.
• If you’re into crawlers and automation, help us build tools for automated testing.
• The community makes decisions together, join us in the decision making process.

Community building

• Take what you’ve learned and share with others, use these slides as reference.
• Setup local community meet ups to talk about issues that affect your region.

[haseebgit]

i think we should add about communications, like how to reach out individual team member or team, communication channels, weekly meetings, mailing list etc

[adamopenweb]

That's a good point @haseebgit. Maybe we should expand the Contact page a bit and add something to the welcome section here.

Also a few links to keep in mind while working on this page:
https://github.com/webcompat/webcompat.com/wiki/Contributor-role:-Issue-Triager
https://github.com/webcompat/webcompat.com/wiki/Contributor-role:-UX---Design
https://github.com/webcompat/webcompat.com/wiki/Contributor-role:-Web-Opener

[shwetaseema72]

i think the contributors link should also be on the top so that the more number of visitors can see it and contribute.

[zoepage]

I love this thread. So many really good ideas already! :)

The Rust community is well known for a good on boarding of new contributors. The structure of their index is clear and you are able to find everything really quick.
https://www.rust-lang.org/en-US/community.html

https://community.rs/resources/

[lockettm]

As @zoepage suggested, I drafted specific roles that outline the ways to contribute. It’s a high-level overview of each role with links to relevant documentation and resources. I’m not sure if the tone of voice is friendly enough--I tried to keep it conversational but concise. Feel free to make any edits or suggestions.

I also reworked an introduction, as I think the first half of Adam’s previous draft is well suited for the About page changes mentioned in #1296. However, I’m not sure--so let me know your thoughts.

---

Join us!
Learn new skills. Connect with others. Improve the Web.

We believe everyone should be able to use the Web from whichever device or browser they choose. You can help us make this a reality. We welcome all kinds of contributions. Whether you want to code, design, write, or outreach we can use your help!

Explore the different ways to get involved below and reach out to the community on our IRC channel or the public mailing list. We’re here if you have any questions or if you just want to say hi.

Bug Reporter
The easiest way to get started is to report bugs you find on the internet. Anyone can identify a web compatibility issue and file a bug report. It’s the first step towards resolving an issue, as we can’t fix bugs if we don’t know they exist.

Issue Triager
Before we can find a fix we need to figure out why it’s broken. A simple way to help is to confirm a bug by seeing if you can reproduce an issue. If you’re comfortable, you can then use developer tools to help diagnose issues by looking for errors in the console and explaining what needs to be fixed.

Web Opener [Perhaps a different title?]
Once the community has an understanding of a bug and how to fix it, it’s time for outreach.
Search online to find contact information for sites and companies then send them a message explaining the issue. It’s a simple way to get involved and make new contacts with companies located all over the world.

Community Builder
You know all about Web compatibility issues and want to help spread the word. Speak or write about webcompat.com to share what you’ve learned with others. You can even host a local community meetup to talk about issues that affect your region.

Site Contributor
See something on webcompat.com that could be improved? Suggest a change or a new feature by filing an issue.

You can also contribute by:

• Writing code for an existing webcompat.com issue
• Making a UI or UX design contribution
• Using your native language to help with localization
• Helping build tools for automated testing

[miketaylr]

Great work @lockettm, the content is such an improvement.

Web Opener [Perhaps a different title?]

It's a funny term, but I think it works. I may or may not have had this as a real job title in the past. >_>

I think next steps are probably to start wire-framing and think about how to design this, and then build it. @lockettm do you have any ideas here? The giant click-to-reveal stuff with overly big screenshots isn't the most elegant. ^_^

[lockettm]

@miketaylr Ahh okay, Web Opener works.

Yeah, the current “how to” panels demonstrate the process well but I agree, it’s a bit clunky.

We could reformat and add the content to tabs (similar to the mock-up below) as a sort of “quick start guide.”

Or, thinking ahead, we could build out landing pages for each role?

[miketaylr]

I like the tabs idea, visually. I assume that would just turn into a vertical list for mobile.

[adamopenweb]

I agree, the tabs look nice. Also, we don't have a high percentage of users on mobile currently.

[zoepage]

@lockettm great work :) it looks so much cleaner.

[karlcow]

Adding @magsout to the discussion for the implementation part of the design.

• The navigation list as tabs is implementable. The issue comes with the smaller screens layout. @miketaylr mentioned vertical list. Maybe with flexbox and reordering the boxes with smaller viewport. That would be an interesting thing to test.
• The description roles can be implemented as flexbox. Similar to what I did for the boxes of http://www.la-grange.net/

[lockettm]

@miketaylr A vertical list for mobile or an adapted design like the one below--not sure how difficult it'd be to implement.

http://codepen.io/hayatbiralem/pen/KpzjOL

[karlcow]

@lockettm from what I read these days, carousel and UX seem to no be friends. :)
http://shouldiuseacarousel.com/

[lockettm]

@karlcow Didn’t think of it as a traditional carousel i.e. it’s below the fold, not on the homepage, doesn’t look like an ad, no auto-rotating—which I agree can be frustrating. :)

That said, a list does have the benefit of displaying all of the descriptive titles—assuming the user scrolls beyond the expanded content.

[magsout]

@karlcow agree with @lockettm's Argumentation.

The website you mention is about big carousel on HOMEPAGE for marketing.

[magsout]

@lockettm interesting idea. I like the layout. And the idea of tab is nice.

Your example for small screen is pretty good.

[denschub]

Or, thinking ahead, we could build out landing pages for each role?

The screenshot in #1149 (comment) looks worrying, the page is way too long to me, so I am definitely for splitting this up into at least two pages. Also, the "bottom" part of the contents look much nicer than the wall of text above.

However, aside from being picky, I don't have a solution for that available right now, but maybe that's something to think about.

[karlcow]

ah good points everyone. Thanks @lockettm @magsout and @denschub

I think I agree with @denschub too. URIs are cheap. We are not forced to put everything on the same page indeed. Lighter page given us space can indeed be nice too. :) It's not like people need to read a novel. We can even have more than two pages, specifically if we start to hide the content through tabs and navigation artifacts, we can as well, put them on different pages. :)

[zoepage]

URIs are cheap.

But clicks are not. ;) When we split up the content on different sites, this means an additional click. So we'd need a good directing concept first?

[karlcow]

hmm I miss something. Are you talking about latency, or about actions. Because in the two cases, we will be clicking. change tab content, or change page. And for the latency I don't think it matters in this case given the content size.

[zoepage]

@karlcow about action. open / close a tab on one site is different than leaving a site and moving to another.

[denschub]

I highly doubt that a click is worse then getting a wall of text. :) But I agree we need to have a good plan of what we want to do before we do it. (<-- most logical sentence ever)

One idea would be to directly talk to the contributor on that page. I've seen a nice introduction into contributing to a project before, but I don't remember exactly where. Basically, there was a list of actions a contributor could help with:

I want to…

• …report a broken website.
• …help build a community around web compatibility.
• …help teaching web developers on how to avoid compatibility issues.
• …help triaging, reproducing and adding more details to issues.
• …dig deep into website sources and find issues.
• …get in touch with site developers to resolve issues.

Where each item would link to the corresponding documentation with further details. In theory, we could even make something very interactive, asking questions like "Do you like talking to people?" or "Do you enjoy debugging issues deep inside source code snippets?". I remember we had something like this for mozilla in the past, but I don't remember the name that was put under.

[magsout]

@karlcow

And for the latency I don't think it matters in this case given the content size.

Disagree, The latency in france is horrible on mobile network..

it's why actually is better to have one big size file than 4 small file 👎

[magsout]

@karlcow @denschub

It's not like people need to read a novel. We can even have more than two pages, specifically if we start to hide the content through tabs and navigation artifacts, we can as well, put them on different pages. :)

Hum, we are talking about documentation and motivation.

When I read an article, I like this small component than display time to read the entire article. If it's > 5 minutes, I added it on read later.

But for documentation It's different IMHO.
If you take the example of webpack, I agree. But If you look at the design of @lockettm , there is not a lot of reading. And I prefer to have everything on a page that on 5.

We do not risk losing people if they click on 5 links?

[lockettm]

Thanks for the great input everyone.

I should note, I’ll be testing redesign suggestions as mock-ups with users for feedback. So two design concepts with a range of ideas is an option for this first design iteration. Eg tabs vs separate pages (if there are no objections due to technical concerns).

I’ll take our collective assumptions and ideas to create additional variations to be tested.

[lockettm]

Updating this discussion to add some insight gained from user testing.

Picking-up from a previous point, I vote for separate pages for the how-to guides. It didn’t seem to slow down users when they were asked to locate documentation.

Also, the "bottom" part of the contents look much nicer than the wall of text above.

On the mockup, I added small icons to each role in hopes of visually breaking up the heaviness of the text (We'll need new icons if moving forward with this and #1374). However, one user still commented that it felt like too much text when they landed on the page. An option is to get rid of the double columns, with the goal of making it feel less overwhelming.

Also, some users were confused about contributing beyond the 3 part bug lifecycle. One fix may be to separate the roles into two separate sections. “Help Fix Bugs” and “Contribute to the Site/Community” for example.

[miketaylr]

I vote for separate pages for the how-to guides.

That's cool. It's also simpler to build.

Also, really great work @lockettm.

[karlcow]

separate pages are also better for linking.

[zoepage]

For reference and context towards the icons:#1374 (comment)

[karlcow]

@lockettm do you have the texts from the mockups somewhere. So we do not have to type them again? Thanks :)

[zoepage]

@karlcow We might not need the texts as #1933 is about new content, not the one above.

[zoepage]

closing as this is in progress in #1933