I am writing a Mac application that provides a "test" like function. This application (through a connection with a server). Basically the application will give the students a story to read, followed by a series of questions (also from the server) where the user can (attempt) to select the correct answers, and send the result back to the server to be verified.
Implementing the "story" part was easy. Just send all of the text to a NSTextView. I had been planning to implement the "select your answer" as programmatically created NSSwitchButtons. However, some of the possible answers might take up more than one line. I have not been able get (any) NSButton class to wrap text based on the frame size, and there doesn't seem to be an easy way to override NSButtonCell to allow the text to wrap.
What other Cocoa class(es) should I use to accomplish this task? I need to have a check-box interface (so that people can select one or more possible answers, and the answers can be an arbitrary length - within reason!) Ideally it would also be easy to use so that it will be easy to programatically layout the answers as well. (Some problems may only have 2 choices, while others may have 5+) I can't imagine I'm the only one who needs this type of functionality
(Oh...since a picture is worth 1,000 words, I've attached a screen-shot of my app below with some answer text running off of the screen)
An NSButton will respect explicit linefeed characters embedded in the text, but I suppose that would not meet your needs. An alternative would be to have a static text item next to a checkbox with no title. Of course, if you want to be able to toggle the checkbox by clicking the text, you would have a little more programming to do.
Related
I have little experience in developing GUI for desktop applications, but I want to develop a typical GUI for creating/editing entities (e.g. Customer, Suppliers, etc.) which would be similar for many cases and would be comfortable for the users.
[* Please don't close the question. I put much effort in preparing the question and I really need help. *]
After analyzing our tasks I designed the following possible options:
1) In simple cases it is possible to solve the task by using an ordinary grid:
I.e. the workflow is: On pressing the Add button, a new row is added to the grid. On pressing Delete the user is asked for confirmation if he/she really wants to delete the focused entity instance. On pressing Save all previously made changes are saved. On pressing Close the form is closed (user is asked if he/she wants to save changes before closing).
Cons: I think such a GUI will only work for very simple cases. Editing something complex in a grid is not comfortable neither for a user nor for a developer (implementing complex editing in a grid will not be trivial I think).
2) For more complex entities the following option is possible:
The grid is used here only in the read only mode. On pressing Add a modal form for filling information about a new entity is shown. On pressing OK in that form the data is validated and if everything is ok the object is added to the grid datasource. On double clicking on a grid row the same form for editing the chosen entity instance is shown.
Cons: For every entity we will have to create 2 forms.
3) Another possible option:
The grid is also in the read only mode. When focusing a row in the grid, the fields above the grid are filled and a user can edit them. On pressing Add a new entity instance (object) is created and added to the grid's datasource, then the new row is focused, fields above the grid are cleared (binding helps here), the cursor is placed to the first field and the user can start typing.
I don't see any cons here except that maybe you will not have enough place for the grid and the fields on the same form. I like this option though I don't remember that I saw it anywhere.
I tried to ask the users of my program to help me decide which GUI is better for them, but the typical answers are "I think both options are ok" or "I don't know, you decide which one is better".
Now I would like to ask people with experience in GUI design the following questions:
1) Which option do you use usually? Maybe another one (not shown above)?
2) Would be nice if you also said a couple of words about your implementation (dataset/custom business objects/binding, etc.)
3) Which cons did you notice in my options?
4) Any advice on what I can read on the subject?
Thank you for help!
Junior1993, This is a great question, and there are many online resources that will spell out the trade-offs of each of these interaction design patterns, when to use them, and when they are most effective. You did not provide project-specific details, so it's impossible to answer those questions.
The "Work With" pattern is the foundation of your write-up, and you were asking about the pros and cons of different variations. Here is some reading on "Work With": http://quince.infragistics.com/html/PatternView.aspx?name=Work+With
All of the patterns you described are well-documented and can be modified to fit different purposes.
Your #2 pattern is "Edit-In-Place". It can also be found on the Quince site.
Your #3 pattern is "Two-panel selector".
This one takes many forms, but it helps to preserve context while editing.
The one you did not mention was "New-Item Row". You might want to look at that one, too, and select the pattern or combination of patterns that best fits your users' goals and the content they are creating/editing.
There are other pattern websites out there, and most build on the work of Jennifer Tidwell, author of "Designing Interfaces", an interaction design classic.
Best of luck to you!
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
I'm writing an internal-tools webapp; one of the central pages in this tool has a whole bunch of related commands the user can execute by clicking one of a number of buttons on the page, like this:
toolbar http://img709.imageshack.us/img709/1928/commands.png
Ideally, all of the buttons would fit on one line. Ordinarily I'd do this by changing each widget from a button with a (sometimes long) text label to a simple, compact icon - e.g.
button labelled "Save" http://img337.imageshack.us/img337/773/saver.png
could be replaced by a familiar disk icon:
Unfortunately, I don't think I can do this for every button on this particular page. Some of the command buttons just don't have good visual analogs - "VDS List". Or, if I needed to add another button in the future for some other kind of list, I'd need two icons that both communicate "list-ness" and which list. So, I'm still considering this option, but I don't love it.
So it's come time for me to add yet another button to this section (don't you love internal tools?). There's not enough room on that single line to fit the new button. Aside from the icon solution I already mentioned, what would be a good* way to simplify/declutter/reduce or otherwise improve this UI?
*As per Jakob Nielsen's article, I'd like to think that a dropdown menu is not the solution.
Edit: I'm not looking for input about the icon idea. I'm looking for other solutions. Sorry my example disk icon was a small one; it was just an example. I'm showing a bigger one now to hopefully be more clear.
I would add a More Link Like Google does.
See the Top Bar of Google with WeB Images Map More >>
To this more >> drop down you can add logic to add button less frequently used by user or something like that.
If you read Jef (and Aza) Raskin, you'll probably realize that icons are also not a good solution – both were pretty vocal in their dislike for them (with very few notable exceptions). For a start they're even harder to hit than tiny buttons, then their symbols can be confusing, culture-dependent and misleading. We're already good at reading text, parsing and interpreting icons is often slower.
In any case, that button bar looks like it accommodates pretty much anyone and their dog who might be using that product. You might have had some specific scenarios in mind when creating it that should be easy to do and are important. Most likely not all buttons are needed at once for such a task to complete.
Another thing is that maybe not all buttons are even useful at any single state of the application. Can you maybe branch into different sets of buttons, depending on the state. That's only possible however, if each state has clearly defined what actions can be taken. If all buttons are equally pressable regardless of state this won't do anything.
Grouping commands according to related functionality might also be an option. This doesn't have to be done with menu-like idioms, you can also put them into containers with different background color or even color the buttons themselves (just keep in mind color blindness, though). Depending on how related those individual functions are this can be a good way of speeding up interaction. It might requier some training for users to know what the colors refer to but for an in-house tool that's only used by people you know (instead of by arbitrary random ones [which is a problem Microsoft faces quite prominently]) this should pose not much of a problem.
What if you use icons and text?
For the commonly understood commands - use just an icon (like the save)
For the uncommon commands use an Icon + the text.
If you put a border around the button as a whole it should tie the icons / text together nicely and show it's still a button. You could also do some hover effects.
Since you can't do a dropdown menu (or similar techniques like clicking a button to generate a secondary menu). The best I can think of is what Prescott did or showing an area of buttons that are grouped in such a way to make it easy for the user to know which section their button should be in.
I would start by changing some of the longer labels. At a minimum, "Application Loading" could be abbreviated "App Loading." What's another (shorter) way to say "Quick File Transfer"?
You could also group the buttons into tabs (i.e. make it a ribbon). That might work particularly well if different classes of users tend to use different, non-overlapping sets of buttons.
Numerous options:
Group and labeling. Any time you have more than eight commands, you should divide the menu items into semantic groups of about four to help the user scan for the command they want. Labeling the groups also helps the scan and can make the menu more compact. For example, Instead of VDS Ping and VDS List, Have a group labeled “VDS” with “Ping” and “List” menu items. You’ve one less word to fit in (two if you put the label above it’s associated menu items when using a horizontal orientation).
Pulldown menus. Nielsen is correct about avoiding the use of a dropdown menu for making commands. However, he’s clearly in favor of pulldown menus which look and behave like a menubar in a thick client app (Nielsen calls them “command” and “navigation” menus). I think you’ll find that there are several Javascript pulldown menus out there now, unlike back in 2000 when Nielsen wrote his post. You can fit 100s of commands in a menubar.
Sidebar menu. Arraying the menu items vertically and you should be able to fit 20 or more commands and you won’t have to shorten any command names to something user might not understand. If that’s not enough, consider a “menu bank” than combines the benefits of sidebar menu with the capacity of a pulldown menu.
Ribbon. If your commands fit into discrete tasks, where the user tends to stick to one task for a while, you can arrange the buttons on a tab control, with one sheet per task.
Command Overloading. Represent your data objects as selectable entities in your window and change your commands into more general operations, like Drill-down, Create, Copy, Move, Delete, and Link, that can be applied to various different classes of objects, thereby reducing your total number of commands. The user can select one or more data objects then select the desired command to act on them.
Work Area Attributes. Some of your commands may not be commands by settings or attributes. Remove them from the menu and represent them as data objects in the work area of the page (or another page, if they are rarely used) using controls like radio buttons, dropdown lists, and check boxes. This has the added benefit clearly showing the user the current setting as well as providing a means to change it.
Variants. For an internal app, you probably have formal roles and responsibilities that vary by work position. Include the user’s position in your model, and dynamically hide commands (and other controls and pages) that aren't relevant to that position.
What about a combobox and a Confirm button?
Or a simple dropdown menu?
Add a "Tools" or "Actions" menu bar, and stick rightmost 4 commands (or more) into the menu.
Would it be possible to implement a "most used" or "preferred" set of buttons (preferably for the user, but globally if necessary) and button to take you to the rest of the items if you need one of those?
You could group them (like the two 'vds' buttons) behind a single button that, when clicked pops a context menu with the individual icons.
It truly seems like what you're developing is a administration console which happens to present its UI through a web page, rather than something which I'd quantify as a web app. As such, especially given your statement that this is an internal use application, Jakob Nielson's advice regarding <select> tags being poor design need not apply.
For this particular set of assumptions, I think the better option is to imitate a system menu setup using one of the many CSS-based menuing designs possible.
Icons are terrible from a user experience stand point. A picture of a Floppy Disk doesn't un-equivocally mean SAVE. It means something to do with a Floppy Disk. A Floppy really, its 2010, SAVE on a web app means save to the server, how does a Floppy Disk even compute?
Here is an application that has had the same extremely usable interface for 10 years! And hardly any images for buttons, and it is one of the most productive applications in its category.
You know what ICONS stand for I ncomprehesible C ryptic O bfucsated N onsense S ymbol!
Also how do you internationalize an icon?
I have an application that displays a dialog when the user needs to enter information. The reason for this, is to keep the main form readonly, and only when you need to add/edit data will a dialog appear.
The problem I'm wrestling with is what to display for the label names in the dialog. The application is a WPF desktop app and traditionally desktop apps are very short on label names (usually one or two words). I want to make the dialog user friendly and be more descriptive about the information that is required. Web developers seem to be catching on to this and are much more descriptive with their label names, but most of the forms I've looked at are forms that are only filled in once, whereas I will have data that can be edited.
An example: If I had a label that asked a user if an employee smoked, in most a destop apps the label would normally be something like 'Smokes?' with a checkbox, whereas I want something like 'Does the employee smoke?'. My issue with this is, that the first time you come across this dialog and enter the data, then it seems OK, but what about when you are editing data that is already there. Does this label now make any sense. Past tense and present tense seem to be getting in my way and I was interested in what people think or ways they have approached this. The application I'm writing is a WPF app and I feel that traditional label names are a bit old in the tooth now.
Another example would be entering contact details for a person. Do I just have labels that say Phone, Fax, Email or something more descriptive. i.e. a label that appears before the textboxes stating 'Enter the contact details below' and then the single word labels?
Maybe I'm just being pedantic about all this, but I would like to take a step forward so that my application contains more than single word labels that are sometimes unclear to the user about what is required.
Why not make use of the concise labels and use Tool tips for a longer explanation.
The longer explanation is only required when a user is unfamiliar with the application anyway.
Also, you could re-word a label to make it sound more like a question such as "Is a Smoker?"
Since you are using Stack Overflow, take note of their use of tooltips, I think Jeff Attwood has a blog post or comments in a podcast about the use of tooltips in SO. I can't remember where I heard / read it.
Have you thought about creating a "quickstart" flow or wizard for entering data for the first time? This would give you the opportunity to guide the user through the process, using labels with descriptions, so that they learn to associate the description with the label you've chosen (hopefully something succinct but intuitive). Then when they need to edit data, they have learned the application taxonomy.
If you are running into issues with tenses, steer clear of using verbs or only use the present tense. I would try using nouns - "smoker?" instead of "smokes?"
When you're asking for common data like phone numbers, email addresses, you can probably assume that the user will understand what you mean. Just be clear as to whose contact information you are asking for - using a title for the field set that is explicit is a good idea ("Employee Contact Details"), adding a short description above the field set will help too.
Of course, you should always do some level of usability testing on your application before you launch it to uncover any issues with the interface.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I think it's considered a bad practice to have controls appearing and disappearing and the size of the window changing in a single GUI screen dynamically based on a user's input. However, I can't seem to find a definitive reference that states this.
I've been asked to create a GUI that has a text box at the top in which a user enters a file name (using a file chooser). Of the files that can be chosen, each has certain properties, however some of these properties can be null for a given file.
Below the file name text box are rows of pairs of labels and text boxes with values for each of those properties. I've been asked to not show a label and a text box if the associated property is null.
The user can repeatedly choose different files and the values in the text boxes should update accordingly. In addition, the labels and text boxes should appear and disappear depending on whether the values are null. Moreover, the value of the screen should shrink or expand so that there isn't empty space (because of null values and, hence, missing controls).
This seems to me like it would be very jarring to the user (to have controls appearing and disappearing and so on).
Is this bad GUI design? If so, could someone quote an authoritative reference that I can use in trying to argue against this design?
(What I would prefer is to just leave the text boxes blank for null values.)
I have to disagree with Konrad and Brian here -- this will end up being jarring for most users.
While dynamic response is definitely a valid GUI paradigm, hiding/showing and resizing displays dynamically based on selections from the same list (or entry into the same text box) tends to be very jarring for normal end users. This is why the so-called "smart" menus in Office (and Win2K/XP) were loathed by many -- features seemed to appear and disappear for no good reason.
The correct paradigm in this case is disabling ("graying out") the controls. If you're looking for specific citations, I believe this has been discussed in About Face: The Essentials of User Interface Design. I know that the Microsoft Office usability team also produced the same results from their labs.
Pre-emptive Note:
Showing/hiding is not always a bad paradigm. But use it when it makes sense. It makes sense for the Windows Explorer detail bar to show different contextual information based on whether you've selected a Word Doc, an image, or an MP3. That's a small, borderline incidental piece of the UI, with no discernible (and especially no editable) controls. It's expected that navigating to a new tab will hide the controls from the previous tab and show the ones from the new tab -- but then again, tabs are a navigational paradigm.
Showing and hiding within the same view, for what (to most users) will appear to be the same kind of data, is the jarring experience.
I think it's considered a bad practice to have a single GUI screen that changes dynamically based on a user's input.
Honestly, that seems like a very odd guideline, at least when formulated this broadly. In fact, in order to get a result, the GUI has got to change dynamically reacting to user input.
This seems to me like it would be very jarring to the user
Try it. I don’t think that it will be a problem, as long as you don’t make the input field shift while it has the focus. The user shouldn’t be chasing the text box she’s typing into.
No, that sounds like a normal GUI design. No matter what the file type is, you're doing the same basic task. You just slightly change the details of which properties are shown. Same task = should be on the same screen.
How would I go about implementing something along the lines of "scrubby sliders", like in Photoshop and quite a few other image-processing applications?
They are slightly hard to describe.. basically you have a regular numeric input-box, but you can click-and-hold the mouse button, and it functions like a slider (until you release). If you click in the box, you can select text, edit/paste/etc as usual.
The Photoshop docs describe it, and I put together a quick example video (an example of the sliders in Shake)
Another similar implementation would be the jog-wheel in Final Cut Pro, which functions similarly, without the numeric readout being underneath.
I can't seem to find any mention of implementing these, although there is probably alternative names for this. It is for a OS X 10.5 Cocoa application.
It is for a colour-grading application, where a user might need to make tiny adjustments (0.001, for example), to huge adjustments (say, -100 +100) on the same control. A regular slider isn't accurate enough over that range of value.
Copy-and-pasting values into the box would be a secondary concern to scrubbing the values, and the Photoshop/Shake setup really well. The unobviousness of the control is also of a low concern, as it's not a "regular desktop application"
I've encountered those. They suck, because they prevent the user from dragging to select the text of the number.
A better idea would be a miniature slider beneath the field that expands to a full-size slider when the user holds down the mouse button on it and collapses back to its miniature size when the user releases the mouse button. This way, the selection behavior is still available, but you also provide the slider—and in a more obvious way.
There's no built-in class in Cocoa for either one. You'll have to implement your own.
I doubt that this exists in Cocoa framework. As far as I remember it is not mentioned in the Apple Human Interface Guidelines.
You can develop one yourself by using a custom view and tracking mouse events (-mouseDown:, mouseUp:, -mouseDragged:).