Ableton Forum

The expand/collapse arrow icons, seen throughout the Live GUI, seem to be pointing at rather pseudo-random directions in this version ... It's no biggie, but it feels odd clicking an arrow representing an expansion in a completely different direction than where it's actually going to happen.

For example, see opening and closing the browser and other screen panels, showing and hiding arrangement tracks, rack submix channels in the mixer, extra plugin parameters, and so on. The arrows point either down or right, no matter what function they are representing, and what direction the actual GUI element is going to be at.

I totally agree, I have no idea why they changed them, it looks goofy to me everytime I glance at them.

actually I think they just unified them - in the old version they all followed different logic. What they do now is what most folder trees do - like in the browser. When an item is folded it now looks like this:

> Category

and when you unfold it it looks like this

V Category
- Sub item
- Sub item
- Sub item

to me that seems logical, and indeed, some areas of the app have always been like this. And some weren't!
So now, they point in the direction that indicates the current state, rather than showing what it would be if you pressed it. Just like all the other toggle action buttons do, like those in preferences. When a button shows [off] it is off, when it shows[on] it is on. And likewise

[>] is a folded lane , and
[V] is unfolded

No way. Check out the help info view arrow in the bottom left corner, or the clip view / midi editor / chain view arrow in the bottom right corner. Or my favorite so far, the Sampler "zone" arrow.

They're simply fucked up

Angstrom wrote:[>] is a folded lane , and
[V] is unfolded

The main browser arrow is exactly the opposite.

Anstrom I think we're going to have to take this out back, the current way is dumb, you're getting a beat down.

I always thought of them as "click this to close the browser" (ie, arrow points left), "click this to view the clip lane" (ie, arrow points up). The whole folder tree methodology only works for the vertical browser, for anything else it looks stupid.

I said, IT LOOKS STUPID!

out back of the forum?
I ain't going back there!

I'm actually just biding my time until Poster shows up - he has a kind of obsession about those little buttons.

me, I just click em.

and.. cue..

Live only had 2 methods; left<>right and up<>down, which didn't tell you anything..
It was just a private Ableton convention, which made it confusing because 99% of other software doesn't use this..

I think the new icon's are how should've been years ago..
that is; following the common fold button method;
folded: preferably pointing to the right (but that depends on the situation/location)
unfolded: always pointing into the direction of the unfolded content..

Especially the track fold buttons in Arrange have confused me since day one;
just looking at them didn't tell you wheter a track is folded or not..
Up=unfolded and Down=folded? even the opposite would've made more sense..
I always had to do a 2nd check, looking at the actual track's content; do I see waves/notes? yes? unfolded then..
Sure, the thinking could be that if you'll use it long enough you'll get used to it..
But I didn't.. never.. because it was not intuitive..
And why think of an own convention when there's already one that has been there for years, for a good reason..

So yes, the arrows now point into alot of different directions,
but now I finally know wheter it's folded or not.. in a split second..

The only ones I'm still not sure about are the buttons on all devices with sidechain;
it would make more sense if they would point to the unfolded sidechain section..

I like the new way

How can you not tell if something's folded or not by looking at it?

Tarekith wrote:How can you not tell if something's folded or not by looking at it?

why then use fold buttons, with an arrow, anyway?
you could as well use a happy/sad smiley..

the arrows were sending confusing information..
especially in Arrange, with alot of tracks, and very little visual track differentiation to begin with, it was very confusing..

Poster wrote:

garyboozy wrote:i know what you mean about uniformity -the browser working one way and the track folding another way- but i've just gotten used to it and don't see it as a problem at all. the browser works as any OS file browser does, and the track automation folding and sampler zone work as, well, like the itunes play button does- while playing, it shows the pause icon; while paused, it shows the play icon.

this is not about uniformity alone,
this is about communicating wrong signals..

for sure you can bypass general accepted interaction laws and think of your own rules complemented with your own graphic language,
but Ableton has not chosen it's own, native language..
They've adopted the arrow, which in all software points towards the folded content..

thanks for the iTunes example, that's exactly what I mean;
the differentiation between the play and pause button is there because they both say very different things..
And that's the in general accepted graphic language of saying music plays or is paused..

What if Apple decided to have a picture of a performing band as the play icon,
and a picture of that same band drinking a beer backstage as the pause button?

Some rules should not be bend, even if you accept them after a while..

The plot thickens! Everyone, let's get ready to paint huge banners, with sad triangular arrows in perverse orientations, and shout slogans outside the Ableton HQ!

Poster wrote:And why think of an own convention when there's already one that has been there for years, for a good reason..

There is, most certainly, a GUI convention in which arrow icons are pointing at the actual direction where the expansion is going to take place. In my opinion, that's also the most intuitive one.

All of Live's "Audio From", "Midi From" (and similar) controls still use this logic. There's an arrow down, and you know you're going to get a vertical expansion at that location if you click it. Yep, I know they aren't actual expandable GUI panels per se, as they are menus which appear on top of the other controls - but they demonstrate the logic.

The convention of arrows denoting the direction of the expansion is a very common one, and it's often used in the case of expanding GUI panels being used in multiple directions inside the GUI - just like Live's browser, help info view and the clip/MIDI/chain view. Think about expanding and collapsing web browser panels, think about the Photoshop dock panels, Lightroom view panels, Microsoft Office expanding selection panels, numerous web interfaces - they all use arrows pointing at the actual direction of the expanding area, and for a good reason. They do this instead of an abstract "if the arrow indicates an arbitrary direction parallel to the current GUI element, there must be something closed over here"

Seriously, if you place expanding elements in your GUI and they are arranged in a uniform fashion, like a vertical column, using the more abstract "directory-tree-like" arrow notation is of course a valid design (think of the left panel of Google Earth, for example). However, when you have stuff expanding like in Live, that is, towards the right from the left, towards the left from the right, upwards from the bottom, upwards from somewhere in the middle, and so on, AND you choose to use the tree-like abstract arrow notation, AND you decide to rotate the arrows while doing so, to fit what ever relative position you might need...

That's how it is at the moment. I mean, we now have arrows pointing down, right, left, and they all mean "there's stuff collapsed over here, and it's most likely going to expand 90 degrees from the direction of this arrow." I do see the logic and know I'll soon be using it without flinching, but it WILL throw a lot of people off when they first try it.

Nokatus wrote: There is, most certainly, a GUI convention in which arrow icons are pointing at the actual direction where the expansion is going to take place. In my opinion, that's also the most intuitive one.

I don't think that's right.
I believe that the convention is - that the arrows point in the direction indicating the current state, not what will happen afterwards.

That's what I meant with my earlier statement, that they point in the direction of the opened item if they are opened and conversely.

So an opened envelope lane will have the arrow indicating opened, and a closed one indicates closed. This is the convention AFAIK ...

see here

Angstrom wrote:I believe that the convention is - that the arrows point in the direction indicating the current state, not what will happen afterwards.

In your example pictures, you show the directory tree-like arrow convention, INSIDE a panel/window. You're showing and hiding content inside a tree-like structure (layers and transform parameters). In my examples I mean cases where whole GUI panels themselves are being expanded and collapsed.