Adapt_framework: adapt-contrib-boxMenu: add 'menuBody' attribute to contentObject for sub menu support

[kirsty-hames]

The contentObject _body_ attribute is used for both menu item body text and page body text. For pages, we have the _pageBody_ attribute so you can render body text in the page but not for the menu item. Or set different body text for both.

https://github.com/adaptlearning/adapt_framework/blob/2b684d53a5349305d33d4868a124b786453b6583/src/core/templates/page.hbs#L32

However, if the contentObject is a menu then the _body_ attribute is used for both menu item body text and menu body text and no alternative is available. I suggest we add the attribute _menuBody_ to give authors the same flexibility.

[tomgreenfield]

My preference, if we were starting again (i.e. with a breaking version), would be to use body for the page / menu text and a new attribute itemBody to be displayed on the menu item.

[kirsty-hames]

I would prefer that also @tomgreenfield . Also, with the current implementation, you can set page body text without having to display menu item body text but not vice versa.

Is it still worth implementing _menuBody_ until we have a breaking version? This is something I've manually added in Adapt projects on a few instances now so there is a use case.

[guywillis]

We could look to expand this and include titles too in the breaking change - with the idea to treat menu / page title / body differently to menu item title / body.

Content object e.g.
"title" = page title / menu title (if submenu)
"body" = page body / menu body (if submenu)
"menuItemTitle" = menu item title
"menuItemBody = menu item body

The benefit is that users can shorthand, tweak, or amend titles and body text between the menu and page to a greater distinction without adding too much overhead on the content side.

RE: adding menuBody attribute: I'd be a little bit hesitant to add an attribute to remove it again 'shortly' afterwards though I am not against it by any means.

[kirsty-hames]

I'm happy to wait for a breaking version to implement. Do we just label this ticket as _breaking_ and it will get picked up with the next breaking release?

[chucklorenz]

My attention turned to these issues as I played around with the newly released boxMenuGroup.hbs. Reiterating what has been said above that echoes with me:

• boxMenu.hbs only uses body. Since this property is used by boxMenuItem.hbs, I always put short text into body. I want the ability to display longer text when the same contentObject is presented as a submenu.
• I instinctively like flexibility, so Guy's proposed menuItemTitle has some appeal. But I currently don't need it. And I wonder if it is good UX to have one particular title link to a page with a different title. I'm thinking there might be other ways to address this case.

Here's some thoughts about how to address some of this.

1. Rename body to menuBody.
   Result: menuBody parallels pageBody, reduces confusion about how these json properties function when a contentObject takes on different roles: menu vs page.

1. Move the conditionals found in page.hbs to boxMenu.hbs, thusly:

{{#any menuBody pageBody}}
    <div class="menu__body">
        <div class="menu__body-inner">
          {{#if pageBody}}
              {{{compile pageBody}}}
          {{else}}
              {{{compile menuBody}}}
          {{/if}}
        </div>
    </div>
{{/any}} 

Result: This provides the option to have longer text appear when the submenu "page" is displayed, while shorter summary text will appear in its menu item.

1. Add test for legacy body to boxMenu.hbs , thusly:

{{#any body menuBody pageBody}}
    <div class="menu__body">
        <div class="menu__body-inner">
          {{#if pageBody}}
              {{{compile pageBody}}}
          {{else}}
              {{#if body}}
                  {{{compile body}}}
              {{else}}
                  {{{compile menuBody}}}
              {{/if}}
          {{/if}}
        </div>
    </div>
{{/any}}

Result: If a course is updated to v5.7+, body will be recognized if menuBody is not present.

1. Modify boxMenuItem.hbs and boxMenuGroup.hbs to use a similar test for legacy body, e.g.,

{{#any body menuBody}}
    <div class="menu-item__body boxmenu-item__body">
        <div class="menu-item__body-inner boxmenu-item__body-inner">
          {{#if body}}
                  {{{compile body}}}
              {{else}}
                  {{{compile menuBody}}}
              {{/if}}
        </div>
    </div>
{{/any}}

Result: Makes these templates backwards compatible.

1. Remove body from the conditionals found in page.hbs, thusly:

{{#if pageBody}}
    <div class="page__body">
        <div class="page__body-inner">
            {{{compile pageBody}}}
        </div>
    </div>
{{/if}}

Result: Separates the summary text (menuBody) on a menu item (boxMenuItem.hbs) from the longer text (pageBody) appearing on a page (page.hbs). Neither interferes with each other. If one wants the same text to appear in both places, yes, the text needs to be copied into both menuBody and pageBody—no big deal IMO.

1. Change the labels in the AT (ref pic attached below :
2. “Body” becomes “Short Body”.
3. “Short Body” tooltip reads something like: “Displayed within menu item, menu group header, and page header.”
4. “Page Body” becomes “Long Body”.
5. “Long Body” tooltip reads something like: “If used, displayed within page header, submenu header, and menu group header.
6. Change the breadcrumb for submenu edit from “page settings” to “submenu settings”.
   Result: Eliminates some confusion in the AT.

Some notes about 6.:
The authoring tool config screens reflect overlapping of functions--menu vs page. It can confuse users who don’t understand what’s happening in the framework templates. Whether one adds a page or a menu, the config options are the same: both body and pageBody are presented.

When the user adds a menu object, she must confront pageBody and try to understand what that means in the context of a menu--even though pageBody will never be used. When the user adds a page object, she must confront both body and pageBody. In that context, they seem like redundant fields.

The AT smartly uses the word “submenu” in its interfaces. But when the choice is made to add a submenu, the config screen continues to use the word “page” in the breadcrumbs.

Unaddressed:

• Can AT course import handle receiving body when the current version expects the proposed menuBody?