Universal search in UI is cool, and I’m all for it, but it shouldn’t be the only/primary way of accessing tools as tool discoverability is very low. The author tries to deal with this by putting the a menu next to a search bar and putting hints in the bottom menu (which I don’t think would really work here, as raster tools are less selection-specific than 3D tools). Search fixes the speed-of-access issue, but doesn’t help discoverability very much, as users still have to hunt through highly nested menus.
Looking at the screenshots here, I don’t think you actually need search to make those menus more manageable. One screenshot of current GIMP shows a menu tree that looks like “filter->render->noise->solid noise…”. I think you could probably combine the entire noise submenu from that tree, and make it instead a segmented control on the actual “noise” dialog that chooses your type of noise. I suspect dropping the “render” level as well would also be good. “Render” is a bit of a jargon-y term in the context of graphics editing, and I don’t think it means much to most people using it. Furthermore, the top “filter” menu isn’t actually all that long, and people generally prefer wide flatter trees to narrower deeper trees. So, I’d pitch for a simpler menu that would just be “filter->noise…”. By flattening and combining, I think that menu could be made much more usable and discoverable.
Universal UI search is great, and at this point it should be present in all but the simplest applications. I first saw it introduced in Google Docs, and it's precisely for things you suspect exist, but it's not even remotely clear which menu, submenu, or dialog it's in. (Apple OS Settings is another great example of it.)
E.g., you want to apply a hanging indent in Docs? Just type "hanging" into the menu search, and it shows "Indentation options". It's smart enough to know that hanging indentation is an option within the dialog that shows up there. And the menu search seems to have a large range of synonyms, so typing "picture" brings up lots of "insert image" choices.
But it bothers me that even in Docs, almost nobody knows about menu search because it's hidden under the "Help" menu, rather than being a nice prominent rounded search box in the upper-right corner like you'd expect.
Menus are great for discoverability (so do not get rid of them), but frequently you know what an application can or cannot do (e.g. you assume a word processor can do hanging indents or watermarks), but you don't know where exactly it lurks in the menus or which tab of the settings dialog, and don't want to waste two minutes hunting for it.
It's time for a universal search box to exist in every major desktop application. Apple and Microsoft really need to take the lead here to provide standard API's and UX components for this, and it saddens me that they haven't, and continue to show no signs of interest.
macOS has had the ability to search menus for what seems like a decade. It should be a feature of the toolkit, not something apps need to implement themselves. This doesn’t extend to other UI elements (like System Prefs/Settings), but I agree that it should (and again, should be a toolkit feature).
> But it bothers me that even in Docs, almost nobody knows about menu search because it's hidden under the "Help" menu, rather than being a nice prominent rounded search box in the upper-right corner like you'd expect.
They changed it recently. Now it’s a nice prominent rounded search box in the upper-left corner.
My problem with GIMP is that there's too many ways to access controls and some controls only appear in certain menus. You've got the iconographic tool picker which has submenus on right-click for some tools. Then there's the classic menu ribbon at the top which has most things you expect. Then there's the right-click context menu inside the canvas that has a subset of all other menu items. And then you have inscrutable hotkeys. Some actions are reasonable, others are not. There's too many hotkey layers with modifier keys and some actions which should be on the same layer are not.
Then there's the escape key. Sometimes it does what you want, other times it just gives you an error ding with no other information.
The core problem with GIMP is that the interface is bad. No two ways about it, it's just bad. It needs a total redesign, but that would be unacceptable as it would alienate evryobe who has already learned it.
As an editing program, GIMP does everything you need and then some. It's fully featured and functional, just not usable.
That said, GIMP is still my only choice for photo editing. All the other options are worse in different and mostly worse ways.
I’d say it’s biggest core issue, even more that the UI, is that it’s basically harecoded to work with generic RGB. No native CMYK or good support for color management.
How do you support discoverability, sleek work areas with minimal interfaces such as search, and power users at the same time? What does that look like?
I started with rhino3d a while ago. I like that everything can be done by typing a command. By default your cursor is in a command field and everything you type instantly searches for a command. There are menu items as well. But once you get used to typing commands its so damn fast.
Yes! I also encountered this in Rhino 10+ years ago and instantly implemented in multiple online projects with great success.
What's crazy is that i'm pretty most times wasted on a computer is from "where is this setting, how do i do this" type stuff, in users ranging from experts to the elderly.
It's bizarre to me that this hasn't been implemented all over faster. Instead cloud interfaces have become even more esoteric in my opinion.
All functions on a computer should have a tiny descriptive string you can search for.
The GUI paradigm from the last 30 years in was a mistake with nested stuff just hiding in random places. CLI was a bit better when you could pipe / search etc. but for most people Universal Search is it.
There’s a huge amount of head room to improve search though. For each of the items we can add all sorts of synonyms and descriptions so that users at any level can find the tool they’re looking for.
And we can even add crude customization to the search. Gimp can easily remember the prefix-tool click pairs, so that you don’t even need to type “cropping tool”, if you type “cr” Gimp will remember which tool you clicked last time.
> So, I’d pitch for a simpler menu that would just be “filter->noise…”.
Noise being in the Filters menu never made sense to me. Noise is an input source. It's like classifying the paintbrush tool as a filter. I shouldn't be too hard on GIMP for that I guess, as Photoshop puts it under filters as well.
I'm surprised there's uncertainty about how Gimp should be redesigned. Just copy Photoshop! Select tools on the left, configure the current tool at the top, global options on the right. Affinity does this and nobody complains. Thanks to MacOS help search, we even already have the command search that this video proposes. And it has interaction hints too.
Gimp isn't more complex than Photoshop. We don't need it to reinvent drawing applications.
The thing is, Photoshop didn't win the "graphics wars" in the 90s by having a good interface. It won by having an interface that's analogous to physical photo editing and by having a bunch of the weird/fiddly things that professional need.
The best from-the-ground-up interface for a graphics program imo is that of CorelDraw, which survives as the interface to Inkscape. Rather than a craptasm of random, physical-analogue tools, you have a small number of highly functional tools giving you a wide range of options at any one point.
And yes, I'm "confusing" vector-graphics editors and bit-map editors. But imo they should be the same, the form of the image should be secondary. High film editors produce a script of editing operations to be done on the raw film. Bit-maps should also produce a sequence of operation that can be edited afterwards.
In this case, Deluxe Paint deserves a honorary mention. It's amazing the range of creations people were able to pump out using its very basic and incredibly functional interface.
This still blows my mind a bit - yes literally they should just copy Photoshop because everyone knows how to use it. Menus are fine, any complex tool has lots of menus. I have been wishing for a photoshop-like GUI frontend for GIMP for 20 years. It's not even that far off. That sounds ungrateful, and it's not meant to be - I know this is just how it is, amazing stuff under the hood and janky interfaces
I mean, linux today is full of macos GUI ripoffs and people love it - because Apple did some great UI design. I was using windows 11 recently and so many common things are complex to the typical user - e.g. making an application run at startup, anyway I'm in boomer mode so I'd better stop writing
> I have been wishing for a photoshop-like GUI frontend for GIMP for 20 years. It's not even that far off. That sounds ungrateful, and it's not meant to be - I know this is just how it is, amazing stuff under the hood and janky interfaces
They used to have a Windows build that was like this called "Gimpshop":
None of modern UIs are built the way I’d like to work with tool apps as an amateur, nonpro, jack of all trades master of none. I only use a small subset of functions. Old programs which had programmable toolbars in 98/2k+ era were the most useful in that regard. I just set these toolbars (and key bindings) up for frequent functions and was fine with it up until when it disappeared. It reappeared in windows start menu, but that’s it. Configurable UIs are obsolete and over, so we have to explore various common denominators. So that new users could still struggle with finding menu items and power users could still struggle with quick access. Because setting up your workspace went out of fashion.
I had the same experience, and searching for answers using keywords was not very effective. There are so many features that the terms I guessed were often a different concept in GIMP, leading to a bunch of irrelevant results.
I have found that ChatGPT solves this problem very well, so I don't even try searching first anymore. I can verbosely explain what I am trying to accomplish, and it tells me "that is called X in GIMP, and here is how to use it: ...".
A recent example is that the Bucket Fill tool was filling in adjacent pixels that were a slightly different color than the one I clicked on. ChatGPT told me this is called the "threshold" and how to change it to 0 so it only filled exact matches. I would have searched for something like "gimp bucket fill sensitivity" or "gimp bucket fill precision", then had to read through a forum answer or the GIMP documentation to see that term.
> I would have searched for something like "gimp bucket fill sensitivity"
And you would have seen the correct answer if you searched this instead of trying to explain it to ChatGPT.
The first result of my Kagi search for that exact query is the official GIMP documentation. It provides the answer in the snippet.
> The Threshold slider sets the level at which color weights are measured for fill boundaries. A higher setting will fill more of a multi colored image and conversely, a lower setting will fill less area.
The second result is from graphicdesign.stackexchange.com and the snippet tells you that you might want to check the anti-alias setting if you want non-softened filling. That seems relevant if you want exact color areas to be filled with the exact color you picked as well.
Overall pretty happy with the first two results, I feel that they answered the question without even clicking away from the results page or trying to explain things to ChatGPT.
Inkscape has a lot to work on as a "content creation" app, while in terms of being true to SVG, it's done a lot of things the way you'd expect.
And I think that's most of the disconnect in the UI, which the devs have gradually gotten over by adding shadow XML data in the SVG to support Inkscape features while always presenting a rendered result.
Still, the drawing tools aren't consistent about the units they use yet. There is a lot of stuff there, and some of it is just papercuts.
I found that Inkscape mostly has everything where I expect them, but maybe I just got used to it. I wish the "filters" and "extensions" menus would be better organized since they appear to be just dumping grounds for all advanced features, but I thought the core functionality of drawing shapes and curves were reasonable.
GIMP has one of the best user interfaces of all community driven open source software. I frankly can't think of any that are better, now that Firefox followed Chrome in hiding all its most important features.
UX affordances are different when the price is zero. I learned GIMP the hard way, first because of Photoshop's pricing, and second because Photoshop's UX wasn't that much cleaner when it came to doing anything outside of trivial layer operations.
GIMP does have search, just hit / and you can find any action.
The problem with search and discoverability is that search requires input from me, whereas discoverability means that the program explicitly offers its features to me. With search, I would never discover some handy new feature I wouldn't think of myself, or something that is named differently than I expect.
Hunting through a menu, while not optimal, allows me to view a 'catalog' of all the features.
Universal search is great, as is the overall command pallette idea, every app should have it
Althout the usual menu navigation mechanism should also stick around since it provides consistent invocation of a command with a sequence of keybinds (like File, Open). Fuzzy search doesn't do that since you can match something else. Key combos require too much memorization
(though it doesn't have to be the typical horizontal menu at the top, you could have a "modal" navigation mode in the same command pallette)
And to answer the question: of course it's possible, just highly unlikely
Unity 7 HUD could search the menubar of any application. I was quite good at guessing the name of the function I wanted, far better than I was at finding it in menus. It looks like MATE, XFCE and i3 still have this.
Universal Search? Like F3 in Blender? Sure! just do it...
i studied for a year advertising and marketing degree at an university and i was at the best grades on photograph and any other class that required some creative stuff. all done in Gimp... i don't know how the late game is but certainly some company wanting the proprietary .blob of your work in Photoshop lang binaries exists. but i also think that if you are highly creative, there's so much to-do with simple tools
edit: not that Gimp can't do complex stuff but i remember clear sizing the boobs of a woman once at Photoshop and having some trouble on how-to with Gimp at home...
I know you're joking about "ONLY", but actually, linear drop-down menus are just an edge case of pie menus with multiple items in only one direction: down. So you can also make drop-down, -up, -left, -right, and other direction menus with a decent pie menu editor, like the Blender pie menu editor add-on.
Pie menus are much more useful if users can edit and create their own, especially in feature-rich extensible configurable applications that different people use in different ways like Gimp and Blender.
Blender has great pie menu support, and there's a nice pie menu editor add-on, but it really needs a built-in WYSIWYG pie menu editor, supporting on-the-fly direct manipulation WYSIWYG drag-and-drop pie menu editing, like Simon Schneegans's brilliant Gnome-Pie and Fly-Pie.
By "direct manipulation WYSIWYG drag-and-drop" I mean that ideally you should be able to put any existing menu into edit mode on the fly, and edit the circular pie, linear, or hybrid layout directly by dragging items around to different slices, instead of with an indirect linear scrolling list or outline in a separate window.
You need to be able directly and immediately edit them as they will appear to the user, not as some abstract linear tree outline (or god forbid, raw xml).
>Steve Jobs Thought Pie Menus Sucked: “That sucks! That sucks! Wow, that’s neat! That sucks!”
>On October 25, 1988, I gave Steve Jobs a demo of pie menus, NeWS, UniPress Emacs and HyperTIES at the Educom conference in Washington DC. His reaction was to jump up and down, point at the screen, and yell “That sucks! That sucks! Wow, that’s neat! That sucks!”
>I tried explaining how we’d performed an experiment proving pie menus were faster than linear menus, but he insisted the liner menus in NeXT Step were the best possible menus ever.
>But who was I to rain on his parade, two weeks after the first release of NeXT Step 0.8? (Up to that time, it was the most hyped piece of vaporware ever, and doubters were wearing t-shirts saying “NeVR Step”!) Even after he went back to Apple, Steve Jobs never took a bite of Apple Pie Menus, the forbidden fruit. There’s no accounting for taste!
The ideas behind pie menus have actually been around for even longer than that, since at least 1969:
>Dedication and Thanks to:
Neil E. Wiseman, Heinz U. Lemke, John O. Hiles,
PIXIE: A New Approach to Graphical Man-Machine Communication,
Proceedings of 1969 CAD Conference Southampton
IEEE Conference Publication 51, pp. 463–471.
David Chapman, Cambridge University Library.
Remixing and Synchronization with AfterEffects by Don Hopkins.
>This film demonstrates an early graphical user interface in use. It was made in 1969 to accompany a paper entitled “PIXIE: a new approach to graphical man-machine communication” presented at the 1969 CAD Conference held in Southampton.
PIXIE ran on a PDP-7 with a Type 340 CRT vector display with a light pen, networked with the Titan at Cambridge University, and was one of the earliest examples of a network distributed gui application, developed by Neil E. Wiseman, Heinz U. Lemke, and John O. Hiles.
i'm tweaking with fly-pie (already got 2 menus that i use a lot [there's even a dedicated key when keyboard is at mouse-layer]) & i got the blender extension too...
i think there's so much potential to trackball gestures. have you thought about multiple commands at the same direction based on distance? (could be useful for setting the volume/brightness, for example)
Readit News
Looking at the screenshots here, I don’t think you actually need search to make those menus more manageable. One screenshot of current GIMP shows a menu tree that looks like “filter->render->noise->solid noise…”. I think you could probably combine the entire noise submenu from that tree, and make it instead a segmented control on the actual “noise” dialog that chooses your type of noise. I suspect dropping the “render” level as well would also be good. “Render” is a bit of a jargon-y term in the context of graphics editing, and I don’t think it means much to most people using it. Furthermore, the top “filter” menu isn’t actually all that long, and people generally prefer wide flatter trees to narrower deeper trees. So, I’d pitch for a simpler menu that would just be “filter->noise…”. By flattening and combining, I think that menu could be made much more usable and discoverable.
E.g., you want to apply a hanging indent in Docs? Just type "hanging" into the menu search, and it shows "Indentation options". It's smart enough to know that hanging indentation is an option within the dialog that shows up there. And the menu search seems to have a large range of synonyms, so typing "picture" brings up lots of "insert image" choices.
But it bothers me that even in Docs, almost nobody knows about menu search because it's hidden under the "Help" menu, rather than being a nice prominent rounded search box in the upper-right corner like you'd expect.
Menus are great for discoverability (so do not get rid of them), but frequently you know what an application can or cannot do (e.g. you assume a word processor can do hanging indents or watermarks), but you don't know where exactly it lurks in the menus or which tab of the settings dialog, and don't want to waste two minutes hunting for it.
It's time for a universal search box to exist in every major desktop application. Apple and Microsoft really need to take the lead here to provide standard API's and UX components for this, and it saddens me that they haven't, and continue to show no signs of interest.
Gnome turned out to be a poorly thought-out opinionated mess, learning all the wrong lessons from Apple's work.
They changed it recently. Now it’s a nice prominent rounded search box in the upper-left corner.
Menus in Qt and GTK apps can be exported over D-Bus, allowing for desktop environments, or 3rd party HUDs, to implement menu search bars, as well.
Then there's the escape key. Sometimes it does what you want, other times it just gives you an error ding with no other information.
The core problem with GIMP is that the interface is bad. No two ways about it, it's just bad. It needs a total redesign, but that would be unacceptable as it would alienate evryobe who has already learned it.
As an editing program, GIMP does everything you need and then some. It's fully featured and functional, just not usable.
That said, GIMP is still my only choice for photo editing. All the other options are worse in different and mostly worse ways.
This is the core point made in the article.
What's crazy is that i'm pretty most times wasted on a computer is from "where is this setting, how do i do this" type stuff, in users ranging from experts to the elderly.
It's bizarre to me that this hasn't been implemented all over faster. Instead cloud interfaces have become even more esoteric in my opinion.
All functions on a computer should have a tiny descriptive string you can search for.
The GUI paradigm from the last 30 years in was a mistake with nested stuff just hiding in random places. CLI was a bit better when you could pipe / search etc. but for most people Universal Search is it.
And we can even add crude customization to the search. Gimp can easily remember the prefix-tool click pairs, so that you don’t even need to type “cropping tool”, if you type “cr” Gimp will remember which tool you clicked last time.
Noise being in the Filters menu never made sense to me. Noise is an input source. It's like classifying the paintbrush tool as a filter. I shouldn't be too hard on GIMP for that I guess, as Photoshop puts it under filters as well.
Gimp isn't more complex than Photoshop. We don't need it to reinvent drawing applications.
The best from-the-ground-up interface for a graphics program imo is that of CorelDraw, which survives as the interface to Inkscape. Rather than a craptasm of random, physical-analogue tools, you have a small number of highly functional tools giving you a wide range of options at any one point.
And yes, I'm "confusing" vector-graphics editors and bit-map editors. But imo they should be the same, the form of the image should be secondary. High film editors produce a script of editing operations to be done on the raw film. Bit-maps should also produce a sequence of operation that can be edited afterwards.
https://www.pugi.cafe/uploads/db4664/original/2X/3/3f7a5d40e...
I mean, linux today is full of macos GUI ripoffs and people love it - because Apple did some great UI design. I was using windows 11 recently and so many common things are complex to the typical user - e.g. making an application run at startup, anyway I'm in boomer mode so I'd better stop writing
except new users.
you're part of a self-selecting population.
Personally I think UI experimentation is awesome, because we might end up with an interface usable on modern hardware.
They used to have a Windows build that was like this called "Gimpshop":
https://en.wikipedia.org/wiki/GIMPshop
I mean, that's how I feel using the GIMP menus. I never know where anything is, and my first guess is usually wrong.
I had the same experience, and searching for answers using keywords was not very effective. There are so many features that the terms I guessed were often a different concept in GIMP, leading to a bunch of irrelevant results.
I have found that ChatGPT solves this problem very well, so I don't even try searching first anymore. I can verbosely explain what I am trying to accomplish, and it tells me "that is called X in GIMP, and here is how to use it: ...".
A recent example is that the Bucket Fill tool was filling in adjacent pixels that were a slightly different color than the one I clicked on. ChatGPT told me this is called the "threshold" and how to change it to 0 so it only filled exact matches. I would have searched for something like "gimp bucket fill sensitivity" or "gimp bucket fill precision", then had to read through a forum answer or the GIMP documentation to see that term.
And you would have seen the correct answer if you searched this instead of trying to explain it to ChatGPT.
The first result of my Kagi search for that exact query is the official GIMP documentation. It provides the answer in the snippet.
> The Threshold slider sets the level at which color weights are measured for fill boundaries. A higher setting will fill more of a multi colored image and conversely, a lower setting will fill less area.
The second result is from graphicdesign.stackexchange.com and the snippet tells you that you might want to check the anti-alias setting if you want non-softened filling. That seems relevant if you want exact color areas to be filled with the exact color you picked as well.
Overall pretty happy with the first two results, I feel that they answered the question without even clicking away from the results page or trying to explain things to ChatGPT.
ChatGPT didn't tell you. It scrapped an answer off a forum and regurgitated that to you after applying a language transform. It's second result on DDG for "gimp fill tool border" -- https://graphicdesign.stackexchange.com/questions/42621/hard....
And I think that's most of the disconnect in the UI, which the devs have gradually gotten over by adding shadow XML data in the SVG to support Inkscape features while always presenting a rendered result.
Still, the drawing tools aren't consistent about the units they use yet. There is a lot of stuff there, and some of it is just papercuts.
Anyone who wants to get rid of it is a bad developer and a bad person.
Six-year-old Reddit thread: https://www.reddit.com/r/GIMP/comments/7esx08/even_with_late...
I don't think it's fixed yet.
Please don't do this. You know that isn't true.
If someone wants menus in a pop up box, you can simply hide the menu bar until the user presses Alt (or F12 depending on your OS's convention).
Inventing an entire new weird system for pure novelty while saying "fuck you" to accessibility for disabled people... is just not okay behavior.
- can't search
- don't have 100% functionality
The problem with search and discoverability is that search requires input from me, whereas discoverability means that the program explicitly offers its features to me. With search, I would never discover some handy new feature I wouldn't think of myself, or something that is named differently than I expect.
Hunting through a menu, while not optimal, allows me to view a 'catalog' of all the features.
Althout the usual menu navigation mechanism should also stick around since it provides consistent invocation of a command with a sequence of keybinds (like File, Open). Fuzzy search doesn't do that since you can match something else. Key combos require too much memorization
(though it doesn't have to be the typical horizontal menu at the top, you could have a "modal" navigation mode in the same command pallette)
And to answer the question: of course it's possible, just highly unlikely
https://github.com/ubuntu-mate/mate-hud
https://jamcnaughton.com/2015/10/19/hud-for-xubuntu/#jp-caro...
Here some more screenshots for the uninitiated (with search used on GIMP in the first two screenshots): https://imgur.com/a/5XlgTO3
And the official docs: https://wiki.ubuntu.com/Unity/HUD
Universal Search? Like F3 in Blender? Sure! just do it...
i studied for a year advertising and marketing degree at an university and i was at the best grades on photograph and any other class that required some creative stuff. all done in Gimp... i don't know how the late game is but certainly some company wanting the proprietary .blob of your work in Photoshop lang binaries exists. but i also think that if you are highly creative, there's so much to-do with simple tools
edit: not that Gimp can't do complex stuff but i remember clear sizing the boobs of a woman once at Photoshop and having some trouble on how-to with Gimp at home...
I know you're joking about "ONLY", but actually, linear drop-down menus are just an edge case of pie menus with multiple items in only one direction: down. So you can also make drop-down, -up, -left, -right, and other direction menus with a decent pie menu editor, like the Blender pie menu editor add-on.
Pie menus are much more useful if users can edit and create their own, especially in feature-rich extensible configurable applications that different people use in different ways like Gimp and Blender.
Blender has great pie menu support, and there's a nice pie menu editor add-on, but it really needs a built-in WYSIWYG pie menu editor, supporting on-the-fly direct manipulation WYSIWYG drag-and-drop pie menu editing, like Simon Schneegans's brilliant Gnome-Pie and Fly-Pie.
By "direct manipulation WYSIWYG drag-and-drop" I mean that ideally you should be able to put any existing menu into edit mode on the fly, and edit the circular pie, linear, or hybrid layout directly by dragging items around to different slices, instead of with an indirect linear scrolling list or outline in a separate window.
You need to be able directly and immediately edit them as they will appear to the user, not as some abstract linear tree outline (or god forbid, raw xml).
Pie Menu Development for Blender:
https://devtalk.blender.org/t/pie-menu-development-for-blend...
Blender Pie Menu Editor:
https://blendermarket.com/products/pie-menu-editor
Gnome-Pie (wikipedia):
https://en.wikipedia.org/wiki/Gnome-Pie
Gnome-Pie (github):
https://schneegans.github.io/gnome-pie
Gnome-Pie 0.6.1:
https://vimeo.com/125339537
Fly-Pie 7: GNOME Shell 40+ and a new WYSIWYG Menu Editor!
https://www.youtube.com/watch?v=sRT3O9-H5Xs
Fly-Pie 10: A new Clipboard Menu, proper touch support & much more!
https://www.youtube.com/watch?v=BGXtckqhEIk
And Simon's new project, Kando:
Kando - An Open Source, Cross-Platform Pie Menu:
https://www.youtube.com/watch?v=ZTdfnUDMO9k
Follow and support the project on Ko-Fi:
https://ko-fi.com/schneegans
Kando on GitHub:
https://github.com/kando-menu/kando
I also love the beautiful Trace and Coral menus he designed for his Bachelor thesis 11 years ago:
https://schneegans.github.io/news/2012/10/10/bachelor-thesis
The Trace-Menu:
https://vimeo.com/51073078
The Coral-Menu:
https://vimeo.com/51072812
More of his great stuff:
https://schneegans.github.io/
A retrospective of my 35 years of work with pie menus:
Pie Menus: A 30 Year Retrospective (2018):
https://donhopkins.medium.com/pie-menus-936fed383ff1
>Steve Jobs Thought Pie Menus Sucked: “That sucks! That sucks! Wow, that’s neat! That sucks!”
>On October 25, 1988, I gave Steve Jobs a demo of pie menus, NeWS, UniPress Emacs and HyperTIES at the Educom conference in Washington DC. His reaction was to jump up and down, point at the screen, and yell “That sucks! That sucks! Wow, that’s neat! That sucks!”
>I tried explaining how we’d performed an experiment proving pie menus were faster than linear menus, but he insisted the liner menus in NeXT Step were the best possible menus ever.
>But who was I to rain on his parade, two weeks after the first release of NeXT Step 0.8? (Up to that time, it was the most hyped piece of vaporware ever, and doubters were wearing t-shirts saying “NeVR Step”!) Even after he went back to Apple, Steve Jobs never took a bite of Apple Pie Menus, the forbidden fruit. There’s no accounting for taste!
The ideas behind pie menus have actually been around for even longer than that, since at least 1969:
Flight of the PIXIE - Yuja Wang:
https://www.youtube.com/watch?v=jDrqR9XssJI
>Dedication and Thanks to: Neil E. Wiseman, Heinz U. Lemke, John O. Hiles, PIXIE: A New Approach to Graphical Man-Machine Communication, Proceedings of 1969 CAD Conference Southampton IEEE Conference Publication 51, pp. 463–471. David Chapman, Cambridge University Library. Remixing and Synchronization with AfterEffects by Don Hopkins.
>This film demonstrates an early graphical user interface in use. It was made in 1969 to accompany a paper entitled “PIXIE: a new approach to graphical man-machine communication” presented at the 1969 CAD Conference held in Southampton.
https://www.cl.cam.ac.uk/library/archives.html
PIXIE ran on a PDP-7 with a Type 340 CRT vector display with a light pen, networked with the Titan at Cambridge University, and was one of the earliest examples of a network distributed gui application, developed by Neil E. Wiseman, Heinz U. Lemke, and John O. Hiles.
https://www.cl.cam.ac.uk/research/rainbow/people/neilw.html
https://en.wikipedia.org/wiki/Titan_(1963_computer)
https://en.wikipedia.org/wiki/PDP-7
David S H Rosenthal: Kids Today Have No Idea:
https://blog.dshr.org/2018/11/kids-today-have-no-idea.html
i think there's so much potential to trackball gestures. have you thought about multiple commands at the same direction based on distance? (could be useful for setting the volume/brightness, for example)