[wp-hackers] Usability Interface Guidelines?

[Torger Bjornrud]

> *   Making post status a series of radio buttons means
>     you're likely to forget to set it, which could be
>     embarrassing.

Only if the default option is Publish.  Draft and private still keep  
things sane that way, because they're both not public.

>> Upon more thinking, I really feel that WordPress could benefit now,  
>> and in the future from some quick & dirty design philosophies, and  
>> have them in a central reference page.
>
> What other philosophies do you have in mind? Personally I don't think  
> WordPress is nearly big enough for writing up interface design  
> philosophies to be worth it. That time would be better spent just  
> improving the design. (Or writing installation/customization/plug-in  
> docs.)

Well, I disagree as to "time better spent" because quite honestly,  
right now, I'm not up to snuff on the WordPress codebase enough to be  
doing other things, so as I'm acquainting myself with it, I'm making  
notes of other snags along the way, like UI hangups.  To each their own  
talents...  :) I see no reason for us to completely draw up a set of  
principles out of thin air, but rather borrow them from the multitude  
of other usability documents out there, and make them our own.  I  
haven't found a great source of *web application* UI rules yet, but I  
see no reason why we can't adapt other rulesets.

Five minutes of googling turns up some promising results for sources to  
draw rules from:

Apple Guidelines
http://developer.apple.com/documentation/UserExperience/Conceptual/ 
OSXHIGuidelines/index.html

Cornell Univ Guidelines
http://ergo.human.cornell.edu/ahtutorials/interface.html

IBM Web Design (not so much the application part of it...)
http://www-3.ibm.com/ibm/easy/eou_ext.nsf/publish/572

The results go on and on...

> Like any design principle, though, sometimes you need to sacrifice  
> that for the sake of other design principles. So if you were wanting  
> this list of design principles to exist so you could be certain  
> whether a particular change was a good idea, I think you'd be  
> disappointed.

I agree in that it would be wrong to hope this document would be the  
"one true" and that design principles are more like marionnette strings  
working with one another to make the software dance.  The purpose of  
the document would be to help prevent more clear-cut design flaws.   It  
is by no means a silver-bullet, just a reference to how things should  
work most of the time. :)

--
Tor Bjornrud
http://brainscat.com