Changes between Version 19 and Version 20 of DevProjects


Ignore:
Timestamp:
Nov 3, 2007, 8:50:37 PM (17 years ago)
Author:
Nicolas
Comment:

Format correctly

Legend:

Unmodified
Added
Removed
Modified
  • DevProjects

    v19 v20  
    4343
    4444Medium:
    45  *Typography corrections/improvements
    46  *
     45 * Typography corrections/improvements
    4746
    4847Difficult/Complex:
    49  *Information Architecture — eg creating a appropriate, stable URL structure, allowing for future expansion and change (eg use of HTTP default documents rather than current practice).
    50   *Any changes to URL structure require (permanent) redirects from all previous locations to all new locations.
    51  *Valid Markup & style declarations
    52   *Should aim for HTML v4.01 Strict (XHTML served with the correct MIME-type/content-type doesn't have sufficient support, modern HTML authoring techniques are perfectly capable, adequate, suitable, and appropriate).
    53   *If Strict isn't reasonably attainable (very few reasons why apart from time constraints to correct poor design/implementation), then aim for Transitional as an intermediate step, so that the code will at least be valid.
    54  *Semantic Markup — marking-up things based on what they are, not the default appearence of certain elements (eg using <blockquote>…“quoted” text</blockquote> for indentation is inappropriate. Block-quotes should be marked as <blockquote><p>…</p></blockquote> and nothing else. In this example, if indentation is required then CSS should be used to apply styling to an appropriate element (a regular paragraph (<p>Paragraph text</p>) would probably be suitable unless the element isn't actually a paragraph.
    55  *Accessibility
     48 * Information Architecture — eg creating a appropriate, stable URL structure, allowing for future expansion and change (eg use of HTTP default documents rather than current practice).
     49  * Any changes to URL structure require (permanent) redirects from all previous locations to all new locations.
     50 * Valid Markup & style declarations
     51  * Should aim for HTML v4.01 Strict (XHTML served with the correct MIME-type/content-type doesn't have sufficient support, modern HTML authoring techniques are perfectly capable, adequate, suitable, and appropriate).
     52  * If Strict isn't reasonably attainable (very few reasons why apart from time constraints to correct poor design/implementation), then aim for Transitional as an intermediate step, so that the code will at least be valid.
     53 * Semantic Markup — marking-up things based on what they are, not the default appearence of certain elements (eg using {{{<blockquote>…“quoted” text</blockquote>}}} for indentation is inappropriate. Block-quotes should be marked as {{{<blockquote><p>…</p></blockquote>}}} and nothing else. In this example, if indentation is required then CSS should be used to apply styling to an appropriate element; a regular paragraph ({{{<p>Paragraph text</p>}}}) would probably be suitable unless the element isn't actually a paragraph.
     54 * Accessibility
    5655  * Replacing table-based layouts with CSS positioning
    5756  * More semantic mark-up
    5857  * using appropriate units in style declarations to enable resizing of text based on user's preferences in browser.
    59   * Unobtrusive, accessible ECMAScript (JavaScript) use, implemented via DOM Scripting methods. [http://www.456bereastreet.com/archive/200612/you_cannot_rely_on_javascript_being_available_period/ Scripting is not always available (for many reasons, most outside the user's control) and can not be relied upon], and the back-end needs to be able to provide same functionality (albeit less elegent/sophisticated) when scripting isn't available for whatever reason. A simple example would be back-end form input validation when scripting isn't available to protect against garbage/bogus form data and provide feedback to user.
    60  *Usability
    61  *Proper navigation model
    62   *Navigation bar/panel on common pages (rather than always having to (or only being able to) go back to “Home” and then navigate to desired section from there).
    63   *Interface designer to establish the appropriate navigation options for each page.
    64  *HTTP efficiency
    65   *Content-Encoding
    66   *Providing correct Last-Modified and ETag headers to enable conditional GET requests.
    67     *Back-end support to enable “HTTP 304 Not Modified” reponses to be sent when content hasn't changed based on conditional GET request(s).
    68   *More ‘agressive’ caching for content who's frequency of change is predictable (such as images).
     58  * Unobtrusive, accessible ECMAScript (!JavaScript) use, implemented via DOM Scripting methods. [http://www.456bereastreet.com/archive/200612/you_cannot_rely_on_javascript_being_available_period/ Scripting is not always available (for many reasons, most outside the user's control) and can not be relied upon], and the back-end needs to be able to provide same functionality (albeit less elegent/sophisticated) when scripting isn't available for whatever reason. A simple example would be back-end form input validation when scripting isn't available to protect against garbage/bogus form data and provide feedback to user.
     59 * Usability
     60 * Proper navigation model
     61  * Navigation bar/panel on common pages (rather than always having to (or only being able to) go back to “Home” and then navigate to desired section from there).
     62  * Interface designer to establish the appropriate navigation options for each page.
     63 * HTTP efficiency
     64  * Content-Encoding
     65  * Providing correct Last-Modified and ETag headers to enable conditional GET requests.
     66    * Back-end support to enable “HTTP 304 Not Modified” reponses to be sent when content hasn't changed based on conditional GET request(s).
     67  * More ‘agressive’ caching for content who's frequency of change is predictable (such as images).
    6968
    7069