Hi Atlassian,
Thanks for sharing this RFC. I have a number of reservations:
Byline items
I have concerns similar to the other comments posted so far. For bylines, what is wrong with the status quo? The rationale for making these changes was not stated, but I think this entire change would be a mistake. Byline items are used to deliver app-based features and functionality to users. Diminishing their visibility (and removing their easily-visible dynamic components) prevents apps from communicating in an effective way with users.
It is even less clear why the icons are being removed: text-only buttons are harder to discover and less memorable, and users are less likely to click on them. I imagine that the proposed app buttons/menus look more harmonized and similar when they do not have icons, but that is only a good thing if you want to file away these menu items and never actually use them. (I note in passing that absolutely everything else on the same line is adorned with icons for the built-in features that are rendered here. Imagine how difficult the page would be to read if you removed those icons too. If it is good for Atlassian, then it should be good for vendors too.)
If the problem is that there are potentially too many byline items shown, can Atlassian instead consider a method for controlling this, such as by allowing users or admins to hide or prioritize them? For example, see what was proposed by Atlassian in RFC-59.
Sidebar overflow menu lumping everything under “apps”
I understand that menu real estate is at a premium, but I think this is also reminiscent of the issue I mentioned in RFC-59. Third-party apps deliver functionality to users, and Atlassian is proposing to take these previously-defined localized extension points and throw all of it under a separate “Apps” menu.
The recent focus from Atlassian is to harmonize working across products (“System of Work”), but the proposed change goes in the opposite direction by creating an artificial barrier by throwing everything non-Atlassian under an “Apps” menu. Users do not know or care whether a feature is native to the platform or whether it is provided by a third-party vendor, and moving these existing items will create friction and get in the way of a seamless user experience. It also hurts discoverability. (Why do end users need to know that something is an “App” when they just want to approve the page?)
If the concern is (again) too many items in the menu, there are a number of other ways to solve the problem. For example:
- Allow app vendors to create sub-menus. If my (say) page approval app has options like “approve page”, “disapprove page” and “escalate page”, it might make sense to put these under a new “Page Approvals” submenu that is created by the app. But other options belong more properly directly within the content menu, where they have previously lived.
- Allow admins or users to control the order or hide items, or simply display the first ‘X’ items, with an overflow once vertical screen real estate is exhausted.
Missing various web-panels and web-items
Atlassian is positioning the direct-edit page as a replacement for the view page. From this point of view, direct-edit should support everything that the view page does. Since sites will potentially have both types of content, the two should be consistent in terms of extension points and rendering.
For example, what happened to the atl.footer extension point? This should also be rendered in the direct edit view.
Also, reading more closely, can you confirm if this RFC is actually a deprecation notice for the other plugin points you mentioned? Not just in the editor, but actually system-wide? (I am referring to page.metadata.banner, atl.editor.savebar, and so on.)