Confirm
630
edits
Changes
→Compatibility Tables
'''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.
[[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.
[[File:MDN-compat-table.png|660px|thumb|center|More advanced 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.
[[File:Mobilehtml5-compat-table.png|660px|thumb|center|MDN current compatibility data tables 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.
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 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.
[[File:Filter-compat-tables.png|660px|thumb|center|MDN current 4. More advanced compatibility data tables layout]]
==== Compatibility markers ====
