Changes between Version 22 and Version 23 of DevProjects


Ignore:
Timestamp:
Nov 3, 2007, 10:01:08 PM (17 years ago)
Author:
Lee Carre
Comment:

added more items to web interface section, added forum sub-section, expanded/elaborated on existing items

Legend:

Unmodified
Added
Removed
Modified
  • DevProjects

    v22 v23  
    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?).
    2526 * Typography corrections/improvements
    2627 * Quality copy-writing to enhance readability and clarity of content
     
    2930 * 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).
    3031  * Any changes to URL structure require (permanent) redirects from all previous locations to all new locations.
    31  * 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].
     32 * 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].
    3233  * 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).
    3334  * 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.
     
    4950  * Content-Encoding
    5051  * Providing correct Last-Modified and ETag headers to enable conditional GET requests.
    51     * Back-end support to enable “HTTP 304 Not Modified” reponses to be sent when content hasn't changed based on conditional GET request(s).
     52    * Back-end support to enable “HTTP 304 Not Modified” responses to be sent when content hasn't changed based on conditional GET request(s).
    5253  * More ‘agressive’ caching for content who's frequency of change is predictable (such as images).
     54
     55=== Forum ===
     56
     57 * Accessibility
     58  * Table mark-up to better indicate headers and relationship between cells and headers (mostly involves changing the template used by the back-end to generate thread tables)
     59   * A side-advantage is that by indicating such things allows user agents to render a table as soon as it starts getting data, rather than having to wait for the entire table to begin calculating the width, this will result in significant rendering improvements.
     60  * Checking/validating user-input
     61   * Make authoring accessible, semantic forum posts as easy as possible (the markdown syntax would be a good candidate).
     62
     63 * HTTP Functionality
     64  * Use correct type of HTTP Request based on purpose/function
     65   * GET requests should not change anything (as per the [http://tools.ietf.org/html/rfc2126 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.
    5366
    5467=== Back-end ===
     
    6578
    6679Medium:
    67           * Must reliably produce valid front-end code (mark-up).
     80          * Back-end must reliably produce valid front-end code (mark-up).
    6881          * Add a mechanism where team members can be designated as ‘admins’, and have some of the powers of the founder.
    6982          * Add a mechanism where joining a team or group requires approval of an admin.
     
    130143          * Scheduler: implement mechanisms so that server:
    131144                * Attempts to send results from the same WU to hosts with similar speed, so that a fast host doesn't have to wait weeks to get credit.
    132           * Implement a 'benchmark result' mechanism: every host runs a benchmark result per app version, and the CPU time determines credit/CPU for future results
     145          * Implement a ‘benchmark result’ mechanism: every host runs a benchmark result per app version, and the CPU time determines credit/CPU for future results
    133146
    134147Please check with [ProjectPeople area owner or David Anderson] before undertaking any of these.