I have a dialog that includes file selection and it has a "Browse..." button. But it seems like it would be a good idea to provide some kind of drop target so that the user can use his/her favorite file browser to select a file (or files) and drag it onto my application.
Is there any standard practice for what to use as a drop target?
Is it a file icon of some sort? what would that look like?
I tend to think that drop targets should be where the file "should land". That is, if I had a browse button and file path editbox, I'd make the path box the target. If I made a document editing application, I'd make the entire editing area the drop target (unless that would make an embedded object of course ... :-P who said these things are easy?)
So I'd say it depends on the application. But having a dedicated, separate target with no other purpose than to drop things on may not be the best solution, since it unneccessarily clutters the interface even for people who will never be interested in using the feature.
In Safari (on the Mac, at least), a file-chooser form element (Consisting of a "Choose..." button and a field showing the chosen file's name) is also a drag-and-drop target. (Contrast with Firefox, which treats the whole window as a drag-and-drop target, and will replace the current page with the dropped item.)
Other places, I've seen an inset box, sometimes with a centered, grayed-out "Drag items here" text which disappears if anything is dragged in.
As Ruddy said, I don't recall any standard icon for the drop idea. There is one for the no drop as shown in this image
(source: west-wind.com)
Otherwise I tend to like this kind of drop explanation; I find them pretty explicit.
Usually if a window accepts files for drag'n'drop - it just accepts them anywhere in the window.
If you have a list of files (listbox/view) or an just an text box that accepts a single file, those individual control windows could be the drop target rather than the entire window.
Normally there is no visual indication that a window accepts file drops. The only indication would be that you try it and you don't get the no-drop cursor when you drag across the window.
(Note: this is under MS Windows, other os window systems may have different standards)
Related
I am using SWT tables in my project and there are few columns which are having longer strings which are not completely visible by default (for ex. path to a file location). Though I have tooltip to show the content and using mouse we can increase the column width to see the complete value.
Is there a way to do it with only keyboard usage?
Note: This question is more related to accessibility.
The following answer is based on my experience under windows. It can be different for other OS.
I'm afraid that there's no keyboard-only default way to adjust the size or reorder the column in a table, tree view or list view.
This is true not only with SWT but also with all other frameworks based on native win32 such as wxWidgets.
You must provide a keyboard-only way to resize and reorder columns yourself. here are a few ideas implemented by some applications:
Provide an option somewhere in the application that opens a dialog box with a checkbox list of the different columns. Ctrl+Up/Down to swap two items. Check/uncheck an item with spacebar to make the column visible or invisible.
Make the headers focusable. Use Shift+Left/Right to resize, Ctrl+Left/Right to swap two columns. Application key / Shift+10 opens a context menu where you can check/uncheck columns to show/hide and an option to open the column selection dialog box.
Some screen readers allow to do it by simulating mouse operation in some way. For example, use Jaws cursor, click lock on a header, release lock on the header to swap with.
But it's quite complicated, not always reliable, and thus very rarely actually used.
This is a very good question. I would be happy to give 100 rep to someone giving an answer being for windows and:
generic, working by default, everywhere or in most cases
Independant from screen readers (Jaws, NVDA, etc.) and techniques that simulates the mouse with keyboard (mouse keys)
Unfortunately, I don't think it exists.
I have a simple app that accepts dropping files from Finder.
I want to support 3 different dragging types:
move
copy
link (make alias)
When pressing Alt+Cmd while dragging, Finder usually creates an alias (link). However, in my app in draggingEntered: the flag NSDragOperationLink is not set in that case.
Below are the various flags for the different modifier key combinations:
move (no keys): Private, Delete, Copy, Generic, Link, Move, All_Obsolete, Every
copy (Alt) : Copy, All_Obsolete, Every
link (Alt+Cmd): Copy, Generic, All_Obsolete, Every
Note how in the last case the Link flag is not set. How could I tell in performDragOperation: that I need to create an alias?
Do I really have to check the modifier keys in the current event? I'd much rather have a clean solution via the source dragging operation mask...
Tested on 10.8.5 and 10.9.
You need to register first your dragged types in the code using
registerfordraggedtypes: api
Yes, I know it's a very old thread but it still comes up in search results.
For drag-and-drop operations that span applications you have to hold down Control to filter for the Link flag.
In the online documentation for NSDraggingInfo draggingSourceOperationMask there's a table showing how the modifier keys are handled but it's wrong (it seems to be describing how the Finder works). If you can dig up older documentation on the drag-and-drop API it shows a different filtering algorithm where Option filters for Copy, Command filters for Generic, and Control filters for Link. That's the filtering algorithm that the OS still applies to inter-application drag-and-drop.
I have a rather unusual question, namely, how is called this window from icon tray?
I would like to make it in my application, and I could not find his name. I would ask for some information, or the name, the rest I should have to deal with.
The Windows UX Guidelines don't say anything about it. From my perspective it's just a normal dialog, albeit one that has rather immediate actions (as opposed to first clicking on an OK button of sorts) and resides in a fairly small size in a specific location. It is meant to be opened, interacted with quickly and then dismissed, never being the center of your attention. If your idea fits those criteria as well, then go ahead. It's easy to recreate with standard means.
Every once in a while I try to add a new data model version, and the menu item is missing. It seems the Editor menu is supposed to change depending on the file selected, and this sometimes doesn't happen. It the past I've randomly clicked, cleaned, built, etc. and eventually it showed up again with me not knowing what happened. Today it seems restarting Xcode fixed it, but I don't know if that will always work. Below are two screen shots, the first showing the wrong menu, and the second showing the correct menu. My data model is selected in both cases. Has anyone else seen this? Is it a bug, or is there some setting or selection I'm missing?
From the color of that file navigator bar I can see that you did not select the datamodel file. You probably were in "Assistant Editor"-Mode and had a .h or .m file on the right side. The active cursor was in the right file too.
The selected file shows a darker shade of gray:
The not selected file uses a lighter shade of gray:
It's important to know that the file selection highlight in the left side bar does not change when you select a different file without using the side bar. Don't trust the sidebar when you are editing files.
Click into the data model file first and your menu will be like you expect it.
Unless your are selecting the menu super fast after selecting the file (possibly not giving Xcode time to swap it out) then I say file a bug report http://bugreporter.apple.com
You should give Xcode a few moments to swap the menu out though to determine what kind of bug it is, if it doesn't swap out after 60 seconds or so then it likely isn't just a performance issue). Make sure to include a system profile as I just checked on my and every time I switched to a data model it changed the menu accordingly.
Does the same thing ever happen with xib files? Any other file types you use that sometimes have different menus?
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.