13

I'm building a site that uses the jQuery iScroll plugin in the main navigation system. (http://lab.cubiq.org/iscroll/examples/simple/). Please note that the plugin is not exactly drag-n-drop.

Right now, I'm just using a different cursor to indicate the page is draggable.

A grab/drag hand similar to this:
Two images - both green, one with an open hand cursor, one with a closed/grabbing hand cursor

How else should I warn the user about the draggable interface?
A DRAG ME message (as cursor) that appears for some seconds when the page loads?
Does anyone have any ideas/references?

EDIT: I could see in the answers some tips and references to other questions where some of the divs inside the page are draggable. But in my case the whole page navigation is draggable. How should I warn in that case?

Here are some examples:

  1. A small animation at the beginning. (I don't like this kind of option much)
  2. A circle appears when pressing the mouse
  3. Four-arrow cursor + Scroll Sign
  4. The hand/grab cursor I was proposing
  5. Hand/grab cursor
  6. Hand/grab cursor
  7. Not exactly draggable but I found interesting the way of warning the unusual navigation
  8. Same as the last one here.

So I think I can come up with various "small" solutions which are:

-Visual instructions like in example#3 and example#8

-Small animation at the beginning as in example#1

-Make a first complete plain screen that will force the user either to drag that page to enter or leave the page like in example#1

-Small tips like in example#2 or making the page auto-drag a little if the user hasn't drag it (proposed in one of the solutions below)

-Making kind of a zoom-out when the user tries to drag like in example#7

-Lack of any scrollbar or button to go next like in example#2. Two opinions with this, either the user realises he must drag or leaves the page. If I put buttons the user will use the buttons to go left/right and probably won't realise the page was draggable like in example#4

This all makes me think of when MAPS websites were not draggable. When they began to be draggable, how did they warn the user?

EDIT 2: I found this article that might be interesting for the subject: http://blog.maxrudberg.com/post/38958984259/if-you-see-a-ui-walkthrough-they-blew-it

9
  • ux.stackexchange.com/questions/216/…
    – rags
    May 27, 2013 at 5:10
  • Thanks. Interesting solutions but most of them are focused on draggable elements, not whole website.
    – Alvaro
    May 27, 2013 at 5:52
  • 1
    Dragging stuff with the cursor is pain in the ###. Not everyone has the dexterity to use such a UI, and it's pretty much impossible on a laptop's trackpad. And you already discovered the surfacing problem with draggable stuff. Are you sure you want to lean so heavily on this concept? Why is it important? May 27, 2013 at 19:50
  • 1
    One of the biggest issues you'll face is that you have to be interacting with the content using the mouse to recognise the cursor being unusual.
    – Kit Grose
    May 27, 2013 at 23:41

9 Answers 9

1

I agree that most answers here apply only to draggable elements. In those cases there are clear conventions for giving such elements affordance. In the situation where the whole canvas can be explored by dragging, the only real convention I know is the hand cursor.

I think the following points are important to keep in mind if you choose to pursue this design:

  • You're breaking the convention of the web. There is a clear convention to let the user agent determine the scrolling mechanic. On a tablet or smartphone it's dragging, on a regular pc it's scrolling, which may be implemented as a specific touch gesture or using a specific device like a scroll wheel. You are taking over this task, so it's now your responsibility to ensure that scrolling works well on all conceivable platforms. You can no longer hold the platform and web browser responsible. This is a big investment
  • Remeber accessibility. Ususally the platform and browser take care of most of this, but if you take over, you're on your own. Have a strong plan for graceful degradation and progressive enhancement.
  • Whatever you do, test the hell out of it on all platforms you can think of. If it's a long-term website, make sure to keep some budget open for when the next big platform comes along.

Nevertheless, you are not the first to make this decision, although in all the examples you give, I would not consider the choice justified. You really need a better reason than wanting to stand out in order to risk such bad UX experiences. Some cases where the paradigm does work:

The common element in these seems to be that there is a very large canvas, where the user will want to place the viewport accurately on a specific area. Zooming in and out is always an important use-case in these examples.

The scrolling mode in these examples is relatively well known. Drag the canvas around, double-click to zoom, etc. Make sure you implement all elements of it, not just the dragging.

The following elements may help to let the user understand that they are in this mode.

  • A navigation menu top left. Let the user move up, down, left, right, and set the zoom level by clicking. This is also a visible safety option for when they don't understand they can drag. If you detect that they use these controls a lot, you can give them a small unobtrusive message explaining the dragging option. If you detect that they use the dragging options, you can collapse or hide the controls.
  • Alternatively, place arrow keys at the edges of the canvas. Again, this will alert you to users who have missed the dragging option, and give those users a fail-safe to navigate.
  • An overview of the whole canvas, showing the current viewport as a red rectangle. (Like the navigator view in Photoshop). This also allows the user to quickly jump to a point that would be too far to drag to.
  • Let the content cut off unnaturally at all borders. If it only cuts off at the bottom or the top and the bottom, it will look like a regular scrolling web page. Make sure there are no clean margins for any direction that can be scrolled.
  • Consider making the dragging a secondary mode (like in most PDF readers) that can be activated and deactivated explicitly. A button with an open hand is a good convention here.
0
17
+50

Common patterns to indicate draggability:

Drag handles
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.

Cursor 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 cursor at all.

Maps
By now people are used to dragging maps around in Google Maps. It is two-dimensional content and it's easy to see some of it is outside the viewport. Large photo's might also trigger this recognition. However, people are used to scrolling pages of text, so don't make a drag-centric interface for text based content.

Tutorialize
Show something about how to use the interface upon first use. Indicate where more content can be found and how to get there. Not however, that on the web people will hardly ever have the patience for this.

That said...

Draggability should always be offered as a secondary mode of interaction. Everything a user can do by dragging should be possible by clicking as well. This is why Google Maps has that D-pad in the upper left.

I see a lot of "I want users to behave like X" and "I want user to have a sense of exciting discovery". This is not user-centered! Besides, people tend to go through annoyance and irritation before reaching discovery, and on the web that means they're long gone.

This article mirrors my own experience:

They agreed that drag and drop felt ‘fun’, and ‘creative’, but overwhelmingly stated that it was unnecessarily complicated, and that it was just as easy, or easier, to click. ‘Dragging was a drag’ was one of my favourite quotes. :)

Draggability should be used in situation where it supports the usability. The primary advantage is in indicating relative location. If you need to move an object from A to B, it's much faster to just have a click do that. If you need to move an object from A to somewhere between B and C, it's better to have the user drag it to the desired position.

Finally, let's review your examples, as they handily cover a number of pitfalls:

  1. A small animation at the beginning. (I don't like this kind of option much)
    I only saw it because you told me to look for it and even then only the second time I visited the site. As a whole this website is a major challenge to interact with.

  2. A circle appears when pressing the mouse
    I really had to look for this one and only found it because I knew it had to be there and I persevered. While you can see that there should be content off-screen there is no indication of how to get to it. I tried scrolling and it seems to work, but that was more luck than anything else.

  3. Four-arrow cursor + Scroll Sign
    "I'm only an indicator, drag the page!"... go drag yourself dude. There is no reason I can't use the website the way I know and like other than laziness or ineptitude of the creators.

  4. The hand/grab cursor I was proposing
    This one is actually good. Everything is designed around a draggable interface and it makes sense for the content. And it is clickable too.

  5. Hand/grab cursor
    I'm still trying to figure out this one. There is not a single thing I understand about it.

  6. Hand/grab cursor
    Funny to see a website called Form Follows Function to be so concerned about Form. They have some nice attempts at tutorialization, but I still don't get why it needs to be this hard to use. Swiping with a mouse is way harder than clicking on a button.

  7. Not exactly draggable but I found interesting the way of warning the unusual navigation

  8. Same as the last one here.
    Someone has confused "technical proof of concept" with "website" for these last two...
4
  • 1
    Thanks, you gave me some tips I was going to discard like 'Draggability should always be offered as a secondary mode of interaction'. Awareness of content outside the viewport is also a good one. example#6 has 'nice attempts at tutorialization', do you mean the fact that the website starts spinning?
    – Alvaro
    May 29, 2013 at 8:10
  • Also that in some cases it shows a cursor and indicates what you can do in a little animation. May 29, 2013 at 10:22
  • I see,definetely this is really good example for dragging: fff.cmiscm.com/#!/section/rainingmen fff.cmiscm.com/#!/section/surfacewaves
    – Alvaro
    May 30, 2013 at 5:25
  • Yes, definitely. The interaction wouldn't have been half as cool without it. And the little intro makes it obvious enough what you can do. May 30, 2013 at 6:18
6

Instead of using the clenched fist cursor I would suggest using this enter image description here instead.

or else continue reading.


Show it to the user that it's draggable. Like in real life physical Products do.

For example the switch on this table lamp here. The grip is enough to tell the user that it's draggable and it can be slided since there is no other reason why to put bumps on a switch.

enter image description here

Similarly in iOS draggable Table rows have "grips" in the far right .

enter image description here

Also notice the scrollbar if you're on windows 7 or less. It too has grips which means it can be dragged

So you can put "grips" on whatever you want the user to drag .

3
  • These tips are good for draggable objects inside the page, but what if the whole page is draggable as in the IScroll example? Why would you suggest using that cursor instead?
    – Alvaro
    May 27, 2013 at 12:37
  • Oh I see. That cursor is conventionally used to move stuff on screen and hence its name "Move" . Check it under Control Panel if you're on windows. And if nothing else works you can put a pretty scrollbar. Scrollbars are pretty easy to manipulate and design as required, thanks to CSS3.
    – Nash Vail
    May 27, 2013 at 12:51
  • @nashmaniac I think you're on the right track, but you should throw in the keyword affordance in there somewhere. There are a number of common patterns for showing that something's draggable, so build on that. May 27, 2013 at 19:43
0

If the page contains a mixture of draggable and non-draggable divs they should be visually distinguished if possible. For instance the draggable divs could have a dotted border and the non-draggable ones a solid border. Or a slight drop shadow on the draggable divs to suggest they are floating and unanchored.

1
  • The main concept of the web is the draggability.As in the example I posted, the main idea of navigation is to be dragable.
    – Alvaro
    May 27, 2013 at 4:08
0

I've been thinking about this and to my understanding and findings, form elements which itself teach you about their interactive nature are the most successful ones. For example scroll-bars, buttons, drop-down menus etc. But here we are talking about an additional interaction, the DRAGABLE PROPERTY which a static image cannot explain. Taking lead from here, I suggest something like that.

  • Keep the dragable div above the fold so it is seen the moment a page is loaded.
  • Use a delay to display such a div so it is noticed by the eye as it becomes visible.
  • Set the div to an auto-motion where it slowly moves 80-100 pixels on the screen and then eases out its motion and comes to stop.
  • keep track of the fact that weather div was ever moved by the user or not. In case user didn't interact with it, move it again another 80-100 pixels after waiting some 5 seconds.
  • If interaction didn't happen for the second time either, bind the further sliding with the scroll-bar and slide the div (a little) as the user scrolls up or scrolls down on the page.

Now these interactions are in addition to whatever approach you use to make the div seen as draggable. You should still use a cursor with arrows, possibly have scroll-bar near the div and other discussed visual aids which help the user understand its interaction and nature.

1
  • The whole website is draggable not just a div. However your last three points could be valid. But still I believe not enough to warn the user. I improved the question. Thanks
    – Alvaro
    May 29, 2013 at 4:57
0

Whatever you try to do, try to avoid using a solution such as http://blacknegative.com/. It a kop out (in my opinion). If you have to tell users how to use a website you're overcomplicating an issue. So the whole area is draggable? The below answer comes from just some creative ideas and nothing more - I think you have received some good ideas above and they are not to be discounted.

  • If the user clicks on the screen, ensure that the draggable object that is selected is prominent. A way to do this is to use Apple OSX feature when you tab to another feature (dim the background and ensure that the property is selectable). Or if you're on a window machine now press Win key + Tab.
  • Have you thought how this might work on iPad and iPhone? How can users drag objects? It's unnatural for the user to hold down their finger and move to navigate as they will swipe, not hold their finger. (pinch to select and then drag? Unsure of the technical possibilities here)
  • The cursor of the hand as in http://rvlt.com/ is perfectly valid to indicate this kind of motion
  • Have you thought about (without knowing the concept/design) using ulterior methods. For example, what happens when a user scrolls? Or presses"-->" on they keypad? Could you either a) accept these methods of scrolling or b) place a warning to explain that users must drag the page to navigate. Goes against my very first point but still valid as the user has interacted with the site first and then you are instructing them upon error, not immediately.
  • @Salman's indication of animation is a good one. Can these ideas not be incorporated with full screen? For example "keep track of the fact that weather div was ever moved by the user or not. In case user didn't interact with it, move it again another 80-100 pixels after waiting some 5 seconds." is surely still valid when place in the context you are discussing?

I'm out. Understand that might not particularly help but I'm throwing my two cents in regardless - plus it was great/interesting to think about. My general advice would be to use simple GUIs to indicate that the page is draggable. And if that fails, screw it, just tell them! (eurgh, kop out kop out) Questions/considerations:

  • Undertake some quick user testing on the above sites WITHOUT explaining your concept and see if users understand the draggability (a new word!) aspect of the site to navigate. Id be interested to know the results of this if you do do this.
  • Have you got an example of what you are discussing in terms of competition?

EDIT: Sorry why can't you do what @Salman said and have properties (div) similar to http://www.narrowdesign.com/ - when the user drags it, only then does it go full screen?

1
  • There is no problem about iPad functionality.As you can see in the iScroll example(lab.cubiq.org/iscroll/examples/simple), that is in fact the natural way of intracting in touch device. I considered what happens when scroll or --> are pressed, but warning the user if he does it gets again to the main question,'how?'.'@Salman's indication of animation' warns something can be done, but I don't think the user will realise it is to 'drag'. Going fullscreen could be, but it happens also if the user just scrolls (try narrowdesign.com), so I'm not sure of the effectiveness. Thanks
    – Alvaro
    May 29, 2013 at 8:22
0

Some parts of interactive design is also about discovery. You shouldn't have to explain, indicate or notice about all that is possible. Not even have to be intuitive per se. Life is also about discovery! When you have users who are familiar with the interaction style you created, they will find it out themselves. Other users will find out by accident. It's almost like an art form. Now how cool is that!?

3
  • 1
    That was my first approach to the design but as you can see in others comments not everyone thinks this way. The design is going for this discovery-functionality but I want to make sure not-in-the-mood-for-discovery users can still make a good use of the website.Thanks
    – Alvaro
    May 29, 2013 at 8:25
  • If I need to discover how to do X, that means I can not do X until I discover how. In a game that might be cool, but people don't want to learn how to use a website, they just want to get on with it. So, you could hide stuff for me to discover, but it can only be extra special ways of doing X. E.g. keyboard-shortcuts. May 30, 2013 at 9:53
  • 1
    I would say that the use of interfaces is about discovery, but the design of them is about discoverability. True, too much explanation can harm an interface and cause excessive cognitive load, but if a critical interface element (like scrolling) has poor discoverability, you will frustrate a percentage of your users. They may feel that they have discovered the feature by accident, but if the UI is well-designed, their accident was your plan.
    – Peter
    May 30, 2013 at 9:53
0

You should change the width of the scrollbar on mouseover; that helps a lot to get noticed by the user. Next, you must change the mouse icon that you yourself suggested. It's a good way. Anything extra will be overload. I am attaching how facebook chat show that its draggable and then increasing the width to get the user attension

Facebook Chat Draggable

1
  • Hi Rohit. Welcome to the site! Can you add any evidence to support your post? May 30, 2013 at 1:52
0

The best way I can think of is just put a little popup near the cursor with the Message "Hold and drag for scrolling" or something like that.

So something like this: http://www.hscripts.com/tutorials/html/tooltip.php

You can then specify to hide the tooltip on hold. I think this is the most simple way. It does not have to be difficult.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.