Changes between Version 26 and Version 27 of DevProjects


Ignore:
Timestamp:
Nov 6, 2007, 4:02:31 PM (17 years ago)
Author:
davea
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DevProjects

    v26 v27  
    99Then communicate with the [ProjectPeople area owner], sketching what you want to do and how. Work with the the area owner to carry out and check in the work.
    1010
    11 The following development projects are available:
     11The following development projects are available
     12'''(Note: please do not add items to these lists.
     13Suggest new items in the boinc_dev email list.)'''
    1214
    13 == Web Interface ==
     15== Web features ==
    1416
    15 === Front-end ===
    16 
    17 Requires front-end specialists with detailed knowledge and experience of markup and styling.
    18 
    19 Requires 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).
    20 
    21 Medium:
    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).
    23  * All styling declarations to be contained in external files
    24   * 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.
    25  * Typography corrections/improvements
    26  * Quality copy-writing to enhance readability and clarity of content
    27 
    28 Difficult/Complex:
    29  * 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).
    30   * 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   * Should aim for HTML v4.01 Strict or XHTML 1.0 Strict.
    33   * 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.
    34  * Semantic Markup — marking-up things based on what they are, not the default appearance of certain elements.
    35  * Accessibility
    36   * Replace table-based layouts with CSS positioning
    37   * Using appropriate units in style declarations to enable resizing of text based on user's preferences in browser.
    38   * 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.
    39  * Usability
    40   * Include error-messages and similar
    41  * Proper navigation model
    42   * 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).
    43   * Interface designer to establish the appropriate navigation options for each page.
    44  * HTTP efficiency
    45   * Content-Encoding
    46   * Providing correct Last-Modified and ETag headers to enable conditional GET requests.
    47     * Back-end support to enable “HTTP 304 Not Modified” responses to be sent when content hasn't changed based on conditional GET request(s).
    48   * More aggressive caching for content who's frequency of change is predictable (such as images).
    49 
    50 === Forum ===
    51 
    52  * Accessibility
    53   * 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)
    54    * Fill the requirements for progressive table rendering.
    55   * Checking/validating user-input
    56    * Make authoring accessible, semantic forum posts as easy as possible (the markdown syntax would be a good candidate).
    57 
    58  * HTTP Functionality
    59   * Use correct type of HTTP Request based on purpose/function
    60    * 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 (e.g. making the function unavailable via GET) to indicate that the (un)subscribe function changes something and isn't just fetching a page.
    61 
    62 === Back-end ===
    63 
    64 Requires advanced knowledge of PHP and MySQL.
     17(Requires advanced knowledge of PHP and MySQL.)
    6518
    6619Easy:
    67           * Collaboration/consultation with front-end specialist(s) when wanting to alter front-end code due to back-end changes (see front-end section).
    6820          * Convert PHP code to use [PhpDb the new database abstraction layer].
    6921          * Combine user page and profile
    7022          * Change the ops/ web pages to require login by a user with admin privileges.
    7123          * Change default Q&A page to refer BOINC-specific questions to BOINC web site
    72           * As much as possible; separate back-end and front-end code, to enable front-end specialists to edit front-end code without having to know about, or deal with back-end code.
    7324
    7425Medium:
    75           * Back-end must reliably produce valid front-end code (mark-up).
    7626          * Add a mechanism where team members can be designated as ‘admins’, and have some of the powers of the founder.
    7727          * Add a mechanism where joining a team or group requires approval of an admin.