Changes between Version 22 and Version 23 of DevProjects

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

DevProjects

@@ -23 +23 @@
  * All styling declarations to be contained in external files
  * Separation of structure/content and presentation — removal of deprecated presentational markup elements (that's what CSS is for).
+  * 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?).
  * Typography corrections/improvements
  * Quality copy-writing to enhance readability and clarity of content
@@ -29 +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).
   * Any changes to URL structure require (permanent) redirects from all previous locations to all new locations.
- * 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].
+ * 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].
   * 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).
   * 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.
@@ -49 +50 @@
   * Content-Encoding
   * Providing correct Last-Modified and ETag headers to enable conditional GET requests.
-    * Back-end support to enable “HTTP 304 Not Modified” reponses to be sent when content hasn't changed based on conditional GET request(s).
+    * Back-end support to enable “HTTP 304 Not Modified” responses to be sent when content hasn't changed based on conditional GET request(s).
   * More ‘agressive’ caching for content who's frequency of change is predictable (such as images).
+
+=== Forum ===
+
+ * Accessibility
+  * 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)
+   * 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.
+  * Checking/validating user-input
+   * Make authoring accessible, semantic forum posts as easy as possible (the markdown syntax would be a good candidate).
+
+ * HTTP Functionality
+  * Use correct type of HTTP Request based on purpose/function
+   * 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.
 
 === Back-end ===
@@ -65 +78 @@
 
 Medium:
-          * Must reliably produce valid front-end code (mark-up).
+          * Back-end must reliably produce valid front-end code (mark-up).
           * Add a mechanism where team members can be designated as ‘admins’, and have some of the powers of the founder.
           * Add a mechanism where joining a team or group requires approval of an admin.
@@ -130 +143 @@
           * Scheduler: implement mechanisms so that server:
                 * 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. 
-          * Implement a 'benchmark result' mechanism: every host runs a benchmark result per app version, and the CPU time determines credit/CPU for future results 
+          * Implement a ‘benchmark result’ mechanism: every host runs a benchmark result per app version, and the CPU time determines credit/CPU for future results 
 
 Please check with [ProjectPeople area owner or David Anderson] before undertaking any of these.