Notice: The WebPlatform project, supported by various stewards between 2012 and 2015, has been discontinued. This site is now available on github.

Notes

These are early notes about the Flags concept.

List of Categorization Flags

TODO: These aren’t implemented as “Flags” anymore, but normal form fields.

We will revisit this whole thing in the future. On hold for now.

These are flags that call out special status of articles. They do not represent work that must be done on the article, but rather properties of the things the article documents.

Standardization Status

  • W3C_Editors_Draft
  • W3C_Working_Draft
  • W3C_Candidate_Recommendation
  • W3C_Recommendation
  • Deprecated For technologies that have been replaced or retracted, and are not recommended for use (but which are valuable to have for reference)
  • Non-standard For technologies that are not yet being standardized in any formal body, don’t have 2 or more compatible implementations, and likely never will
  • Defacto-standard For technologies that are not yet standardized, but have 2 or more compatible implementations (modulo prefixes)
  • Experimental For technologies that are not yet being standardized, don’t have 2 or more compatible implementations, but aim to one day be a standard
  • TODO: fill out this list with other standards bodies

Browser Support

Which browsers support this technology. ‘Stable’ means that that browser’s most recent main release includes support. ‘Preview’ means that a preview release of that browser (e.g. a "Beta", "Alpha", or “Developer Preview”) includes support. Only one of these tags should be included for each browser (and always the highest one).

  • Internet_Explorer_Stable
  • Firefox_Stable
  • Safari_Stable
  • Opera_Stable
  • Chrome_Stable
  • Internet_Explorer_Preview
  • Firefox_Preview
  • Safari_Preview
  • Opera_Preview
  • Chrome_Preview

Prefixes

  • Prefix_Everywhere Every stable browser this ships in includes the prefix
  • Prefix_Somewhere At least one stable browser ships this without a prefix
  • Prefix_Nowhere No stable browser ships this with a prefix

Design

Flag appearance and icons

These are even earlier notes:

Design exploration

Presentation

Most warning templates are displayed as a banner, often at the top of a page before the content, but sometimes inline in the content itself. This is eye-catching, but can be distracting. The goal is to draw attention to the warning without detracting from the use of the page.

Presentation Proposal

One way to make is easy for people to assess the status easily is by having color-coded flags (e.g. CSS ribbons) with icon arranged along the top edge of the content area, each with a different indicator; mousing over these flags would raise a tooltip indicating the specific message.

(See Top Ribbons for a visual example of this type of flag, and Flags Mock for a mock of what this could look like on this site.)

User Experience

Traditionally, these flags are added by using a specific bit of Mediawiki markdown to the page. However, not everyone is familiar with the way to do this, and discovering the correct types of “content flags” is not obvious.

UX Proposal

Each page could feature a dropdown, with a Semantic Form backend, that automatically adds the appropriate flag template to the content (and also records who flagged it). This could look like a simple button that says "Flag this page", and expands into a set of options when pressed.

Implementation

You can see the current implementation of flags in the WPD wiki at the page css/properties/font-size, and at its corresponding edit form.

The following are the pages involved in the data structure for setting flags:

“Form template” page (a reusable section of form syntax):

Display template (will eventually get called by each main template):

Property pages:

And you can see one example of pages being aggregated by their flags, using a Semantic MediaWiki query, at Stub pages.

Requirements

This is a section kept for historical purposes only The specific implementation for this will require coordination between content needs, technical implementation abilities, and visual design. Here are the requirements that solutions should satisfy (in decreasing order of importance). Note that we’re using “flags” as the catch-all term for these, but they might end up not being displayed that way.

  • Allow flags to be displayed in different styles depending on which type they are. For example, some may show as little flags at the top of the content , some may be big banners at the top of the content, and others could be subtle and at the bottom of the content.
  • Allow some method of listing which pages have a given flag on them
  • Make it easy for editors to add or remove flags
  • – Big gap in priority–
  • Allow some tags to be related in behavior/style/meaning (e.g. subclassing or categories)
  • Make it easy to define new tags as necessary (this will be pretty rare)