obso1337.org

Two things in life are guaranteed (death and taxes) and email is not one of them.

I’ve had some email and client trouble over the past few days.. if you’ve sent me an email you think I should respond to, you may want to send it again :)

seele :: Dec.27.2006 :: Asides, Life :: Comments Off

It seems there is a lot of confusion about the ellipsis. I will start with a simple definition of an ellipsis:

An ellipsis is a method used in writing to indicate that there is more information than provided (it has either been omitted for one reason or another).

When this affordance is applied to the interface, it basically indicates that there is more than just an action behind this label. This isn’t completely true, because all four platforms only use it to indicate hidden information when their input is necessary (This is good because if half of them menu contained items which included an ellipsis, then it would be more noise than information and the strength of the indicator would be significantly reduced).

Sans the explanation from before, here is a rehash of the guidelines:

The ellipsis is used after menu items which the user is either required or is able to provide input

This means any dialog which takes use input, from the File Open dialog to Konqueror Settings, gets an ellipsis after its label. This also means is that dialogs which do not take user input, such as About and Properties, do not get an ellipsis.

I had also added an amendment to remove the ellipsis in certain cases:

Do not use an ellipsis if user input is not required

So this would remove the ellipsis from configuration dialogs such as Configure Konqueror because user input is not required. I am willing to revisit this rule because it is inconsistent between platforms and this use takes away from the affordance an ellipsis implies. I made this distinction because configuration is not a part of the work flow and is its own activity.

I am going to strike the following amendment to the guideline because it doesn’t really make sense and for the most part is covered by the previous guideline:

Do not use an ellipsis in an action-oriented label

So now, it doesn’t matter what form of grammar the label is, if input is required to complete the action, use an ellipsis. If input is not required, do not use an ellipsis.

For a moment, let’s forget about the ellipsis and think about our information needs. We have two of them. One is a need to know if a menu item will execute and action or open up a dialog. Currently that is disregarded by our four platforms. The second need is to know if user input is necessary or possible to complete your action. Our four platforms handle this a little different, but agree for the most part.

We cant represent both needs because it would be too much information in the menu (that is not up for argument). Our problem is: which need is more important? Is it more important to let the user know that a dialog or window is going to popup, or that their input is required or possible to complete their action? Four out of four platforms agree that indicating to the user the importance of their input is more important than just alerting them this item will popup some kind of menu or dialog. This is what I agree with, however it seems like others do not.

Now, for buttons.

It seems that general inconsistencies in the KDE environment may make understanding of ellipsis on buttons difficult. Ellipsis on buttons are not used consistently. If it is within an application which opens a new dialog, they aren’t used. The only time they are (sometimes) used is when a button opens a dialog from a different application. KDE applications work together on a very modular level, so essentially every new dialog might be its own program. Essentially KDE is meant to be a seamless integrated environment, so the fact that these little programs don’t belong to the same mother program shouldnt matter.

In the context of the activity — why does it matter if it is a different application if it is part of the workflow? The only thing that matters is completing a task.

Perhaps no more ellipsis on buttons and make it a purely menu-based thing? I’m OK with that.

Ellipsis are only used in menus

Questions, comments? This is only an ellipsis!

seele :: Dec.21.2006 :: Design, General, KDE/Kubuntu :: 8 Comments »

This one is for Aron Stansvik

[Update 1, fixed typo about Quit and ellipsis]
[Update 2, clarified my decision about Report Bug and use of ellipsis with non-required input]

Discussion:

The Ellipsis (…) is used in a menu item or button label to tell the user they must provide information before completing their task. In a way, it tells the user they have a chance to customize their request before something happens. For example, File -> Print… includes an ellipsis because it allows the user to customize the request before actually printing. Other examples of this include dialogs which require user input before further action. The most common examples of this can be found in a typical application menu, such as File -> Open… , or File -> Save As…

Here are some examples of an ellipsis being used in different contexts:

(Example of a button with an ellipsis)

(Example of a menu with an ellipsis)

(Example of a context menu with an ellipsis)

For the most part, Gnome, KDE, Apple, and Microsoft all agree on the basic use of ellipsis that I have illustrated above. However.. that is where the similarity ends between the different environments. Figuring out where to use an ellipsis for other types of controls which may require user input is a little more difficult.

In the case of configuration dialogs such as Preferences, KDE and Apple both include ellipsis in the labels to these items whereas Gnome and Microsoft do not. Gnome and KDE do not document why they chose their respective styles in their guidelines. Apple explains that configuration dialogs are a place where users can set their own information and the absence of an ellipsis implies an immediate action. However, Microsoft’s position is that setting preferences in configuration dialogs are an activity in themselves, and opening a preference dialog is an action in itself. Even so, Microsoft is not very consistent in the way they adhere to this rule — their display of Properties does not include an ellipsis, but Options… does.

I tend to agree with parts of Microsoft’s decision (which is a bit sensitive, considering KDE currently sides with Apple). The labels used to describe configuration dialogs are often explicit in the type of activity that menu item provides. For the example of configuring Konqueror, the menu item Settings -> Configure Konqueror is an explicit action, and adding an ellipsis to an explicit action which already implies user input seems a bit redundant. This is still a bit sticky and completely dependent on the label, not necessarily what results in selecting that item.

(Example of Configure… menu items)

In the end, I beleive the ellipsis should be used to indicate to the user they can make changes, only if the label does not imply it first. For example, Choose Details does not need an ellipsis because it is an explicit action which implies user input. Another example, Details… does need an ellipsis to indicate the user can provide input because the label does not imply the user will be able to make modifications. Confirmation or alerts do not count as “user input”, so a confirmation before Quit does not mean Quit should include an ellipsis after it.

Now it is a matter of standardizing a set of menu items so we dont have both Choose Details and Details… in the environment. (Another example is using Properties only for non-editable information and Options… or Preferences… for editable information)

Ellipsis Guidelines:
An ellipsis is used to inform the user their input is necessary, or that they are able to provide their input, to complete an action. An ellipsis is not used when the label already implies action of user input, such as with the term “Configure”, or when after invoking the item does not result in the ability for the user to edit anything.

An ellipsis is used to inform the user their input is required in order to complete an activity.

An ellipsis is not used when the label implies and action and user input is not required to complete the activity. Configuration dialogs are a good example of this, the label already implies action and making changes is not necessary to complete an activity such as checking a setting.

An ellipsis is placed after a label on menu items (application or context menu) and buttons.

• Use an ellipsis for buttons or menu items which require user’s input before completing their action.
• For example, use an ellipsis for the following menu items:
  • Find…
  • Open…
  • Options…
  • Preferences…
  • Print…
  • Save As…
  • Send…
• Do not use an ellipsis for items which result in actions or do not require user input.
• Do not use an ellipsis for an action which may require confirmation before it is completed.
• For example, do not use an ellipsis for items which call the following activities and dialogs:
  • About
  • Check Spelling
  • Close or Quit
  • Configure [something]
  • Delete
  • Help
  • Print Preview
  • Properties (non-editable information)
  • Toolboxes

Working Example:

As an example, let us take a look at the Security option in the Konqueror menu (View -> Security…) and discuss it’s use of an ellipsis:

(Security option in Konqueror)

(Security dialog in Konqueror)

Right away, we can see that the use of an ellipsis in Security… is a pretty clear violation of our new guidelines. When invoking Security… from the menu, the user only gets information, they can not make changes in that dialog. This is similar to Properties only providing non-editable information (which therefore, should not have an ellipsis either). The menu item label Security… should be changed to Security.

Further discussion will lead us to the actual dialog. Its use of an ellipsis in the button for Cryptography Configuration… is correct in the sense that it refers to an object which can be edited by the user. Conversely, if the button label were Configure Cryptography, an ellipsis would not be needed because the action of configure is already implied.

Now for an edge case: Report Bug…

(Example of Report Bug… menu item)

(Example of Report Bug dialog — click to englarge)

This one is a bit more tricky. If you compare it to the previous example, it would be easy to conclude this is similar to the Security… case and the ellipsis should be removed. However, if you notice at the top of the dialog, the user can select which part of the application the bug occurs before opening the bug wizard. At the same time, the label includes an action (Report), so maybe an ellipsis isn’t necessary after all? I think this is a very atypical case, and removing the ellipsis is recommended mostly because Report already implies action.

User input in this dialog is not required in order to complete a bug report, and that is why the ellipsis is not necessary

I don’t think case like this will show up very often, and if it does, be sure to run through the guidelines and these examples to help make your decision.

—

To think, I picked this one to do first because I thought it would be easy. It is interesting to see how much thought and debate could go in to a simple interface element such as an ellipsis. Now what would be great is someone familiar with docbook to help me put this stuff in to something more official than the OpenUsability development wiki and get it committed.

KDE4 HIG Request #2 should be around in a few days!

seele :: Dec.20.2006 :: Design, General, KDE/Kubuntu :: 20 Comments »

This holiday season, I though I would take a few minutes to list some of the things I’d love to get from KDE in the next year:

• Kivio to become so kick ass I can replace Visio, but right now I’d be happy with improved stencil placement and line drawing
• Someone to help me create web and KDE4 UI stencil sets after I switch to Kivio
• Krita to become a little more comfortable to use so I can use it to do simple image manipulation rather than Photoshop
• Konqueror to support/migrate my Firefox extensions
• AmaroK to see the err of their ways and work towards a more KDE-consisten UI
• SpeedCrunch add an option to display number pad so people stop thinking Kubuntu doesn’t provide a calculator

Other random things I want:

• The projector or monitor to work from my laptop on the first try
• Blizzard to fully forgive application “wrappers” so I can play World of Warcraft in Linux without risk to my account
• Second Life to get with the program and use first-person-shooter affordances for avatar control, and stop reinventing the wheel and use things like the Quake engine and Alice modeling environment
• Adobe to support their products on Linux until OSS catches up
• More opportunities to do OSS work during my day job
• A pony and a Wii

Luckily I have a lot of friends (or so I think :) so maybe I’ll see some of these things in the next year!

seele :: Dec.18.2006 :: Design, General, Humor, KDE/Kubuntu :: 14 Comments »

As I mentioned before, one of the goals for my break this winter is to specify an ambitious number of interface guidelines. By the end of the break, I hope to have a list to pass on to the HCI-related and Core-devel communities to comment on before committing. The current list of “topics” for the KDE4 HIG I have is huge, and working on random ones may or may not target immediate needs of developers.

What are specifications you have looked for or would like written? What are GUI questions you have stopped to ask yourself and wish you could go look up? Here is an opportunity to give me an idea of which guidelines or interface examples are the most important/immediate/interesting and should get drafted and finalized before nonpertinent items.

Please limit your request to one idea or concept, I would like to have a list which has attainable closure ;-)

seele :: Dec.11.2006 :: General, KDE/Kubuntu, Usability :: 12 Comments »