Talk:Style guide/Forms

Previous page history was archived for backup purposes at Talk:Style guide/Forms/LQT Archive 1 on 2015-07-10.

I'm writing an extension, Extension:RevertRange, that lets a sysop enter a starting timestamp and an ending timestamp for reversion of a user's actions. (e.g. a bot might have misbehaved and now it's desired to undo everything that it did.) What's the best way to have the sysop enter such a timestamp? My current implementation has him enter a 14-digit timestamp, but humans are not used to that kind of format, usually.

First, this is an awesome resource for those of us who have little aesthetic awareness, so thank you!

However, it would be immensely helpful if there were readily available templates for implementing these things in HTML and CSS. The CSS could also very easily be included in the base CSS for MediaWiki pages, so it was possible to implement these elements in pure HTML with classes.

Just a thought! Keep up the awesome work!

I do not totally agree with your analysis here. To be fair, I'm a guy who doesn't like user interfaces and would generally prefer to have everything just be text-based... but still:

I think that multi-selects are actually valuable and I prefer using them (as a user) over groupings of checkboxes - particularly a long list of checkboxes. They have two key features that checkbox groupings don't:

1. You can rapidly select and deselect options because you can shift+click/command+click to select a long row of options.
2. They require less precision when clicking (drinking and clicking becomes a lot easier).

It's easy to prevent against a scrolling multi-select. And while I concede that a multi-select is likely less intuitive... my grandmother knows how to use one (this is saying a lot). Now, what would be cool is a multi-select coded to look like a checkbox grouping so we get the best of the functionality AND usability.

Hrm. Such a thing should be possible, actually.

One of the secondary bits for this is to actually define interface components based on function rather than form. So, for example, a "radio button" is the same as a "select pull down" in function: choose one item out of a set of discrete elements. This is the same functionality as a volume knob, or even a slider.

Ideally, you could just say "This is a time selection control" and the underlying system would know to generate a time selection slider.

As far as your point about multi-select, I'll grant that there are uses for them but in general people choose them when they aren't necessary (e.g., five options or some such). Further, I'd posit that if you are dealing with an interface that has hundreds of options in the set, the interface probably requires a different approach entirely.

This is awesome!!!!! I would be very interested to find out about suitable UI-options for a longer list of multi-select items? Unfortunately, we won't be able to get around this. I have seen category tree entry, but don't find that very appealing. Any other options?

I just found this interesting site about this problem: http://www.ryancramer.com/journal/entries/select_multiple/

It would be awesome, if we would have asmSelect or "Two select multiples" forms for Mediawiki.

In my opinion asmSelect is great. But you can't select many options at ones. On the other hand its gives you an overview which options are selected.

That article listed disadvantages of asmSelect as well. Requiring js, and usability disadvantages where after selecting one item, you have to go back to the select and start all over trying to find out where you were in the list.

IMHO, if we have a form in MediaWiki where we have enough check boxes that you would suggest using asmSelect as a fix for it, then what we really need to do is completely re-think the form. Not add some half-usable band-aid on top of it.

I'm quite a fan of the Chosen jQuery plugin (http://harvesthq.github.com/chosen/) for multi-selects. It also handles the related problem of single selects where there are an enormous number of options to scroll through, by adding a textbox for a filter search.

While we can certainly review some core forms for having "too many" multi-select options, it's not sensible to assert that a multi-select with 'many' options must, by definition, be badly designed. In many cases the number of options that will appear in the final form is entirely down to the user or the wiki administrator. So we might want to review the watchlist-edit form because users commonly have 'many' pages there. But there is no reason why a wiki might not be perfectly legitimately configured with hundreds of namespaces, and suddenly all sorts of filter selections have "many" options.

I don't suppose that the

Discard Changes

and

Save Changes ►

buttons were made in HTML/CSS? On the off chance that they were, could the code be made available?

They were made in photoshop, but we can probably dig up some css for them. Lemme see what I can do.

Out of interest, which icon scheme is being used in the screenshots?

They are not from a set. They are hand-built for the functions. They're mine entirely with one exception (the trash can icon) which I built from an icon created by Trevor Parscal (I would have used it directly but his version of it has grey lines and a white background and isn't suitable for use on a button, so I recreated it in pure white).

I've added direct assets for the three circular icons (checkmark, alert mark, and no mark) in both png and svg formats. They're at the bottom of the page, under "Assets". I am assuming this is what you were referring to.

I like what you're doing (and we already have some of this in UploadWizard). I would only disagree with the "horizontal" style here as I think it is hard to make that work universally, especially in languages that are more verbose. I think vertical should be mandated.

Another question there is whether a large number of errors can "push down" the rest of the form. While in theory one could just "double space" the inputs out, and hope that it all worked, it seems inevitable that an error condition will push the rest of the form down, sooner or later.

I am not a person who believes that vertical positioning of form elements must be maintained. I think it's okay for elements to shift on the page as long as the user understands the context as to why (and adding errors to a field is a pretty decent context).

I'm totally fine with mandating vertical; the horizontal layout was a effect of doing live validation and to offset complaints about wasted space in layouts.

I'm not sure I agree; I think the horizontal style is perfectly reasonable. What needs to happen is that if the error block gets too long, or the window gets too narrow, it automagically switches to the vertical style; that should be achievable with CSS.

This.

This looks great already - thanks much for working on it. :-) It is badly, badly needed.

+1

+ 1

my new nickname for you: formasaurus. happy to see this work is happening (it's gotten lost in the mix before). it's no small undertaking and i think your first article will already prove useful to community devs. yay!

a couple suggestions for consideration:

• i didn't go through the entire doc, but you could really pull it all together if you show a couple examples of complete forms that illustrate successful use of your guide and principles, whether from wikipedia (HA! maybe you could use the link dialog or upload wizard) or elsewhere. if you wanted to go one step further, you could pull from a poorly designed form, apply the principles, and show the wp-style-guide-ified results.
• assuming this is the start of a larger guide (because that would be *awesome*), i imagine most people will use it as a reference or when looking for explicit direction on conventions or specific styling, but i like that you pull in some larger design principles that aren't just specific to wikipedia forms, say. i think you're trying to achieve two things 1) provide guidance that will increase the sites consistency and make it easier for mediawiki developers to maintain or update (a wikipedia style guide) and 2) help mw developers create tools, gadgets, extensions that are more user-friendly than they, er, sometimes are (a general/web style guide). as the guide develops, it would be nice to separate these out. your article has a tone of there being only one right way to do something - which is appropriate for part 1) but not as much for part 2). for part 2) i think it's important to stress there are typically multiple ways to achieve a desired behavior or effect. so while human tendency is to group things that are in close proximity to each other, we also, as you know, use similarity (color, font), common fate (drop downs), figure/ground (action item, buttons, etc). but i wouldn't assume everyone reading this knows they have these options at their fingertips.

exciting. looking forward to the next installments.

That's a great idea, including fully-realized forms, and I've included two examples. A complex one (account creation) and a simpler one (login).

I've also added a whole section with some rules-of-thumb regarding color selection and the psychology regarding that.

+1. Looks pretty reasonable. I started just glancing at it and ended up reading through it.

1) The buttons you have pictured have very intense colors. The problem with intense colors is that you then have to keep upping the ante for everything else (like alerts, which then have to be in gaudy yellow, and so on...)

Perhaps these are just examples, but people tend to remember what they see in pictures.

This is just a personal preference, but I like the standard jQuery.UI / Vector look where the buttons are all the same very light cyan, with very small, relatively subtle pixel-oriented icons. We've already chosen jQuery.UI as the basis for most of our form interfaces.

2) Ease of producing buttons is also a factor. I think it goes without saying that we are never going to require an artist to be involved in creating forms, it has to be all in code.

So in this example we have white icons on dark, intense-colored + gradient rounded-corner buttons. Not all of this is doable in CSS on all browsers that we care about. If we do come up with a way to do this, then the text loads before images, so for a while the button text will appear to be white on white. Even if we do fallbacks to standard buttons, there is a big difference in what seems "right" when the designed form has an intense red button, and when it's a flat grey rectangle. So it becomes harder to make the form work everywhere.

Also, if you allow such radical color changes you have to produce more versions of the icons (white or black at a minimum).

Again, this is my preference but I think subtle wins over intense for a lot of reasons. If I can take a standard 'submit' button and apply CSS it's 10x easier/faster than creating a div with a fancy background and attached JS behaviours to simulate a submit button, not to mention that key shortcuts (return for submit) will still work, etc.

3) Re: "reset" buttons; I feel they should be abolished from interfaces generally, as they are often included just because HTML Forms have them by default. They trick users into clicking on them far more often than they help anybody. Perhaps you are just including it as an example, for the rare cases where you do need it. But again, people remember what they see. They will copy that, and ignore what you say.

Jakob Nielsen hates them too: http://www.useit.com/alertbox/20000416.html -- in his view, even "cancel" buttons are a questionable idea. "Making it easy for users to destroy their work in a single click violates one of the most basic usability principles, which is to respect and protect the user's work at almost any cost. (That's why you need confirmation dialogs for the most destructive actions.)"

I agree that those colors are extreme, and that's intentional. There's marked, measurable changes with brighter color buttons based on user behavior. I'm not worried about implementation but I should find myself exceptionally surprised if jQuery.UI can't do more intense colors. I don't believe that we should stay with a button design just because it's the current style and there are several instances (even from internal interviews) where the current button styles get lost.

As far as the reset button: you're right; I included the reset button as an example, and don't really intend for it to be used. It's there for completion ("reset" as an action type). I don't want to say directly "Never use reset" because for all we know that could be untrue (though I'm at loss to come up with one in the moment). I think wording needs to be included that reset is strongly discouraged and I'll remove the reset button from the example. Probably replace it with a different fourth button ("preview?")

"Cancel" and destructive actions I'm less adverse to but I think they absolutely need to be called out for what they are. I don't like the word "cancel" in most instances, though ("Cancel what? What am I canceling?") but that's a larger issue.

...Aaaaaaaaand done. Replaced graphic (s/Reset Form/Preview/) and added a bit of warning text in the document.

I really like this - frankly, I'm oddly moved by it. I've not seen a philosophy on buttons laid out before (I'm a backend guy so my exposure to this is limited), and this feels really right to me.

I am, however, curious to hear how this works for RTL languages? The same but backwards?

Thanks!

RE: Left-to-right button groupings: I've not personally done much research into the psychology of LtR button layouts but that seems right to me. I wonder if anyone with more direct experience can answer this?