Child Association Headers suggestion

[andrewminton]

Hi Nils,

Looking at the UI as it stands, I think it's looking and feeling great. I still think that an icon/more visual prompt to edit should be considered. Will get me thinking cap on to suggest one or two things here.. I know Icons aren't really the Symphony way so it needs to fit into the current scheme of UI presentation.

The other thing that has cropped up for me is the depth issue when you have a child association which in turn has it's very own association:

We really do lose quite a bit of screen real estate when it goes deeper. What if we collapsed the UI down to a minimum for nested associations and used something similar to the below to navigate back up the tree?

Just a thought really.

[nilshoerrmann]

Something to think about.
One thing that we should consider is the fact that clicking the parent page (= the next paper in the stack) will close all nested pages. So the different sheets of paper are like breadcrumbs you can use to navigate. This will be more clear, when we finished writing the documentation.

I still think that an icon/more visual prompt to edit should be considered.

Just so we are talking about the same thing: we do have an icon. A page icon. You don't seek something more visual, you're just not convinced that the metaphore works. Right?

:)

[andrewminton]

Thanks Nils, Breadcrumbs are a good thing in this instance yes, I just feel it takes up a lot of real estate at present.

With regards to the icon, is it worth a text prompt/tooltip or something? we have remove as a block of text and edit is in the same context for applying an action to the item. the page icon feels too much like it's the instigator for drag/drop re-ordering right now.. is it worth shifting it from the edge of the item and make it clearly visible all the way around it?

Or does that look too much like a menu icon now?

[nilshoerrmann]

Personally, I have to say that I'm not fond of a drag indicator at all. We don't use it in the Symphony interface and the user already gets a drag cursor. If you have to explain to your users what the drag cursor means, you'll also have to explain to them what a drag indicator means. Additionally, if you have a drag indicator, people tend to think that that's the only area that can be used to drag, which is wrong – it works on the entire row.

So for me it's already a design compromise to have it in the interface at all.

the page icon feels too much like it's the instigator for drag/drop re-ordering right now.

It does look like this at your place, does it?

[andrewminton]

Nope...

So there in lies the problem then :) I don't see that icon at all! missing svg maybe? using Chrome on mac.

[johannahoerrmann]

A different idea: How about making the caption a link which opens the editor? Much like it works in the section overview.

[nilshoerrmann]

Ha, okay.

[andrewminton]

It's always the little things :)

[nilshoerrmann]

The thing is: it works just fine in Chrome here. Strange. It's an SVG image.
Which Chrome version do you use?

[nilshoerrmann]

And to further clarify things:
The lines you see on the left of the row is the drag indicator, that grey paper is the trigger for the page editor.

[nilshoerrmann]

Andrew, can you check, if you see the icon in other browsers?

[andrewminton]

I'll check now.

[andrewminton]

I don't see the icon in Chrome: Version 36.0.1985.125 on OSX Mavericks
I see the icon in: Firefox v30
I don't see the icon in: Safari 7.0.5 (9537.77.4)

[nilshoerrmann]

Let's move here: #17

[nilshoerrmann]

Regarding the child headers, let's consider this for version 1.1.0.

[andrewminton]

Agree.