Rules to Better Websites - Writing Rules

Hold on a second! How would you like to view this content?
Just the title! A brief blurb! Gimme everything!
  1. Do you know when to write a rule?

    The purpose of a rule is to effectively establish and record a process to guide employees in their day to day activities.

    Rules facilitate:

    • Consistency
    • Coherent instruction
    • A high standard of documentation
    • Better understanding of processes
    • Efficiency improvements

    Only write a rule after the situation has happened more than once – chances are it will happen again and a rule/standard should be created.

  2. Do you use the correct Rule structure?

    Your rule should be structured as follows:

    • Heading as a question
    • Why this rule exists and description
    • Bad example
    • Good example
  3. Do you have a master template for your website layouts?

    Consistency across your similar pages (such as standards pages in this case) is very important and should be made easy to implement.

    Guidelines and standards for the SSW website pages can be found at SSW Web Design References .

  4. Do you avoid the first person narrative?Unpublished

    ​When writing for an audience, you want to make sure you're consistent in your way of addressing them. For standards and rules, it's best to explain what they should do from an objective standpoint.
    If you want to use an example from your company to explain how something is done, you should avoid speaking from the 1st person (i.e. I or we) or 2nd person (i.e. you or your). Use 3rd person, like Wikipedia.
    ​​​​​​​Bad Example: I often see pages have 2 or 3 links to the same page
    ​Good Example: Pages sometimes have 2 or 3 links to the same pag​e
    Bad Example: At SSW, we use CRM to track sales activities 
    Good Example: SSW uses CRM to track sales activities

  5. Do you phrase the heading as a question?

    By forming the heading as a question you are encouraging the reader to answer with a simple yes or no. When the answer is no, it is clear that the rule has been broken and will need to be corrected.

    Phrase the heading as a question. 

    Bad example – the heading isn’t a question.
     Do you consider phrasing the heading as a question?

    Good example – the heading is phrased as a question.
  6. Do you give implementation examples where appropriate?

    By giving examples you are demonstrating clearly to the reader how he/she can to implement the rule correctly. It is better to position an example of the best possible scenario last so that the reader is left with a clear example in his/her mind as to what is required.

    See Do you show examples, a "bad example", then a "good example"? for more information.

  7. Do you label your example with a tick/cross followed by the word Figure:?

    Always use a green tick for a good example and red cross for a bad example followed with a label “Figure:”?

    Bad example - background colour is manually added to <tablegt; tag

    Bad example – example isn’t labelled with the X symbol followed by ‘Figure:’ 
    Figure: Bad example - background colour is manually added to <tablegt; tag
    Figure: Good example – It is clear that this example is incorrect.
     
    Figure: Good example - background colour is automatically added to <tablegt; tag
    Figure: Good example – It is clear that this example is correct.
  8. Do you have a nice small example?

    Your good and bad examples should be concise and to the point.

    Keep it simple, stupid :)
  9. Do you always get your rules proof read?

    It is important to have high quality text to communicate your message. If your grammar, spelling and expression are poor, the reader may be left confused and have the sense that you really aren’t writing thoughtfully and with authority on the subject.


    Always get a rule proof read and edited by a good English speaker who can assess whether or not your rule communicates its message and conforms to company standards, and who can find any errors in spelling, grammar and punctuation.

  10. Do all your employees know the quickest way to fix small web errors?

    ​Imagine this scenario... Mary notices a small error on a page in her intranet. She is a good employee... She fires up an email and reports the spelling error to info@s*w.com.au. As she sends it she says to herself "That it took more time to report the error than it would have taken me to fix it".

    Small  errors should be fixed by the person who found it. Text changes can be easily done in SharePoint or WordPress. If you know who is the culprit, it might be a good idea do inform that person, including the things you have fixed.

  11. Do you avoid duplicating content?

    ​​Every time you decide that a process should be documented, it’s important to double check that the content does not already exist. 

    Spending 5 minutes Googling can save you a lot of clean up and maintenance later.

     
    ​​​​
    Figure: You should think twice before adding content. As a great Australian Kerry Packer once said: "If you want to pass a new law, why don't you do it only when you've repealed an old one?"
    ​​

  12. Do you know how to submit a new rule suggestion (or bug report)?Unpublished

    This field should not be null (Remove me when you edit this field).
  13. Do you write the word 'email' in the correct format?

    ​Do you spell 'email' correctly?

    There is one correct way to spell 'email' and many incorrect ones. The common incorrect ones are:

    • EMail
    • e-mail

    Lower Case with dash:

    <p>Your e-mail address must match your confirm e-mail address</p>

    Bad example: Using 'e-mail' in your text

    <p>Your email address must match your confirm email address</p>

    Good example: Using 'email' instead
    Upper Case with capital M:

    <input class="form-control" data-val="true" data-val-required="The EMail field is required." id="EMail" name="EMail" placeholder="EMail" type="email" value="" data-cip-id="EMail" autocomplete="off">

    Bad example : 'EMail' used as a placeholder and in the validation message

    <input class="form-control" data-val="true" data-val-required="The Email field is required." id="Email" name="Email" placeholder="Email" type="email" value="" data-cip-id="Email" autocomplete="off">

    Good example: Use 'Email' instead 

    We have a rule in SSW Code Auditor and SSW Link Auditor to check for this.