MDN/Archives/Projects/Development/CompatibilityTables/Vision

FOR DISCUSSION: This document is currently a re-hash of the deliverables. It will most likely be updated after a discussion with the development team.

Vision

Objective of this document

In order to help us structure the work and communicate better with other stakeholders, we may want to follow the Agile Manifesto guidelines

This document should be viewed as a summary of the project priorities to assist us in the decision process.

It is meant to follow the objectives of a Project Vision document defined by the Scrum Alliance.

« Every Scrum project needs a product vision that acts as the project’s true north, sets the direction and guides the Scrum team. It is the overarching goal everyone must share – Product Owner, ScrumMaster, team, management, customers and other stakeholders. As Ken Schwaber puts it: “The minimum plan necessary to start a Scrum project consists of a vision and a Product Backlog. The vision describes why the project is being undertaken and what the desired end state is.” (Schwaber 2004, p. 68) »

Please keep this document as short as possible to reflect the current project direction regardless of the phase we are in.

Vision Board

Serve feature compatibility information across multiple outlets and formats without data duplication

Target group	Needs	Product	Value
People who make websites, are on MDN, and want to learn if a specific feature is supported ("web developer") Browser vendor representatives who want to update their product’s support data ("Vendor rep.") People who make contributions to MDN ("contributor") People who work on translating MDN content ("translator") People working on projects who want to use compatibility data in their app	Display up to date feature support data consistently Easy data entry process ("contribution") Easy access to data Easy moderation of the data entries Easy translation of notes and labels	Specialized web service serving feature support data in multiple languages (e.g. English, French, German, etc.) and formats (JSON, HTML) Dashboard that allows maintenance and moderation of the data being contributed Search engine to find features based on criteria such as author, feature, browser, etc.	Improve resiliency of MDN site infrastructure Simplify maintenance tasks related to feature support updates Help all browser vendors contribute to MDN

ref: The Product-Vision Board

---

Expanded vision notes

Which customer needs will the product address?

Priorities are marked by a star (☆)

• View up to date feature support tables embedded within MDN content ☆
• Add/Edit a given feature entry using tools within MDN ☆
• A way to input/import data
  • Scraping existing MDN compatibility tables ☆
  • Manual contribution by users using external tools
  • Bulk data entry that may span many features (both changing existing features and adding new ones)
• A way to maintain the data (outside of MDN)
  • Search by feature, contributor, or specification
  • Individual contribution (i.e. contributor, time of contribution, contribution data) not clear what this means
  • Bulk data entry that may span many features (some features may or may not exist)
  • Erase one or many contributions
  • Localization of labels in the UX and the tables so we can support displaying the data in multiple languages

Which product attributes are critical to satisfying the needs selected, and therefore for the success of the product?

• Seamless communication flow between separate web applications: the database, the API, and the MDN production content should always present the same data
• Every translation of a given article should display the same compatibility data, just presented according to the user's locale
• Erasing contributions should adjust internal data representation to the sum of data entries between an initial state and the entry events applied in an ordered manner, modulo what's been erased
• Import data should be structurally identical to the data Export output What does this mean??
• data entry format should be structurally identical for both bulk and individual contribution
• Data should not store localized labels; these should be stored in a centralized manner which supports localization of those labels
• Ability to snapshot the database ("export") into appropriate formats (json, HTML...?)
• Ability to restore service quickly
  • Easy to maintain the service
  • Easy to restore backups of the data to roll back if a data irregularity occurs

How does the product compare against existing products, both from competitors and the same company? What are the product’s unique selling points?

No feature for feature equivalent found yet

What is the target timeframe and budget to develop and launch the product?

TODO

---

System properties

Components

(most likely incomplete)

1. Display data at most recent state
2. Search current data, by Feature, Author, Browser
3. Search data entry events, by Feature, Author, Browser
4. Compile data view as the sum of data entries between an initial state and the entry events applied in an ordered manner
5. Render an HTML representation of the data (may or may not have more than one HTML format)
6. Accept writes only if authenticated to trusted authentication provider
7. Contribution data types:
   1. Feature (e.g. border-radius)
      1. Supports (e.g. Basic Support of border-radius)
   2. Specification
   3. Browser
      1. Browser Version
   4. Note
8. Frontend JavaScript client
   1. add editing capabilities from MDN embed
   2. Convert a given data entry into a "contribution packet" to send to the API

Properties that has common attributes

Common properties should indicate the system dependencies and, therefore, makes them critical to supporting other features of the system as a whole.

Data entry events

As stated in critical attributes above;

Erasing contributions should adjust internal data representation as the sum of data entries between an initial state and the entry events applied in an ordered manner, modulo what's been erased

The following type of data is subject for edit events and moderation may be required on a given event.

In their respective contexts;

• Bulk (i.e. event data adds/edits more than one data type)
• Individual entry
• Individual entry, triggered from external site
• Initial import

It means we may want to focus on a system that helps us browser data entry events.

Search

Search capability is required for two different contexts: Current data, Contribution event log.

Compile a data view as the sum of data entries

Each visualization of the data, regardless of their format, is the result of changes that has been made on a given resource (e.g. Feature, Specification, Browser, Labels)

In order to support moderation, and the underlying need to allow removal of unaccepted data, we must have a system that handles ways to apply changes in an ordered manner.