I understand that links are currently not click-able in Touch UI when in Edit Mode.
I have a situation where I am trying to improve the experience for my authors.
We have tabs on the pages that authors are editing. The tabs change what content is shown on the page. Currently the author has to click on the preview mode, then they can switch tabs, then they have to go back to edit mode, click the component, and then click the wrench.
The solution I want is to enable specific links, or even non-external page links on a page. I can see the need for this for in-page navigation, or enabling functionality in Tabs or Sliders.
I identified that touch ui places a overlay ontop of the page, that prevents interaction from bubbling to the iframe below with the content. Instead all components get a overlay rendered inside the overlay container, which represents there interaction point. I also identified that components get this extra overlay for interaction by the CQ element that is created automatically.
While this is clever, it is also heavy handed and prevents previous functionality from working.
For example, I can create a edit button, that calls the same properties as the edit toolbar button, but because of the overlay, the component gets selected first. So even if I try to improve the experience by removing 1 extra click for the author, the UI prevents that from working.
So my question is this in summary.
1. I need a solution for enabling certain iterations from being stopped by the touch UI overlay while in Edit Mode.
2. Alternatively, if I could put interaction in the page that can be done without opening up a component Edit dialog or toolbar, or going to preview mode. For example, a direct link to open a components dialog. Is there a API for this instead that lets us build the interaction out of Coral UI instead of placing it in the template for the page.
In my situation, these pages are only edited by a Author, and create data for nodes that populate other pages. These are never exposed to an end user. Hence why these requests may sound very author focused, it is because there is no consumer viewing these pages.
Your assumption is correct, and this is also documented.
Reason for that choice was not to interfere with the customer page's DOM anymore, like it was done in Classic UI. I agree his also has the drawback you mentioned.
In 6.1, we're introducing a keyboard shortcut to easily switch between the current editing mode (edit, target, etc.) and preview, and the layout of the header bar is also allowing to save one click, since the preview option is no more under the menu.
Regarding 6.0, you mention:
For example, a direct link to open a components dialog
What do you mean exactly? A link global to the page? For this we have an extension point.
One solution I see for the issue could be to create a toolbar button that would display a popover with the list of tabs, which can be selected, and that action would trigger the same action as if you'd click the tab in preview mode.
I would strongly recommend you to take a look at those, and reuse as-is if possible. Otherwise, we're happy to get your feedback through creating issue(s) under adobe/aem-core-wcm-components Github project.
The pattern for achieving such a task (select a non-visible tab/panel and edit) is reusable.
I understand the reason why. In this case, we have functionality on the customer page (the page is shown to the authors) that I would like to allow the authors to interact with.
The action of selecting the overlay layer to expose the toolbar, is a extra set of clicks that in this case are not ideal. There will be over 1000 interaction points between three pages, adding a extra click to anything would slow down the content authoring of our authors.
For example, a direct link to open a components dialog. I mean that we could embeded a link that opens a dialog directly. IE, not clicking the components overlay, then toolbar. The only action of authors on these pages, is edit components data, and switch between tabs that organize the components on the page.
I don't really understand how I can trigger from the toolbar, a tab within the content site itself.
Truthfully, the best thing, would be to flag a piece of HTML and exposing interaction to the authoring tools. In other words, the overlays that are created, would create a overlay for those elements as well, and route the click event to the real element.
We had the same issue, when we author for tab container or accordion component. For example, If we add Tab container on to page and author it to have three tabs. After authoring it display three tab on the page. there will be parsys for each tab. default it will be in tab1 with parsys, we can add components in tab1 parsys. Issue here is how can we author in tab2 and tab3 in edit mode itself ? instead going to preview, click tab2 and go back to edit and author tab2. Is there any solution for this issue in AEM 6.3 ? Thanks for your help !