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

A grab/drag hand similar to this:

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?

-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?

Thanks. Interesting solutions but most of them are focused on draggable elements, not whole website.
–
AlvaroMay 27 '13 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?
–
Koen LageveenMay 27 '13 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 GroseMay 27 '13 at 23:41

9 Answers
9

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

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.

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

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.

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:

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.

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.

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

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.

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?
–
AlvaroMay 29 '13 at 8:10

Also that in some cases it shows a cursor and indicates what you can do in a little animation.
–
Koen LageveenMay 29 '13 at 10:22

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!?

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
–
AlvaroMay 29 '13 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.
–
Koen LageveenMay 30 '13 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.
–
PeterMay 30 '13 at 9:53

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?

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
–
AlvaroMay 29 '13 at 8:22

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.

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
–
AlvaroMay 29 '13 at 4:57

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?
–
AlvaroMay 27 '13 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 VailMay 27 '13 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.
–
Koen LageveenMay 27 '13 at 19:43

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.