Prevent the context menu from opening.

[Fishrock123]

This frees up the right-click for us to use.

Closes #16

[artursapek]

What do you want to use right-click for? A custom context menu? If so, could you include a simple MVP context menu (copy, paste, delete, etc.) in this PR? If not, what ideas do you have?

Context menus are meant primarily for redundancy, for computer illiterate people. Mondrian's simplistic design goes against that principle. I think right-click could actually be more useful as an alternative click for complex tools, rather than a context menu. For example, right-clicking a point with the pen tool could remove that point from the shape. Right-click could do a lot of things that alt-click does in Illustrator.

If this was the case, you would also want to add a @_rightClick method to cursor-tracking that the Tool class could take advantage of.

You can see here how tools bind to these methods. Also for reference, this is how the cursor events get forwarded to the currently selected tool.

Removing the context menu alone isn't enough to warrant a merge. I'd love to see you actually utilize right-click somehow. My vote goes to the second option - using right-click for alt-clicks. Thoughts?

[Fishrock123]

My vote also goes to the second.

This will also the alleviate control constriction if we resolve #1 the easy way.

[artursapek]

Glad you agree. Try hacking on it, get some tool to do something new with a right-click, and I'll review the code. Ask me if you can't figure something out. There are still a few spots in the codebase that are pretty confusing.

[Fishrock123]

Currently it just relies on the event endpoints to decipher if they wish to check event.which.

[artursapek]

Instead of checking e.which every time, you should add a rightClick event that tools can bind to. This is way easier to read.

[Fishrock123]

Aight.

[Fishrock123]

@artursapek Should I also add right* handlers for all 3 drag events then? Or should I just listen to e.which in the tool for now?

[Fishrock123]

@artursapek LGTY? Can squash if you'd like, but I think separated commits are more readable.

[artursapek]

This looks good, nice job navigating through the code.

I also just moved all those cursor event proxies out of the big ugly ui/ui.coffee file (probably the worst file in the codebase). They're in a separate file now (https://github.com/artursapek/mondrian/commit/028c5cff44edfec9ff598db1b818138ae1cb8017). They need to be cleaned up regardless but I'm just going to isolate them for now.

I'll merge & deploy all this after I have some more time to test the changes.

[artursapek]

After playing around with it, I think we should switch the behaviors of alt-click and right-click, because users coming from Illustrator will expect alt-click to zoom out. Right-click can be zoom 100%. I can make this change.

Also working on some other improvements to zoom that this will be merged in with, so haven't been able to get this in yet.

[Fishrock123]

Ugh, -1, but ok, if you really think that when tooltips land people can't learn a couple differences.

[artursapek]

Alt-click is more accessible than right-click to people with laptop trackpads, Wacom tablets, etc. And how would a tooltip help in this case?

In any case, all hotkeys should be customizable eventually (this sort of personalization can lead to much longer user retention).

[Fishrock123]

• Laptop trackpads: I can't think of one that can't right-click easily.
• Wacom tablets: To my knowledge all have at least one button, for this purpose. (mine has two, one for double click also)
• Touch devices: This is a different story; we need entirely different handlers for this either way.

The tooltip would simply explain what functions are available for the hovered tool, not simply its name and hotkey.

I agree that it is far less of an issue once user keybindings land, but alt-click is really not intuitive. Left click zooms in once, why would right click reset? (I see it as a sort of opposite to the left mouse button)

[artursapek]

The way I see it there are two goals:

1. Teach people the hotkeys - this is the use case for tooltips. Ideally everyone who uses an app like this will learn and use the hotkeys, because it's much more efficient than the grandma-style point-and-click interaction. To push people in that direction, we show them tooltips when they use the mouse so that they associate the hotkey with the tool and gradually start using the superior method of interaction. These tooltips should look just like the menu items: "name, hotkey"

1. Teach people advanced features - there's are times when a tool has advanced features that people can't just figure out on their own. I would argue that this case, the alternate click-to-zoom-out function, is likely something most people will just learn by playing around with the app (or already know from using similar products). For other features that are more advanced, like the Visual History, an in-depth written explanation of a feature does not belong within the app. Cluttering the app with learn-it-once-know-it-forever stuff like this is a waste of space. If this is really needed, it should be a separate guide that people can read alongside the app. But it should be considered a last resort to:
   1. Users learning by playing and discovering things.
   2. The interface explaining itself.

Ideally we can make the entire thing easy to learn by relying those two learning techniques. Everything else is a crutch.

To use the zoom tool as an example again, people always try modifier keys. That's a known pattern in computers applications at this point. What Adobe does is put a minus sign inside the magnifying glass when "Alt" is pushed down. Once you see it once, you get it. After that it's a nice little indicator that Illustrator does indeed recognize your pushing down the Alt key and the app will zoom out if you click the mouse. This is way more elegant than a tool-tip that says "Push down alt to zoom out" - that's way too heavy-handed.

For a contrived example of my philosophy, think about a chainsaw. The first time using a chainsaw can be confusing - you have to learn how to fill the gas tank, undo the safety, put on the blade, rev up the motor, etc. After that it starts to become routine. You don't carry around a manual every time you use the saw, it would just get in your way. There's still labels and warnings on the chainsaw that explain things should you forget, but you start to ignore those too as you develop muscle memory. Eventually with years of use, the labels wear off and you don't even notice because it's all second nature.

With all good tools, there is a learning stage and then there is a using stage. They overlap, but the learning stage always fades away and the using stage far outlives it. You have to design with both stages in mind.

The tooltips have to not be a crutch.

[artursapek]

And by the way, based on my experience people drag-to-zoom and reset back out to 100% far more often than zooming in and out incrementally. I know I do, it's way faster. That's another reason why I wanted right-click to reset to 100% - with a mouse I'd have access to both without moving my hand - which is way better than how it works currently where I have to reach for the "1" key to reset zoom to 100%.

Going forward, implementing some tracking of every interaction within the app could give us the concrete data to prove things like this and make the primary behaviors the primary options.

[Fishrock123]

What Adobe does is put a minus sign inside the magnifying glass when "Alt" is pushed down.

I like that idea.

The tooltips have to not be a crutch.

Dully noted.

... based on my experience people drag-to-zoom and reset back out to 100% far more ...

Yeah, I think you're right.