| At line 1 changed one line |
| It's often practiced -- especially when extending existing systems -- to model the input data based on the way that the system actually works internally, instead of chosing the format optimal for the task at hand. This is unacceptable for final product. |
| In these days when processor power is cheap and programmers are serving the whole world, it's all too common to see systems requiring input based on how the system works, instead of how people work. This user-unfriendly approach exposes these systems to competition from products that are nicer to their users, though we might view them as technically inferior. |
| At line 3 changed one line |
| Always design the interface (be it commands, switches, input text files or GUI) so that it is optimal for the work that the human user has to do. Never require strict or weird formatting, specific ordering of fields, duplicating information or similar things that make the user work harder just for the sake of simplier code. |
| To that end, please consider the following advice - |
| * Compute the information that can be derived, don't require the user to count characters or keystrokes, specify level of nesting or numbering of items if they are obvious from the structure of the document -- unless there is a good reason to do so. |
| * Present data in the form optimal for the user's task: |
| ** make the text readable and easy to navigate, |
| ** don't require a lot of work to only make a tiny change. |
| * Collaborate on user interface design. |
| ** Don't be different without a reason. |
| At line 5 changed one line |
| Always make the system compute the values that can be derieved, present data in the form optimal for the user's task, etc. Processor power is cheap these days. |
| This doesn't mean that you should never require specific format or duplicated data -- they can have their own uses. For example, when changing your password, you're prompted to enter it twice. This serves to verify a concealed entry and avoid losing system access. This is close to [[http://en.wikipedia.org/wiki/Poka-yoke|poka-yoke]], so it's OK. Similarly, if the input files are to be heavily edited by various people, then it's good to keep them readable by restricting markup syntax, stripping formatting markup added by word processing bloatware, etc. Of course, such a strict syntax should be paired with validation, and a good, non-destructive way of indicating errors. |
| At line 7 changed one line |
| This doesn't mean that you should never require specific format or duplicated data -- they can have their own uses. For example, when changing your password, you're prompted to enter it twice. This is has its use outside of just simplyfying the system, so it's ok. Similar, if the input files are to be heavily edited by various people, it's good to keep them readable by requiring strict syntax. Of course, it should be paired with apropriate validating and error reporting. |
| This is a good practice: use your computation power to ease the use of markup, even if that complicates your parser. Users will be grateful for a forgiving parser -- unless they have to become more forgiving for other, sloppy users too as a result. |
| At line 9 changed one line |
| This is a good practice: Use your computation power to ease the use of markup, even if that complicates your parser. Users will be greatful for a forgiving parser. |
| ---- |
| At line 11 changed one line |
| The most common way that good formats make the machine work harder is by allowing multiple administrator or user-group choices or plugin configurations to deal with the same simple markup. This should be done anywhere that a decision must be collective on the part of the users as a group without every single user being necessarily able to over-ride the decision. Three examples to illustrate this: |
| There are also some pieces of advice useful for web browser and wiki engine developers: |
| * When using real-time parsers to check syntax, make sure they don't interrupt the user's pattern of entry. Do mark the error, but don't require the user to fix it right then. |
| * Never throw formatting errors unless the user's meaning is ambiguous, and only then when the system needs non-ambiguity. For example, phone numbers read by people can be ambiguous, while auto-dialed ones should not. |
| * Where entries must be unambiguous, (e.g., entering credit card numbers,) parse the input and auto-correct all unambiguous exceptions (e.g., dropping non-numerics, switching to all uppercase, etc.) |
| * For ambiguous exceptions, calculate the exception level in the parser and display a likely guess of the correct entry. For example, a user entering a two-digit birth year probably means one in the past 100 years, a reservation is probably in the next 100 years, and a food safety date is probably within 50 years either way. |
| * Never, EVER, lose or discard a person's work. Instead - |
| ** Allow users making incomplete entries to save them and finish them later. Do this automatically for users that time-out. |
| ** Allow users making errors to correct them in the original context with the non-parsible portion highlighted. |
| ** Disable, handle or support undo on all "buttons of death" (e.g., jumping to the last page on Backspace, overstriking a highlighted field, etc.) |
| ** Support undo and redo. |
| * Do not require entries to follow a specific order. |
| * Do not require users to re-enter anything for the sake of simpler code. |
| ** Store entries in a user context and recall them from there as needed. |
| ** Compute all values that can be derived, e.g., browser version, display size, amount of memory remaining, number of characters left before reaching allowed field size, etc. |
| * Collaborate on user interface design. (Hey! - we're back where we started.) |
| ** Reuse code |
| ** Don't be different without a reason. |
| At line 13 changed one line |
| == specifying emphasis without differentiating bold, italics, underlines, fonts |
| To make your system widely-adopted, give it a humane user interface (be it commands, switches, input text files or GUI). Further, expect to redesign and adapt this interface as users evolve, even when you don't like their evolution. The needed goal is to optimize human effectiveness and minimize potential human errors, i.e. [[http://en.wikipedia.org/wiki/Poka-yoke|poka-yoke]]. |
| At line 15 changed 18 lines |
| When defining titles and alternate titles, quotes or editors notes, or headings, or links, we don't usually want to specify how. What matters is that everyone presents the same type of thing (external link, internal link, alternate title, quote, citation or reference) the same way for clarity. Fonts and text styles are supposed to be a subtle cue to meaning, not an excuse for users to show off how much markup they know (why we all hate PowerPoint and the PowerPointies who use it to lie to us). CSS goes a long way to make it easy to standardize these presentations so that people can easily read our text without our having to put a lot of work into learning typography, which is an expert profession of its own. |
|
| == tags, lists, categories |
|
| Bloggers use tags, wikis have categories, everyone has lists, and it's all the same thing. We are attaching keywords to items and asking for lists to be put together from them automatically. This is one way the machine really must work much harder, and where wiki has fallen behind drastically by assuming that every list must be manually maintained. It would be nice also to see lists that are assembled from internal information put into the same namespace as the manually maintained ones, perhaps with a prefix like "all" so we know they're up to date. |
|
| Also a few conventions can save manual work and redundant pages like letting {{{ [[tag:WHATEVER]] }}} direct by default to {{{ [[category:WHATEVER]] }}} and possibly include external resources with that tag (not just the local items in that category). It is hard to think of a case where you'd want a tag named WHATEVER to not put items into a category with the same name exactly. |
|
| == handling votes, ranks, surveys, polls |
|
| Contentious decisions are inevitable in [[wiki governance]] and not all of them are unanimous. Modern definitions of [[consensus]] allow for the exclusion of a small number of persistent voices with very different priorities, or for those who disagree to be differentiated into a watchdog or indemnified group that is highly motivated (and maybe rewarded) to spot problems with the majority view. Some definitions go further and claim that "consensus" only means about 75 per cent of the voting members! In other [[social software]] it's become common to have surveys, polls, ranking, votes, and other formal quantitative ways to rank options. This could even apply to trivial matters like presenting people in a list or allocating some kind of points like BarnStars. In any case, the machine can offer a far far better polling booth than the ordinary and generic wiki page. Yes, wiki pages do barely work for this, but only if everyone cooperates. |
|
| So one way to make the machine work harder is to let users specify things to vote on, like pages to delete or users to elect as administrators or policy to adopt, in the simplest possible notation, preferably some variant of [[list]] notation. Characters for this can be reserved (as they often are in language/format work) without requiring the functionality to be implemented in the wiki software itself. If it isn't, then, the functionality defaults to an ordinary list and people deal with as they do now on wiki voting pages. If there is however some support for voting, then each notation can be assigned to one type of vote, which allows for a lot of methods, or a very few methods, to be applied. When we vote we are used to preferring one method and getting another (especially for say the President of the United States) so it's no tragedy if only one method is available. Being forced to agree on voting methods is part of democracy. In practice, it's not hard to list candidates and say "I prefer preference voting but if approval voting is available use that, if neither then first past the post, and if nothing then just make a normal list marked as a vote". This could be done by using list notation variants like {{{ #*# }}} etc. When plugin developers see a market developing that wants real support to run those votes, they'll act quickly. Reserving those character combinations meanwhile costs $0. |
|
| ''See [[Talk.ListsReasoning]] for a proposal to deal with votes as a type of list.'' |
|
|
| |
| However, Creole is a markup standard, and as a standard it should never change dramatically and become incompatible with itself in the future. The things we specify must be final, so that Creole is not a moving target for the developers and a cause of constant confusion for the users. |
.