[wp-hackers] Usability Interface Guidelines?

[Matthew Thomas]

On 27 Jun, 2004, at 9:36 AM, Torger Bjornrud wrote:
>
> I naively filed bug 124, titled, " "Publish" button is redunant and 
> confusing. "

In the bug report you write:
>
> What happens when you do a writeup on something private, check the 
> radio as private and hit publish? You have a conceptual collision on 
> what the behavior of the publish button should do.

Doing a spec for the post page design has been on my to-do list for a 
while (and I probably wouldn't have done it by now if I hadn't been 
asleep for most of the past week). Of course Matt is free to ignore 
part or all of any design I come up with.

However, I raised this particular problem with Matt several months ago, 
because I noticed it as soon as I saw the post interface. My proposed 
solution was ... to get rid of the radio buttons.

Fleshing that out a bit more, perhaps instead of the current "Save" and 
"Publish" there could be three pushbuttons with text varying depending 
on the post's current state:
*   "Save as Draft"/"Save Draft"/"Change to Draft"
*   "Publish as Private"/"Update Private Post"/"Change to
     Private"
*   "Publish"/"Update Public Post"/"Change to Public"

My reasoning:
*   Clicking a pushbutton is much faster than clicking a
     radio button and then a pushbutton (especially since
     this is a Web app where you might have to scroll to get
     to one or both of those controls).
*   Making post status a series of radio buttons means
     you're likely to forget to set it, which could be
     embarrassing.

On the other hand:
*   That changing text for those pushbuttons could be
     confusing.
*   Pressing Enter while in a single-line field (e.g. the
     Title field) would change the post status to Draft in
     Opera and Gecko-based browsers, even when you didn't
     want it to. Which is a stupid bug in those browsers, but
     (afaik) not likely to be fixed soon in any of them.

So I'm not sure what to do.

> ...
> When I filed the bug, I thought this was obvious and didn't warrant 
> discusssion.  I could have written a response to mark's bug comment in 
> the bug tracker, but I see the hacker-list as a better forum to 
> address what is fundamentally a UI decision, precedent for future 
> design decisions,  that WP I think should decide upon.

Agreed. Bug databases suck as a forum for discussing interface design, 
especially in a volunteer project. (Bitter, bitter experience.)

> 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.)

> Essentially, I don't feel that in a specialized web application of 
> such small scope (compared to large office programs, IDEs, or other 
> software) should offer redundant ways of accomplishing the basic 
> tasks.

IMO that's true for all software, no matter what its size or scope. And 
it's not just IMO: Jef Raskin advocates it, for example, though in a 
stellar display of poor marketing he calls it "monotony". My guideline 
is that there shouldn't be more than one *similarly accessible* method 
of doing a particular thing. "Similarly accessible" means that, for 
example, you could have a keyboard combo for doing something as well as 
a menu item for doing it, but not two menu items for doing it.

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.

-- 
Matthew Thomas
http://mpt.net.nz/