Related
I need to figure out how to programmatically find and select a context menu item from a separate application's system tray icon. The only way I could imagine accomplishing this was to use mouse_event() with some hard-coded x/y values, and set the icon to always be shown. Aside from the hacky use of hard-coding in general, the problem here is the assumption that the icon will retain it's position (which is likely to break any time another application loads/unloads). I was wondering if anybody knew any other way to go about this?
Depending on how the application has been written, selecting the item from the context menu will cause a WM_COMMAND message to be posted to a window belonging to the application. You can use a tool like Spy++ to check for this. If this is the case then all you would have to do (in theory) is simulate that message.
If the application does not use WM_COMMAND to receive selections from the context menu, your job is much harder. There is no documented method of discovering the position and identify of system tray items, and so your method of hard-coding the x/y values is probably the best option you have.
See this MSDN Forum article which discusses how to find the systemTray's Handle. The article then references a CodeProject Article on how to find the handle of the application you are searching for. I have not tried this but it looks like it might be a viable starting point.
I'm relatively new to Cocoa and I would like to implement the ability to add or delete items from a pop-up menu in the same way that the OS X System Preferences/Network Location pop-up works. Selecting the 'Edit Locations...' option rolls down a window that provides the ability to add to, or delete from the existing Location list. My interest in doing things this way is as much about conforming to the relevant Human Interface Guidelines as having a way to dynamically change the menu content. (I have no real problem with the 'background' coding side of things, it's the user interface that's my primary issue at this stage.)
Is this a standard IB View?
On the surface, I can't see anything appropriate, but maybe that's just my inexperience. I'm assuming that, because this is not an uncommon sort of requirement, the task should be pretty straightforward and that Apple, or someone, would even have a relevant code sample to show how to define such a window.
Can anyone point me in the right direction?
Sorry for the late answer. I found this tutorial: http://cocoadevcentral.com/articles/000014.php
I have a Cocoa application managing a collection of objects. The collection is presented in an NSCollectionView, with a "new object" button nearby so users can add to the collection. Of course, I know that having a "delete object" button next to that button would be dangerous, because people might accidentally knock it when they mean to create something. I don't like having "are you sure you want to..." dialogues, so I dispensed with the "delete object". There's a menu item under Edit for removing an object, and you can hit Cmd-backspace to do the same. The app supports undoing delete actions.
Now I'm getting support emails ranging from "does it have to be so hard to delete things" to "why can't I delete objects?". That suggests I've made it a bit too hard, so what's the happy middle ground? I see applications from Apple that do it my way, or with the add/remove buttons next to each other, but I hate that latter option. Is there another good (and preferably common) convention for delete controls? I thought about an action menu but I don't think I have any other actions that would go in it, rendering the menu a bit thin.
Update I should also point out that delete should be an infrequent option - the app is in beta so users are trying out everything. This is a music practise journal, so creating new things to practise happens every so often (and is definitely needed when you start out using the app), but deleting them is not so frequent.
Drew's remark is always your first consideration. All other things being equal, I'm not a fan of making deletion as easy as creation; it's a dangerous and comparatively rarer action, and the UI should reflect that fact. However, not having an explicit delete control can indeed lead to support enquiries (the same happened in MoneyWell after the minus buttons were removed). The issue is that you won't hear from the people who avoided accidental deletion by hitting a too-close-to-the-plus deletion control; those people are happy and quiet. You will, however, hear from those who can't immediately find a button to click for deletion, even though almost all of Apple's applications have no such control.
If you feel that you need explicit UI for deletion, I think you can find a middle ground. The problem with deletion controls is accidental triggering, and the conventional "solution" to that problem is a confirmation alert. The problem with that is how intrusive and jarring they are, because they're modal. iPhone OS can teach us a lesson here: you can make confirmation entirely contextual and non-modal.
Examples are row-deletion (swipe to put the row into its "are you really sure you want to delete?" state, which visually tends to slide a red Delete button into view), then interact again (by tapping Delete) to actually confirm the action. There's a similar model on the App Store whereby tapping the price button changes it into a Purchase button; it's essentially an inline, non-modal confirmation. The benefit is that if you tap anywhere else (or perhaps wait a while), the control returns to its normal state on its own - you don't need to explicitly dismiss it before continuing work.
Perhaps that sort of approach (non-modal change as a sort of inline confirmation) can get rid of the support queries by making deletion controls explicit, but also patch up some of your reasonable concerns about intrusive confirmation.
I would say this depends on how important deletion is to the particular task. Is it something that the user has to do often, or very rarely. If it is rare, delete should just be left as an Edit menu option, and perhaps as backspace (Why cmd-backspace? If you can just have backspace, you probably won't get as many queries.)
As with everything in interface design, my take is to apply an 80-20 rule. If something belongs to the 20% of most used functionality, it should be exposed directly in the interface. If it is in the other 80%, you can hide it deeper (eg in a menu, action menu etc).
A + button is definitely in the top 20% --- you can't do anything without it --- whereas a delete is usually not a common operation, and is destructive, so can probably better be hidden away a bit.
The usual solution to this problem is to put the [+] and [-] buttons next to each other (see, for example, the Network pane in System Preferences). I generally find those buttons large enough that I don't hit the wrong one by mistake, although I can see that potentially being a problem.
If that option doesn't suit you, maybe take inspiration from Safari: put an 'x' inside the selected (or hovered) item.
Since your app supports undoing of deletion, I would suggest that you err on the side of making deleting stuff easy (at the expense of making it too easy) and make it obvious that these mistakes are easily undo-able. GMail does a decent job of that.
HTH.
How frequently is delete needed? Does the data and the user's expectation encourage deleting this data often? (is it a list of tasks, for example)? If so i'd certainly include a contextual action menu, even if Delete was the only option.
Cmd + Backspace may be a little unusual for people too - I know it's used in other places on OSX, but those places also provide context menus to expose the delete - i'd be surprised is every user knows about Cmd + Backspace, so i'd probably change it to Backspace (you do have undo support, so you're covered there).
Finally, and hopefully I don't sound like a git, but it suggests that the built-in help doesn't offer enough guidance on this - might be worth revising it?
Matt gave pretty much the same answer I was going to write.
Note that when you delete the object, you should animate it away: this provides valuable visual feedback: the animation (about 1/3 of a second is good) is long enough to catch the user’s eye, and they’ll see the object disappearing. If the object just disappeared without animating, the user would notice that something had changed instantaneously in the list, but would be less certain what it was. The animation reinforces the meaning of the delete button in the user’s mental model.
Often times convention is one of the most important design consideration for user interface. Usually the advice goes to do it like Microsoft does.
This is for three reasons:
If it ain't broke, don't fix it.
If your users expect to click on a floppy disk icon to save, don't change the icon (even though some of them may have never seen an actual floppy disk).
Users don't want to re-learn the interface (and hot keys, etc.) with each different application they use.
At the same time Emmerson said "*A foolish consistency is the hobgoblin of little minds.*" So when does maintaining a consistent user interface cross the line from a good idea to stagnated innovation?
Microsoft shook up the good old WIMP GUI with the introduction of the tool bar, and then again with the Ribbon control (which is the natural evolution of the tool bar, like it or not.) Now we are seeing ribbons everywhere.
So my question is, what are some user interface paradigms that are accepted and consistent across multiple applications, but have stayed past their prime and are starting to reek? Are there some important changes that would benefit from a grass roots push by developers to innovate and improve the user interface experience for our users?
One thought that came to mind for me is the modal pop-up dialog. You know the ones that say: "Are you sure you want to . . .. - [Yes] [No] [Cancel] [Maybe]" and its evil twin "Successfully completed what you wanted to do! [OK]." We are seeing a movement away from these with the "info panel" in browsers. I think they need to be adopted in windows application development as well.
If possible please list a solution for each stale UI item.
And please don't list clippy. We all know he was a bad idea.
NOTE: This is specifically Windows client user interface paradigms, but I am certainly open to drawing inspiration from the web, the Mac, etc.
You mentioned popup modal dialogs , and I'd argue that non-modal ones are just as bad. Any dialog box remove focus from the program, they could end up behind the program and make it hard to find it, they might not even appear on the same virtual screen.
I'd like to see an end to all dialog boxes. If you need to stop someone from using the UI because of some non-normal circumstance, then remove the relevant parts of the UI from the window, and replace it with what the dialog would contain. Bring back the UI once the problem has been handled.
Clicking things on touch interfaces
It's incredibly difficult to click on things on a touch interface, because you don't know when you have pressed the screen hard enough. And if you add an animation to the button you are clicking, you most likely wont see it, because your finger is in the way. Adding other reactions, like vibrating the phone or painting waves on the screen might work, but there is usually a delay which is too large, much larger than the tactile sense of a button being pressed. So until they invent a screen with buttons that can be pressed, all touch devices should move towards dragging user interfaces (DUIs) instead.
Counter intuitively it is easier to press an object on the screen, drag it, and then release it than it is to just press and release it. It's probably because you can see the object moving when you start dragging, and you can adjust the pressure while dragging it. Dragging also has a lot more options, because you now have a direction, not just a point that you clicked. You can do different things if the user drags the object in different directions. Speed might also be used, as well as the point where the user releases the object. The release point is the real strength of DUIs, because it is very easy to release something, even with pixel precession.
Some designs have started to use DUIs, like (here we go) the iPhone, palm pre and android phones. But only part of their design is DUI, the rest is clicking. One area they all have in common is the keyboard. Instead of clicking on a key the user presses any key, then drags their finger towards the key they really wanted to click. Unlocking these phones also uses dragging.
Other easily implemented DUI features would be things like mouse gestures, where dragging in different directions, or drawing different shapes does different things. There are also alternate keyboards being researched which puts a bigger emphasis on dragging. All buttons can be changed into switches, so have to drag them down a bit to click them. With a well designed graphics, this should be intuitive to the user as well.
The Apple Human Interface Guidelines are a good read on this topic. They discuss this from a very broad point of view and the guidelines apply to any platform, not only Mac.
The file system. I want to save a file.. >OOOPs I need to think of a file name first. Well.... how about ... blah.doc.
6 months later...
Where the %#*(%& * did I save that %()#*()*ing file?
The solution is build a versioning system into the application, or better, the OS. Make files findable by their content, with a search engine, instead of forcing the user to come up with a memorable name, when all they want is for their file to not get lost.
Eliminate the save step. Type something in to the application, and it's just there, and there's no risk of losing it by some misstep, like forgetting to save. If you want an older version, you can just pick a date and see what the document looked like back then.
To build on the search engine idea: It's a pain having to navigate some arbitrary tree structure to find your stuff. Searching is much easier. However, you might still want to have something like a "folder" to group multiple files together. Well, you can build a richer metadata system, and have a "category" or "project" field, and setup the search engine to show items by project, or by category. Or group by those, or whatever new UI discovery we make next.
This question is a bit too open-ended, IMHO.
However, my main approach when designing anything is:
Fits in to wherever it is. If it's a windows app, I copy MS as much as a possible
It's simple.
It provides options
Buttons have a nice description of what the result of clicking will be, as opposed to 'yes or 'no'
Harder to answer the rest of your post without spending hours typing out an arguably useless (and repeated) set of guidelines.
In my mind, the one thing that really stands out is that USERS need more and easier control over the application's user interface appearance and organization.
So many interfaces can not be modified by the user so that the most used/favorite functions can be grouped together. This ability would make your favorite software even easier for you to get things done.
Error messages need a "Just do it!" button.
Seriously, I really don't care about your stupid error message, just DO WHAT I TOLD YOU TO DO!!!
I think the entire Document model of the web needs to change. It's not a user interface, but it leads to many, many bad user interfaces.
The document model was a good idea to connect a bunch of documents, but now the web is also a collection of applications. Today, I think the Page/document model corrupts our thinking. We end up lumping things together that aren't related, modularizing our code wrong, and in the end confusing users with our monolithic control board type websites.
Find dialogs that sit over the widget in which you are doing the search are terrible. Loads of apps do that. The find bar in Firefox works much better.
Many applications have multiple panes within the UI - eg in Outlook there's the preview pane and the inbox pane (amongst others). In these applications typically cursor key presses apply to the currently focussed pane. But there's very poor hinting to show the user which pane has focus and there are seldom keyboard shortcuts to move the focus between panes.
The focussed pane should be highlighted somehow.
Something like alt+cursor keys should move the focus around.
Ctrl-Tab and Ctrl-Shift-Tab cycle left and right through tabs instead of MRU behavior, even though in most cases the same behavior is duplicated with Ctrl-PageUp and Ctrl-PageDown.
There are a lot but here's an idea for a couple of them:
Remove some clicks like in "add another" or "search item" and the like.
This is well done with interfaces like ajax which have autocompletes ( and auto search ) but is slowly being adopted for platform UI's ( and in some cases they were originated in platform UI's. )
This is how StackOverflow does it for some scenarios.
But of course, we all know that already don't we? No need for "Seach tag" or "Add another tag" buttons, they just happen
Dialogs as you described.
Guys at Humanized proposed Transparent messages which actually are used in their product Enso and some other places.
Mac uses them for notifications ( like in Growl ) use them very well, or Ubuntu new notification system.
alt text http://blogs.sun.com/plamere/resource/NowPlayingGrowl.png
Firefox replaces the traditional "Search" dialog box with a search bar at the bottom.
Although not everyone likes the placement for next/previous as in this screenshot
And even SO ( again ) :) replace the notification with the yellow bar.
Finally:
File managers
I really like ( sometimes ) the simplicity of regular file managers, but some times I would like to work faster/better with them.
If you compare IE 4 with IE 8 you can tell the advance ( even better compare IE 4 with Google Chrome )
But if you compare Windows 95 Explorer with Win XP they are almost the same!! ( Win Vista/7 is a step forward )
But I wonder: Why haven't file managers improved as much as webbrowsers?
That's one reason I like stuff like QuickSilver but it is just a step. Much work is needed to create something like a "Perfect program launcher" or (FileManager/DesktopSearcher etc as you wish )
QuickSilver featuring "move to" action
I am designing the (G)UI of a program, and have stumbled across a problem; The program will convert a number into different units, and the layout of a unit been converted to is:
[Unit name (when clicked gives information)]
[Special status, if any]
[Output in textfield that can also be used for input (to convert to other units)]
I want the user to be able to copy an outputnumber onto the clipboard, without having to mess around with highlighting and finding the right buttons to press. So, I thought I'd make a button after the text-output field, saying something like "C" or "Copy".
But I was reading on joelonsoftware.com yesterday, and discovered that users seem to be cursorclumsy. So what should I do?
I've thought about a number of different options:
Click on textfield to copy to clipboard - BUT: I want to use it for input as well
Pressing a numeral on the keyboard to copy the respective one - BUT: There will probably be more than 10, and I need them for new input
Bigger Copy button, like on that actually says "Copy" - Hmm, would this work? I know that I like to use the keyboard when I can, so a solution involving it would be nice.
Each unit will have its own space, where everything (name, textfield etc.) fits in. What if it would copy to clipboard when clicked anywhere in that space except for on the name or textfield. - BUT: What if you miss, meaning to click below one textfield, and clicking above another?
But what about highlighting the unit's space as I went along? - Could still mean trouble...
What do you think? I think I just might opt for #3 - Bigger copy-button..
There's nothing wrong with a Copy button after every field if you feel that it's going to be a very common operation.
Two suggestions, however:
In terms of look and feel, make sure that the button is clearly associated with the field. For a text field, the best way to do this is to put the Copy button inside the text field (on the right side - but be prepared to handle RTL languages by switching its position as needed!).
To avoid making it overly big, don't use any text, but rather use the stock Windows icon for Copy (like this one: ), and put the text into its tooltip. If you do that, you may also get rid of button border entirely, further reducing its size, though you'd still want some visual hover indicator to make it clear that it's an active UI element. In fact, you might want to specifically copy Vista/Win7 Explorer (also seen in IE7/8) UI for location field and the Reload icon in it.
I think the solution #3 is the best in your list, but I would like to see a sketch of your GUI.
What ever you do, it is important to use the OS standard keyboard and mouse event bindings and preferable look-and-feel too otherwise users get confused.
For sheer speed, the keyboard is the way to go. How about letters A-Z to copy the text boxes instead? Skip “E” to allow scientific notation to be inputted. Potential speed is high, but learnability is low. I’d expect users will have a hard time figuring out this UI even with explanatory text on the page/window, and if users have to read explanatory text, then the time that takes will likely negate the time savings of the UI, unless the user is using the app all the time (Joel also writes correctly that users hate to read).
For an app that will be used only occasionally, the big button is a better choice, the bigger the better, as predicted by Fitts’s Law. And absolutely label it “Copy,” not “C” and not an icon, to maximize learnability. Your other ideas have learnability and tolerance issues without the speed of the keyboard.
That said, I think you’re taking what Joel says too far. Certainly you want to eliminate unnecessary clicks, but the typical design for this type of app would require one click on the text box (which should by default highlight the whole value) followed by one click on a Copy menu item –or better, Alt-C or Ctrl-C from the keyboard. It’s hard for me to imagine a task where saving one click or a couple keyboard presses would be worth the clutter of a bank of Copy buttons beside your text boxes. Are you also going to have buttons for Paste and Clear? At some point the clutter will slow your users down more than the extra click.
How often are users going to be copying? If it’s really dozens of times per session, then you should re-think the whole design approach because any copying and pasting of one number at a time is going to get tedious. Maybe you should support batch processing, taking multiple numbers at once and outputting results in a form already suitable for the expected use. Maybe have it work within other apps like the way Enso does: user highlights a number in any document or text field of any app, commands Convert - Feet - Meters and it’s changed in the document or field.
If you accidentally click on the wrong area, you could just click on the right area after that. If your issue lies in the user not knowing when they click on the wrong area, just highlight the last-clicked area.
Is there a problem with copying whatever is in the textfield when they click on it? So what if it's being used for input? They're just going to copy the value they need after they type values in.
You could also have a ctrl-click or shift-click in the text box be a copy.
Most people know how to copy text on their own computer. Perhaps the best solution is to just auto-highlight all the text in a textbox when it gets focus so they can just ctrl-c to copy or start typing to begin input.