UI: Headline Markup #799

Closed
nilshoerrmann opened this Issue Oct 4, 2011 · 104 comments

Comments

Projects
None yet
7 participants
@nilshoerrmann
Owner

nilshoerrmann commented Oct 4, 2011

This issue summarises the decisions of the UI discussion at the Symposium in Cologne.

The markup of the h2 at the top of the backend should be changed in 2.4, Symphony 2.3 should prepare everything for that markup change (deprecate the old one, presenting the new one)

@ghost ghost assigned nickdunn Oct 4, 2011

@designermonkey

This comment has been minimized.

Show comment Hide comment
@designermonkey

designermonkey Oct 4, 2011

Owner

This is a little vague for those that weren't involved. Can you give a little more info on what this is about?

Thankies!

Owner

designermonkey commented Oct 4, 2011

This is a little vague for those that weren't involved. Can you give a little more info on what this is about?

Thankies!

@nilshoerrmann

This comment has been minimized.

Show comment Hide comment
@nilshoerrmann

nilshoerrmann Oct 4, 2011

Owner

Sure. The idea is to make the current h2 (the headline displaying section and entry titles) more semantic: it currently contains the buttons on the right as well and the hierarchy is not that clear between h1 and h2. So we'd like to add a wrapping div containing the headline and the buttons that can be used for the new Drawer plugin that will be used for filter interfaces (more on that in another issue soon).

The idea is to not change the markup in 2.3 yet but to deprecate the current implementation and publish the new markup as an information to developers with the release of 2.3. 2.4 will then introduce the new markup and remove the old one.

Does that help?

Owner

nilshoerrmann commented Oct 4, 2011

Sure. The idea is to make the current h2 (the headline displaying section and entry titles) more semantic: it currently contains the buttons on the right as well and the hierarchy is not that clear between h1 and h2. So we'd like to add a wrapping div containing the headline and the buttons that can be used for the new Drawer plugin that will be used for filter interfaces (more on that in another issue soon).

The idea is to not change the markup in 2.3 yet but to deprecate the current implementation and publish the new markup as an information to developers with the release of 2.3. 2.4 will then introduce the new markup and remove the old one.

Does that help?

@designermonkey

This comment has been minimized.

Show comment Hide comment
@designermonkey

designermonkey Oct 4, 2011

Owner

Yes, I understand now, and agree. :o)

Owner

designermonkey commented Oct 4, 2011

Yes, I understand now, and agree. :o)

@DavidOliver

This comment has been minimized.

Show comment Hide comment
@DavidOliver

DavidOliver Oct 4, 2011

Member

It looks like the backend is already using HTML5, so maybe this preparation in 2.3 might be a good time to also look at including the header and footer tags (as opposed to just divs with those ids). It wouldn't make much odds either way for most users, but if it doesn't hurt anyone it might conceivably help certain screen readers regarding accessibility, perhaps more so in the future.

Member

DavidOliver commented Oct 4, 2011

It looks like the backend is already using HTML5, so maybe this preparation in 2.3 might be a good time to also look at including the header and footer tags (as opposed to just divs with those ids). It wouldn't make much odds either way for most users, but if it doesn't hurt anyone it might conceivably help certain screen readers regarding accessibility, perhaps more so in the future.

@nilshoerrmann

This comment has been minimized.

Show comment Hide comment
@nilshoerrmann

nilshoerrmann Oct 4, 2011

Owner

The idea was to not change the backend markup drastically – and this is a quite huge change. So I'm not sure about this idea.

Owner

nilshoerrmann commented Oct 4, 2011

The idea was to not change the backend markup drastically – and this is a quite huge change. So I'm not sure about this idea.

@designermonkey

This comment has been minimized.

Show comment Hide comment
@designermonkey

designermonkey Oct 4, 2011

Owner

This is more of a 2.4 idea, and worth considering for then.

Question: is the footer removal due for 2.3?

Owner

designermonkey commented Oct 4, 2011

This is more of a 2.4 idea, and worth considering for then.

Question: is the footer removal due for 2.3?

@nilshoerrmann

This comment has been minimized.

Show comment Hide comment
@nilshoerrmann

nilshoerrmann Oct 4, 2011

Owner

Yes, I thought so. Otherwise the navigation changes won't make sense.

(I hear you saying: "Why don't we do all changes now?")

Owner

nilshoerrmann commented Oct 4, 2011

Yes, I thought so. Otherwise the navigation changes won't make sense.

(I hear you saying: "Why don't we do all changes now?")

@DavidOliver

This comment has been minimized.

Show comment Hide comment
@DavidOliver

DavidOliver Oct 4, 2011

Member

@nilshoerrmann, I've had a quick look at the markup and styling of the header and footer, and I don't think it would have any impact on the styling. It could be as simple as wrapping what is now the header div in a header tag (if the footer is going), so if you think it would be a good thing to do in general I'd recommend thinking about doing it at the same time as you change other semantics of the backend. But in reality I don't see it actually making much difference to (m)any users.

Member

DavidOliver commented Oct 4, 2011

@nilshoerrmann, I've had a quick look at the markup and styling of the header and footer, and I don't think it would have any impact on the styling. It could be as simple as wrapping what is now the header div in a header tag (if the footer is going), so if you think it would be a good thing to do in general I'd recommend thinking about doing it at the same time as you change other semantics of the backend. But in reality I don't see it actually making much difference to (m)any users.

@nilshoerrmann

This comment has been minimized.

Show comment Hide comment
@nilshoerrmann

nilshoerrmann Oct 4, 2011

Owner

It's not about the styling, it's about extensions that rely on the current markup to add other UI elements on the fly.

Owner

nilshoerrmann commented Oct 4, 2011

It's not about the styling, it's about extensions that rely on the current markup to add other UI elements on the fly.

@DavidOliver

This comment has been minimized.

Show comment Hide comment
@DavidOliver

DavidOliver Oct 4, 2011

Member

I wondered about that - so some extensions use the header?

Member

DavidOliver commented Oct 4, 2011

I wondered about that - so some extensions use the header?

@brendo

This comment has been minimized.

Show comment Hide comment
@brendo

brendo Oct 5, 2011

Owner

Is it worthwhile finding those extensions that use the Header markup and chatting with the Authors to ensure a smooth transition to 2.3? The less cruft/old stuff in the core the better, and we are doing a major release :)

Bluntly, most extension developers are going to have to update their extension for 2.3 anyway ($this->_Parent is gone, jQuery is updated to 1.6.4 - hopefully 1.7.., new extension metadata etc.), so I don't think it's that big of a problem.

Owner

brendo commented Oct 5, 2011

Is it worthwhile finding those extensions that use the Header markup and chatting with the Authors to ensure a smooth transition to 2.3? The less cruft/old stuff in the core the better, and we are doing a major release :)

Bluntly, most extension developers are going to have to update their extension for 2.3 anyway ($this->_Parent is gone, jQuery is updated to 1.6.4 - hopefully 1.7.., new extension metadata etc.), so I don't think it's that big of a problem.

@nilshoerrmann

This comment has been minimized.

Show comment Hide comment
@nilshoerrmann

nilshoerrmann Oct 5, 2011

Owner

So you say we should just break the markup compatibility (again) now?

Owner

nilshoerrmann commented Oct 5, 2011

So you say we should just break the markup compatibility (again) now?

@brendo

This comment has been minimized.

Show comment Hide comment
@brendo

brendo Oct 5, 2011

Owner

Yes.

When did we break it in the first place?

I just feel it's only the Header markup, so it's not going to affect the majority of extensions anyway (but that I mean field extensions).

Do we have a list of extensions that will be affected or is it hypothetical?

Owner

brendo commented Oct 5, 2011

Yes.

When did we break it in the first place?

I just feel it's only the Header markup, so it's not going to affect the majority of extensions anyway (but that I mean field extensions).

Do we have a list of extensions that will be affected or is it hypothetical?

@nilshoerrmann

This comment has been minimized.

Show comment Hide comment
@nilshoerrmann

nilshoerrmann Oct 5, 2011

Owner

Keep in mind that the main point of this ussue is to change headlines and headline structure. I'm not sure if these should be changed without notification and so I'm not sure about the other changes. The conclusion in Cologne was to publish the desired future markup as a preview for developers alongside 2.3 but to first implement it in 2.4.

The last time we broke markup support without notification was 2.1. The problem is that I guess most extensions relying on the markup are not published publicly because they were made for special client sites. So we don't have numbers.

That said, I would love to change things now but I'm not sure if it was bad practice. How do frameworks like jQuery handle this kind of fundamental implementation changes?

Owner

nilshoerrmann commented Oct 5, 2011

Keep in mind that the main point of this ussue is to change headlines and headline structure. I'm not sure if these should be changed without notification and so I'm not sure about the other changes. The conclusion in Cologne was to publish the desired future markup as a preview for developers alongside 2.3 but to first implement it in 2.4.

The last time we broke markup support without notification was 2.1. The problem is that I guess most extensions relying on the markup are not published publicly because they were made for special client sites. So we don't have numbers.

That said, I would love to change things now but I'm not sure if it was bad practice. How do frameworks like jQuery handle this kind of fundamental implementation changes?

@brendo

This comment has been minimized.

Show comment Hide comment
@brendo

brendo Oct 5, 2011

Owner

How do frameworks like jQuery handle this kind of fundamental implementation changes?

Through beta's and RC's. Symphony 2.3 isn't launched yet, not even a beta, so we are pretty flexible at the moment.

Again, how many extensions will this affect? That's the single biggest thing that should decide if this is going to be deprecated or just fixed. If it's going to be break 100 extensions, deprecate, if it's going to break 10, just do it. We have Dev Notes and can make noise/contact extension developers directly so they can update their extensions.

Owner

brendo commented Oct 5, 2011

How do frameworks like jQuery handle this kind of fundamental implementation changes?

Through beta's and RC's. Symphony 2.3 isn't launched yet, not even a beta, so we are pretty flexible at the moment.

Again, how many extensions will this affect? That's the single biggest thing that should decide if this is going to be deprecated or just fixed. If it's going to be break 100 extensions, deprecate, if it's going to break 10, just do it. We have Dev Notes and can make noise/contact extension developers directly so they can update their extensions.

@nilshoerrmann

This comment has been minimized.

Show comment Hide comment
@nilshoerrmann

nilshoerrmann Oct 5, 2011

Owner

@nickdunn: Mr Dunn, what do you think?

Owner

nilshoerrmann commented Oct 5, 2011

@nickdunn: Mr Dunn, what do you think?

@DavidOliver

This comment has been minimized.

Show comment Hide comment
@DavidOliver

DavidOliver Oct 5, 2011

Member

Just to clarify the HTML5 header tag part, the safest way to change might be from:

<div id="header">
    <h1>....</h1>
    <ul>....</ul>
</div>

to

<header>
    <div id="header">
        <h1>....</h1>
        <nav>
            <ul>....</ul>
        </nav>
    </div>
</header>

(Note: optional nav tag included - another non-essential HTML5 tag that theoretically improves semantics in the header area.)

The div#header only contains the h1 and nav (not the h2 which I expect more extensions do use). So I imagine it wouldn't affect many extensions at all?

Again, while header and nav might be nice to have at some point, I don't think including them would actually benefit (m)any users, so I wouldn't say they are an important/urgent inclusion. But if it is safe to do so, then it would be a good thing to do with a view to future browsers that may actually do something useful with those tags for users.

Member

DavidOliver commented Oct 5, 2011

Just to clarify the HTML5 header tag part, the safest way to change might be from:

<div id="header">
    <h1>....</h1>
    <ul>....</ul>
</div>

to

<header>
    <div id="header">
        <h1>....</h1>
        <nav>
            <ul>....</ul>
        </nav>
    </div>
</header>

(Note: optional nav tag included - another non-essential HTML5 tag that theoretically improves semantics in the header area.)

The div#header only contains the h1 and nav (not the h2 which I expect more extensions do use). So I imagine it wouldn't affect many extensions at all?

Again, while header and nav might be nice to have at some point, I don't think including them would actually benefit (m)any users, so I wouldn't say they are an important/urgent inclusion. But if it is safe to do so, then it would be a good thing to do with a view to future browsers that may actually do something useful with those tags for users.

@nickdunn

This comment has been minimized.

Show comment Hide comment
@nickdunn

nickdunn Oct 5, 2011

Contributor

Thanks David, this looks like a good suggestion to me.

[brendan] Do we have a list of extensions that will be affected or is it hypothetical?

For definite:

These extensions hook for the presence of an h2 and append their shit around it:

  • Publish Filtering
  • Publish Tabs
  • Order Entries

These extensions rely on specific markup to modify the view with CSS

  • Subsection Manager (CSS hiding?)
  • Modal Editing (not fully released, minor extension)
  • Minimal Backend

However because Symphony bastardises the h2 by appending the "Create New" button into the heading directly, any other extensions that add buttons will need amending. More importantly, any extension that implements its own buttons or backend content pages will need amending. These include:

  • Dashboard
  • Search Index
  • XML Importer
  • Import/Export CSV
  • Backend Views
  • Tracker
  • Email Template Manager
  • Email Template Filter
  • Publish Shortcuts
  • Author Roles
  • Documenter

I'm sure there are more if we search hard enough.

Changing the order of this heading markup isn't too bad — pages that use the appendSubheading method (which I'm optimistically guessing that 100% do) don't care if we add a wrapper or change the position of the heading in the DOM (or even if it's an H1 or an H2). So the two problems that exist:

  1. The selector for this area will change. The few that use this with JavaScript will need to be updated regardless. Not a massive issue as the three I know of are mine anyway. (Oops.)
  2. Buttons really shouldn't be appended to the heading itself, but this is how all extensions do it. I really think we shouldn't break backwards compatibility for this, as some of the biggest extensions use this, and will be a pain to upgrade.

That is not to say we shouldn't try and fix this. Buttons should not be appended to the heading, and so in the core they should not be. It should set the example. But we need to ensure that the existing method (h2 > a.button) still works, or doesn't break extensions horribly. We can then fully deprecate in a future version.

To this end, we need to figure out what the new markup is going to be for this page title/buttons/drawer area, then add new methods similar to appendSubheading for appending buttons.

Contributor

nickdunn commented Oct 5, 2011

Thanks David, this looks like a good suggestion to me.

[brendan] Do we have a list of extensions that will be affected or is it hypothetical?

For definite:

These extensions hook for the presence of an h2 and append their shit around it:

  • Publish Filtering
  • Publish Tabs
  • Order Entries

These extensions rely on specific markup to modify the view with CSS

  • Subsection Manager (CSS hiding?)
  • Modal Editing (not fully released, minor extension)
  • Minimal Backend

However because Symphony bastardises the h2 by appending the "Create New" button into the heading directly, any other extensions that add buttons will need amending. More importantly, any extension that implements its own buttons or backend content pages will need amending. These include:

  • Dashboard
  • Search Index
  • XML Importer
  • Import/Export CSV
  • Backend Views
  • Tracker
  • Email Template Manager
  • Email Template Filter
  • Publish Shortcuts
  • Author Roles
  • Documenter

I'm sure there are more if we search hard enough.

Changing the order of this heading markup isn't too bad — pages that use the appendSubheading method (which I'm optimistically guessing that 100% do) don't care if we add a wrapper or change the position of the heading in the DOM (or even if it's an H1 or an H2). So the two problems that exist:

  1. The selector for this area will change. The few that use this with JavaScript will need to be updated regardless. Not a massive issue as the three I know of are mine anyway. (Oops.)
  2. Buttons really shouldn't be appended to the heading itself, but this is how all extensions do it. I really think we shouldn't break backwards compatibility for this, as some of the biggest extensions use this, and will be a pain to upgrade.

That is not to say we shouldn't try and fix this. Buttons should not be appended to the heading, and so in the core they should not be. It should set the example. But we need to ensure that the existing method (h2 > a.button) still works, or doesn't break extensions horribly. We can then fully deprecate in a future version.

To this end, we need to figure out what the new markup is going to be for this page title/buttons/drawer area, then add new methods similar to appendSubheading for appending buttons.

@nickdunn

This comment has been minimized.

Show comment Hide comment
@nickdunn

nickdunn Oct 5, 2011

Contributor

Also forgot to say that extensions implement their breadcrumbs directly into the H2. We've got suggested markup for this elsewhere.

Contributor

nickdunn commented Oct 5, 2011

Also forgot to say that extensions implement their breadcrumbs directly into the H2. We've got suggested markup for this elsewhere.

@nickdunn

This comment has been minimized.

Show comment Hide comment
@nickdunn

nickdunn Oct 5, 2011

Contributor

Something like:

<div id="wrapper">

    <header id="header">
        <span>Site Name</span>
        <nav class="content">
            <ul>...</ul>
        </nav>
        <nav class="structure">
            <ul>...</ul>
        </nav>
    </header>

    <div id="context">
        // if no breadcrumb, no list, just an h1
        <ul class="breadcrumb">
            <li><a href="#">Parent 1</a></li>
            <li><a href="#">Parent2 </a></li>
            <li><h1>Page Title</h1></li>
        </ul>
        <ul class="actions">...</ul>
        // drawers would be added here
    </div>

    <div id="contents">
        // page body (table or form)
    </div>

    // #footer removed

</div>
Contributor

nickdunn commented Oct 5, 2011

Something like:

<div id="wrapper">

    <header id="header">
        <span>Site Name</span>
        <nav class="content">
            <ul>...</ul>
        </nav>
        <nav class="structure">
            <ul>...</ul>
        </nav>
    </header>

    <div id="context">
        // if no breadcrumb, no list, just an h1
        <ul class="breadcrumb">
            <li><a href="#">Parent 1</a></li>
            <li><a href="#">Parent2 </a></li>
            <li><h1>Page Title</h1></li>
        </ul>
        <ul class="actions">...</ul>
        // drawers would be added here
    </div>

    <div id="contents">
        // page body (table or form)
    </div>

    // #footer removed

</div>
@DavidOliver

This comment has been minimized.

Show comment Hide comment
@DavidOliver

DavidOliver Oct 5, 2011

Member

Just in case anyone hasn't already come across it, this is useful for checking the structural outline of HTML5 markup: http://gsnedders.html5.org/outliner/

("Untitled Section" is okay if it's a nav)

Member

DavidOliver commented Oct 5, 2011

Just in case anyone hasn't already come across it, this is useful for checking the structural outline of HTML5 markup: http://gsnedders.html5.org/outliner/

("Untitled Section" is okay if it's a nav)

@nilshoerrmann

This comment has been minimized.

Show comment Hide comment
@nilshoerrmann

nilshoerrmann Oct 5, 2011

Owner

@nickdunn: Are you sure about using a span for the page title?

Owner

nilshoerrmann commented Oct 5, 2011

@nickdunn: Are you sure about using a span for the page title?

@nickdunn

This comment has been minimized.

Show comment Hide comment
@nickdunn

nickdunn Oct 5, 2011

Contributor

I consider it relatively un-semantic to the rest of the page. What would you suggest?

Contributor

nickdunn commented Oct 5, 2011

I consider it relatively un-semantic to the rest of the page. What would you suggest?

@nilshoerrmann

This comment has been minimized.

Show comment Hide comment
@nilshoerrmann

nilshoerrmann Oct 5, 2011

Owner

I'll have to think about it for a moment, I guess, but it looks a bit strange to me (in a hierarchical sense). But maybe this (again) reflects that we both value the importance of the page title differently :)

Owner

nilshoerrmann commented Oct 5, 2011

I'll have to think about it for a moment, I guess, but it looks a bit strange to me (in a hierarchical sense). But maybe this (again) reflects that we both value the importance of the page title differently :)

@designermonkey

This comment has been minimized.

Show comment Hide comment
@designermonkey

designermonkey Oct 5, 2011

Owner

I'm going to chime in here...

The page title of an 'application' interface doesn't need to follow the same constraints of a 'website' interface. We don't need to worry so much about the SEO benefit of semantics, yes it wold be nice to be fully 'website' semantic, but it doesn't really matter in the long run.

Either way I'd be happy, but it isn't a big deal at all.

Owner

designermonkey commented Oct 5, 2011

I'm going to chime in here...

The page title of an 'application' interface doesn't need to follow the same constraints of a 'website' interface. We don't need to worry so much about the SEO benefit of semantics, yes it wold be nice to be fully 'website' semantic, but it doesn't really matter in the long run.

Either way I'd be happy, but it isn't a big deal at all.

@nickdunn

This comment has been minimized.

Show comment Hide comment
@nickdunn

nickdunn Oct 5, 2011

Contributor

Ditto, I'm not fussed what it is. Even retaining it as an H1 doesn't bother me that much so let's not spend too long on this one right? ;-)

Contributor

nickdunn commented Oct 5, 2011

Ditto, I'm not fussed what it is. Even retaining it as an H1 doesn't bother me that much so let's not spend too long on this one right? ;-)

@nilshoerrmann

This comment has been minimized.

Show comment Hide comment
@nilshoerrmann

nilshoerrmann Oct 5, 2011

Owner

As long a we decide to use some kind of markup I'll be fine. But … (okay, I'll stop here)

Owner

nilshoerrmann commented Oct 5, 2011

As long a we decide to use some kind of markup I'll be fine. But … (okay, I'll stop here)

@designermonkey

This comment has been minimized.

Show comment Hide comment
@designermonkey

designermonkey Oct 5, 2011

Owner

If it needs changing in the future, then change it, but pro-action first guys ;o)

Owner

designermonkey commented Oct 5, 2011

If it needs changing in the future, then change it, but pro-action first guys ;o)

@eKoeS

This comment has been minimized.

Show comment Hide comment
@eKoeS

eKoeS Oct 5, 2011

Contributor

I like David' suggestion about making the markup more HTML5-ish. I also like Nick's proposed outline (not sure about having h1 inside a li, but I agree it doesn't matter that much!).

Let's pave the way for a more semantic and accessible backend, if possible.

Contributor

eKoeS commented Oct 5, 2011

I like David' suggestion about making the markup more HTML5-ish. I also like Nick's proposed outline (not sure about having h1 inside a li, but I agree it doesn't matter that much!).

Let's pave the way for a more semantic and accessible backend, if possible.

@nilshoerrmann

This comment has been minimized.

Show comment Hide comment
@nilshoerrmann

nilshoerrmann Oct 5, 2011

Owner

Yes, of course. But I think we should still be allowed to question things: in my eyes semantic is about content not about SEO so it's not a theoretical question I was raising. I'm just not sure about the logic of the markup. Full stop here :)

Of course Nick's proposal is a good start we could work with immediately but coming back to the main discussion, we currently have two different options and opinions:

  • Don't change the markup now, but prepare everything for 2.4.
  • Change the markup now and use the betas and release candidates to spread the word about these changes.

We opted for the first idea in Cologne, while most of the participants here seem to like the idea to change the markup now. I think it would be quite strange to change all the rest of the markup (introducing HTML5 elements) and not taking care of the headline and button problem: using header and footer is not a necessity as the current markup isn't illogical. So in my eyes we should opt for the one or the other way – the how can be discussed and changed over time when we decided if we change things now.

So can I have short votes for the one or the other option, please?
Thanks!

Owner

nilshoerrmann commented Oct 5, 2011

Yes, of course. But I think we should still be allowed to question things: in my eyes semantic is about content not about SEO so it's not a theoretical question I was raising. I'm just not sure about the logic of the markup. Full stop here :)

Of course Nick's proposal is a good start we could work with immediately but coming back to the main discussion, we currently have two different options and opinions:

  • Don't change the markup now, but prepare everything for 2.4.
  • Change the markup now and use the betas and release candidates to spread the word about these changes.

We opted for the first idea in Cologne, while most of the participants here seem to like the idea to change the markup now. I think it would be quite strange to change all the rest of the markup (introducing HTML5 elements) and not taking care of the headline and button problem: using header and footer is not a necessity as the current markup isn't illogical. So in my eyes we should opt for the one or the other way – the how can be discussed and changed over time when we decided if we change things now.

So can I have short votes for the one or the other option, please?
Thanks!

@designermonkey

This comment has been minimized.

Show comment Hide comment
@designermonkey

designermonkey Oct 5, 2011

Owner

Perfectly valid markup.

Owner

designermonkey commented Oct 5, 2011

Perfectly valid markup.

@nickdunn

This comment has been minimized.

Show comment Hide comment
@nickdunn

nickdunn Oct 5, 2011

Contributor

I vote #2 (change markup in 2.3), but as I described above, ensure the CSS still works for the old markup, so that extensions that implement their own pages with buttons inside H2s still work without any change.

Contributor

nickdunn commented Oct 5, 2011

I vote #2 (change markup in 2.3), but as I described above, ensure the CSS still works for the old markup, so that extensions that implement their own pages with buttons inside H2s still work without any change.

@DavidOliver

This comment has been minimized.

Show comment Hide comment
@DavidOliver

DavidOliver Oct 5, 2011

Member

If the markup is going to be changed, it should be valid, semantic and accurately outline the content.

I very much agree with Simone and Nils that this is about usability and accessibility, not SEO.

I like Nick's proposal.

Member

DavidOliver commented Oct 5, 2011

If the markup is going to be changed, it should be valid, semantic and accurately outline the content.

I very much agree with Simone and Nils that this is about usability and accessibility, not SEO.

I like Nick's proposal.

@nilshoerrmann

This comment has been minimized.

Show comment Hide comment
@nilshoerrmann

nilshoerrmann Oct 5, 2011

Owner

Right, in this case we just need to make sure that the old styles will still be applied to buttons inside an h2. I'm just fine with this.

Any objections?

Owner

nilshoerrmann commented Oct 5, 2011

Right, in this case we just need to make sure that the old styles will still be applied to buttons inside an h2. I'm just fine with this.

Any objections?

@nilshoerrmann

This comment has been minimized.

Show comment Hide comment
@nilshoerrmann

nilshoerrmann Oct 5, 2011

Owner

I think I just found the reason why the markup was irritating me: the page title should be a link to the front-end and thus there is no need for a span.

Owner

nilshoerrmann commented Oct 5, 2011

I think I just found the reason why the markup was irritating me: the page title should be a link to the front-end and thus there is no need for a span.

@nilshoerrmann

This comment has been minimized.

Show comment Hide comment
@nilshoerrmann

nilshoerrmann Oct 5, 2011

Owner

So what about this adjusted markup:

<div id="wrapper">

    <header id="header">
        <a href="/link/to/site">Site Name</a>
        <nav class="content">
            <ul>...</ul>
        </nav>
        <nav class="structure">
            <ul>...</ul>
        </nav>
    </header>

    <div id="context">
        // if no breadcrumb, no list, just an h1
        <ul class="breadcrumb">
            <li><a href="#">Parent 1</a></li>
            <li><a href="#">Parent2 </a></li>
            <li><h1>Page Title</h1></li>
        </ul>
        <ul class="actions">...</ul>
        // drawers would be added here
    </div>

    <div id="contents">
        // page body (table or form)
    </div>

    // #footer removed

</div>
Owner

nilshoerrmann commented Oct 5, 2011

So what about this adjusted markup:

<div id="wrapper">

    <header id="header">
        <a href="/link/to/site">Site Name</a>
        <nav class="content">
            <ul>...</ul>
        </nav>
        <nav class="structure">
            <ul>...</ul>
        </nav>
    </header>

    <div id="context">
        // if no breadcrumb, no list, just an h1
        <ul class="breadcrumb">
            <li><a href="#">Parent 1</a></li>
            <li><a href="#">Parent2 </a></li>
            <li><h1>Page Title</h1></li>
        </ul>
        <ul class="actions">...</ul>
        // drawers would be added here
    </div>

    <div id="contents">
        // page body (table or form)
    </div>

    // #footer removed

</div>
@eKoeS

This comment has been minimized.

Show comment Hide comment
@eKoeS

eKoeS Oct 5, 2011

Contributor

as I described above, ensure the CSS still works for the old markup, so that extensions that implement their own pages with buttons inside H2s still work without any change.

Right, in this case we just need to make sure that the old styles will still be applied to buttons inside an h2.

No problem.

Any objections?

Well, since it seems like everybody agrees on the markup, let's roll it into Symphony 2.3. No objections from me.

Contributor

eKoeS commented Oct 5, 2011

as I described above, ensure the CSS still works for the old markup, so that extensions that implement their own pages with buttons inside H2s still work without any change.

Right, in this case we just need to make sure that the old styles will still be applied to buttons inside an h2.

No problem.

Any objections?

Well, since it seems like everybody agrees on the markup, let's roll it into Symphony 2.3. No objections from me.

@nickdunn

This comment has been minimized.

Show comment Hide comment
@nickdunn

nickdunn Oct 5, 2011

Contributor

the page title should be a link to the front-end

Kapow! Of course :-)

Contributor

nickdunn commented Oct 5, 2011

the page title should be a link to the front-end

Kapow! Of course :-)

@eKoeS

This comment has been minimized.

Show comment Hide comment
@eKoeS

eKoeS Oct 5, 2011

Contributor

Two thoughts:

  • I think that the two nav elements in #header can be merged into one, with the two ul having different IDs/classes.
  • In my opinion, breadcrumbs are a navigation element, so I'd make it nav
Contributor

eKoeS commented Oct 5, 2011

Two thoughts:

  • I think that the two nav elements in #header can be merged into one, with the two ul having different IDs/classes.
  • In my opinion, breadcrumbs are a navigation element, so I'd make it nav
@eKoeS

This comment has been minimized.

Show comment Hide comment
@eKoeS

eKoeS Oct 7, 2011

Contributor

Do we have a method of dynamically adding content into that area with PHP? I know we can with js using .appendTo(). Maybe a delegate?

That would be as easy as:

$this->Context->appendChild(new XMLElement('div', NULL, array('class' => 'drawer'));

even if I think it's better to do that via JS.

Contributor

eKoeS commented Oct 7, 2011

Do we have a method of dynamically adding content into that area with PHP? I know we can with js using .appendTo(). Maybe a delegate?

That would be as easy as:

$this->Context->appendChild(new XMLElement('div', NULL, array('class' => 'drawer'));

even if I think it's better to do that via JS.

@designermonkey

This comment has been minimized.

Show comment Hide comment
@designermonkey

designermonkey Oct 7, 2011

Owner

Just checking, you never know what ext devs want to do ;o)

Owner

designermonkey commented Oct 7, 2011

Just checking, you never know what ext devs want to do ;o)

@eKoeS

This comment has been minimized.

Show comment Hide comment
@eKoeS

eKoeS Oct 7, 2011

Contributor

eheh, no worries ;)

Contributor

eKoeS commented Oct 7, 2011

eheh, no worries ;)

@eKoeS

This comment has been minimized.

Show comment Hide comment
@eKoeS

eKoeS Oct 7, 2011

Contributor

Found another unlucky delegate that is not going to have any place in the new world: AppendElementBelowView. Same question: what shall we do with it?

Contributor

eKoeS commented Oct 7, 2011

Found another unlucky delegate that is not going to have any place in the new world: AppendElementBelowView. Same question: what shall we do with it?

@eKoeS

This comment has been minimized.

Show comment Hide comment
@eKoeS

eKoeS Oct 7, 2011

Contributor

If you want to take a look at my branch, here's the first commit:

eKoeS/symphony-2@90b8100

Contributor

eKoeS commented Oct 7, 2011

If you want to take a look at my branch, here's the first commit:

eKoeS/symphony-2@90b8100

@nickdunn

This comment has been minimized.

Show comment Hide comment
@nickdunn

nickdunn Oct 7, 2011

Contributor

a. Extension-specific items added to the navigation.

I say let the developer chose which group works better. Essential, depending on different use cases. Is the extension modifying content tasks or structural tasks? Maybe administration or developer is a better name than structure.

b. How do we deal with the AddElementToFooter delegate? Do we rename it something like AddElementToUserLinks instead?

How many extensions use it. Can it be removed entirely now there is no footer?

c. If I got it right, the drawer div will be dynamically appended to the page when needed.

Correct. I am exploring ways to do this, so leave for now.

d. AppendElementBelowView

We need to see how extensions are using it. I've found searching on Github to be useful to do this.

Contributor

nickdunn commented Oct 7, 2011

a. Extension-specific items added to the navigation.

I say let the developer chose which group works better. Essential, depending on different use cases. Is the extension modifying content tasks or structural tasks? Maybe administration or developer is a better name than structure.

b. How do we deal with the AddElementToFooter delegate? Do we rename it something like AddElementToUserLinks instead?

How many extensions use it. Can it be removed entirely now there is no footer?

c. If I got it right, the drawer div will be dynamically appended to the page when needed.

Correct. I am exploring ways to do this, so leave for now.

d. AppendElementBelowView

We need to see how extensions are using it. I've found searching on Github to be useful to do this.

@eKoeS
@brendo

This comment has been minimized.

Show comment Hide comment
@brendo

brendo Oct 8, 2011

Owner

Let's remove AddElementToFooter, it doesn't make sense when no footer exists, so it would be an oddly named delegate anyway.

  • Order Entries actually doesn't use AppendElementBelowView since version 1.9, so that's fine.
  • Am I right in saying that Translation Manager has been replaced by Localisation Manager?
  • @czheng's extensions still use AppendElementBelowView though.
Owner

brendo commented Oct 8, 2011

Let's remove AddElementToFooter, it doesn't make sense when no footer exists, so it would be an oddly named delegate anyway.

  • Order Entries actually doesn't use AppendElementBelowView since version 1.9, so that's fine.
  • Am I right in saying that Translation Manager has been replaced by Localisation Manager?
  • @czheng's extensions still use AppendElementBelowView though.
@eKoeS

This comment has been minimized.

Show comment Hide comment
@eKoeS

eKoeS Oct 8, 2011

Contributor

Am I right in saying that Translation Manager has been replaced by Localisation Manager?

I think so, yes.

@czheng's extensions still use AppendElementBelowView delegate though.

It shouldn't be a big issue to move the Documenter contents to a different part of the page. @czheng, is that okay for you?

@brendo: Any opinions about the navigation problem?

Contributor

eKoeS commented Oct 8, 2011

Am I right in saying that Translation Manager has been replaced by Localisation Manager?

I think so, yes.

@czheng's extensions still use AppendElementBelowView delegate though.

It shouldn't be a big issue to move the Documenter contents to a different part of the page. @czheng, is that okay for you?

@brendo: Any opinions about the navigation problem?

@nilshoerrmann

This comment has been minimized.

Show comment Hide comment
@nilshoerrmann

nilshoerrmann Oct 8, 2011

Owner

As we will have a new Drawer plugin, I think the Documenter implementation is likely to change alongside Symphony 2.3 so I think we don't have to care too much about it now. I we do it right, there will the an official hook for the extension to populate a drawer in the sidebar.

Owner

nilshoerrmann commented Oct 8, 2011

As we will have a new Drawer plugin, I think the Documenter implementation is likely to change alongside Symphony 2.3 so I think we don't have to care too much about it now. I we do it right, there will the an official hook for the extension to populate a drawer in the sidebar.

@nilshoerrmann

This comment has been minimized.

Show comment Hide comment
@nilshoerrmann

nilshoerrmann Oct 8, 2011

Owner

Do we let the developer chose which group works better?

It should always be up to the developers in my eyes.

Owner

nilshoerrmann commented Oct 8, 2011

Do we let the developer chose which group works better?

It should always be up to the developers in my eyes.

@eKoeS

This comment has been minimized.

Show comment Hide comment
@eKoeS

eKoeS Oct 8, 2011

Contributor

It should always be up to the developers in my eyes.

Fine for me. It would be as easy as having a new key in the array like:

...
'type' => 'content',
...

If none is specified, it could be structure by default.

Contributor

eKoeS commented Oct 8, 2011

It should always be up to the developers in my eyes.

Fine for me. It would be as easy as having a new key in the array like:

...
'type' => 'content',
...

If none is specified, it could be structure by default.

@nilshoerrmann

This comment has been minimized.

Show comment Hide comment
@nilshoerrmann

nilshoerrmann Oct 8, 2011

Owner

Sounds good to me.

Owner

nilshoerrmann commented Oct 8, 2011

Sounds good to me.

@brendo

This comment has been minimized.

Show comment Hide comment
@brendo

brendo Oct 8, 2011

Owner

@brendo: Any opinions about the navigation problem?

I think they can sit inside .structure without issue. The Navigation rendering logic is separate to the delegates so developers don't really have a choice other then what top level navigation item they will sit under.

Owner

brendo commented Oct 8, 2011

@brendo: Any opinions about the navigation problem?

I think they can sit inside .structure without issue. The Navigation rendering logic is separate to the delegates so developers don't really have a choice other then what top level navigation item they will sit under.

@eKoeS

This comment has been minimized.

Show comment Hide comment
@eKoeS

eKoeS Oct 8, 2011

Contributor

So, here's what I've done so far:

  • appendFooter has been renamed to appendUserLinks and the version number has been removed (will be probably included in the Preferences page as explained somewhere else here on GitHub...)
  • There's no longer $this->Footer while a new element is now accessible called $this->Context, containing the breadcrumbs, the page title and the Drawer
  • The signature of appendSubheading has been updated to reflect the changes to the markup. The old $html variable is now called $actions and is supposed to be an array of either XMLElements or strings. However, in order to maintain the backward compatibility, it is still possible to pass a single XMLElement object (this feature will be removed in Symphony 2.4)
  • A new method has been created called insertBreadcrumbs that accepts an array of XMLElements and/or strings. Basically, it adds the breadcrumbs before the page title. If a path already exists, the new items are appended to the rightmost part of the breadcrumbs.
  • AddElementToFooter has been removed.
  • Stylesheets have been updated to reflect the changes in the markup.
Contributor

eKoeS commented Oct 8, 2011

So, here's what I've done so far:

  • appendFooter has been renamed to appendUserLinks and the version number has been removed (will be probably included in the Preferences page as explained somewhere else here on GitHub...)
  • There's no longer $this->Footer while a new element is now accessible called $this->Context, containing the breadcrumbs, the page title and the Drawer
  • The signature of appendSubheading has been updated to reflect the changes to the markup. The old $html variable is now called $actions and is supposed to be an array of either XMLElements or strings. However, in order to maintain the backward compatibility, it is still possible to pass a single XMLElement object (this feature will be removed in Symphony 2.4)
  • A new method has been created called insertBreadcrumbs that accepts an array of XMLElements and/or strings. Basically, it adds the breadcrumbs before the page title. If a path already exists, the new items are appended to the rightmost part of the breadcrumbs.
  • AddElementToFooter has been removed.
  • Stylesheets have been updated to reflect the changes in the markup.
@brendo

This comment has been minimized.

Show comment Hide comment
@brendo

brendo Oct 8, 2011

Owner

Good work, sounds great :)

Owner

brendo commented Oct 8, 2011

Good work, sounds great :)

@eKoeS

This comment has been minimized.

Show comment Hide comment
@eKoeS

eKoeS Oct 8, 2011

Contributor

Open questions

  • Can developers decide which part of the main navigation they can append items to? (e.g. structure or content)
  • Can we get rid of AppendElementBelowView?
  • Is the new backend as sexy as Megane Fox?
Contributor

eKoeS commented Oct 8, 2011

Open questions

  • Can developers decide which part of the main navigation they can append items to? (e.g. structure or content)
  • Can we get rid of AppendElementBelowView?
  • Is the new backend as sexy as Megane Fox?
@eKoeS

This comment has been minimized.

Show comment Hide comment
@eKoeS

eKoeS Oct 8, 2011

Contributor

Breadcrumbs for all the standard content pages

See the commit.

Blueprints

  • Authors -> $author
  • Data Sources -> $datasource
  • Events -> $event
  • Utilities -> $utility
  • Sections -> $section
  • Pages -> $page
  • Pages -> $page -> $template

Publish area

  • $section -> $entry

Extra buttons in the #context div

Sections -> $section

  • View Entries: takes you to $section -> entries

$section -> entries

  • Edit Configuration: takes you to Sections -> $section

$section -> $entry

  • Edit Configuration: takes you to Sections -> $section
Contributor

eKoeS commented Oct 8, 2011

Breadcrumbs for all the standard content pages

See the commit.

Blueprints

  • Authors -> $author
  • Data Sources -> $datasource
  • Events -> $event
  • Utilities -> $utility
  • Sections -> $section
  • Pages -> $page
  • Pages -> $page -> $template

Publish area

  • $section -> $entry

Extra buttons in the #context div

Sections -> $section

  • View Entries: takes you to $section -> entries

$section -> entries

  • Edit Configuration: takes you to Sections -> $section

$section -> $entry

  • Edit Configuration: takes you to Sections -> $section

eKoeS added a commit to eKoeS/symphony-2 that referenced this issue Oct 9, 2011

@eKoeS

This comment has been minimized.

Show comment Hide comment
@eKoeS

eKoeS Oct 9, 2011

Contributor

[Simone] Can developers decide which part of the main navigation they can append items to? (e.g. structure or content)

[Brendan] I think they can sit inside .structure without issue. The Navigation rendering logic is separate to the delegates so developers don't really have a choice other then what top level navigation item they will sit under.

The current implementation is: let the developer choose. This can be done by setting the type key of the navigation item array to either structure or content. If not present, it's structure by default. By the way, the code is as simple as an inline if/else statement, so it's not a big issue in my opinion.

[Simone] Can we get rid of AppendElementBelowView?

[Nils] As we will have a new Drawer plugin, I think the Documenter implementation is likely to change alongside Symphony 2.3 so I think we don't have to care too much about it now. I we do it right, there will the an official hook for the extension to populate a drawer in the sidebar.

Right, I didn't consider that!

Contributor

eKoeS commented Oct 9, 2011

[Simone] Can developers decide which part of the main navigation they can append items to? (e.g. structure or content)

[Brendan] I think they can sit inside .structure without issue. The Navigation rendering logic is separate to the delegates so developers don't really have a choice other then what top level navigation item they will sit under.

The current implementation is: let the developer choose. This can be done by setting the type key of the navigation item array to either structure or content. If not present, it's structure by default. By the way, the code is as simple as an inline if/else statement, so it's not a big issue in my opinion.

[Simone] Can we get rid of AppendElementBelowView?

[Nils] As we will have a new Drawer plugin, I think the Documenter implementation is likely to change alongside Symphony 2.3 so I think we don't have to care too much about it now. I we do it right, there will the an official hook for the extension to populate a drawer in the sidebar.

Right, I didn't consider that!

@eKoeS

This comment has been minimized.

Show comment Hide comment
@eKoeS

eKoeS Oct 9, 2011

Contributor
Contributor

eKoeS commented Oct 9, 2011

@brendo brendo closed this in b872615 Oct 9, 2011

@brendo

This comment has been minimized.

Show comment Hide comment
@brendo

brendo Oct 9, 2011

Owner

Big thanks to everyone for discussing this one at length and to @eKoeS for the implementation. Great stuff :)

Owner

brendo commented Oct 9, 2011

Big thanks to everyone for discussing this one at length and to @eKoeS for the implementation. Great stuff :)

@nickdunn nickdunn reopened this Nov 15, 2011

@nickdunn

This comment has been minimized.

Show comment Hide comment
@nickdunn

nickdunn Nov 15, 2011

Contributor

I would like to re-open this because I don't think we discussed, or implemented, anything to do with backwards compatibility. My list above mentions:

  • extensions that look for an H2 to append things around it
  • extensions that look for an H2 to append things to it (button and breadcrumb)

Are we saying that these are no longer compatible, and we should force these extensions to be updated for S2.3+, or should we try and make their existing markup work with the new styles?

Contributor

nickdunn commented Nov 15, 2011

I would like to re-open this because I don't think we discussed, or implemented, anything to do with backwards compatibility. My list above mentions:

  • extensions that look for an H2 to append things around it
  • extensions that look for an H2 to append things to it (button and breadcrumb)

Are we saying that these are no longer compatible, and we should force these extensions to be updated for S2.3+, or should we try and make their existing markup work with the new styles?

@nickdunn nickdunn closed this Nov 15, 2011

@nickdunn nickdunn reopened this Nov 15, 2011

@brendo

This comment has been minimized.

Show comment Hide comment
@brendo

brendo Nov 16, 2011

Owner

Are we saying that these are no longer compatible, and we should force these extensions to be updated for S2.3+, or should we try and make their existing markup work with the new styles?

I think given the list of extensions we should at least investigate what it'd take to support the existing markup, at least so it can be fully deprecated.

Owner

brendo commented Nov 16, 2011

Are we saying that these are no longer compatible, and we should force these extensions to be updated for S2.3+, or should we try and make their existing markup work with the new styles?

I think given the list of extensions we should at least investigate what it'd take to support the existing markup, at least so it can be fully deprecated.

@eKoeS

This comment has been minimized.

Show comment Hide comment
@eKoeS

eKoeS Nov 16, 2011

Contributor

[OT] I just realized we didn't mention insertBreadcrumbs() in the last Developer Notes. Next episode? [/OT]

Contributor

eKoeS commented Nov 16, 2011

[OT] I just realized we didn't mention insertBreadcrumbs() in the last Developer Notes. Next episode? [/OT]

@brendo

This comment has been minimized.

Show comment Hide comment
@brendo

brendo Nov 16, 2011

Owner

Definitely.

Owner

brendo commented Nov 16, 2011

Definitely.

@eKoeS

This comment has been minimized.

Show comment Hide comment
@eKoeS

eKoeS Nov 20, 2011

Contributor

I'm not sure there's any safe/simple way to maintain markup backward compatible. Perhaps it's not worth the effort. Any ideas?

Contributor

eKoeS commented Nov 20, 2011

I'm not sure there's any safe/simple way to maintain markup backward compatible. Perhaps it's not worth the effort. Any ideas?

@nilshoerrmann

This comment has been minimized.

Show comment Hide comment
@nilshoerrmann

nilshoerrmann Dec 7, 2011

Owner

Perhaps it's not worth the effort.

Exactly my feeling.

Owner

nilshoerrmann commented Dec 7, 2011

Perhaps it's not worth the effort.

Exactly my feeling.

@designermonkey

This comment has been minimized.

Show comment Hide comment
@designermonkey

designermonkey Dec 7, 2011

Owner

I was under the impression that 2.3 would be a 'breaking' release, especially in the eyes of extensions. That way, we can announce very early before release that it will break extensions that edit the UI, and those developers should upgrade the extensions using the beta releases.

We can then see who is and isn't actively maintaining extensions, and which ones should be pulled into Symphonists for future compatibility.

At least that was what I thought...

Owner

designermonkey commented Dec 7, 2011

I was under the impression that 2.3 would be a 'breaking' release, especially in the eyes of extensions. That way, we can announce very early before release that it will break extensions that edit the UI, and those developers should upgrade the extensions using the beta releases.

We can then see who is and isn't actively maintaining extensions, and which ones should be pulled into Symphonists for future compatibility.

At least that was what I thought...

@brendo

This comment has been minimized.

Show comment Hide comment
@brendo

brendo Dec 8, 2011

Owner

If it's not feasible to support both, then lets not.

We will need to show an example showing how to replicate the 2.2 behaviour in 2.3. This should then be added to the Migration Guide

Owner

brendo commented Dec 8, 2011

If it's not feasible to support both, then lets not.

We will need to show an example showing how to replicate the 2.2 behaviour in 2.3. This should then be added to the Migration Guide

@nilshoerrmann

This comment has been minimized.

Show comment Hide comment
@nilshoerrmann

nilshoerrmann Dec 8, 2011

Owner

Why don't we just add the new markup to the migration guide?

Owner

nilshoerrmann commented Dec 8, 2011

Why don't we just add the new markup to the migration guide?

@eKoeS

This comment has been minimized.

Show comment Hide comment
@eKoeS

eKoeS Dec 8, 2011

Contributor

Why don't we just add the new markup to the migration guide?

Yes, it seems like the simplest thing to do.

Contributor

eKoeS commented Dec 8, 2011

Why don't we just add the new markup to the migration guide?

Yes, it seems like the simplest thing to do.

@eKoeS

This comment has been minimized.

Show comment Hide comment
@eKoeS

eKoeS Feb 17, 2012

Contributor

We will need to show an example showing how to replicate the 2.2 behaviour in 2.3. This should then be added to the Migration Guide

See #1016. I'm closing this issue again.

Contributor

eKoeS commented Feb 17, 2012

We will need to show an example showing how to replicate the 2.2 behaviour in 2.3. This should then be added to the Migration Guide

See #1016. I'm closing this issue again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment