Difference between revisions of "Design Philosophy"

Revision as of 22:52, 6 August 2008 (view source) Rahaeli (Talk | contribs) (Basic start of the design guidelines) Newer edit →

(No difference)

---

Revision as of 22:52, 6 August 2008

Some things to keep in mind when designing features (or enhancements/changes/revisions to existing features) for DW. This is both "social design philosophy" and "human interface design paradigm", and is in no particular order. While it might not always be possible to hit on all the elements in any one particular design -- indeed, some of them might contradict each other in specific implementations -- but whenever you have to violate one of these guidelines, you should know you're doing it and be sure you're doing it deliberately (and also be sure that there isn't a better way to do it).

Many of these are draft suggestions -- please do bring up concerns/suggestions on the talk page or on the mailing list.

Viewing preferences follow the logged-in user

Journal-level viewing preferences (how you see text, widgets, etc in someone else's journal space) should follow the logged-in user preferences, and if the journal owner's prefs and the logged-in user's prefs conflict, precedent should go to the logged-in user prefs.

There are two possible interaction models for something like DW: "journal owner gets to have exact control over how their journal is presented to others", and "logged-in user gets to have exact control over their site-wide experience". On DW, the precedent should go to the logged-in-user model: the journal owner can specify how they want their journal to look, but users should be able to set their viewing preferences and also select whether or not to override the journal owner's choices.

When designing something that a journal owner can set and a logged-in user can override, a well-designed feature should allow the logged-in viewer to select one of three options:

• Show me (feature) everywhere, even on the journals of people who have turned this feature off.
• Don't show me (feature) anywhere, even on the journals of people who have turned it on.
• I don't care either way; show me whatever the journal owner has chosen for their journal.

Privacy-aware (content)

Everything on DW should be privacy-aware from the ground up, and be designed to let users select their own privacy settings, with as much granularity as they want to have. Individual elements of any feature that involves the user providing content for other people to see should be (as much as possible) settable to different privacy levels: at the very least, Everyone/Trusted/Private, with the possibility of additional settings (Everyone/Registered Users/Trusted/Trust Filters/Private).

The one exception to this is that everything inside the same journal entry itself should hold to a single privacy level: there shouldn't be any way to have trusted-only content inside an otherwise public entry.

Privacy-aware (contact)

Any feature that contains some way of letting someone else contact another user (whether the contacter is a registered DW user or not) should offer privacy options as well, to let people control who can contact them. At the very least, there should be Everyone/Trusted/Nobody, with the possibility of additional settings (Everyone/Registered Users/Trusted/Trust Filters/Private). Anything involving someone contacting another person should also be aware of the ban list, so that anyone who's banned from commenting should also be banned from using alternate contact methods.

Option flexibility

Whenever possible, a feature should be designed to be as flexible and configurable as possible. This includes not only adding an opt-out whenever possible and letting people choose their own privacy settings, but also allowing multiple levels of configuration (ie, if it's logical and rational that people would want to display things in multiple layers of depth, etc, they should have the option to set their own preferences).

This element is hard to pin down exactly, and it's impossible to cover it all the time, either because the opt-out for many new features is just "don't use it", the change removes functionality that we don't want to keep in the DW codebase, the change is flat-out incompatable with the old way of doing it and there's no easy way to retain the old way, or maintaining two separate versions would be inconvenient or impossible from a code maintenance standpoint. However, there should be as much customizability as possible under these limitations.

Don't overwhelm the user

On the other hand, we also have to be careful not to overwhelm the user with too many options all presented in one place. Ideally, the user should be presented with a (small) default set of things-to-configure that we think will cover 75%-80% of the use cases, with the option to get into the guts of the interface if they really want to. Configuration of any new feature/change/offering/etc should be two-tier: the basic options for customizing, with a link to the advanced options for customizing if the user really really wants to tweak everything.

Design for the codebase, not the hosted service

Dreamwidth, as a project, is both hosted service (dreamwidth.org) and an Open Source programming project (the Dreamwidth code). When designing, we want to always keep in mind that other people and services using the code won't make the same choices (administrative choices or business choices) that we have.

Any new feature or function that we add to the DW code should be easily configurable by a site admin, either to turn the function on/off or to change the default settings easily, without having to resort to patching the code. Design new features & functions in a modular, plugin-like fashion, so site admins can have as much control as they want, and try to keep things self-contained as much as possible.

Be accessible

Any visual design or human interface design work must follow all of the W3C's Web Accessibility Guidelines, to be as accessible as possible to all users of the site.

Remember the use cases

The [Design Personas] list gives (what we think will be) our four major use cases, but any design work should also remember that people use the site in a hundred weird and wonderful ways. Be sure to examine your assumptions really carefully and make sure that you're not just designing for how you use the site -- the ideal design will take as many use cases as possible into account, and avoid (as much as possible) breaking someone else's site usage.

Be consistent

The existing LiveJournal codebase is all over the map in terms of configuration, design model, visual interaction, paradigm, etc, etc. It'll take us a while, but we'll build a standard list of [Visual Interaction Vocabulary] -- when to use blockquotes, when to use standouts, when to use headers, when to use checkboxes vs. drop-downs, etc, etc.

Offer clear workflows

Users should be able to complete the task -- however "task" is defined for any particular feature or enhancement -- as simply as possible, without having to detour, visit five or six places, etc. As much as possible, try to keep a single task to one workflow, without offering too many ways for them to get distracted mid-task. This applies to the page itself as well; material and interfaces on the page should appear in roughly the order that the average user is going to want to read/do/set them.

Consolidate

Related to "offering clear workflows", try as much as possible to keep the user on the same page (through use of AJAX, etc) instead of sending them to a different page to complete the task. (Do be absolutely certain that you offer a no-scripting version, though.)

Degrade gracefully

Our design must degrade gracefully in older browsers, text-only browsers, and browsers with scripting turned off (or only partially implemented). This doesn't mean that the site has to function perfectly in Netscape 2.0 on a 286 running Windows 3.1, but it should at least be minimally usable (all major functionality accessable in some fashion). (We should build a pool of people who are willing/able to test things on older browsers.)

Document, document, document

Be sure to work with the site documentation team at all points of coding from spec to final release, so that the documention editor who's going to be writing the user docs for your code will understand what the feature is, what it does, why it does what it does, and how to work it (along with any subtle nuances or neat tricks it can do). If the documentation team knows about things early on, they'll be able to write the docs more quickly and without having to read code or go through the entire feature looking for things that should be documented.

(This will also help the QA and regression testers know what to test. If they know what changes you're making and how it's supposed to work, they'll be able to catch what doesn't work.)

Have fun

Don't forget to enjoy yourself as you go. :)