On Monday 26 September 2005 23:30, neil@civicspacelabs.org wrote:
I'd avoid adding rules. Comitted patches can always be refactored for UI later. This happens with code too. I think the best thing would be some way of making UI changes more findable for review. I think this would allow for time UI people give to Drupal more well-spent.
the big problem with this is that refactoring a UI requires coding too. Most Usability experts care not/cannot/will not code. Thus usabiltity 'feature' request will stick as issues in the queue forever. They will because they do already. Somehow developers do not pick up these features from the queue, when they do not have a patch. (and I know why....) So if we want to cater these experts we need to help and include them in our process. Not bolt some usability review on top. And optionally (never) fix issues afterwards. Cateering them would mean: screenshots, example or test sites, etc. I found that when a screenshot is submitted the UI oftne comes out much nicer then when it was not. Because -i assume- usability reviewers find it far too much hassle to maintain local devel sites where they can apply patches. Usability, code style(ity), security, feasability, flexibility are all of equal importance in Drupal. That is quite unique, but a very good thing. Developers often care about only a few of these -itys. Making it go trough more people ensures that most of the itys are touched and reviewed. And to allow different people to look at this in differen ways we need to cater these. Ber