Changes between Version 24 and Version 25 of DevProjects


Ignore:
Timestamp:
Nov 4, 2007, 1:24:53 AM (17 years ago)
Author:
Didactylos
Comment:

typos, language

Legend:

Unmodified
Added
Removed
Modified
  • DevProjects

    v24 v25  
    1717Requires front-end specialists with detailed knowledge and experience of markup and styling.
    1818
    19 Requires colaboration between front-end specialists and back-end developers when changes to back-end/features affect front-end behaviour (to ensure correct front-end code).
     19Requires collaboration between front-end specialists and back-end developers when changes to back-end/features affect front-end behaviour (to ensure correct front-end code).
    2020
    2121Medium:
    22  * Some kind of ‘Quality Assurance’ process to check any changes to front-end are appropriate (far easier to have poor front-end code be submitted and missed than back-end code; bad back-end code generally doesn't work and/or breaks something, poor front-end code is tollerated by browsers).
     22 * Some kind of quality assurance process to check any changes to front-end are appropriate (far easier to have poor front-end code be submitted and missed than back-end code; bad back-end code generally doesn't work and/or breaks something, poor front-end code is tolerated by browsers).
    2323 * All styling declarations to be contained in external files
    2424 * Separation of structure/content and presentation — removal of deprecated presentational markup elements (that's what CSS is for).
    25   * Separate “General” and “Project-specific” CSS files. The idea being that a project can make customisations in the Project-Specific file, over-riding the “general” styling, while still being able to easilly “update/upgrade” the general styling CSS file needed for basic layout and such. This is to help projects avoid having to ‘back-up’ their customisations to avoid them being over-written during a server upgrade, thus encouraging each project to adopt a ‘unique’ look & feel for better identity (many projects don't change the default presentation, so the web-interface of many projects looks the same. The difficulty in making, and maintaining customisations while still trying to upgrade BOINC server versions is likely a reason most don't bother; afterall, what's the point if they're just going to be over-written at the next upgrade?).
     25  * Separate “General” and “Project-specific” CSS files. The idea being that a project can make customisations in the Project-Specific file, over-riding the “general” styling, while still being able to easily “update/upgrade” the general styling CSS file needed for basic layout and such. This is to help projects avoid having to ‘back-up’ their customisations to avoid them being over-written during a server upgrade, thus encouraging each project to adopt a ‘unique’ look & feel for better identity (many projects don't change the default presentation, so the web-interface of many projects looks the same. The difficulty in making, and maintaining customisations while still trying to upgrade BOINC server versions is likely a reason most don't bother; after all, what's the point if they're just going to be over-written at the next upgrade?).
    2626 * Typography corrections/improvements
    2727 * Quality copy-writing to enhance readability and clarity of content
    2828
    2929Difficult/Complex:
    30  * 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).
     30 * Information Architecture — e.g. creating a appropriate, stable URL structure, allowing for future expansion and change (e.g. use of HTTP default documents rather than current practice).
    3131  * Any changes to URL structure require (permanent) redirects from all previous locations to all new locations.
    3232 * Valid Markup & style declarations — Importance of valid code: “[http://diveintomark.org/archives/2003/05/05/why_we_wont_help_you Why We Won't Help You]”, [http://ln.hixie.ch/?start=1037910467&count=1 How User-Agents Handle Tag-Soup].
     
    3434  * 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.
    3535  * Closing tags
    36   * Correct nesting of elements: closing tags in the opposite order to opening, eg closing the most recently opened first: {{{<1><2><3></3></2></1>}}}
    37   * Mark-up authored in such a way as to allow presentation to be radically changed via CSS — involves structure * ID/class values based on purpose rather than presentation/appearence.
    38  * Semantic Markup — marking-up things based on what they are, not the default appearence of certain elements. For example: using {{{<blockquote>…“quoted” text…</blockquote>}}} for indentation is inappropriate. Block-quotes should be marked as {{{<blockquote><p>…actual block-quote…</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.
     36  * Correct nesting of elements: closing tags in the opposite order to opening, e.g. closing the most recently opened first: {{{<1><2><3></3></2></1>}}}
     37  * Mark-up authored in such a way as to allow presentation to be radically changed via CSS — involves structure * ID/class values based on purpose rather than presentation/appearance.
     38 * Semantic Markup — marking-up things based on what they are, not the default appearance of certain elements. For example: using {{{<blockquote>…“quoted” text…</blockquote>}}} for indentation is inappropriate. Block-quotes should be marked as {{{<blockquote><p>…actual block-quote…</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.
    3939 * Accessibility
    4040  * Replacing table-based layouts with CSS positioning
    4141  * More semantic mark-up (see semantic markup item)
    4242  * Using appropriate units in style declarations to enable resizing of text based on user's preferences in browser.
    43   * Unobtrusive, accessible use of ECMAScript (!JavaScript), implemented via progressive enhancement and DOM Scripting methods. [http://www.456bereastreet.com/archive/200612/you_cannot_rely_on_javascript_being_available_period/ Scripting is not always available and can not be relied upon] (for many reasons, the majority being outside the user's control), 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.
     43  * Unobtrusive, accessible use of ECMAScript (!JavaScript), implemented via progressive enhancement and DOM Scripting methods. [http://www.456bereastreet.com/archive/200612/you_cannot_rely_on_javascript_being_available_period/ Scripting is not always available and can not be relied upon] (for many reasons, the majority being outside the user's control), and the back-end needs to be able to provide same functionality (albeit less elegant/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.
    4444 * Usability
    4545  * Including error-messages and similar
     
    5151  * Providing correct Last-Modified and ETag headers to enable conditional GET requests.
    5252    * Back-end support to enable “HTTP 304 Not Modified” responses to be sent when content hasn't changed based on conditional GET request(s).
    53   * More ‘agressive’ caching for content who's frequency of change is predictable (such as images).
     53  * More aggressive caching for content who's frequency of change is predictable (such as images).
    5454
    5555=== Forum ===
     
    6363 * HTTP Functionality
    6464  * Use correct type of HTTP Request based on purpose/function
    65    * GET requests should not change anything (as per the [http://www.w3.org/Protocols/rfc2616/rfc2616.html HTTP/1.1 RFC]). Currently the Subscribe/Unsubscribe functions use regular links (resulting in GET requests) to change subsciption status, instead a POST request should be required (eg making the funcion unavilable via GET) to indicate that the (un)subscribe function changes something and isn't just fetching a page.
     65   * GET requests should not change anything (as per the [http://www.w3.org/Protocols/rfc2616/rfc2616.html HTTP/1.1 RFC]). Currently the Subscribe/Unsubscribe functions use regular links (resulting in GET requests) to change subscription status, instead a POST request should be required (eg making the function unavailable via GET) to indicate that the (un)subscribe function changes something and isn't just fetching a page.
    6666
    6767=== Back-end ===
     
    7070
    7171Easy:
    72           * Colaboration/consultation with front-end specialist(s) when wanting to alter front-end code due to back-end changes (see front-end section).
     72          * Collaboration/consultation with front-end specialist(s) when wanting to alter front-end code due to back-end changes (see front-end section).
    7373          * Convert PHP code to use [PhpDb the new database abstraction layer].
    7474          * Combine user page and profile