Just an idea to make the interface more "standard", consistent and faster to grasp: Whenever the contents of the desktop don't fit in the view, scroll bars would appear along its bottom and right edges (just like you scroll the time-line but don't "pan" it with the mouse). Besides, when the Pointer tool (1) is active, clicking and dragging the desktop would draw a selection box around devices rather than pan the desktop. I think it's a more "expected" behaviour. If you add modifier keys to selecting (Shift and Ctrl to add and toggle), you could get rid of the selection tool altogether. You already have the "pan" tool to pan the desktop and, if you want, you could even add an "overview" small window (a la Photoshop) to pan very quickly to different parts of the arrangement (like you already have an overview for the time-line, and it would make both time-line and desktop more alike in the ways you move around them).
Comments (10)
I get where you're coming from, but from years with working with Audiotool, I've grown accustomed to the interface, and I'm sure many others have as well.
However, this would be an interesting feature to at least give a try, all in favour of finding the most efficient workflow and workspace.
If not as a separate feature then combine some of these ideas with the current (e.g. I'd advocate for a shortcut, such as (5) or a Ctrl + some key, to enable scrolling rather than dragging, I see how it can be useful in some circumstances, particularly, in my tracks where I stack all of my synths above the main centroid, I'd be able to scroll up towards the top one more quickly than I would have using the click and drag method. (this would also implement the alternative behaviour for selecting you suggest when this option is toggled))
I do 100% agree with a small overview window, though.
That would be immensely useful, especially on large tracks, navigation would be pretty effortless then.
I know that we just get used to what we're given. I'm used to it too. But when I compare it to the behaviour of other, more mature programs or window (GUI) systems, I realize that there are widely followed standards, for a reason. They save time. Most software has a pointer mode that by default handles all selection tasks by combining different actions (click, double-click, click-drag) and modifier keys (Shift, Ctrl). There's no need to have an additional "selection" method. Also, selection behaviour is usually uniform across all areas of a given GUI.
I understand, in that case, I definitely think it'd be worth a try.
As long as horizontal scrolling is also implemented, I see how this could be more efficient.
Hmm - the audiotool workspace can definitely get very large when you work on a big project, which would make the scrollbars very small and hard to grab with the mouse.
IMO panning is the easiest option. In order to move the workspace I just have to click on any spot and drag where I want to go, I don't have to hunt for little scroll bars or use small, precise mouse movements. It's the most frictionless way.
I guess the point would be that you wouldn't have to use the scrollbars all the time, you could just toggle the scroll functionality on your mouse from zoom to pan and you could move from one spot to the next near instantaneously. In conjunction with horizontal scrolling this would be super helpful.
The idea is that when your arrangement gets too big to fit the window and you want to move around it, you have to click and drag somewhere, either to pan or to scroll. Panning only lets you move the size of one window at a time with each click and drag. It takes time. With scroll, a single click and drag lets you move anywhere you want. Scroll bars exist because they are the fastest way to move around big documents. And the point about size is relative: Lets say that the height of your window is 980 pixels and you have a monster arrangement that takes 10 windows to display at 100% zoom. Your scroll bar handle is still 98 pixels high, which isn't that hard to grab. Besides, the navigation keys of your computer keyboard (arrows, page up and down, begin and end) could also be made use of for navigating purposes in the app if you don't like dragging scroll bars (you do have them in the time-line and I don't imagine anybody wanting to get rid of them.)
@andremichelle You're right that 3D software used to be very variable in their interface models. But in my experience, that was more than two decades ago. Since Maya became a dominant package for animation and special effects, and since the then existing packages like Softimage, Alias|Wavefront and so on merged into it, and software developers (Autodesk, etc.) bought each other and unified products, the tendency has been to convergence and nearly every package (even Blender, which has a really unique interface) has adopted the "3 mouse button -> X, Y and Z axis" for transformation, for example. The idea of the time-line as a model was because, in my opinion, it follows user interface standards more closely (maybe there was a good reason to make it like that) and it's easy to work with and navigate. My point is that there's no need to reinvent the wheel. GUIs and interaction with them have been developed since to 60 at least and popularized since the 80s. In these decades, lots of options have been tested, perfected and widely adopted. We might as well take advantage of interaction standards, the same way that you take advantage of web standards.
@jordynth I definitely see where these conventions could be applied in Audiotool.
Conceptually, scrolling to navigate rather than click+dragging would cut down on unnecessary effort (more actions are required in click+dragging over just scrolling), and with audio programming, effort should be focused on the audio rather than interfacing with it.
@andremichelle Thanks for the feedback on the scrolling request, duly noted.
I would not mind a scrollable minimap-like window for navigating the desktop.