Changes between Version 20 and Version 21 of DevProjects
- Timestamp:
- Nov 3, 2007, 9:17:55 PM (17 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
DevProjects
v20 v21 25 25 26 26 Medium: 27 * Add a mechanism where team members can be designated as 'admins', and have some of the powers of the founder.27 * Add a mechanism where team members can be designated as ‘admins’, and have some of the powers of the founder. 28 28 * Add a mechanism where joining a team or group requires approval of an admin. 29 29 * Groups (sub-teams). New DB table with name, description, team ID, flags, forum ID. Group membership table. 30 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.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 32 * Same for forum preferences 33 33 * Add new profile features: … … 42 42 Requires front-end specialists with detailed knowledge and experience of markup and styling. 43 43 44 Requires colaboration between front-end specialists and back-end developers when changes to back-end/features affect front-end behaviour (to ensure correct front-end code). 45 44 46 Medium: 47 * All styling declarations to be contained in external files 48 * Separation of structure/content and presentation — removal of deprecated presentational markup elements (that's what CSS is for). 45 49 * Typography corrections/improvements 50 * Quality copy-writing to enhance readability and clarity of content 46 51 47 52 Difficult/Complex: … … 51 56 * 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). 52 57 * 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. 53 * Semantic Markup — marking-up things based on what they are, not the default appearence of certain elements (eg using {{{<blockquote>…“quoted” text</blockquote>}}} for indentation is inappropriate. Block-quotes should be marked as {{{<blockquote><p>…</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. 58 * Closing tags 59 * 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>}}} 60 * 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. 54 61 * Accessibility 55 62 * Replacing table-based layouts with CSS positioning 56 * More semantic mark-up 57 * using appropriate units in style declarations to enable resizing of text based on user's preferences in browser.58 * Unobtrusive, accessible ECMAScript (!JavaScript) use, implemented via DOM Scripting methods. [http://www.456bereastreet.com/archive/200612/you_cannot_rely_on_javascript_being_available_period/ Scripting is not always available (for many reasons, most outside the user's control) and can not be relied upon], and the back-end needs to be able to provide same functionality (albeit less elegent/sophisticated) when scripting isn't available for whatever reason. A simple example would be back-end form input validation when scripting isn't available to protect against garbage/bogus form data and provide feedback to user.63 * More semantic mark-up (see semantic markup item) 64 * Using appropriate units in style declarations to enable resizing of text based on user's preferences in browser. 65 * 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 elegent/sophisticated) when scripting isn't available for whatever reason. A simple example would be back-end form input validation when scripting isn't available to protect against garbage/bogus form data and provide feedback to user. 59 66 * Usability 67 * Including error-messages and similar 60 68 * Proper navigation model 61 69 * 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).
