It is a skeumorphic depiction of notching, indicating that the area can be pulled/dragged. Similar to the notching on the end of the gun slide (providing extra grip to the fingers).
This appeared as early as Windows 98 (see the bottom right corner of window).
Edit: This is not unique to guns, but more of an industrial design technique. See here the battery ...
While Bowen's gun example is decent, an even better example would be the back of your TV remote control (or many other devices that store batteries under a slide cover):
The notching on the pistol, the battery cover, and plenty of other everyday items are primarily to provide extra friction/grip for your fingers, while also pointing out the best place to ...
Move objects to rearrange them, grab objects to perform operations on them
The move cursor should be used when objects are just being rearranged (translated) without any alteration to their properties other than position. For example:
Rearranging shapes on a canvas
Rearranging items in a list
The grab cursor is usually used for drag and drop operations ...
I would say that this often leads to an unwanted drag and drop action. What if this window for example has a small scrollbar, you want to scroll to the bottom of the page and you accidentally miss the scrollbar? You would drag the window down and you might need to reverse this action.
Why is it uncommon that windows can be moved by clicking anyway in the ...
There's no reason not to implement multiple solutions for best results.
Anna Rouben's animation intro is a great idea. Though I wouldn't use it by itself.
I would combine it with a 4-way arrow icon (used commonly for moving objects) with possibly a tooltip.
For uncommon practices such as dragging input fields, I would make this as obvious as possible.
As I've learnt – the more options you provide for the same actions – the better the application is. So the advice would be to implement both drag-n-drop and click-to-add, and you don’t have to worry about which one users use.
Even better, you have the option to track which one is most popular in your specific case, which may differ from an existing more ...
I agree with ted.strauss's answer, there are existing grip-indicators. A more suitable type would be a quare-pattern, that resembles a grippy surface like a floor mat. I think it does a better job in transporting the "grab here" message than a three-bar icon and it can also be expanded to a larger area. Also the three-bar icon is now more commonly used as an ...
To add to the existing excellent answers.
This type of design feature is known as an affordance (see https://en.wikipedia.org/wiki/Affordance).
Notched or textured surfaces are used in real life objects to suggest they can be gripped or pushed by a finger, and this has been adopted as a skeuomorphism in computer UIs.
Here's a screen-shot of Java Swing's "...
If you want to drag a sign perhaps you can add another sort of indication that the object moves, i.e.
However I do think it might feel unnatural to the user to drag a sign around. Clicking on object and make the sign move on to the new object would be a more natural behaviour for the user.
Users always assume that the objects are the ones that are ...
Drag & drop is absolutely an expected behavior to support. It's like asking "Should we support keyboard shortcuts?".
While the feature may not be used by the majority of users, the ones that do use it really rely on it.
Dragging and dropping is quite hard to communicate.
You can provide a 'grabbing hand' or 'four way arrow' cursor on hover (but this only works if you can get users to hover in the first place, and besides, my experience from user tests is that cursors don't make much impact anyway)
Give draggable items a hover state, or make them 'come off' the page by ...
Common patterns to indicate draggability:
This goes towards affordance. Users need to be able to recognize something can be dragged just by looking at it. A "grippy surface" is a common metaphor for this.
A grab-hand makes sense as well as the arrows (move) cursor. Currently grab is Webkit-only. Also note that some devices don't have a ...
The context is key, and you will probably have to learn what it means for each context. Even when you know it is a menu, it is not clear what kind of menu it is. Take Chrome. In Windows, there is only the hamburger, while on Mac OS, there is the top main menu as well, as in all Mac Apps. The Hamburger does not say what kind of menu it is.
The Draggable ...
If you're confident in the quality of the touch-screen, your design is a good one.
Some points to note:
Some touch panels, particularly bigger ones, have quite a lot of noise and can have "dead spots" where the touch is not (as easily) registered. You may want to delay snapping back the item once you notice the touch event finishing if you can.
It's not ...
For issues like this I find it best to look at how other interfaces handle it. That way part of the user training has already been done — you don't need to reinvent the wheel.
In this instance the first thing that came to mind is Pegman for Google Maps Streetview.
Google handle this issue by placing the draggable indicator in a separate toolbar 'off ...
It's more a question of whether you need to see the entire mapping or not.
If you don't have to see the whole mapping at once, there is another possibility.
download bmml source – Wireframes created with Balsamiq Mockups
If the entire mapping is essential then your best approach is to use a matrix that will allow people to view the entire mapping.
There are a number of options that can ease this, as the onus should not be on the user to feel they have to go and drop it in its original position - assuming they can even remember where that might have been.
One is to provide an undo redo capability. This puts users much more at ease in that they know even if they do drop something somewhere ...
The title bar isn't always the only spot to that can be used to drag the window, (these days some windows can be dragged by parts of their background, but it's rare) but it's the oldest and most established and common convention. It originated in the early WIMP UIs, the Smalltalk systems from the 70s and 80s.
If you study the way the above windows were ...
This is actually not always true. In some cases the default behavior of most apps would be to allow to drag windows by empty space. An example is KDE. See the screenshot:
KDE's default Oxygen widget style has window decoration visually merged with window contents. Thus, to make feel match look, the theme also by default allows to drag windows from all empty ...
Add a drop shadow to the element so it appears pinned to the finger.
Left: Material Design Components > Lists > Behavior
Right: Apple Human Interface Guidelines > iOS > User Interaction > Drag and Drop
Apple's HIG specifically mentions the ‘rising’ action:
Touching and holding selected content makes it appear to rise and adhere to the user's finger.
Came across this post today and wanted to provide a response based on some developments in the past couple of years (since 2012).
Google offers a good solution signaling its Gmail users of sortable elements by using two rows of stacked dots on hover (desktop)
A lot depends on how many items and groups you expect there to be, as well as how many you expect someone to be actively working with at a time.
If working with large numbers of groups and items, the first option would become unusable. Although, I would tend away from it even if the numbers were small.
The second option may not look fancy, but is both ...
You could try to expand responsive zones of small draggable areas. Moving close toward those zones is clear indicator of user intentions. It brings smart behavior to your app and provide better usability, as target is increased and moving distance is decreased (Fitts's law in action).
To indicate small zones more clearly, you could also use more brighter ...
The Windows OS provides the (optional) title bar and control box, as well as a mechanism for OS users to organize their application windows (re-positioning, minimizing, maximizing, closing).
From the perspective of the Windows OS, the title bar is the user's API for these operations. Everything else in the window is "content" that is under the control of ...
The SELECTED object looks like tooltip or label. I think a pointer should be more like an object, as it used as a control. I think pointer could be used without excessive SELECTED notion. Still you could use tooltip.
To show the interaction abilities ("liveness") of the pointer you could use unobtrusive animation with rather long "steady" state, see image ...
I'd observe that the kernel of the issue is that simply these are two semantically different icons, namely
Grab handle is a symbol that replicates has friction area for a thumb or finger
Hamburger Menu is a symbol that represents a list of menu items
these two icons have accidentally fallen upon the same symbol. The fact that they look the same is ...
Other answers have adequately addressed the skeuomorphic inspiration for this convention, but since the question also asked about history, let's look at that a bit.
I'd nominate Macintosh System 7.0 (1991, but I vaguely recall the UI style being widely previewed before then) as the originator of this convention... you see the ridging in active scroll bar ...
Personally I'd go with option B on iOS, and would look what do Androids show.
On desktop, I'd use some kind of "bumping", it's important, you can see why here in this answer: https://ux.stackexchange.com/a/25032/16685
I think there are several reasons for it.
First and foremost, it is tricky to do if you already have scrolling implemented. It is possible to do, but it would require solutions like lists where you can scroll in one direction (say, vertical), and then use the other direction to 'detach' the item from the list, after which you can drag it in any direction. ...