Back at DrupalCon Chicago, Dries outlined a strategy for Drupal 8 involving a series of "gates" that would help ensure core quality in a number of different categories.
The purpose of gates is to define essentially a set of "checkboxes" which outline the most important aspects to each category, and does so in a way that is both not overwhelming to core developers (list of hoops to jump through is kept as small as possible) and also creates very little additional burden on the team in question (contains sample links to documentation/resources so developers/reviewers can help themselves).
Proposed gate
The current proposal is outlined below, we would love feedback on it.
| Description | When is this needed? | Details | Resources |
|---|---|---|---|
| Drupal's design principles are followed. | Any patch that changes the user interface. | Design consists out of a lot of different guidelines, ideas and principles. Follow the overarching principles to create a delightful experience. | Discussion |
| User interface guidelines are followed, and new patterns are documented. | Any patch that changes the user interface. | By following the user interface standards we create a more consistent experience. Provide a strong rationale when you deviate; and document new interface patterns in the library. | UI standards |
| Make it easy for people to give design feedback. | Any patch that changes the user interface. | Follow common practices, to allow for feedback from non-developers. By supplying screenshots and rationale on how your change affects the user. | Process how-to |
| Verify your solution with users by performing usability testing. | Any patch that makes major changes to the user interface. | Usability testing is an important tool for determining the benefit of a proposed change to the user interface. For major changes it is required to verify the user experience of your solution with users. | Discussion |
To do's
We have a a few big discussions that we need to have and resources we need to develop to allow these gates to be understandable by our developers.
In general we will need to work some more on specifically how we word each gates, especially the details.
Follow Drupal's design principles
This will require more extensive discussion and research on which principles we want to use. It is expected that these principles will need further feedback from the community on how they interpreted them.
- Determine which design principles we want to cover.
- Provide appropriate documentation how to apply the principles.
Discussion on this is already happening at UX Gate: Principles.
User interface guidelines are followed, and new patterns are documented
We have been developing user interface guidelines but with limited resources haven't gotten very far. We will need to discuss to what extend the current UI standards are sufficient, and if not which essential parts we are missing.
- Determine how complete the UI library must be
- Document missing parts
- Document how to document new patterns
Discussion on this can be in this thread.
Make it easy for people to give design feedback.
This only requires us to finish the handbook at Process how-to. It is important that this handbook is complete, and easily illustrates which steps a developer can take to allow for UX review.
- Document the best practices for ux feedback.
Discussion on this can be in this thread.
Verify your solution with users by performing usability testing
This requires extensive discussion on how to make this gate work, and what the qualifications are for a usability test that is in appliance to this gate requirement.
- Determine what qualifies as a "pass" in usability testing
- Provide documentation how to setup a usability test that counts
Discussion on this is started at UX Gate: Verify.
Comments
On a side note
On another side note, we are about to get started with our bi-weekly UX meetings rolling (Details coming soon!) The intention of the meeting is to discuss the way forward with D8 usability and the top issues which we would like to address. The meetings would also serve as a happy hour review (drink beer at your desk - as we would like to call it :P) where people can bring in their designs and the UX team would provide inputs.
Dharmesh Mistry
UX Researcher | Acquia,Inc.
Suggested Usability Gates
This is an interesting idea! Here are some thoughts on possible gates that don't require a full-on review or a usability test setup.
1) Sensible default options?
If 90% of the time, you need to "check box foo", it should be checked
2) Clear call-to-action - required for any major UI changes
3) Description of any hidden functionality - for instance, in D7, it's not obvious what hides behind "Vertical Tab #2" when adding a node
4) Clear, meaningful error messages, and if possible, associated with the UI element corresponding to the error.
Would this be an appropriate
Would this be an appropriate place to add support for small screens and touch screens?
I've been looking for a way to get new UI elements considered for mobile devices going forward.
I stubbed this out a bit
Certain there are items and clarity to add.
@lewisnyman, I believe the
@lewisnyman, I believe the goal is to define the requirements that UI changes/additions to Drupal must go through prior to being accepted. E.g., you must pass usability requirements X, Y, Z before you can pass through the gate. That said, there are usability mobile best practices, and mobile is becoming the dominant player - so add away.
Maybe look at issue queue to derive future gates?
Noyz might have done exactly this - what about combing through the usability queue to find the five highest-frequency issues and turn those into our five gate items?
From experience in working in
From experience in working in the core issue queues I think UI copy writing and consistency checks will be most effective in most cases.
That's a good idea, but I
That's a good idea, but I suspect I've covered it.
I'm in Drupal and Drupal core 10+ hours a day reverse engineering and redesigning UI's. In addition, I'm exposed to quite a bit of usability data through myself, dharmesh and our support, training, and professional services teams. To that end, the 3 most common issues ARE what I outlined (or at least attempted to outline) above. At the risk of repeating myself, they are:
Content—particularly page orientation text and form help text—is badly written. It's often verbose, redundant, and explains proceeding UI's that users might or might not use
Existing patterns are not considered or adhered to.
Every option is exposed, which results in an intimidating UI
Looks like we're in agreement
Looks like we're in agreement there! The 'expose every option' one will be hard to create checks for without some consensus on what core should do for you out of box.
I think the obvious thing to
I think the obvious thing to do is hide child elements until you've chosen to act on the parent, that is...
etc, etc.
My very basis initial list
My very basis initial list was something like:
It's good to dump all possible checks in here somehow, but as webchick requested, we need to come up with max. 5 topics/checklists for people to review their own work against.
Most of this points at
Most of this points at /admin, what about non-admin stuff, aka our new core theme, will the gates apply (I assume all gates will apply), so would this be handled under these same criteria (mainly the first one), or do we need something extra?
For the most part, I think
For the most part, I think the gates apply to a new theme, since many patterns and content are derived from the theme.
However, you raise an interesting point which I hadn't considered; the theming layer (aka how you theme) needs to be usable too. Determining the usability gates of a product that's code based might need some thought. Not sure.
They way I see it!
They way I see it, I think we can club #1 (Meaningful description or tool tips on the various UI elements) and #3 (Help text is succinct and helpful and does not repeat a forms label) could be combined together to ONE action item. It is essentially about providing meaningful and effective information.
Dharmesh Mistry
UX Researcher | Acquia,Inc.
Gates should not be too specific
Let's avoid the trap of putting too much detail (e.g. specific UI patterns) in the gates themselves. If we write them that way, we will find ourselves revising them over and over again as time goes on.
Instead, these should be worded as tasks that need to be completed before a patch is ready to commit, and we can refer to outside documents for the gory details.
Based on that, I can really only think of two gates that we need. Something like this:
To make those the gates will require some work on our part, though. In particular:
The screenshot gate?
The screenshot gate already listed above ("Supporting screenshots are supplied") might make sense as a third gate, actually, but I think we have to clarify it to refer to patches that make substantial or non-obvious changes to the UI only. A screenshot should not be a hard requirement for every UI patch; for example, there is no way that a patch like http://drupal.org/node/1167458#comment-4623186 needs a screenshot before it's committed.
At least as important as guidelines for "Needs U testing"...
are guidelines for "Passed usability tests."
There are many different ways to test usability, and no one method is definitive for every conceivable usability issue.
And I'm not referring to the question of whether the testing must be done in a formal lab setting. Great tests can be done there, but a lab isn't always necessary and often isn't even the best place to do a test. After all, who builds, manages, or updates websites alone (or alone with a moderator) in a room with a one-way mirror? I would actually rather do remote tests with the participant at their own computer. But they won't always work, either.
So I agree that we need to come up with guidelines for tagging something with "needs usability testing." But we also need guidelines for figuring out what aspects to test, how to test them (including who the participants should be), and how we will know if it works.
No point building a gate if you don't know what it should take to get through it.
Good points. I agree to the 3
Good points. I agree to the 3 gates (ui guidelines, needs testing, needs screenshot). I'm less convinced on your last point though. True, you can just click "patch" to get an understanding of what's in the patch, but that link is pretty intimidating, and probably not understood (outside of the community) as a link you'd click to see/understand the patch. That's also exacerbated by the fact that many of those links pull up LOTS of code.
True, the issue I pointed to
True, the issue I pointed to was probably a bad example since even though it was simple, there was some information hidden in the patch file. But imagine if the issue comment had explicitly said "this patch changes the wording of the tooltip to XYZ" - given the context of the whole conversation I think a screenshot wouldn't have added any extra information and would have seemed just like a hoop to jump through rather than a meaningful gate.
Maybe what we can do here is something along the lines of what the documentation team did for some of their gates ("Required for X issues, recommended for all").
So overall, if we had those three gates (and stealing some other wording from above comments) it could look like this:
I think in general this looks
I think in general this looks good although I don't think that the usability team has to not be developers. I would more or less specify that it needs to be people trained in usability. A slight nit-picky suggestions... :P
Shane Bill
Freelance Web Developer
The usability team consists
The usability team consists of people who volunteer to help out with usability issues. There are no requirements for joining :)
Did you read the "non-developers" statement as saying otherwise? The way I read it (and the way I think it was intended) is not to say anything about who the usability team has to be, just to point out an actual fact; many (most?) of the current active members are non-developers and thus may not be able to easily understand what an issue is doing by reading the code in patch files; thus, screenshots (or at the very least meaningful issue descriptions) are helpful.
Feel free to suggest different wording if you think it would help make that more clear.
This looks good to me.
This looks good to me.
Really like what you got so far...
I really like what you have @webchick. I might also add some kind of guideline that takes into consideration accessibility. So providing functionality for
My $0.02.
Shane Bill
Freelance Web Developer
There's a accessibility gate
There's a accessibility gate in the making as well here: http://groups.drupal.org/node/158759
Great work!
Looks like we've mostly got consensus here, and the gate doesn't look too intimidating to pass. Yay. :)
Though we're desperately short on the "Resources" column on these; specifically:
However, it seems to be describing problems with these UI items instead of patterns on when you should use them?Scratch that. I need to learn how to read. :DWait, which do we have
Wait, which do we have consensus on, exactly? The ones at the top of this post, or the ones at http://groups.drupal.org/node/158764#comment-535534?
I don't agree that the ones at the top of this post are a good list, and it sounds like at least Noyz agreed with me. There's an IRC usability meeting on Monday (http://groups.drupal.org/node/160269), so more decisions can happen then. (Not sure if I can attend or not, maybe the first half.)
My understanding is that http://p1.drupalusability.org/ was a test site to flesh out ideas to eventually move into the Drupal documentation. However, someone's been doing some awesome work on it since the last time I looked :)
Oh, whoops. I was reading
Oh, whoops. I was reading Jeff Noyes's post as a reply to the main thread, not to yours.
Cool, let's flesh this out more at the meeting on Monday.
I am happy to see this topic
I am happy to see this topic progress, there is a lot of food for thought. One of the things I feel is missing is what we want to achieve with these requirements specifically for usability, not just all gates. From my perspective, what we want to achieve is that we get the community as a whole to make more informed design decisions. During the Drupal 7 cycle we have done our fair share of educating people about user experience through practice, rather than documentation - because at the time we felt it was more effective long-term strategy and created greater leverage. Whenever I see other contributors apply these principles to criticize certain UI directions, I feel like we have accomplished something more impacting.
Although these gates serve to function as sort of "checklists" to essentially communicate our quality-checks better. We should primary enforce it to get contributors to think more deeply about the UI change they are proposing. A more "rule-based" approach to our requirements will often lead to people just "checking-off" rather than giving thought to the impact of their change. Jared Spool had a great talk on this at and its documented by LukeW at http://www.lukew.com/ff/entry.asp?1160.
Onto the actual principles, what I propose is that we include design principles - although potentially harder to explain and apply. They do more fully capture the complexity of some of the design decisions that people need to make. Principles like; "Optimize for intermediate users", "Create smart defaults", "Create (visual) hierarchy", "Keep the context close at hand" and many more should be looked at(examples at http://www.ixd101.com/ ). Design principles are often either meh, useful as as a rule or really insightful and changing ones line of thought. Obviously we want to aim for the last one and I feel with discussion what applies in our context and best captures a full breath of design considerations that we want people to make - this could be really valuable.
Now to apply, what I just said. I propose the following requirements - these could be seen as a rough sketch, not sure about any of them :').
I left out screenshots because although its a well established requirement for Drupal core, its also one I rarely have to say anymore. Its one that is as natural as applying the patch to the issue. The rare opportunity that gates give us in terms of exposure, I want to avoid spending on something as small as that - also because its not really a quality check.
Why not just add one line to
Why not just add one line to Davids table that reads: Design principles are followed? E.g.,
BTW, these are Acquia's design principles, we can borrow where necessary https://docs.google.com/a/acquia.com/document/d/16r5RmWyyu1IXdlSCtZnyf-G...
I'm going to throw in the
I'm going to throw in the principles we developed for the Design Initiative. They could be too generic for this case but worth considering. It would also be nice to get some feedback on them.
http://groups.drupal.org/node/153014
@Bojhan I like the way you
@Bojhan I like the way you spell out the design principles.
It is leaving them relatively open, like WCAG 2 does. But this is the way to go, I guess. I would not think anyone reads the guidelines and starts right away. Mostly they will try to find out what the fuss is about and hopefully put questions in a comment here and there.
Thus better not to write it too nailed down or too intimidating. A good Design Manual I always found one that needs a good designer to make use of it and have some freedom of interpretation, while still guiding. The Pattern Library can be much more precise in what has to be done, and is a needed Resource, even if more for Contrib.
Life is a journey, not a destination
Two complimentary points:
Two complimentary points:
#1: Heuristic Evaluations
We should make use of usability heuristic evaluations as UI design guidelines. The most widely used heuristics are:
These are ten general principles for user interface design. They are called "heuristics" because they are more in the nature of rules of thumb than specific usability guidelines.
1. Visibility of system status
The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.
2. Match between system and the real world
The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.
3. User control and freedom
Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.
4. Consistency and standards
Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.
5. Error prevention
Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.
6. Recognition rather than recall
Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.
7. Flexibility and efficiency of use
Accelerators -- unseen by the novice user -- may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.
8. Aesthetic and minimalist design
Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.
9. Help users recognize, diagnose, and recover from errors
Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.
10. Help and documentation
Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large.
#2: Usability Checklist
Here is a rough checklist for usability testing:
1. What exactly to test about the feature?
a. This is the essential part. Sorting this would help answer the rest of the questions. This should be decided based on frequency and criticality of use.
2. How to test?
a. Lab/ Remote testing, Moderated/ Unmoderated testing, Usability/ Heuristic evaluation, etc.
3. Whom to test?
a. Participant demographics – new or existing or both
4. Number of participants to test
5. Duration of the study
6. Time frame
a. Provide a rough estimate as to how long will the entire process take.
7. Allocating resources for testing
a. Decide on who will be conducting (from the usability testing). Add collaborators. We will need an effective way to assign resources.
8. Preparing for testing
a. Depending upon on what and how things are tested, the usability tester has to do some ground work (more on this section, later!) The primary list include: moderator’s guide and to test the software applications that will be used during the study
9. Conducting testing
a. And also recording sessions
10. Analyzing the study
a. Fun times :P
11. Issues: Once the issues are identified, they need to be prioritized. For this, we should have a more robust system in place. I (as many other usability people) am inclined to use severity ratings. There are several of them in the market: Jacob Nielsen’s scale is pretty effective.
More information on severity ratings:
“Severity ratings can be used to allocate the most resources to fix the most serious problems and can also provide a rough estimate of the need for additional usability efforts. If the severity ratings indicate that several disastrous usability problems remain in an interface, it will probably be unadvisable to release it. But one might decide to go ahead with the release of a system with several usability problems if they are all judged as being cosmetic in nature.
a. The severity of a usability problem is a combination of three factors:
b. The frequency with which the problem occurs: Is it common or rare?
c. The impact of the problem if it occurs: Will it be easy or difficult for the users to overcome?
d. The persistence of the problem: Is it a one-time problem that users can overcome once they know about it or will users repeatedly be bothered by the problem?
e. Finally, of course, one needs to assess the market impact of the problem since certain usability problems can have a devastating effect on the popularity of a product, even if they are "objectively" quite easy to overcome. Even though severity has several components, it is common to combine all aspects of severity in a single severity rating as an overall assessment of each usability problem in order to facilitate prioritizing and decision-making.
f. The following 0 to 4 rating scale can be used to rate the severity of usability problems:
i. 0 = I don't agree that this is a usability problem at all
1 = Cosmetic problem only: need not be fixed unless extra time is available on project
2 = Minor usability problem: fixing this should be given low priority
3 = Major usability problem: important to fix, so should be given high priority
4 = Usability catastrophe: imperative to fix this before product can be released” Link: http://www.useit.com/papers/heuristic/severityrating.html
12. Provide recommendations
a. This is a hard out to iron out. I am not exactly sure if the team should provide with recommendations or not. In some cases, it might be useful and necessary whereas in others it might not be. At this point, this discussion could go to quick IRC meeting or discussion on G.D.O. (may be?)
13. Generate short and effective usability reports
Dharmesh Mistry
UX Researcher | Acquia,Inc.
UX Meeting quick summary
So a quick summary from our IRC discussion where yoroy, jeff burnz, dharmesh, jeff noyes, lewisnyman and David Rothstein participated in (see log http://groups.drupal.org/node/160269 ).
In general everyone liked the direction where this was going and we decided that we should focus our gate requirements around the following four items:
Many of the items above are already roughly translated into actual wording as seen in both David's and mine comment above. Our biggest discussion was around the fact of how we actually define each of these requirements, and how we want to word them to draw a certain reaction from those applying these requirements. So we now have a good idea what more we need to discuss around each line item:
We decided, that we want to have design principles in our gate requirements. These principles can live on a page deeper down, and cover more overarching design principles you need to keep in the back of your mind. An example of this would be "Simple on the surface, powerful underneath". The outstanding to-do item on this, is to build the list of principles we want to cover here with the goal to keep it a small list.
This requirement can be very effective, but we still need to build a clear idea what is missing in drupal.org/ui-standards section to make this requirement work. Other than that, it needs a little bit of work on the definition.
This needs more discussions, we agreed for now it could stay on as we could expand it to cover more process parts, for example when a contributor should attach the "needs UX review" or "needs usability testing" tag. But yoroy and Bojhan think it might be a standard (adding screenshots) already and in the scheme of things not really an important quality check.
We need to do more discussions around, what this requirement means (e.g what does it mean to pass?) and which guidelines need to accompany it.
The fact that the screenshots
The fact that the screenshots one is an existing standard is even more of an argument to add it for me - that standard isn't documented anywhere that I'm aware of, so this provides an opportunity to do that.
I tend to think screenshots
I tend to think screenshots are less of a quality check more of a way for those coming into an issue to quickly grasp what it is about or what its trying to achieve, especially the maintainers.
As alluded to the development of the UI Guide is critical and I would also like to have a style guide for Seven (which probably falls on my plate, darn it).
I think screen shots or a
I think screen shots or a similar proof of concept is a positive thing. It allows the team to get a quick view on when patterns are being reused and establish new patterns.
It's also a great way to establish decent documentation early on.
Intitial thoughts on verify
What is also needed is more information about each item going through the gate like:
- Item is in what stage? Idea/ Mockup/ Design/ Implementation?
- Where does the item belong? Core/ Contrib
- What is the critical-ity and frequency of use of the item?
- Is it an existing/ new/ redesigned item?
Having all this information will help us decide if the item needs testing or not. We could come up with a rating scale as well :)
Dharmesh Mistry
UX Researcher | Acquia,Inc.
Summary discussion with webchick
Summary of a discussion between me, webchick and yoroy in #drupal-usability.
During our UX open-hour on this topic, we concluded that although our gates still required more work - the direction was good. In the discussion with webchick this assumption was confirmed, but also created questions on how we would make these gates more actionable.
We should keep in mind that these gates are the doorsteps, to getting it in and not the final decision for getting it committed. So the UX-Team will still be giving feedback, but hopefully avoid countless hours of basic triage in the issue queue. Freeing up time to work on the bigger issues and spend more time actually designing.
Feedback on each gate requirement:
1) Principles - practice your design thinking
We had a long discussion about this one. The concern that webchick voiced is that these could be too subjective to be effective. Requiring the developer to understand the principles and it parts fully, to actually pass this requirement. Which is quite unrealistic. However we concluded that the benefit of "setting the mind-set" out weights that of it being less actionable.
Where this gate requirement would be more of a guiding principle, a goal. Which is intentionally worded more subjective to show it’s something that we are aiming for.
2) Guidelines - check your work against core/web standards
The worry with this one is that it’s not very actionable, because it requires developers to basically read a lot of (incomplete) handbooks. However it is similar to many standards and could be made more actionable by creating better structure in the available UI standard handbooks.
3) Process: post screenshots
Great, this one is most actionable out of the four. It's easy to say "If a patch affects the UI, post screenshots". If we are adding other process parts, we should consider how to make that actionable too.
4) Verify - test where necessary
Good, we have to emphasize that this only applies to larger UX changes.
Overall the feedback was primarily that our gate requirements as currently set are not actionable enough, and we need to push hard to make them both understandable and actionable for developers with little to no UX knowledge. Essentially what webchick wants to see is:
- A clear set of requirements
- A clear set of when those requirements apply to you, personally, the developer
- Extremely clear language on how to fulfil the requirement
As a step forward I propose, we move the discussion about 1) and 4) to a separate group discussion, to hash out the individual details. And continue discussing the gates requirement overall here.
Thanks Bojhan!
Yeah, this a pretty good summary of the things we talked about. I just want to re-iterate from the original post:
"The purpose of gates is to define essentially a set of "checkboxes" which outline the most important aspects to each category, and does so in a way that is both not overwhelming to core developers (list of hoops to jump through is kept as small as possible) and also creates very little additional burden on the team in question (contains sample links to documentation/resources so developers/reviewers can help themselves)."
The goal here is to take work off you guys, and crowd-source it, so that you can focus on the things only you can do, and don't have to spend time doing things 1000 core developers could be taken care of. But in order to do that, we need to make sure the gates outlined are both identifiable and passable by people without benefit of your expertise.
Thanks so much for the conscientiousness you're treating this with. It feels like we're getting close! :)
From practice
I strongly disagree that the principles could be "too subjective". In practice, most of our, admins' fight is that with consequences of lack or inconsistency of principles.
Examples:
Principle of hierarchy: all content types/entities organized in hierarchy should have bidirectional ties between host (parent) and hosted (child) "data objects", preferably exposed to Views.
Rationale: Zillions of hours lost by admins trying to display all feed content (in the block or pane) in the context of one feed item. The same or even harder struggle is now with Fields Collection that is completely blind for host entity and vice versa, despite both are listed as accessible by Views and Rules.
Principle of modularity/integration: all-purposes-machines should NOT be internally integrated; only armed with interfaces to connect them.
Examples: There are no well-usable media application in Drupal. For example SWF Tools require a lot of players, codecs etc. to be enabled/installed, albeit in practice almost everyone needs only a few of them. The same is for Media and Video, afaik. We can say that such all-in-one concepts break the most valuable Drupal strength - the principle of modularity (basement of its flexibility).
Principle of examples: How an admin could know how to "add (custom) CSS class". Where to put the code? What syntax? How and where to register? etc. I tried various options and couldn't.
Principle of completeness (partially related to the first above). Every Entity should have a complete of tokens and formatters (if it is fieldable); also the requirement should be elaborated as to the exposure to Views and Rules, support for references, attachments etc. Disaster of Drupal 7 launch is a proof of rationale...
....
Scope of Usablity issue
Above I mean that Usability issue should not confine to labels and descriptions, e. g. only visual and text elements. It is also what User can find in the Views, Panels, Butler etc. exposed to her and to manipulation. Let's say - usability of "components".
Such point of view, I hope, preserves and requires integral approach to application design.
Draft UI text guidelines
http://groups.drupal.org/node/165659 is a start for documenting the basic guidelines for writing sensible user interface text for Drupal admin pages.
Possible to wrap up by Friday?
Since Dries wants to announce these gates at DrupalCon London, which is in 3 weeks, we basically need to wrap this up by the end of the week in order to give ample time for review and revision. Does this sound doable? How can I help?
Not going to happen, if this
Not going to happen, if this was the deadline it should have been voiced earlier. All we can do is deliver an incomplete gate, with lacking documentation.
We still need to thourghly discuss the principle and usability testing gate requirements. Which are just starting up.
Moved to http://drupal.org/core-gates
Thanks so much for your hard work on this, everyone. This is a really solid first stab, so I went ahead and moved it to http://drupal.org/core-gates, where we can always refine it later if necessary.