Confirm
630
edits
Changes
→Compatibility Tables
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 possible layout 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.''
The first example show two tables like the ones available 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 developer 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]]
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 detail 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]]
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 setsets) by a set of browser. It looks a lot like the current MDN layout but does not address the same populationusers. 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]]
The fourth example show various other table layout layouts with the ability to filter the displayed data (more about filtering below). Those layout 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 a of change. It allows users to know more specifically about the support in side 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 cover covers the same kind of need 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.
