Attendees: Daniel Appelquist (Samsung), Jory Burson (Bocoup), Kyle Pfug (Microsoft), Dominique Hazael-Massieux (W3C), Meggin Kearney (Google), Chris Mills (Mozilla), Robert Nyman (Google), Ali Spivak (Mozilla), Kadir Topal (Mozilla).
- Date/Time: June 4-5, 2019
- Location: Mozilla Berlin office, Schlesische Strasse 27, 10997 Berlin, Germany
- 9:00 Arrive at the Mozilla office & breakfast
- 9:30 Welcome & Orientation
- 9.45 Review action items from January
- 10:30 MDN status January-June
- Product (Kadir)
- Content (Chris)
- 12.30 Lunch
- 13:30 MDN H2 content plans
- 15.15 Break
- 15:30 View Source conference discussion (Ali)
- 16:00 Other topics
- TAG: Ethical Web Principles (Dan)
- PWAs discussion (Dan)
- 9:00 Arrive at the Mozilla office & breakfast
- 9:45 DNA Survey discussion (Kadir)
- 11:30 Break
- 11:45 MDN Membership update (Ali)
- 12:30 Lunch
- 13:30 Working sessions
- 16:30 Wrap up session
- Action item prioritization
- Decide on next meetings
- Update how Edge is referenced in web compat tables: mdn/browser-compat-data#3705 [Kadir]
- Drop Edge mobile from the table rendering on MDN and maybe also from the data? (related issue: mdn/browser-compat-data#3888 ) [Kadir]
- Look into doing a combo View Source/TPAC event in 2020 [Ali]
- See if there is interest in a Developer needs survey results talk at TPAC 2019, also a breakout session soliciting participation from W3C community. [Dom]
- [done] Share screenshots of State of the Web dashboards for India, Indonesia and Japan w/ PAB members [Robert]
- Content collaborations/partnerships - following up on conversations from collab summit & other ideas [Chris]
- Update the experimental spec warning banner to ask for feedback on the spec [Chris]: #58
- Meeting with Google & Mozilla about learnings from migrating docs to GitHub (Ali, Meggin): #37
- Share the MDN Beta performance numbers with React with PAB members [Kadir]
- Connect Kadir w/ Sebastian on React [Robert]
- Figure out what the default set of browsers should be for MDN customization [Kadir]
- Consider using customization w/ framework set [Kadir]
- [done] Follow up w/ Kyle on some possible help with Web Authentication doc overhaul [Chris]
- Updating MDN spec tables [Chris & Dom]
- Keep info on W3C specs up to date on MDN [Dom]: #19. Yes, it would be good to move forward on this
- Next steps: Come up with a plan to agree upon.
- Follow up on framework documentation on MDN [Chris]
- Add an item to our agenda to talk more about MDN and GitHub [Ali]
- Help Kadir w/ connections to the Lighthouse team re: browser compatibility audits
- Original issue Meggin created (that got closed by Lighthouse team): GoogleChrome/lighthouse#4377
- Create a description & goals of conversation areas at View Source [Ali]
- PWA issues:
- [done] Create GDoc to start brainstorming new PWA content [Chris] — see MDN PWA docs update, 2019
- Form a team & figure out “f2f” working session on PWA’s [Dan & Ali]
- Put together a GTM template & short description of the developer needs survey for partners (blog template description of survey, methodology, who has contributed, how it could be used) [Kadir & Ali]
- Work on guidelines for supplemental/membership content on MDN web docs, curation, etc [Ali]
- [done] MDN Q2 update:
- The customized MDN experience: Update on strategy and progress
- High quality browser compatibility data: Automation and crowdsourced feedback. Update on strategy and progress.
- [done] MDN Web Developer Needs Assessment: Early results.
- [done] PWAs discussion - PWAs on different browsers.
- Link to/from PWA Builder
- [covered yesterday, will follow up on structure of docs] Content collaborations/partnerships - following up on conversations from collab summit & other ideas
- How do we want the new Edge to be represented? Both in the data and in the tables on MDN? (related issues: mdn/browser-compat-data#3705)
- Followup; can we drop Edge mobile from the table rendering on MDN and maybe also from the data? (related issue: mdn/browser-compat-data#3888 )
- [done] Ethical Web Principles
- [done] PWA documentation
- MDN PAB & cross-standardization orgs needs
- There are a number of topics, etc covered by different (standards) orgs/groups developer relations, discussing how to have a more organized approach. PAB is one area the common need may emerge.
- How specs are represented, how we classify what is experimental, getting feedback on specs, etc.
- Common requirements (for example using GitHub)
- Figuring out how MDN / PAB could fit within this work
- MDN@TPAC
- 2020 TPAC will be in Vancouver, maybe do a combo View Source/TPAC?
- May experiment with opening plenary session up to “public”
- Some sort of joint MDN/TPAC event would be great
- 2019, maybe do a talk on Developer needs survey results, also a breakout session soliciting participation from W3C community.
- 2020 TPAC will be in Vancouver, maybe do a combo View Source/TPAC?
- 5 minutes from Robert
- State of the web in India/Indonesia and Japan
- Need of feedback loop for new web platform features
- Wordsmithing developer needs survey
Items needing follow up:
- Update the experimental spec warning banner to ask for feedback on the spec [Chris]: #58
- Not done yet - will work with Dom to identify candidate specs
- Keep info on W3C specs up to date on MDN [Dom]: #19. Yes, it would be good to move forward on this.
- Next steps: Chris and Joe will share proposal with PAB & MDN team. Come up with a plan if it is agreed upon.
- Do some triage on Microsoft priorities for Web Component docs and get back to the board members [Patrick]: #6. The web components docs on MDN are fairly cool. Is anything else needed? (closed)
- Discuss getting developer feedback in APIs/usability studies [Kadir]: #59. Another nice-to-have. Did this go anywhere Kadir? [Keep open, will look into this after Developer Needs survey)
- Designate a point person at your org to do compat data pull request reviews [Kadir, everyone]: #32. Yes, we should do this. Again related to BCD governance project Florian is working on.
- IE is one area people are looking for. Can generate a list of what is missing for IE ACTION: [Chris] - follow up w/ Florian to generate the report and follow up with Kyle for inputs
- Close this issue, raise another one on IE compat data
- New plan on getting 100% BCD to be presented later by Kadir
- Everyone to check to see what their orgs are actually doing as far as updating compatibility data after each release. Implement a system to do this if not. Will report back on this next meeting [Daniel, Patrick, Meggin] — #31.
- Next Steps: Chris send around again for PAB members review, approve, get the right point people connected with Florian to move forward. Follow up meeting with point people scheduled.
- Meeting with Google & Mozilla about learnings from migrating docs to GitHub (Ali, Meggin) — #37. This would be a useful exercise. Maybe just do it as an async exercise (get the Google folks to write some thoughts in a doc?)
- Next Steps: Ali will connect Will & Ryan with Meggin (keep open)
Closed actions:
- Start conversation with caniuse about MDN schema [Kadir]: #54
- Highlight feedback loop from MDN articles to W3C specs / GitHub repos [Chris]: #25
- JS Foundation MDN cross-promotion [Ali]: #61.
- Provide more information on what "supported" means on MDN [Chris, Florian]: #33.
- Determine if we can automate PR assignments through a GitHub hook [Kadir]: #36
- Look into compatibility data integration with WebHint [Kadir, Dan]: #52
- Happened, generated useful feedback on BCD
- Dan noted issues with accessibility on the current built-in MDN Editor. Moving to a more modern platform w/ ability to do more integrations will be helpful.
- Localization = Google is looking into git localize.
- Machine learning vs human translation - challenging
- When we move to git we'll have to pick something.
- Google always prefers to serve a localized version if available, even if it is out of date. Might make sense for the canonical version to be most recent.
- Would-be translators of MDN don’t know where to start.
- We should figure out what is the most important content to translate. Ali - seems like guides, tutorials, etc., would be more important to translate than reference pages.
- W3C - ask translators to wait until specs are finalized before translating, since beforehand there is a lot of change and things can quickly get out-of-date.
- For other content, there is a grace period before translations get pulled out after substantive edits in the original
- Mostly covering the last 3 months
- Idea from Jory: Make a blog post on practical dev about the dev needs assessment &/or MDN love story
- <add link to presentation)
- Traffic Update
- Goal for 2019 is 10% growth; we measure 28 day. periods, which means you get the same number of weekends (MDN traffic drops over weekends). Year over year data is the most stable.
- Q: Have we noticed significant effects on traffic of big events (like Olympics, World Cup), etc. A: No, have not noticed any effects. Big national holidays do tend to have impact. Lunar new year, for example.
- In May we had 13% y/y growth, 13m users per month. Seasonality has effects.
- Search traffic is 85% of overall traffic. This is good because people want to find MDN, bad because it is also affected by SEO, etc.
- Referral traffic is also going up, except from Stack Overflow - dropped precipitously. One reason could be that they removed MDN links when they launched their own documentation, and when that went away they never re-added the MDN links.
- Search traffic from the US is down 5%, which is vexing. We looked at all kinds of patterns, there is no apparent pattern we (or our SEO expert) can discern. Stumped. Hunch is that W3Schools new features are pulling traffic. Or might be Google is displaying results in the US somewhat differently, but we don’t know. It is not straightforward.
- In March, traffic overall was down due to SEO issues; we fixed those and all other countries recovered, except US.
- Usage is really low on mobile (5%). We think this s because MDN is so CPU reliant. We run a lot of unused CSS on the site + a lot of JavaScript. It's a legacy codebase that needs some changes.
- We don’t have resources to dig into it at this point.
- Web.dev created React-specific docs and these are getting a lot of traction
- Moving MDN to React-based front end
- Know this is controversial
- Was running 7-year old JQuery & JQuery UI
- CPU usage will go down, and performance will go up
- Interested in seeing the performance numbers with React
- On a Recent Google trip in India, they witnessed lots of movement to React, but there is a big performance hit. They couldn't address it because they were all-in on the move.
- One gate is performance parity. Currently looking at synthetic measurements, which are currently at parity.
- Worried about long-term improvement, because when you buy into React, the cost of transition gets high.
- We are using server-side rendering to help mitigate this.
- Architecture: server-side rendered version of the document page, load react, then hydrate the parts that are custom to you. Using React to help us do the static content + customization.
- [done] Robert can connect Kadir w/ Sebastian on React
- Doing some defensive work on communications around this, there will be a political price for this.
- Q: should the MDN code base be a showcase for where the web is going? We can’t resource it to be so - it’s more about the content.
- Long-term web components would be preferable, but it’s hard to manage state using them. Once we get to structured content and separating out, it will be much simpler/easier to replace React long term (we should make sure we highlight this when we launch).
- Accessibility is another highlight, React has good accessibility tools.
- We have a new UX designer working on MDN, so used this opportunity to make some updates
- If you put beta in front of any MDN url you will see the new react site (beta.developer.mozilla.org). We’re not promoting this
- Have separated out the wiki editing part - anyone who logged in was paying the price re: performance. We are separating the editing function, so when you hit the edit button you go to wiki/developer.mozilla.org, which will be on the old framework until we do the contribution migration to GitHub.
- Logged in: Custom BCD.
- We will show a banner saying that if you log in & create an account, you can set browsers & versions you care about & save. Then users will see a banner showing that the feature is not compatible with their set.
- We are not customizing the table; user research indicated they want the whole table, not a subset. We will look into testing sorting the table based on the set.
- Also, we'll show which browsers specifically don't support a feature (vs. generic message)
- Versioning will be simplified based on user testing. We will also implement a default set since it is a lot of data for them to choose. We can send a signal/nudge on what best practices are. Will need to figure this out as far as providing data, politics, etc.
- Q: Have we considered frameworks in this, using customization w/ framework set? We could customize our data based on which frameworks people use. Interesting idea down the line.
- BCD
- Adding 1% per month coverage, looking at different approaches that are less manual.
- Collaboration with caniuse - started discussions in March, having meetings ~ every 6 weeks. There's a strong interest in collaborating; this is beneficial to developers as it’s less confusing.
- Technically, there are some blockers; the representation, data structures, granularity are all different.
- MDN is very hierarchical, with deep granularity; caniuse is more ad hoc.
- We should be able to map ~80% (200) of the overlapping data items
- Next step is for caniuse to come up with an experimental representation of MDN data. Next meeting is in a few weeks.
- SEO
- We were rate limiting indexing; we've turned it off for MDN
- This has led to reduced server errors
- Google Search Console is now tracking Security issues; security will be a big focus area for Google over the next year
- Title change experiments didn’t have any impact, so we won't move forward. We are sticking with what we currently have.
We documented all platform changes that occurred in these versions of Firefox:
The year of maintenance. Cleaning up existing stuff, rather than just focusing on new stuff.
- Event reference migration
- Very nearly complete (one small user story left to finish)
- Old events ref
- New events example
- Much better. No longer the long long list of events in one place.
- Still want to make some clean-ups in old events page.
- Cleaning up API sidebars
- We are making sure stuff is displayed in sidebars properly. Able to specifically display dictionaries and types, rather than incorrectly dumping things into interfaces.
- browser-compat-data quality improvement project
- For CSS:
- We started with CSS — important but also difficult to get data for (the bulk is APIs, which should go faster)
- We've completed data for Firefox, IE, and (almost) Edge. Chrome and Safari are our current focus. Overall the CSS data is 85% complete (60% when the project started).
- For more details see the CSS OKR issue: mdn/browser-compat-data#3710
- Overall progress:
- Data is 59% complete (52% when the project started)
- The year goal OKR and more details is this issue: mdn/browser-compat-data#3555
- Slower growth than CSS coverage because there’s tons of data.
- For CSS:
-
Subgrid
-
New "Introduction to CSS" learning module
-
steps() timing functions
-
CSS env()
-
Scroll anchoring
-
Scroll snap
-
Logical properties
-
User-preference-centric media queries (L4/5)
-
L4 selectors (case (in)sensitive attr selectors)
-
Intl.RelativeTime format, and other i18n features
-
globalThis
-
Hashbang syntax
-
JS modules guide
-
Async JS learning module
-
matchAll() string method
-
Service worker features
-
WebRTC features
-
Storage access API
-
Reporting API (incomplete)
-
Resize observer API
-
Streams API
-
Media formats on the web
- Audio stuff up
- Image formats work-in-progress
-
Performance docs/Hack on MDN
-
Accessibility docs/Hack on MDN
- Fairly decent beginner guides, but we didn’t have more detailed accessibility guide. Now we’re documenting ARIA roles, with proper examples.
- Implementing checks in Firefox DevTools for accessibility — engineer for that has asked Chris to have links from these checks to new docs.
-
CSS Houdini
- Relatively stable enough to write some docs (PaintAPI, TypedOM).
- Happening in the next month or two.
-
WebXR
- Waiting for API to get stable enough to justify writing docs.
- Group went back and re-designed the API, so this has an impact on stabilization.
- Working group meeting in Portland this week.
- Action - Chris to follow up w/ Kyle on some possible help with Web Authentication doc overhaul
-
- At Open JS summit, we talked about Frameworks. Discussion around providing help on frameworks.
- One idea: have a load of little snippets or tidbits on different JS pages about frameworks. Useful things that people might need. Have these tips available as structured data.
- Another idea: lower hanging fruit-- get framework vendors to link from their documentation to MDN.
- Another idea — web related section in documentation. Could be a space for framework content. Smaller frameworks could document on MDN.
- Final idea, but the one with the most interest: write a bunch of beginner’s learning materials for frameworks. Very high level docs that are easy to maintain that then link off to framework docs. Landing page for frameworks. Give beginner’s something to go on, so they don’t feel so intimidated.
- Discussions around covering JavaScript beyond the client. More information on writing server code in JS (node).
- Idea to say whether or not JS API can be used in server code.
- At Open JS summit, we talked about Frameworks. Discussion around providing help on frameworks.
-
- A lot (like 80%) of links to old specs come from MDN
-
- Could be some interesting data to extract out of this results. More than what is popular and needs better docs, but also maybe there’s more we could do for say, standards, etc.
- Possibility of creating a report from this data so that people can see it.
-
"Stumptown" (next gen MDN on GitHub) experiments
Still in early June, so this might change!
- New user accounts - 1st part of the year was getting the front end ready for logged in users.
- Right now only have 2 types - visitors & logged in editors. Logged in you automatically get contribution view & tools.
- Going forward, there will be 4 types: visitor, editor, member, paid member.
- Need to separate the views, so people who want to edit a page get the right view, but we also create a streamlined view for members
- Figuring out flow (UX work going on now)
- Adding authentication options beyond GitHub, have to consider places like China where some options are not available.
- Need to pay attention to privacy and political * Implications of providers
- Customization
- BCD customization is pretty targeted
- Looking at how people keep track of their learning on MDN & figuring out ways to help them.
- Could create to-do lists or save progress.
- Timeline
- Survey
- Fielding/Support
- MDN user accounts (vs contributors accounts)
- “Track my progress” feature for logged in users
- Compat data
- Automated tooling and signaling tools
- Could have automated content, about 80% would be correct
- Have a way for people to easily tell us if something is incorrect (as opposed to the current process, which is arcane and confusing).
- Build a tool for reporting errors in the compatibility tables
- Automation is being worked on with Google, Confluence will only provide data for JavaScript and Web API’s
- Missing 300+ CSS properties on MDN right now, so it’s not complete. Open question about prioritizing, this year focusing on the CSS we have reference pages. [ACTION]: Add to discussion list for tomorrow (prioritization + also tooling to see what is missing).
- [Action] would love some help making connections to the Lighthouse team. Re: browser compatibility audits
- Original issue Meggin created (that got closed by Lighthouse team): GoogleChrome/lighthouse#4377
- We could re-open this issue once we’ve met Paul Irish’s threshold.
- Get a definition and expectations for conversation areas,
- TAG
- PWA
- Get a definition everyone agrees on about what makes a PWA.
- Is possible to make cross browser?
- Would like to prioritize better documentation on MDN
- (Chris’s notes) PWA needs better docs
- Look at the PWA learning path, learning area style.
- Include agreed definition that we can all sign off on.
- More stuff on the cross-browser implications
- Article on creating a PWA out of part of an app, e.g. tracking your order until it arrives; Share other use cases - travel sites, etc.
- Include page on making them work with iOS, or what bits do and don’t work, workarounds, etc. Ask Firt to write this?
- Think about making it more neutral PWA-centric
- See #8
- Provide simple tools to smooth over the hard bits, or point out React does PWAs, etc.
- PWAbuilder.
- SEO needs improving; can’t find PWA docs on MDN.
- Next step - create GDoc to brainstorm updated docs
- [Action] - figure out “f2f” working session
- Research part of the web platform lifecycle (at Mozilla) is lacking
- Want to hear the voices of developers in a more formal fashion
- Draft survey
- Process
- 16 one-hour user interviews with developers (global representation)
- Tool the responses, categorized them, then put them into needs lists
- 4 rounds of feedback from cross-industry group of stakeholders
- Survey is in it’s 6th version
- Between rounds of feedback did recorded pilot surveys (guided and unguided) with developers, to determine if they could understand the questions, etc.
- Mozilla prohibits collecting gender information and PII for certain countries where third genders are illegal. Have worked out q solution where PII will not be collected for these countries in this survey.
- Look into adding a question like “do you consider yourself part of an underrepresented group” to future surveys
- Wordsmith some of the needs questions later in the meeting
- What languages will be supported?
- 2 week delay for localization
- Current proposal is to launch the English version first , then roll out the localized version later.
- Concern at this approach, will discuss impacts (marketing, etc.)
- Fielding support
- Put together a GTM template & short description of that this is
- One the report is out putting together a talk on this would be helpful
- Internal brown bag on results at various companies
- Node+JS interactive in December
- Present at TPAC
- Timeline is in flux, since one of the senior developers has left Mozilla
- MDN will continue is what it is today
- Membership is adjacent to MDN Web docs
- Paid membership will be all adjacent to MDN
- Education and interactivity
- MDN will advertise the paid membership
- “Here’s related courses to this content”
- Want to make sure that people never have the perception that we put MDN Webdocs content behind a paywall
- We’ll have a Mozilla Developer Membership
- We’re looking at ways to time box the paid stuff (you’re paying for early/in person access)
- 2019
- MVP
- Content
- Raffles
- 2020 and beyond
- Enterprise
- MDN merch
- Board wants to make sure there is a distinction between Webdocs and the membership
- Where will be opportunities to co-locate courses that are adjacent to membership content
- Developer Portal for Mozilla. It will have all the Firefox things and things that don’t belong on MDN web docs.
- Concern that things that will sell membership are not necessarily in the best interest of the web. Can there be governing structure we can put in place that can keep that in check? We’ll rely on the board for input and feedback.
- How about community content? Long term we might want to do revenue sharing.
- Jess should talk to Ben at practical dev
- We’ll focus on beyond the beginner developer content
- We might also focus on business needs of developers
- [action] Work on guidelines for supplemental/membership content on MDN web docs, curation, etc.
- Calls in August & November
- Next face to face early February, location TBD