Changes between Version 21 and Version 22 of DevProjects


Ignore:
Timestamp:
Nov 3, 2007, 9:34:35 PM (17 years ago)
Author:
Lee Carre
Comment:

additional comments and refinement

Legend:

Unmodified
Added
Removed
Modified

  • DevProjects

    v21 v22  
    1313== Web Interface ==
    1414
    15 === Back-end ===
    16 
    17 Requires advanced knowledge of PHP and MySQL.
    18 
    19 Easy:
    20           * Convert PHP code to use [PhpDb the new database abstraction layer].
    21           * Combine user page and profile
    22           * Change the ops/ web pages to require login by a user with admin privileges.
    23           * Change default Q&A page to refer BOINC-specific questions to BOINC web site
    24           * 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.
    25 
    26 Medium:
    27           * Add a mechanism where team members can be designated as ‘admins’, and have some of the powers of the founder.
    28           * Add a mechanism where joining a team or group requires approval of an admin.
    29           * Groups (sub-teams).  New DB table with name, description, team ID, flags, forum ID. Group membership table.
    30 Difficult/Complex:
    31           * Propagate profiles between projects. When create or edit profile, if attached to other projects, show ‘propagate changes’ page, with checkboxes for other projects (must have same password on other projects). Add web RPCs for updating profile (args: user ID, profile, password hash). Implement this so that page doesn't block waiting for replies from RPCs.  NOTE: this may not be a good idea — spammers could exploit it.
    32           * Same for forum preferences
    33           * Add new profile features:
    34                 * ‘Buddy lists’
    35                 * list of recent posts and threads this person created, on this and other projects
    36                 * other features from social networking sites?
    37           * Add ‘referral’ mechanism: new user creates account, enters email of ‘referrer’ (or goes to URL that has it embedded). Give referrer a fraction of credit (or a 1-time bonus). List referrals on user page (show only those still active). Add new referral table to DB.
    38           * Make it easy for teams to offer a client download that features their skin, and pre-register the user on that team for any projects he attaches to.
    39 
    4015=== Front-end ===
    4116
    … …  
    4520
    4621Medium:
     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).
    4723 * All styling declarations to be contained in external files
    4824 * Separation of structure/content and presentation — removal of deprecated presentational markup elements (that's what CSS is for).
    … …  
    5329 * 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).
    5430  * Any changes to URL structure require (permanent) redirects from all previous locations to all new locations.
    55  * Valid Markup & style declarations
     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].
    5632  * 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).
    5733  * 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.
    5834  * Closing tags
    5935  * 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>}}}
     36  * 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.
    6037 * 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.
    6138 * Accessibility
    … …  
    7451    * Back-end support to enable “HTTP 304 Not Modified” reponses to be sent when content hasn't changed based on conditional GET request(s).
    7552  * More ‘agressive’ caching for content who's frequency of change is predictable (such as images).
     53
     54=== Back-end ===
     55
     56Requires advanced knowledge of PHP and MySQL.
     57
     58Easy:
     59          * Colaboration/consultation with front-end specialist(s) when wanting to alter front-end code due to back-end changes (see front-end section).
     60          * Convert PHP code to use [PhpDb the new database abstraction layer].
     61          * Combine user page and profile
     62          * Change the ops/ web pages to require login by a user with admin privileges.
     63          * Change default Q&A page to refer BOINC-specific questions to BOINC web site
     64          * 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.
     65
     66Medium:
     67          * Must reliably produce valid front-end code (mark-up).
     68          * Add a mechanism where team members can be designated as ‘admins’, and have some of the powers of the founder.
     69          * Add a mechanism where joining a team or group requires approval of an admin.
     70          * Groups (sub-teams).  New DB table with name, description, team ID, flags, forum ID. Group membership table.
     71Difficult/Complex:
     72          * Propagate profiles between projects. When create or edit profile, if attached to other projects, show ‘propagate changes’ page, with checkboxes for other projects (must have same password on other projects). Add web RPCs for updating profile (args: user ID, profile, password hash). Implement this so that page doesn't block waiting for replies from RPCs.  NOTE: this may not be a good idea — spammers could exploit it.
     73          * Same for forum preferences
     74          * Add new profile features:
     75                * ‘Buddy lists’
     76                * list of recent posts and threads this person created, on this and other projects
     77                * other features from social networking sites?
     78          * Add ‘referral’ mechanism: new user creates account, enters email of ‘referrer’ (or goes to URL that has it embedded). Give referrer a fraction of credit (or a 1-time bonus). List referrals on user page (show only those still active). Add new referral table to DB.
     79          * Make it easy for teams to offer a client download that features their skin, and pre-register the user on that team for any projects he attaches to.
    7680
    7781