Need ability to create alternative main pages with navigation

[billwear]

For the purposes of testing alternative doc layouts, it would be extremely useful to be able to create alternative main pages (in a category not visible to users) which include navigation elements that differ from the public main doc page. Currently there is no obvious way to create another page that accepts the ## Navigation menu and presents it.

[anthonydillon]

@nottrobin have you done anything around this yet? Could this just be a new index page and run the site locally and update the topic ID?

[nottrobin]

@billwear could you elaborate a little on what the use-case is here so we could brainstorm around the best way to solve it?

Basically, at the moment the whole system is based around a single index page - everything about 1 set of docs is defined from that central place. And so, if you wanted a second index page, I would suggest the best way would be to have a second docs installation. As in, example.com/docs could be based off one index page, example.com/some-more-docs could be based off a different index page. This we could do right now without changes to this module.

But as I say, if you let us know what you're trying to achieve we could discuss the best way to achieve it.

[billwear]

I can show you what I meant.

Go to http://stormrider.io/maas-offline/maas-vanilla/maas-documentation-25.html. When you click on one of the tabs, say CLI-only, you'll note that the URLs in the navigation sidebar change from ...maas-offline/maas-vanilla... to ...maas-offline/maas-cli-only... So if you're looking at things from a CLI perspective, you keep that perspective when you select a new page.

Then flip over to http://stormrider.io/maas-rad/maas-vanilla/maas-documentation-25.html. Note that when you click on the CLI-only tab there, the sidebar navigation doesn't change, so when you switch pages, you go back to the "standard (full)" version. So users always have to choose a selector for the page they're on.

I already have tools that could use a second++ docs installation(s), basically, and that would be absolutely desirable, because the page titles would not have to be changed in every case to support different variations. However, there are a fair number of possible "selectors" (deb v snap, ui v cli, 2.8 v 2.9, etc., so that might produce a large number of additional docs installations. And I am reasonably comfortable generating meaningful new titles for pages in different "selections" that aren't just ham-handed insertion of (CLI), (UI), etc.

We had worked out that it might be okay for the selectors to flip back to standard to start with, especially since -- for any given selector -- there are a number of pages that just won't change, hence it makes no sense to maintain a selector at the top of the screen when it doesn't actually apply to a page. Lyubo shared with me a way to do tabs in discourse, so we might be good to go.

That was a bit long, so feel free to interrogate me if needed. :)

On Fri, Aug 21, 2020 at 10:39 AM Robin Winslow notifications@github.com wrote:

@billwear https://github.com/billwear could you elaborate a little on what the use-case is here so we could brainstorm around the best way to solve it?

Basically, at the moment the whole system is based around a single index page - everything about 1 set of docs is defined from that central place. And so, if you wanted a second index page, I would suggest the best way would be to have a second docs installation. As in, example.com/docs could be based off one index page, somesite/some-more-docs could be based off a different index page. This we could do right now without changes to this module.

But as I say, if you let us know what you're trying to achieve we could discuss the best way to achieve it.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/canonical-web-and-design/canonicalwebteam.discourse-docs/issues/39#issuecomment-678356206, or unsubscribe https://github.com/notifications/unsubscribe-auth/AELRBCDFB76MXBDNKA5X4T3SB2IKBANCNFSM4NMPAESQ .

-- Bill Wear, MAAS Developer Advocate

[nottrobin]

I thought what we were exploring was doing switching between different context like this in an in-page tabbed section? This would mean that you don't need different URLs - you would always go to, say, rack-controllers.html, and inside that page would be tabbed sections that allowed you to switch between CLI view and UI view for any specific part of that page.

Making it so that the context you've chosen persisted between those different tabbed sections would be trivial for us to do when we implement this - we would add a cookie as well so it could persist between different pages / reloads. But they would not have different URLs. There would be just one master "rack controllers" page that gave you access to all views (which I think would avoid the need for "full" in your example there).

In this example you've shown me, what you effectively have is 3 different sets of documentation with all different URLs, so you would simply have to create and maintain 3 different sets of documentation. Which is why I suggest you instead do it the way I've outlined above, which shouldn't require you to change the navigation at all between different contexts.

[billwear]

So my key question is: When would someone from your side be able to implement this?

Assume that: (1) I do not have permission from Adam to work on Javascript right now, and (2) I have to have something up, even if it's three different URLS and it's got known issues, for the 2.9 release at 20.10 launch.

On Fri, Aug 21, 2020 at 11:15 AM Robin Winslow notifications@github.com wrote:

I thought what we were exploring was doing switching between different context like this in an in-page tabbed section? This would mean that you don't need different URLs - you would always go to, say, rack-controllers.html, and inside that page would be tabbed sections that allowed you to switch between CLI view and UI view for any specific part of that page.

Making it so that the context you've chosen persisted between those different tabbed sections would be trivial for us to do when we implement this - we would add a cookie as well so it could persist between different pages / reloads. But they would not have different URLs. There would be just one master "rack controllers" page that gave you access to all views (which I think would avoid the need for "full" in your example there).

In this example you've shown me, what you effectively have is 3 different sets of documentation with all different URLs, so you would simply have to create and maintain 3 different sets of documentation. Which is why I suggest you instead do it the way I've outlined above, which shouldn't require you to change the navigation at all between different contexts.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/canonical-web-and-design/canonicalwebteam.discourse-docs/issues/39#issuecomment-678373295, or unsubscribe https://github.com/notifications/unsubscribe-auth/AELRBCD2E4QXUA5ZI6QGPSTSB2MQ5ANCNFSM4NMPAESQ .

-- Bill Wear, MAAS Developer Advocate

[billwear]

Sorry, assumption (3), I have a python tool I built this cycle that will do pretty much whatever configuration you need, most of my work is actual variable document contents and maybe some makefile changes, so not a lot of wasted work, if any.

On Fri, Aug 21, 2020 at 11:34 AM Bill Wear bill.wear@canonical.com wrote:

So my key question is: When would someone from your side be able to implement this?

Assume that: (1) I do not have permission from Adam to work on Javascript right now, and (2) I have to have something up, even if it's three different URLS and it's got known issues, for the 2.9 release at 20.10 launch.

On Fri, Aug 21, 2020 at 11:15 AM Robin Winslow notifications@github.com wrote:

I thought what we were exploring was doing switching between different context like this in an in-page tabbed section? This would mean that you don't need different URLs - you would always go to, say, rack-controllers.html, and inside that page would be tabbed sections that allowed you to switch between CLI view and UI view for any specific part of that page.

Making it so that the context you've chosen persisted between those different tabbed sections would be trivial for us to do when we implement this - we would add a cookie as well so it could persist between different pages / reloads. But they would not have different URLs. There would be just one master "rack controllers" page that gave you access to all views (which I think would avoid the need for "full" in your example there).

In this example you've shown me, what you effectively have is 3 different sets of documentation with all different URLs, so you would simply have to create and maintain 3 different sets of documentation. Which is why I suggest you instead do it the way I've outlined above, which shouldn't require you to change the navigation at all between different contexts.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/canonical-web-and-design/canonicalwebteam.discourse-docs/issues/39#issuecomment-678373295, or unsubscribe https://github.com/notifications/unsubscribe-auth/AELRBCD2E4QXUA5ZI6QGPSTSB2MQ5ANCNFSM4NMPAESQ .

-- Bill Wear, MAAS Developer Advocate

-- Bill Wear, MAAS Developer Advocate

[nottrobin]

Okay yes that makes sense. I don't know the answer to when we can work on it right now (cc @SirSamTumless, @cristinadresch).

So yeah, the quick way is that we set up 3 (or however many) different sets of documentation, each pointing to different index topics, at like /docs, /cli-docs, /ui-docs or something.

We should probably have a meeting about it. Would you be able to schedule one?

[billwear]

Yes, I will schedule one for Monday. And I'll stop fussing with the complex makefile in the meantime, since setting up n different sets of doc makes it so much easier. :)

On Fri, Aug 21, 2020 at 5:43 PM Robin Winslow notifications@github.com wrote:

Okay yes that makes sense. I don't know the answer to when we can work on it right now (cc @SirSamTumless https://github.com/SirSamTumless, @cristinadresch https://github.com/cristinadresch).

So yeah, the quick way is that we set up 3 (or however many) different sets of documentation, each pointing to different index topics, at like /docs, /cli-docs, /ui-docs or something.

We should probably have a meeting about it. Would you be able to schedule one?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/canonical-web-and-design/canonicalwebteam.discourse-docs/issues/39#issuecomment-678545564, or unsubscribe https://github.com/notifications/unsubscribe-auth/AELRBCG6UA76HK2RXPA3GALSB32B7ANCNFSM4NMPAESQ .

-- Bill Wear, MAAS Developer Advocate

[SirSamTumless]

Hi, @nottrobin is back from paternity leave now - are you happy to schedule the meeting or did you have it already?

[billwear]

I am definitely ready to move forward, if anyone has time. The current RAD is decent and useful but has some limitations that the multi-directory problem will easily solve.

On Wed, Oct 14, 2020 at 5:06 AM SirSamTumless notifications@github.com wrote:

Hi, @nottrobin https://github.com/nottrobin is back from paternity leave now - are you happy to schedule the meeting or did you have it already?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/canonical-web-and-design/canonicalwebteam.discourse/issues/39#issuecomment-708301494, or unsubscribe https://github.com/notifications/unsubscribe-auth/AELRBCBCCWMXMGESAJCC5F3SKVZ33ANCNFSM4NMPAESQ .

-- Bill Wear, MAAS Developer Advocate

[anthonydillon]

@nottrobin as you have the most context can you create a meeting with Bill and from that create an epic containing the agreed tasks.

Adding @pmahnke as this will contain URLs which he should be aware of.

[nottrobin]

@billwear so this clearly dropped off the radar. Has anything changed from your end about requirements or urgency for this work?

[billwear]

no changes to requirements AFAIK; in regards to urgency, we have seen one complaint about RAD so far, specifically that when they follow links, they switch back to the current version and don't stay with the variant they've selected, i think the words were "not a step forward" without choices being sticky. essentially, the concept is well-received, but the mechanics are not. would love to be able to remove the clunky top menus and vector people directly to their chosen doc set ASAP.

On Thu, Jan 14, 2021 at 9:34 AM Robin Winslow notifications@github.com wrote:

@billwear https://github.com/billwear so this clearly dropped off the radar. Has anything changed from your end about requirements or urgency for this work?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/canonical-web-and-design/canonicalwebteam.discourse/issues/39#issuecomment-760273122, or unsubscribe https://github.com/notifications/unsubscribe-auth/AELRBCB7JM5KH7LDDNLBE7TSZ4FHPANCNFSM4NMPAESQ .

-- Bill Wear, MAAS Developer Advocate

[nottrobin]

This was closed following a discussion between @billwear and myself. We are aiming to implement the tabbed content switcher (RAD) soon, which will render this work unnecessary.