Confirmed users
630
edits
MDN/Development/CompatibilityTables/Data Requirements: Difference between revisions
Jump to navigation
Jump to search
MDN/Development/CompatibilityTables/Data Requirements (view source)
Revision as of 14:46, 10 February 2014
, 10 February 2014→Compatibility Tables
| Line 11: | Line 11: | ||
This is the current use case for MDN. For each feature we document, we display a table providing an overview of the support of the feature on severals browsers. There is traction to be able to build data compatibility tables like the ones available on [http://caniuse.com caniuse.com]. | This is the current use case for MDN. For each feature we document, we display a table providing an overview of the support of the feature on severals browsers. There is traction to be able to build data compatibility tables like the ones available on [http://caniuse.com caniuse.com]. | ||
Several | Several layouts are possible for compatibility data. In order to be sure we do not forgive any data, the following rough mock-ups provide some examples. | ||
'''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.'' | ||
The first example show two tables like the ones | 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|caniuse.com compatibility data tables layout]] | [[File:Compat-tables-mockups.png|660px|thumb|center|caniuse.com compatibility data tables 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 | 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|More advanced compatibility data tables layout]] | [[File:MDN-compat-table.png|660px|thumb|center|More advanced compatibility data tables 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 | 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|MDN current compatibility data tables layout]] | [[File:Mobilehtml5-compat-table.png|660px|thumb|center|MDN current compatibility data tables layout]] | ||
The fourth example show various other table | 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 information regarding the API supported by Firefox OS as each version bring a lot | 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 second layout is a more complex variation of the first one. It | The second layout is a more complex variation of the first one. It covers the same kind of needs but is a bit more operational as it allow to move from the general view to a more detailed view. | ||
The third layout is even more complex but allows to cover a new need as it is possible to show more than one browser at a time. It is especially handy for project managers or web architects who need to make decision regarding which feature to use among a range of browsers. It allows to compare browsers in order to decide which should be the primary target browser while developing or which browser would need the most important amount of polyfills. It's a decision view. | The third layout is even more complex but allows to cover a new need as it is possible to show more than one browser at a time. It is especially handy for project managers or web architects who need to make decision regarding which feature to use among a range of browsers. It allows to compare browsers in order to decide which should be the primary target browser while developing or which browser would need the most important amount of polyfills. It's a decision view. | ||