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

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

Target group People who make contributions to the documentation site People who work on translating the documentation site People who make websites, visits the documentation site, and wants to learn if a feature is supported Browser vendors representatives who want to update their product’s support data People in projects who wants to use compatibility data into their app

Needs Display Up to date feature support data consistently Easing data contribution Easing access to data Easing moderation of the data entries Easing translation of notes and labels

Product 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 criterions such as Author, Feature, Browser, etc.

Value Make sure feature compatibility data is coherent, and duplicate free, across MDN Improve resiliency of MDN site infrastructure

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 table embedded within documentation site ☆
• Add/Edit a given feature entry within the documentation site ☆
• A way to input/import data (outside of documentation site)
  • Scraping MDN ☆
  • Individual contribution
  • Bulk data entry that may span many features (some features may or may not exist)
• A way to maintain the data (outside of documentation site)
  • Search by Feature, Contributor, Specification
  • Individual contribution (i.e. contributor, time of contribution, contribution data)
  • Bulk data entry that may span many features (some features may or may not exist)
  • Erase one or many contributions
  • Labels so we can support same data display 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
• Every translated article should display the same compatibility data, but translated in the current locale
• Erasing contributions should adjust internal data representation to the sum of all contributions, in the order they’ve been inserted, modulo the erased entries
• Import data should be structurally identical to the data Export output
• Data input format should be structurally identical for both bulk and individual contribution
• Data should not store localized labels
• Ability to snapshot data ("export")
• Ability to restore service quickly

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 to be incomplete)

1. Display current data
2. Search current data, by Feature, Author, Browser
3. Search Data entry events, by Feature, Author, Browser
4. Compile a 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. CRUD Feature entry
   2. CRUD Specification entry
   3. CRUD Browser entry
   4. CRUD Browser Version entry
   5. CRUD Labels entry
   6. CRUD Note entry
8. Frontend JavaScript client
   1. add editing capabilities from documentation site embed
   2. convert 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 to the sum of all contributions, in the order they’ve been inserted, modulo the erased entries

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

Namely;

• Feature
• Specification
• Browsers
• Browser version
• Labels
• Note

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

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.