Crowd funding project: Marking menus for Photoshop and other software
polycounter lvl 11
Recently I was telling a buddy of mine about how I hate digging through the standard menus in some software like Photoshop. In Maya or Zbrush I am used to creating either marking menus or custom palettes that allow me to assign multiple related commands to one hotkey. This is useful for organization and also more efficient than having one command assigned to one hotkey. He mentioned that he made an attempt to address this for Illustrator and wanted to expand the Idea to work with any software. He wants to generate $1000 to hire a programmer to help with the stuff that is outside his scope of knowledge. I figured there are probably others out there like us and I might find some like minded people here. Here is his pitch:
http://www.indiegogo.com/unipie
Maybe people would like to pitch in ideas or gui designs too?
http://www.indiegogo.com/unipie
Maybe people would like to pitch in ideas or gui designs too?
Replies
http://www.ecocardio.com.br/orbit/
Check out this video: [ame="
I would pay for Marking Menus in other software, though! I imagine it could work great with tablet pc's as well, to ween yourself off a keyboard-centric workflow.
@Shader: Orbit is nice but serves a somewhat different purpose.
(Can't send key strokes for example.)
@MightyPea: Indeed sub-pie-menus are very annoying, that's
why at this point the project is aimed at accessing 4-8-16
frequently used functions (per app per hotkey).
Having said that, later on I would like to extend the system with
marking menu like functionality. I have a few ideas how to unify
blind gestures, pie and marking menus, but they will need some
experimentation.
I've also updated the documentation with a special pie menu which
acts as a "color picker" for any numeric property:
Now it's in a semi-usable state with the core features working but also having
one outstanding bug: Key combos sent to Photoshop and Illustrator are
misinterpreted. For example CTRL+G becomes CTRL+SHIFT+WHEELUP. o_O
Stuff seems to be working in other apps (Firefox, Notepad, Explorer, Directory
Opus) so the plan now is to collect software where UniPie fails, then looking for
a pattern. Hopefully I'll be able to discuss this issue with some of the
developers of those applications.
If you want to take the current build for a spin you can find it at
https://unipie.codeplex.com/releases/view/92788
Again, it only has the core features (Pie menus and combo remapping) none of
the advanced stuff like macros or visual styles.
If you find any other software where combos seem to be misinterpreted then
please let me know. Also bug reports, ideas and suggestions are welcome.
Ohhh it also stops working after I use brush in Photoshop. Shows up but doesn't register cursor.
My Documents folder?
What windows flavor are you using?
Could you describe the problems in detail? Kind of like this:
- I switch to Calculator.
- I press "A" which supposed to show a pie menu.
- The pie menu shows up but does not go away after I release "A".
- From then on UniPie stops working even in Wordpad.
http://unipie.codeplex.com/releases/view/93977
The biggest current issues are that mouse wheel is not yet supported and that your configs
will probably be incompatible with the next release so you might need to redo them.
I'm sorry I missed this discussion when it was started a decade ago, and I'm sorry that the links above are broken, but I'll add my comments now for the record.
I published a paper about pie menus in the proceedings of 1988 ACM SIGCHI conference called “An Empirical Comparison of Pie vs. Linear Menus”, in which we measured the performance of pie menus versus linear menus and found them to be 15% faster and have significantly lower error rates, and I presented pie menus at that conference and many other conferences and trade shows, and implemented them in many products, including The Sims from Maxis/Electronic Arts.
https://donhopkins.medium.com/an-empirical-comparison-of-pie-vs-linear-menus-466c6fdbba4b
I love the idea of integrating pie menus into all of the Adobe Creative Cloud products, and recently I've been evangelizing them to Adobe as a member of one of their user interface focus groups.
I'm trying to get to the bottom of why after so many decades Adobe still does not support pie menus in any of their products. I would like to hear from user interface designers and product managers at Adobe why after all these decades Adobe products still don’t support pie menus. Certainly it’s not because nobody’s heard of them or seen them before, so there must be another reason, which I would like to know.
My question for Adobe is if the code really that complex and brittle and deeply mired in technical debt and legacy decisions from decades ago, that they're technically unable to implement something as simple as pie menus, or if it is a cultural problem that makes it politically impossible to implement anything Adobe didn’t invent themselves.
Blender has them. Maya has them. The Sims has them. Here they are running on a PDP-7 at the University of Cambridge in 1967 in a CAD system called PIXIE. So why doesn’t Photoshop have them yet, in 2022? Does Adobe not employ any user interface designers who have ever heard of them, or do Adobe’s user interface designers have any convincing arguments or immovable barriers against using them? Or do Adobe’s cowardly lawyers prohibit their user interface designers from improving their products, because they’re terrified of getting sued by Autodesk because they believe their FUD?
Here are lots of other pie menu examples and citations, and there are many other high-end applications that use them like Houdini and Maya. User customizable pie menus would significantly improve all aspects of Photoshop’s user interface and workflow across the board. Menu selection is an extremely frequent operation in Photoshop, and speeding that common repetitive task up by 15% while lowering the menu selection error rate would have dramatically and measurably more impact than any number of nickle-and-dime tweaks to the Gaussian blur dialog. Especially if users could design and share their own custom task and workflow-specific pie menus, just like the happy users of Maya and Blender and many other products have been able to for decades. In comparison to so many other successful commercial products and games and open source tools with pie menus, not only Photoshop but ALL of the Creative Cloud products look and feel like they were designed in the stone age, and needlessly waste huge amounts of their user’s time.
Links:
Here is a 30 year retrospective of work I and other people have done with pie menus. Why hasn’t any of this ended up in any Adobe products? Not Invented Here Syndrome? But Adobe keeps buying companies and presumably incorporating the best ideas of those products into their own, so why has Adobe been so resistant to implementing ideas you didn’t invent themselves? Does Adobe only buy other companies like Figma to eliminate competition and innovation, then never bothers improving their own products because they’ve wiped out the competition through monopolistic anti-competitive practices, in spite of and to the detriment of their own users?
Michael Knubben's post about "Pie menus are infinitely less powerful than Marking Menus, and absolutely not the same thing" is incorrect, and he is the victim of misinformation and FUD spread by Alias employees Gordon Kurtenbach and Bill Buxton. I wish Michael had read the comment I posted on that video 10 years ago, which would have corrected his misunderstanding. I wrote:
Don Hopkins, 10 years ago: "These "typical pie menus" are not at all typical -- they're just "straw man pie menus". Typical pie menus (like the pie menus in The Sims) don't behave the way this straw man implementation demonstrates, and don't suffer from the disadvantages demonstrated here. Typical pie menus support "mouse ahead" gestures and scale independence, and it's disappointing that the authors of this video weren't aware of that, and attempt to define marking menus in terms of a straw man definition of pie menus."
It's unfortunate that Gordon Kurtenbach and Bill Buxton purposefully made such a deceptive video that lied about the definition of pie menus in order to make marking menus seem better, because he knew very well that pie menus supported both submenus and mouse ahead display pre-emption, since I told him personally in an email discussion in 1990.
Here is the email thread in which we discussed pie menus and marking menus in 1990, and I told him all about pie menus. His first email to me explicitly stated that "We are very interested in the fact that you can mouse ahead with them" which totally contradicts what he subsequently claimed in his own videos, research papers, and patent applications.
From: Gordon Kurtenbach <gordo@dgp.toronto.edu>
To: Don Hopkins <hopkins@sun.com>
Date: Fri, Nov 30, 1990, 11:41 PM
Subject: pie menus!!!!
Hi Don. I'm a Ph.D. student at University of Toronto. Bill Buxton is my supervisor. We are interested in doing some experiments with pie menus and developing some novel ways of using them. We are very interested in the fact that you can mouse ahead with them and would like to explore this feature further. SInce you are the grand implementor of some hot pie menu stuff I have a couple of questions:
1) is their any public domain code for them?
2) have you published any more papers other than the CHI Washington paper?
Thanks in advance.
Cheers
Gord
From: Don Hopkins <hopkins@sun.com>
To: Gordon Kurtenbach <gordo@dgp.toronto.edu>
Date: Dec 1, 1990, 3:44 AM
I'm glad to hear from you! The code I've written is freely redistributable without restrictions, and the idea is not patented or proprietary, and I encourage you to experiment with them and find out how to use them best! I'll send you some more stuff I've written about pie menus, and the code that implements them for NeWS, using the "Lite" toolkit. I have a very very old implementation for X10 on top of uwm, but all of the interesting features are in the NeWS code. I also have a bunch of strange mutant pie menu subclasses I implemented whenever I got weird ideas. NeWS is good that way, the crazier the idea, the more fun it is to implement!
If you want to implement them from scratch, I'd be glad to discuss some mouse tracking strategies I've developed! There are some fine points relating to correct *predictable* handling of mouse ahead, menu display supression, popping menus up at the edge of the screen and pointer warping, and other kinds of interactions. With pie menus, the important thing is how you move your hand, not how you move the cursor. Working with Bill Buxton, I'm sure you know what I mean!
If you like, give me a call at work at (415) 336-3171, any time. I'm usually here until all hours. There's too much to say to type it all in!
At Sun, I am working on TNT 2.0, an Open Look toolkit written in object oriented PostScript for NeWS. In my spare time, I have implemented pie menus for TNT, and I would like to develop them further. Would you be interested in getting a version of TNT for Open Windows when it becomes available, to evaluate and play with? The feedback we've gotten from the people testing the toolkit has been fantastic, and it will be well supported by Sun! If you are into exploratory user interface implementation, rapid prototyping, look & feel customization, interactive object oriented programming, and that kind of stuff, you'll be in paradise! For example, it would be easy to dynamically modify an abstract class in the system, so that certain interactions with certain componants would be timed and logged to a file, to gather data for an experiment.
-Don
From: Gordon Kurtenbach <gordo@dgp.toronto.edu>
To: Don Hopkins <hopkins@sun.com>
Date: Dec 10, 1990, 8:36 PM
Don: TNT sounds great and yes I would be interested. Can you comment on the accuracy of the timing we could get from it? Here's what we are investigating. I'm interested in using markings as an input technique. What I mean by markings are gestures with the mouse or stylus that leave an ink trail. Now the problem with markings is that unless you use mnemonic marking symbols its hard to remember what strange marking corresponds to what command. You may say well then use mnemonic markings. But the problem is that mnemonic markings may not always exist, may be hard to recognise and may be slow to articulate with mouse or stylus. So my approach has been to use very simple marks such as up, down, left right etc. These marks are easily to articulate and very easy to recognize. Now how do pie menus fit into this? The great things about pie menus is that for non-heirarchical ones selection is a simple gesture and this gesture matches the movement needed to make a simple mark!!! So here's the way things could work: novice's mouse down and get the pie menu because they need that amount of support. Its slow but when your a novice you just want to survive not operate at top speed. The the cool thing is that expert can mouse ahead like you've talked about but they get an ink trail so they have a better idea what they've selected without even bothering to wait for the menu to come up. Essentially the markings are a language of glyphs which are really accelerators. Furthurmore if you make a mark and keep the mouse down at the end of it a pie menu comes up so you can verify that you did the right mark. The idea here is that this will give novices a "smoother" transition to an expert user who has the menu layout memorized and can make selections without needing to look at the menu.
So in support of this stuff we are conducting an experiment to see how number of items in a menu and the layout strategy will affect the ability to articulate the gesture to select and how quickly people learn the layouts of menus and are able to "mouse ahead" which in our world is "use the mark instead of the menu".
In the future, I hope to try this stuff on hierarchical menus to create richer marking languages. Plus I'm experimenting with other novel menu gadgets where a marking can correspond to the selction movement.
Ok, hope this wets your appetite. Thanks for the info.
Gord
From: Don Hopkins <hopkins@sun.com>
To: Gordon Kurtenbach <gordo@dgp.toronto.edu>
Date: Dec 1, 1990, 3:44 AM
I think TNT can provide you with excellent timing accuracy. Events are location and time stamped, and you can respond to them in the NeWS server where they are happening. There is a global event manager, a light weight PostScript process running in the NeWS server, that provides synchronization, using a centralized "services" architecture. The global event manager catches certain events and passes them off to local event managers, who are responsible for managing objects who asked for certain classes of events. Any event that would change the input distribution, by expressing or revoking interests, or changing the canvas hierarchy, will cause the input queue to be blocked until the changes have been made and it's safe to continue event distribution. This means that the events get to where they were supposed to, and mouse ahead works very very well, even when the system is loaded and lagging behind. This architecture also saves us a whole lot of time and space (sharing interests and event managers), and makes it much easier to program an object to respond to events (because all the hard stuff is done behind the scenes by the system).
-Don
Interesting to hear! I do wish I'd read that comment, so I didn't further spread the idea that they're markedly different. Thanks for replying here, and sorry for getting back to you so late. Are you still involved in UX design these days?
For anyone interested in the topic of the thread, someone has released an amazing global Radial Menu system based on Autohotkey recently:
Windows only, but it works really well, and I've been using it in all software that doesn't natively support radial menus!