| 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.) |
