Firefox/Windows 8 Metro Style Guides: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
 
(18 intermediate revisions by 4 users not shown)
Line 3: Line 3:


= Design/Theming guidelines =
= Design/Theming guidelines =
* use flyout panes over dialogs
*Message Dialogs
** Use message dialogs to present <strong>blocking questions</strong> that require the user's input.
** Use message dialogs for rror messages that apply to the <strong>overall app context</strong>[http://msdn.microsoft.com/en-us/library/windows/apps/hh738363.aspx]
*Flyout [http://msdn.microsoft.com/en-us/library/windows/apps/hh465304.aspx#flyouts]
** Show a flyout only in response to a user tap or click, and you should always dismiss the flyout when the user taps outside of it
**<strong>Size</strong>: The Flyout should be as small as possible given its content. It doesn't need extra padding beyond what is provided by the Flyout itself. If a control isn't absolutely necessary, then don't include it.
**<strong>Position</strong>: The Flyout should always be positioned near its point of invocation. Flyouts should never be positioned in non-contextual places such as the center of the screen. [http://msdn.microsoft.com/en-us/library/windows/apps/hh465341.aspx]
*Context Menu [http://msdn.microsoft.com/en-us/library/windows/apps/hh465308.aspx]
** A maximum width that equates to approximately <strong>50 characters</strong>.
** Show the fewest number of commands possible, up to the <strong>six-command limit</strong>
** Use <strong>sentence capitalization</strong> for each command name
** Use a separator to distinguish groups of related commands
** Order custom commands in the context menu by importance, with <strong>the most important commands at the bottom</strong>
*App Bar
**Do follow placement conventions.
***Place the New/Add/Create button (+ icon) on the far right.
***Group view switching buttons together and place them on the far left.
***Place Accept, Yes, OK commands to the left of Reject, No, Cancel commands.
**Do set the app bar's dismissal mode to sticky when displaying contextual commands.(Should applied to Firefox Start contextual app bar)
*Typography
** Use "Title Case" only for heading text.  For other text (including button labels, menu items, etc.) use "Sentence case" [http://msdn.microsoft.com/en-us/library/windows/apps/hh465308.aspx][http://msdn.microsoft.com/en-us/library/windows/desktop/aa511453.aspx].
*Help Page [http://msdn.microsoft.com/en-us/library/windows/apps/hh465049.aspx]
** Include a link to your support or home page or either embed an online page into your help page
** Do label the entry point in the Settings pane Help to clearly identify it.
** <strong>Don't use the Help entry point to link directly to a website</strong>. Don't launch a web browser when the user taps Help.
 
= Coding Guidelines =
= Coding Guidelines =
* Generally we use [https://developer.mozilla.org/en-US/docs/Developer_Guide/Coding_Style Mozilla Coding Style], with a few exceptions:
* Generally we use [https://developer.mozilla.org/en-US/docs/Developer_Guide/Coding_Style Mozilla Coding Style], with a few exceptions:
* You don't need to wrap lines to 80 characters.  Use longer lines (up to around 120 characters; use your judgement) if it improves readability.
** You don't need to wrap lines to 80 characters.  Use longer lines (up to around 100 characters; use your judgement) if it improves readability.
* Consistency is king, and supersedes any particular rule.
* Consistency is king, and supersedes any particular rule.
== JS ==
== JS ==
* else in if/else pairings are double cuddled ( eg } else {
* Coding Style exceptions/additions:
** Put the opening brace on the same line as the "function" keyword (rather than on a separate line by itself).
** No space before ":" in object literals.
* https://developer.mozilla.org/en-US/docs/JavaScript_Tips
 
== CSS ==
== CSS ==
* if you create an attribute and it has only one value, do not set it to true/false. Remove the attribute in the case of false. This produces cleaner, more concise css, without imperiling js readability.
* if you create an attribute and it has only one value, do not set it to true/false. Remove the attribute in the case of false. This produces cleaner, more concise css, without imperiling js readability.
== XUL / XML ==
* One attribute per line, aligning with the first character of the first one
* If there is an id attribute, that should be the first attribute listed
* Children are indented 2 spaces
* Treat strings enclosed as children
** In example below, &clearPrivateData.done is an enclosed string where as &clearPrivateData.button is a label, which is an attribute
* If separate open & closing tags,  tags should go on separate lines
* No soft tabs (\t characters)
* Try to keep the 80 character limit
** (and if not, try really hard to keep it below a 100)
** If your oncommand, command, or onclick code is too long, please really consider putting it in a function
* Example
<pre>
<hbox align="center">
  <button id="prefs-clear-data"
          label="&clearPrivateData.button;"
          command="cmd_sanitize"
          flex="1" />
  <spacer id="clear-notification-empty"/>
  <cssthrobber id="clearprivacythrobber">
  </cssthrobber>
  <description id="clear-notification-done">
    &clearPrivateData.done;
  </description>
</hbox>
</pre>
= helpful references =
= helpful references =
* yuan's list of design links: https://kippt.com/yuan/designing-for-windows-8
* yuan's list of design links: https://kippt.com/yuan/designing-for-windows-8
* general coding guidelines for mozilla: https://developer.mozilla.org/en-US/docs/Developer_Guide/Coding_Style
* general coding guidelines for Mozilla: https://developer.mozilla.org/en-US/docs/Developer_Guide/Coding_Style
* general branding/identity/style/usage guide for Mozilla: https://www.mozilla.org/en-US/styleguide/

Latest revision as of 22:21, 7 February 2014

Nota Bene

  • this a spot to jot down guidelines of varying types, largely for front end developers & designers. This includes code style, theming style, and whatever else will help us produce a consistent, shiny produce faster. If you have questions about this page, please ping :ally in #windev.

Design/Theming guidelines

  • Message Dialogs
    • Use message dialogs to present blocking questions that require the user's input.
    • Use message dialogs for rror messages that apply to the overall app context[1]
  • Flyout [2]
    • Show a flyout only in response to a user tap or click, and you should always dismiss the flyout when the user taps outside of it
    • Size: The Flyout should be as small as possible given its content. It doesn't need extra padding beyond what is provided by the Flyout itself. If a control isn't absolutely necessary, then don't include it.
    • Position: The Flyout should always be positioned near its point of invocation. Flyouts should never be positioned in non-contextual places such as the center of the screen. [3]
  • Context Menu [4]
    • A maximum width that equates to approximately 50 characters.
    • Show the fewest number of commands possible, up to the six-command limit
    • Use sentence capitalization for each command name
    • Use a separator to distinguish groups of related commands
    • Order custom commands in the context menu by importance, with the most important commands at the bottom
  • App Bar
    • Do follow placement conventions.
      • Place the New/Add/Create button (+ icon) on the far right.
      • Group view switching buttons together and place them on the far left.
      • Place Accept, Yes, OK commands to the left of Reject, No, Cancel commands.
    • Do set the app bar's dismissal mode to sticky when displaying contextual commands.(Should applied to Firefox Start contextual app bar)
  • Typography
    • Use "Title Case" only for heading text. For other text (including button labels, menu items, etc.) use "Sentence case" [5][6].
  • Help Page [7]
    • Include a link to your support or home page or either embed an online page into your help page
    • Do label the entry point in the Settings pane Help to clearly identify it.
    • Don't use the Help entry point to link directly to a website. Don't launch a web browser when the user taps Help.

Coding Guidelines

  • Generally we use Mozilla Coding Style, with a few exceptions:
    • You don't need to wrap lines to 80 characters. Use longer lines (up to around 100 characters; use your judgement) if it improves readability.
  • Consistency is king, and supersedes any particular rule.

JS

CSS

  • if you create an attribute and it has only one value, do not set it to true/false. Remove the attribute in the case of false. This produces cleaner, more concise css, without imperiling js readability.

XUL / XML

  • One attribute per line, aligning with the first character of the first one
  • If there is an id attribute, that should be the first attribute listed
  • Children are indented 2 spaces
  • Treat strings enclosed as children
    • In example below, &clearPrivateData.done is an enclosed string where as &clearPrivateData.button is a label, which is an attribute
  • If separate open & closing tags, tags should go on separate lines
  • No soft tabs (\t characters)
  • Try to keep the 80 character limit
    • (and if not, try really hard to keep it below a 100)
    • If your oncommand, command, or onclick code is too long, please really consider putting it in a function
  • Example
<hbox align="center">
  <button id="prefs-clear-data"
          label="&clearPrivateData.button;"
          command="cmd_sanitize"
          flex="1" />
   <spacer id="clear-notification-empty"/>
   <cssthrobber id="clearprivacythrobber">
   </cssthrobber>
   <description id="clear-notification-done">
     &clearPrivateData.done;
   </description>
</hbox>

helpful references