In order to implement certain bits of the redesign from a content standpoint, we need to be able to allow KumaScript code to inject blocks of HTML into the sidebars. Ideally, we'd be able to specify which bar to place the content into (left or right, along with the HTML to insert. This will let us do things like update the {{Draft}} macro to place the "draft" message into the sidebar and get it out of the page content. Similarly, we can use this to put "This material only applies to Firefox X" or "This article is obsolete" in the sidebar, where it will be less frightening but will remain visible even after the page has been scrolled.

This would be awesome, death to the banners!

FWIW, KumaScript is kind of a red herring here: All it does is generate content. It has no powers to do things like move content outside the main article body area. For that, we need to make changes in Kuma to the document view template. What we *could* do is set up some more named sections like Quick Links or zone nav that Kuma moves from article content into sidebar slots. It would help to have some more details on exactly what kind of sidebars should be supported. That is, example content, where do they go in relation to existing sidebars, what do they look like, etc. Something like "remain visible after the page has scrolled" sounds like these sidebars could get complicated.

Wait... hum. I just realized that the TOC sidebar isn't fixed in place. One of the reasons we wanted it in a sidebar was to be able to keep it from scrolling offscreen as you scroll around the document. Oh well. That's a discussion for another time. That's what led me to mention that, though. Could we simply support adding an "info box" on each side of the page? Say, an Info_Box_Left and Info_Box_Right blocks, which work just like the quicklinks box, but are simply arbitrary content? This would let us construct these boxes and insert them into the page from script. Although we'd want to be able to concatenate multiple ones together, for cases where multiple macros each need to slip something in there. Not sure the best way to accomplish that. Maybe using Info_Box_x boxes, where x is a unique identifier for each box? That would let a draft macro create Info_Box_Draft, a "Firefox OS only" macro create Info_Box_FxOSOnly, etc, and these would all be assembled into the sidebar. Thoughts?

Sheppy: a class rather than an ID, so it doesn't need to be unique and we don't need to edit all the others to insert a new one.

My major concern here, which will be shared by UX and Design, is that doing so would allow our pages to get wild. Our pages may lose uniformity. I would really like Holly or Sean to have a say here.

I don't believe the pages will get wild. I think it will allow us to finally produce some uniformity, with a standard place for information of this type to be stowed. Since the platform doesn't yet have support for simply setting a flag that says to display a banner like "this is a draft" or "this content only applies to Firefox, and only version 18 and later", then it makes sense to come up with a way to standardize the display of that information in a less obtrusive yet still visible way. It should be pretty easy to implement, which makes this a good option. And since only macros will be able to do it, with some basic policing we'd be fine.

(In reply to Eric Shepherd [:sheppy] from comment #6) > And since only macros will be able to do it, with some basic policing we'd > be fine. Like I said: KumaScript macros are a red herring. They only generate content, have no special powers or privileges, and they can't do anything that couldn't otherwise be done manually. We can't constrict any pattern of markup solely to KumaScript macros.

Sheppy, +1 for the TOC in a fixed position. Adding that to our Fix list etherpad. Instead of offering ultimate flexibility for these content blocks, can we come up with, say... the 5 that are most needed right now and their purpose/benefit for the users? I wouldn't want the contributors to have ultimate control over new content blocks. I think it should be guided by Sheppy and team to determine a set of needed additional content blocks to start with. So, Sheppy gets flexibility to determine the boundaries and not all contributors. Does that make sense? I think that will be a nice way to meet in the middle and not allow the layout to get too out of control while coming up with a system for what the content blocks are, when to show them, where to put them, etc. What do you think? Questions: 1. Are these new content blocks meant to do away with the message banners? 2. Can we see a list of the content blocks/kuma scripts you had in mind? (it will help me figure out the user needs for this and where they should exist... because the left column is where contributor tools show up and content that can be collapsed for better article readability, I want to make sure the hide/show logic doesn't get effected negatively for the users by adding this content)

I must have missed this from our discussions, but the TOC is is supposed to be fixed as the user scrolls? I like the idea but I want to make sure this is correct.

(In reply to David Walsh :davidwalsh from comment #9) > I must have missed this from our discussions, but the TOC is is supposed to > be fixed as the user scrolls? I like the idea but I want to make sure this > is correct. David, yes this is correct. The sticky TOC was brought up a long time ago, but we talked about so many other things in our recent meetings that it was overlooked. I meant to bring it up again in our meeting yesterday. I added it to our Fix etherpad, but will start to move any outstanding items from there to bugs.

(In reply to David Walsh :davidwalsh from comment #9) > I must have missed this from our discussions, but the TOC is is supposed to > be fixed as the user scrolls? I like the idea but I want to make sure this > is correct. Yes. The only trick is if the TOC is very long and needs to be scrollable; not sure how best to handle that. Perhaps it would have its own scroll bar, or perhaps it would scroll until you reach the end of the TOC, then stop scrolling with the rest of the page. That's something UX would need to chime in on, I expect. Holly?

This bug is no longer relevant, I think. We have built-in support for most of this stuff now, and the stuff, I will file separate bugs for.