Confirmed users
630
edits
m (→Export API: typo fix) |
|||
(16 intermediate revisions by the same user not shown) | |||
Line 4: | Line 4: | ||
This part intent to answer the question: What do we want to do with compatibility data? This will help us defining which data we need to have. | This part intent to answer the question: What do we want to do with compatibility data? This will help us defining which data we need to have. | ||
=== Targeted audience === | |||
In order to better understand want we want to do with compatibility data, we identified a few profiles that need to be kept in mind as well as their possible motives. Those profiles will help while moving to a more formal UX step in the project. | |||
==== web developers ==== | |||
Web developers always have a hard time while working in a cross browser environment. To avoid that, they need to be able to found detailed information regarding the features they are working on and their availability among browsers as well as information to bypass a possible lack of implementation. As they are mostly seeking such information during their work time, they have very few time to dig down and need quickly accessible straight forward information. | |||
==== App developers ==== | |||
App developers are a quite similar to web developers, but they wish to focus on a smaller number of platform (if not just one). To that end, they needs detailed information about implementation of feature on a specific browser or version of a browser. As they are mostly manipulating cutting edge technologies, they need a very high level of information about each features and their availability, seeking for each small piece of information to improve their work. | |||
==== web architects/lead dev ==== | |||
Those are people building the technical strategy beneath a project. They need fully detailed information about browser compatibility in order to take rational and accurate technical decisions that can ease or jeopardize their projects in the long run. As they plan things, they have time to dig deep if necessary. | |||
==== project leaders ==== | |||
Those are people who must take decision regarding their project. For that reason they needs decision tools able to provide them with accurate but not overwhelming information regarding browser compatibility. | |||
==== beginners/learners ==== | |||
As they are learning things about the web, beginners are one of our key audience. The complexity of the web interoperability is one of the pitfall of web development. In order to ease their learning experience, we must be able to provide simple understandable overviews of feature support among browsers. | |||
=== Display data === | === Display data === | ||
Line 15: | Line 39: | ||
'''NOTE:''' ''Those mock up are not UX related and does not intent anything on how we should actually display data on MDN. They are just various layout to help us defining the data we need to display in different cases.'' | '''NOTE:''' ''Those mock up are not UX related and does not intent anything on how we should actually display data on MDN. They are just various layout to help us defining the data we need to display in different cases.'' | ||
1. The first example show two tables like the ones availables on [http://caniuse.com caniuse.com]. Those tables are feature centric, which means they display data only for a single feature (or feature set). It's ideal when a user wish to have a cross browser view about a specific feature. Web developers use it quite often when they have to deal with compatibility issues while working on a specific feature. It's an operational view. | '''NOTE:''' ''Those mock up does not always show up the implementation notes. However, there is '''always''' implementations note. How to display them the best way will be discuss while moving to the UX process.'' | ||
=====1. CanIUse table layout ===== | |||
The first example show two tables like the ones availables on [http://caniuse.com caniuse.com]. Those tables are feature centric, which means they display data only for a single feature (or feature set). It's ideal when a user wish to have a cross browser view about a specific feature. Web developers use it quite often when they have to deal with compatibility issues while working on a specific feature. It's an operational view. | |||
[[File:Compat-tables-mockups.png|660px|thumb|center|1. caniuse.com compatibility data tables layout]] | [[File:Compat-tables-mockups.png|660px|thumb|center|1. caniuse.com compatibility data tables layout]] | ||
2. The second example show a table like the ones we currently have on MDN. Those tables are an overview representation. It is still a very detailed vision more feature centric than browser centric. It's ideal when a user plan to use a given set of features and wish to know the compatibility context in detail before starting to work on his project. It's also an operational view. | =====2. MDN original table layout===== | ||
The second example show a table like the ones we currently have on MDN. Those tables are an overview representation. It is still a very detailed vision more feature centric than browser centric. It's ideal when a user plan to use a given set of features and wish to know the compatibility context in detail before starting to work on his project. It's also an operational view. | |||
[[File:MDN-compat-table.png|660px|thumb|center|2. MDN current compatibility data tables layout]] | [[File:MDN-compat-table.png|660px|thumb|center|2. MDN current compatibility data tables layout]] | ||
3. The third example show a table like the one available on [http://mobilehtml5.org mobilehtml5.org]. It provides a quick overview about the support of features (or feature sets) by a set of browser. It looks a lot like the current MDN layout but does not address the same users. Such representation is ideal for project managers or web architects who need to decide if a feature fit the requirements of their project. It's a decisional view. | =====3. MobileHTML5 table layout===== | ||
The third example show a table like the one available on [http://mobilehtml5.org mobilehtml5.org]. It provides a quick overview about the support of features (or feature sets) by a set of browser. It looks a lot like the current MDN layout but does not address the same users. Such representation is ideal for project managers or web architects who need to decide if a feature fit the requirements of their project. It's a decisional view. | |||
[[File:Mobilehtml5-compat-table.png|660px|thumb|center|3. MobileHTML5 table layout]] | [[File:Mobilehtml5-compat-table.png|660px|thumb|center|3. MobileHTML5 table layout]] | ||
4. The fourth example show various other table layouts with the ability to filter the displayed data (more about filtering below). Those layouts are more browser centric as they focus on the browser as the main input factor. | =====4. Tables with filtering===== | ||
The fourth example show various other table layouts with the ability to filter the displayed data (more about filtering below). Those layouts are more browser centric as they focus on the browser as the main input factor. | |||
The first layout list all the features supported by a browser and the version associated to the support of each feature. This typically what we currently need to display to provide information regarding the API supported by Firefox OS as each version bring a lot of change. It allows users to know more specifically about the support provide by a given browser. It is especially handy for apps developers who want to decide which browser version they want to support. It's a decision view. | The first layout list all the features supported by a browser and the version associated to the support of each feature. This typically what we currently need to display to provide information regarding the API supported by Firefox OS as each version bring a lot of change. It allows users to know more specifically about the support provide by a given browser. It is especially handy for apps developers who want to decide which browser version they want to support. It's a decision view. | ||
Line 37: | Line 68: | ||
[[File:Filter-compat-tables.png|660px|thumb|center|4. More advanced compatibility data tables layout]] | [[File:Filter-compat-tables.png|660px|thumb|center|4. More advanced compatibility data tables layout]] | ||
5. The fifth example show an exhaustive support chart as they exist on MDN. This is a browser centric layout made to provide an full overview of the features supported by a single browser. This is an informative view. As an example, see: https://developer.mozilla.org/en-US/docs/Mozilla_CSS_support_chart | =====5. MDN support tables===== | ||
The fifth example show an exhaustive support chart as they exist on MDN. This is a browser centric layout made to provide an full overview of the features supported by a single browser. This is an informative view. As an example, see: https://developer.mozilla.org/en-US/docs/Mozilla_CSS_support_chart | |||
[[File:Support_chart.png|660px|thumb|center|5. MDN Support chart]] | [[File:Support_chart.png|660px|thumb|center|5. MDN Support chart]] | ||
Line 50: | Line 82: | ||
The first idea is one of our functional priority as we already have such markers for Gecko/Firefox compatibility (but currently not bind to any formal compatibility data which requires some time consuming manual maintenance). | The first idea is one of our functional priority as we already have such markers for Gecko/Firefox compatibility (but currently not bind to any formal compatibility data which requires some time consuming manual maintenance). | ||
The second idea is less important and require a deeper investigation as it can be tricky to provide an accurate information. Currently on MDN, most of our pages contain information about several features at the same time or information about feature which evolved greatly over time. Therefor, such information can be often misleading if not handled very carefully. More | The second idea is less important and require a deeper investigation as it can be tricky to provide an accurate information. Currently on MDN, most of our pages contain information about several features at the same time or information about feature which evolved greatly over time. Therefor, such information can be often misleading if not handled very carefully. More specifically, Such summary information can hide inter-compatibility problems: the "support" may mean "it can be made work in this browser", "follow the spec, but maybe with a couple of minor glitch", "follow perfectly the spec". The flexbox support is one example: most modern browsers follow the spec, but maybe with a couple of minor glitch. But flexbox was available in one way or another in browsers long time ago (but interoperability was a nightmare to achieve). | ||
'''NOTE:''' ''For the reason detailed here, the second type of marker requires further UX and technical investigation. However, it is the most requested feature from the users and should not be avoid.'' | |||
==== Compatibility Filters ==== | ==== Compatibility Filters ==== | ||
Line 92: | Line 126: | ||
==== Dealing with vandalism and mistakes ==== | ==== Dealing with vandalism and mistakes ==== | ||
As anyone can contribute to our data, we need a way to revert any vandalism or mistake | As anyone can contribute to our data, we need a way to revert any vandalism or mistake. That means that we need to keep an history of each changes made overtime to our data and a way to revert any change. We also need to track which user has made a change to be able to banish him in case of vandalism. | ||
To deal with mistake it would be nice to allow users to be able to revert their own change. Ultimately, we wish to be able to grant some users to perform admin task on data which include reverting to any change. This should be part of the usual MDN authorization mechanism. | |||
==== Data Licensing ==== | |||
All the data are contributed and accessible under a [http://creativecommons.org/publicdomain/zero/1.0/ CC0 license]. | |||
== Displayable data == | == Displayable data == | ||
Line 118: | Line 153: | ||
'''EXAMPLES:''' ''the <a> tag in HTML or SVG, the display property in CSS and JavaScript, etc.'' | '''EXAMPLES:''' ''the <a> tag in HTML or SVG, the display property in CSS and JavaScript, etc.'' | ||
=== Feature sets === | === Feature sets === | ||
Line 144: | Line 177: | ||
'''NOTE:''' ''Several specifications can define a single feature. The ''navigator'' DOM property is a good example of this case.'' | '''NOTE:''' ''Several specifications can define a single feature. The ''navigator'' DOM property is a good example of this case.'' | ||
Our compatibility data must embed the minimum requirement define below. More complete informations regarding the various specifications involved (such as their name or status) will be handled separately and are out of the scope of that project. | |||
==== URLs ==== | |||
All the URLs to the various specifications (or specification sub-parts) defining the feature. | |||
==== Notes ==== | ==== Notes ==== | ||
Any complementary information regarding a specifications defining the | Any complementary information regarding a specifications defining the feature. For examples, we have cases where a specification contradict another. We need to be able to specified which one is the relevant one (DOM specifications are a good example of this). We also have cases of multiple specification for a single feature where it can be relevant to have some indication of the scope of each individual piece of definition. As there can be many surprising cases, those notes just need to be raw material. | ||
''' | '''NOTE:''' ''Those notes must be localisable.'' | ||
In a feature set, URLs and Notes of the children features are aggregate to provide the associate information of the specifications defining the feature set. | |||
=== Browser === | === Browser === | ||
Line 186: | Line 208: | ||
==== Logo ==== | ==== Logo ==== | ||
The browser logo is a good quick visual hint in many cases so we need to be able to display it. | The browser logo is a good quick visual hint in many cases so we need to be able to display it. We only need to display the latest version of the logo for each browser. There is no need to handle a whole library of logos for various version of a same browser. | ||
==== Version ==== | ==== Version ==== | ||
Line 196: | Line 216: | ||
'''NOTE:''' ''Browser version numbering is a mess, it is not simple numbers.'' | '''NOTE:''' ''Browser version numbering is a mess, it is not simple numbers.'' | ||
''' | '''NOTE:''' ''We do not see any reason to also handle information regarding OSes and Devices, raw implementation notes are good enough to handle special cases for such matter. If there are to much difference in such cases (for example Safari Mac vs. Safari iOS or Firefox Desktop vs. Firefox OS Browser), we plan to handle such cases as two different browsers.'' | ||
==== Prefix ==== | ==== Prefix ==== | ||
Line 212: | Line 232: | ||
'''NOTE:''' ''Such information MUST be localisable.'' | '''NOTE:''' ''Such information MUST be localisable.'' | ||
=== Localisable contents === | |||
For all the contents marked as localisable, we need a proper user interface to handle them. It must be as easy as using the current Wiki interface (which implied to be able to use KumaSript inside those contents). | |||
If for some reason a content is not localized, we will fallback to the English content. | |||
== Relevant e-mail threads == | == Relevant e-mail threads == | ||
Line 219: | Line 245: | ||
* https://groups.google.com/d/msg/mozilla.dev.mdc/DlmsxCyRpso/cryjYMRy6gMJ | * https://groups.google.com/d/msg/mozilla.dev.mdc/DlmsxCyRpso/cryjYMRy6gMJ | ||
* https://groups.google.com/d/msg/mozilla.dev.mdc/tg4wxAjI43w/uMF62f-M8CsJ | * https://groups.google.com/d/msg/mozilla.dev.mdc/tg4wxAjI43w/uMF62f-M8CsJ | ||
* https://groups.google.com/forum/#!topic/mozilla.dev.mdc/yJno61IiN3A | |||
* https://groups.google.com/forum/#!topic/mozilla.dev.mdc/Xb29z27-ySU | |||
=== Verbatim === | === Verbatim === |