MozillaWiki

MDN/Archives/Projects/Development/CompatibilityTables/Vision: Difference between revisions

< MDN‎ | Archives‎ | Projects/Development/CompatibilityTables
(Make product description more coarse than mapping needs 1-1)
 
(21 intermediate revisions by 3 users not shown)
Line 1: Line 1:
'''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.
'''FOR DISCUSSION''': This document not finished elaborating, you can see the feedback in [https://docs.google.com/document/d/1oekQHEkiNSIxKSEhWSUArqMO517t3byoDWsq8Di-iB4/edit# the '''Vision document''' in Google Docs]


= Vision =
= Vision =


== Objective of this document ==
<blockquote style="font-size:1.4em">Serve feature compatibility information across ''multiple'' '''outlets''' and '''formats''' ''without'' data duplication</blockquote>


In order to help us structure the work and communicate better with other stakeholders, we may want to follow the '''[http://agilemanifesto.org/ Agile Manifesto] guidelines'''
== 1. Introduction ==


This document should be viewed as a summary of the project priorities to assist us in the decision process.
The production vision document is about making a consensus about the features and limitations of the product. It should help us by providing a common vocabulary to help better communicate throughout the phases of the project.


It is meant to follow the objectives of a Project Vision document defined by the Scrum Alliance.
Project Vision document defined by the Scrum Alliance and Agile Manifesto as a guideline to structuring work without overdoing it.


<blockquote>« 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) »</blockquote>
=== 1.1. See also ===


Please keep this document as short as possible to reflect the current project direction regardless of the phase we are in.
* Compatibility Data product vision (this document)
* [https://docs.google.com/presentation/d/1plLNTv0O5o4kXTFoD6eVZm_eMuaQ5YbefPPyIyIMm8Q/edit?usp=sharing Compatibility Data: A Shared Resource] (2015 slides deck)
* [https://docs.google.com/document/d/1Nh7ktC1rQQyItBXRdCd7IHKLpdJceZ6LFmMTsbzaaJ8/ Functional dependencies analysis]
* [https://docs.google.com/document/d/1ILwiPv5Wk3PwnKrD-sLmLBKhX6p6uEIj69gE3hr2MuI/ High level feature prioritization worksheet]
* [https://wiki.mozilla.org/MDN/Development/CompatibilityTables/Tribal_Knowledge ''Tribal'' knowledge]


=== 1.2. Preface ===


== Vision Board ==
Compatibility data are one of the key feature of MDN. It allows users to know more about the reliability of any web standard features and to ease the use of web technologies.


{| class="wikitable" style="text-align:left; vertical-align: top;"
Currently, the data are gather and maintain "by hand". Thanks to our awesome community we have some good data. However, this is hardly sustainable as the number of technologies is growing as well a the complexity of the implementation. We start to face some difficulties to stay up to date and to provide and improved content around those data.
|+ ''Vision statement'': Serve feature compatibility information across ''multiple'' '''outlets''' and '''formats''' ''without'' data duplication
 
  '''For''' Web Developers,
  Who '''wants to know if they should use a technique''',
  The BrowserCompat system '''is a specialized web service''',
  That '''provides compatibility data'''
  '''Unlike''' caniuse.com
  '''We'll be able to have a usable maintenance flow''' serving reports in multiple formats
 
 
=== 1.3. Production vision summary ===
 
An overview, summarizing this document
 
{| class="wikitable" style="text-align:left; vertical-align: top; border: none;"
|-
! Target group
! Needs
! Product
! Value
|-
|-
| style="vertical-align: top;" | '''Target group'''
| style="vertical-align: top;" width="25%" |
* People who make contributions to the documentation site
# '''Software Developer''' who has an immediate need for information, and want to know about a User-Agent feature support, and standardization status
* People who work on translating the documentation site
# '''Software Architect''', or Blog Author, writing technical document about recent technologies and how to use
* People who make websites, visits the documentation site, and wants to learn if a feature is supported
# '''Technical writer''' (“contributor”) and/or translator who work on improving web developer documentation and wants to get better tools
* Browser vendors representatives who want to update their product’s support data
# '''Browser vendor representatives''' who want to update their product support data
* People in projects who wants to use compatibility data into their app
# '''Third-party developer''' involved in a product who want to use compatibility data within their software (“Third party”)
| style="vertical-align: top;" | '''Needs'''
| style="vertical-align: top;" width="25%" |
* Make sure feature compatibility data is coherent all across MDN
# '''Import data''' we currently host in Wikitext format
* Easing data contribution
# '''Display up-to-date''' User-Agent feature details and ''support information'', consistently
* Easing access to data
# '''Easing contribution''', translation, and access to data
* Easing moderation of the data entries
# '''Easing moderation''' of contributions (i.e. prevent spam)
* Easing translation of notes and labels
| style="vertical-align: top;" width="25%" |
| style="vertical-align: top;" | '''Product'''
* Specialized web service serving feature support data in multiple languages (e.g. English, French, German, etc.) and formats (JSON, HTML)
* 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
* 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.
* Search engine to ease browsing feature based on various criterions such as Author, Feature, Feature Support, Spec. Maturity, Browser, Browser Version, etc.
| style="vertical-align: top;" | '''Value'''
* Contribution workflows to allow multiple third party contribution to the data.
* Remove data duplication
| style="vertical-align: top;" width="25%" |
* Improve value of MDN by serving reusable utility to support Web Developer Industry
* Improve resiliency of MDN site infrastructure
* Improve resiliency of MDN site infrastructure
* Simplify maintenance tasks related to feature support updates
* Support Mozilla mission by providing a canonical resource about cross compatibility of standards web technologies
|}
|}


Ref: [http://www.romanpichler.com/blog/the-product-vision-board/ The Product-Vision Board]
'''Note''': This table is purposefully rough-grained, giving an overview of what we’re building, what it’ll do, and for whom.
 
----
 
== 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 ==
== 2. Business Opportunity/Problem Statement ==
 
=== Components ===
 
(most likely to be incomplete)
 
# Display current data
# Search current data, by Feature, Author, Browser
# Search Data entry events, by Feature, Author, Browser
# Compile a data view as the sum of data entries between an initial state and the entry events applied in an ordered manner
# Render an HTML representation of the data (may or may not have more than one HTML format)
# Accept writes only if authenticated to trusted authentication provider
# Contribution data types:
## CRUD Feature entry
## CRUD Specification entry
## CRUD Browser entry
## CRUD Browser Version entry
## CRUD Labels entry
## CRUD Note entry
# Frontend JavaScript client
## add editing capabilities from documentation site embed
## 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;
 
<blockquote>Erasing contributions should adjust internal data representation to the sum of all contributions, in the order they’ve been inserted, modulo the erased entries</blockquote>
 
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.
Not finished yet, see [https://docs.google.com/document/d/1oekQHEkiNSIxKSEhWSUArqMO517t3byoDWsq8Di-iB4/edit# Vision document in Google Docs]

Latest revision as of 19:51, 19 June 2017

FOR DISCUSSION: This document not finished elaborating, you can see the feedback in the Vision document in Google Docs

Vision

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

1. Introduction

The production vision document is about making a consensus about the features and limitations of the product. It should help us by providing a common vocabulary to help better communicate throughout the phases of the project.

Project Vision document defined by the Scrum Alliance and Agile Manifesto as a guideline to structuring work without overdoing it.

1.1. See also

1.2. Preface

Compatibility data are one of the key feature of MDN. It allows users to know more about the reliability of any web standard features and to ease the use of web technologies.

Currently, the data are gather and maintain "by hand". Thanks to our awesome community we have some good data. However, this is hardly sustainable as the number of technologies is growing as well a the complexity of the implementation. We start to face some difficulties to stay up to date and to provide and improved content around those data. 

 For Web Developers,
 Who wants to know if they should use a technique,
 The BrowserCompat system is a specialized web service,
 That provides compatibility data
 Unlike caniuse.com
 We'll be able to have a usable maintenance flow serving reports in multiple formats


1.3. Production vision summary

An overview, summarizing this document

Target group Needs Product Value
  1. Software Developer who has an immediate need for information, and want to know about a User-Agent feature support, and standardization status
  2. Software Architect, or Blog Author, writing technical document about recent technologies and how to use
  3. Technical writer (“contributor”) and/or translator who work on improving web developer documentation and wants to get better tools
  4. Browser vendor representatives who want to update their product support data
  5. Third-party developer involved in a product who want to use compatibility data within their software (“Third party”)
  1. Import data we currently host in Wikitext format
  2. Display up-to-date User-Agent feature details and support information, consistently
  3. Easing contribution, translation, and access to data
  4. Easing moderation of contributions (i.e. prevent spam)
  • 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 ease browsing feature based on various criterions such as Author, Feature, Feature Support, Spec. Maturity, Browser, Browser Version, etc.
  • Contribution workflows to allow multiple third party contribution to the data.
  • Improve value of MDN by serving reusable utility to support Web Developer Industry
  • Improve resiliency of MDN site infrastructure
  • Simplify maintenance tasks related to feature support updates
  • Support Mozilla mission by providing a canonical resource about cross compatibility of standards web technologies

Note: This table is purposefully rough-grained, giving an overview of what we’re building, what it’ll do, and for whom.


2. Business Opportunity/Problem Statement

Not finished yet, see Vision document in Google Docs

Retrieved from "https://wiki.allizom.org/index.php?title=MDN/Archives/Projects/Development/CompatibilityTables/Vision&oldid=1173978"