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

From MozillaWiki
Jump to navigation Jump to search
(Completed initial review of system component features)
 
(34 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>


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


It is meant to follow the objectives of a Project Vision document defined by the Scrum Alliance.
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.


<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>
Project Vision document defined by the Scrum Alliance and Agile Manifesto as a guideline to structuring work without overdoing it.


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


* 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]


== Vision Board ==
=== 1.2. Preface ===


{| class="wikitable" style="text-align:left; vertical-align: top;"
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.
|+ ''Vision statement'': Serve feature compatibility information across ''multiple'' '''outlets''' and '''formats''' ''without'' data duplication
|-
| style="vertical-align: top;" | '''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
| style="vertical-align: top;" | '''Needs'''
* Make sure feature compatibility data is coherent all across MDN
* Easing data contribution
* Easing access to data
| style="vertical-align: top;" | '''Product'''
* Specialized service accessible using a Web browser to search and edit data
* Capability to embed information within another web page
* Capability to edit data from within another webpage
| style="vertical-align: top;" | '''Value'''
* Remove data duplication
* Improve resiliency of MDN site infrastructure
|}


Ref: [http://www.romanpichler.com/blog/the-product-vision-board/ The Product-Vision Board]
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


== Expanded vision notes ==
=== Which customer needs will the product address? ===


Priorities are marked by a star (☆)
=== 1.3. Production vision summary ===


* View up to date feature support table embedded within documentation site ☆
An overview, summarizing this document
* 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


{| class="wikitable" style="text-align:left; vertical-align: top; border: none;"
|-
! Target group
! Needs
! Product
! Value
|-
| style="vertical-align: top;" width="25%" |
# '''Software Developer''' who has an immediate need for information, and want to know about a User-Agent feature support, and standardization status
# '''Software Architect''', or Blog Author, writing technical document about recent technologies and how to use
# '''Technical writer''' (“contributor”) and/or translator who work on improving web developer documentation and wants to get better tools
# '''Browser vendor representatives''' who want to update their product support data
# '''Third-party developer''' involved in a product who want to use compatibility data within their software (“Third party”)
| style="vertical-align: top;" width="25%" |
# '''Import data''' we currently host in Wikitext format
# '''Display up-to-date''' User-Agent feature details and ''support information'', consistently
# '''Easing contribution''', translation, and access to data
# '''Easing moderation''' of contributions (i.e. prevent spam)
| style="vertical-align: top;" width="25%" |
* 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.
| 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
* Simplify maintenance tasks related to feature support updates
* Support Mozilla mission by providing a canonical resource about cross compatibility of standards web technologies
|}


=== Which product attributes are critical to satisfy the needs selected, and therefore for the success of the product? ===
'''Note''': This table is purposefully rough-grained, giving an overview of what we’re building, what it’ll do, and for whom.
 
* Seamless communication flow between separate web applications
* 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
 
 
=== 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 components ==
== 2. Business Opportunity/Problem Statement ==


# Display current data
Not finished yet, see [https://docs.google.com/document/d/1oekQHEkiNSIxKSEhWSUArqMO517t3byoDWsq8Di-iB4/edit# Vision document in Google Docs]
# Generate an HTML representation of the data (may or may not have more than one HTML format)
# Compile a data view as the sum of contributions between an initial data and the sum of contributions applied to it
# CRUD Labels
# CRUD Contribution
# CRUD Browser
# CRUD Browser Version
# Search data: Feature, Author, Browser

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