01Mar 2010
CSS 'font-weight' and UI
16:35 - By BlueGriffon - Thinking at loud - 11 comments
CSS is so cool. So cool. But not in terms of UI for a CSS editor...
- let's suppose you can have your text 'bold' or 'normal'; one checkbox or checkboxButton is enough, and you can have this button live with other buttons like italic, underline and others
- let's suppose now you can have your text 'bold', 'normal or
unspecified ; a few options here:
- one checkbox to say the boldness is specified or not and a checkbox/checkboxButton for bold
- two checkboxes/checkboxButtons for 'bold' and 'normal'; property is unspecified when both are unchecked
- a menulist with three choices
- let's suppose now, and that's the CSS real case that matters to me,
boldness can take the values 'bold', 'normal', 'bolder', 'lighter',
'inherit', 'initial', 100, 200, 300, 400, 500, 600, 700, 800, 900 or can
be unspecified... The two reasonable choices here are:
- one checkbox to say the boldness is specified or not and a menulist
- a menulist where 'unspecified' is one of the options
In other terms, offering the full power of the 'font-weight' CSS property to a CSS editor will necessarily suck in terms of UI (yeah, forcing a menulist when most users will only use the 'bold' choice just sucks)... I am even tempted to have two modes in the CSS editor, basic and advanced. Pffff....
Ideas, suggestions?
11 comments
A checkbox named something like "Bold" and a link next to it called "more options". Checkbox not checked means "not specified". If the link is clicked, the checkbox is replaced by the menulist (with "not specified"/"bold" preselected according to checkbox selection). If font-weight:bold is already inherited from a parent - show menu list immediately, the checkbox makes little sense then. Same if the user previously selected a setting for this element that isn't "not specified" or "bold".
There are a lot of UI solution to handle this, but it depend a lot on the targeted audience :
1 - If you work with experienced users in mind who know what is the CSS "font-weight" property, a simple select box which allow him to choose any available value (including "unspecified" which can be represent as a "leave blank filed") is the easiest approach.
2 - If you work with unexperienced users in mind who just want to bold something, it's useless to give them the all list of option and it could even be confusing for them. In this case, use a simple checkbox with an intuitive behavior : if it's checked, the element is bolded, if it's unchecked, the true value of the font-weight property depend on the context (should be inherit, but this is a matter of discussion)
With those two profile, you can imagine a double UI approach where the user explicitly said if is an advanced user or not. An other option is to propose a quick style panel with some basic feature and an advanced panel with the whole bunch of CSS properties and values.
Now forget about those two basic profiles and imagine a progressive UI. Start with a dummy approach (meaning, the single checkbox alone). When you tick it, the UI expend to show you a list of choice to be more specific. Now the question is : Does the UI must change automatically or on demand and how far should it change? There is no easy answer to this and it depend a lot on your audience and your will to make your user smarter on CSS. But it's a very interesting approach
> 3. a menulist with three choices
Terrible UI choice. I hate popup form entries. They're the spawn of the devil. Esp. when here's only a few or two items to choose from. They hide information from the user without saving much space, if at all. It requires the user to waste time clicking on he damn thing to see what is expected of him.
What's wrong with using 3 radio buttons instead?
◉ Inherit
○ Plain
○ Bold
Is a UI user going to want to choose between 100 and 900, when not all browsers even render the differences? (IE & Webkit only render bold or not bold). Those who care to use the numbers, and the named values are those who will be looking at the generated CSS. I’d say leave the choice out of the UI entirely, don’t even bury it somewhere. A developer eager to learn will probably see the numbers and named values when examining someone else’s code.
If it must exist, bring up a context menu with the choices when the user right-clicks on the tickbox and place a tooltip to explain the availability of this feature.
How about another variation of a menulist: a pop-up slider (normal through 900), with the selected value as a label?
textfield !
Ok, je sors ...
Shouldn't be too bad with proper labelling.
Just an example, with bad wording.
<label for="setbold">Boldness:</label>
<input id="setbold" type="checkbox">
<select> // disabled=!setbold
<option>inherit</option>
<option>initial</option>
<optgroup label="Textual">
<option>bold (700)</option>
<option>normal (400)</option>
<option>bolder</option>
<option>lighter</option>
</optgroup>
<optgroup label="Textual">
<option>100</option>
<option>200</option>
<option>300</option>
<option>400</option>
<option>500</option>
<option>600</option>
<option>700</option>
<option>800</option>
<option>900</option>
</optgroup>
</select>
Even better, do what Obi says and just have a text field and add auto-completion to it. Even better still would be to have the ability to cycle through values a la Firebug and also get a drop-down with all possible values as above when pressing the down button when the textfield is empty (i.e. unspecified) or something like that.
@Wladimir: hey, I like that ; will be a bit tricky to implement because of all the machinery behind but that's the best option so far ; thanks !
The OS X editors such as Coda and CSSEdit seem to have things right approach IMO - don't try to abstract away all the CSS into some sort of MS Word type interface, just provide a nice interface to the existing model that makes it easy to set possible properties to possible values and preview their effects. Why fight the existing system when it actually makes a lot of sense already?
IMO it would make sense to default to an empty list of properties, and then have an option to add any relevant property to that list.
For options like bold which have an obvious common set of values (true or false, when set) you could then have a checkbox, and a button (with a little settings gear or something on it) that pulls up a drop down menu with more options, setting the checkbox to an inconsistent state (half set) if an 'advanced' setting is chosen.
I suggest to forget about the unspecified value and just display the actual value of the bold property, inherited or not.
Internally, you could keep adding styles to the CSS whenever the user changes something.
Then you can have a "Reset style" to be able to delete all your modifications and return to parent style (like OpenOffice).
Or your software could try to be (too?) smart and delete the style entry when the user chooses what actually would have been the default inherited value. Note that this could lead to this strange behavior: I bold my paragraph, I unbold some character, I unbold my paragraph (the font-weight is actually removed from my characters since it is the same as my paragraph), I bold my paragraph again and boom, my characters are bold again, may not be expected behavior).
I think a UI for CSS is silly. CSS is too complex and has too many options. If you try and implement every option advanced users who know what they are doing would find themself frustrated and normal users would find themself overwhelmed. Personally, I would like a text editor that does solid syntax highlighting, formatting options and non intrusive auto completion / suggestions.
As mejy has already mentioned "Coda" does cover both levels of users well... and as I hand code, I've never bothered with the UI.