Dnn.platform: RFC: AdminExperience: Improve Initial Loading and Appearance

[ohine]

Request For Comments.

Please review the problem and suggested solution and provide your comments to help drive this feature implementation into a future platform release.

Description of problem

The control panel currently animates in on every page view and takes up the entire left border of the site. This can cause layout issues or make it difficult to work quickly because buttons and actions move around when this animation is running.

Additionally, there are 7 XHR requests on each page load which add to the performance degradation of the platform for content editors.

Description of solution

I'm suggesting we add an icon (3 gears?) in either the top or bottom left. This icon would always be displayed and part of the personabar loader. When clicked, it would render the entire control panel and then squish the page content.

As a bonus, if we can reduce and combine the 7 XHR requests at the same time into one query we should get a very noticeable performance improvement for every pageview of the site by a user with content editing permissions.

[ohine]

Current XHR requests as of v9.3.0.24

/API/personaBar/localization/gettable?culture=en-US
/DesktopModules/admin/Dnn.PersonaBar/Images/nav_Content.svg
/DesktopModules/admin/Dnn.PersonaBar/Images/nav_Manage.svg
/DesktopModules/admin/Dnn.PersonaBar/Images/nav_Settings.svg
/DesktopModules/admin/Dnn.PersonaBar/Images/nav_Edit.svg
/API/personabar/serversummary/GetUpdateLink
/API/personaBar/ServerSummary/GetServerInfo

[valadas]

I experimented a bit on the css of the persona bar and came up with a quick and dirty solution that would prevent having to push the site content by 80px. Basically I made it show only the Dnn logo on top left but instead of pushing the site content, I made it 50% transparent over the site content. That only covers a 80x100 pixels top left corner of the site, then on hover the whole iframe becomes opaque and expands in height. Works nicely on a device with a mouse, but I did not submit a pull request because that would not work on mobile. I guess with some javascript we could make the first click expand and opaquify the iframe, but did not have time to do it.

[sleupold]

IM it would improve performance, if we could use a single sprite for the nav_... images.
I am not sure, how difficult it would be to combine the other calls..

[sleupold]

IMO skin designers should get an option to specify a space for the persona bar to render. This would allow, if it is not a full width screen with space on the left, the PersonaBar to open without shifting site content to the right.

[ohine]

@sleupold I agree we should use a sprite for all of the main images in the admin experience, and an additional sprite for each of the extensions. It would be great if this could be automated and put into the build process when generating the installation packages.

[OllyHodgson]

@sleupold To an extent, skin can designers already do this. Default behaviour is for PersonaBar to squash the page 80px to the left. If they'd rather it sits on top of the page they can put body.dnnEditState { margin-left: 0 !important; } in their CSS (and even use media queries to vary the behaviour based on screen size). I know the inline styling on the body element makes it a little bit awkward but we could change that! What else would you like to see?

@valadas You're right, I think we need to move away from using hover for everything! It's crappy on touch devices and makes accessibility really difficult.

@ohine I really like the ever-present nature of the personabar. Editing a page or opening an admin pane is a one-click task. So if it gets folded away be default, I'd want to see some of "pin" or "latch" functionality to keep it open (and for that to last across sessions, perhaps using a cookie).

[mtrutledge]

I think this is really two separate issues. One is improving the performance. Which can be done without changing the UI at the moment, and I think it should be done. The second is changing how the Persona Bar is loaded via the UI. I agree with @OllyHodgson, I like the ever presence of the persona bar. I dislike all the hover states but doing this on mobile isn't a concern for my team at the moment. I think we need to plan out the UI / UX for the persona bar in wireframes / mockups before making changes to it. The community can then vote and the UI can then be implemented. I am not a UI / UX expert but I do know in the developer group there were several people interested in improving the UI / UX and we should get in touch with them.

[david-poindexter]

@ohine great ideas for improving the performance of the PersonaBar!

@mtrutledge regarding the larger UI/UX suggestion, there is already a team formed to look into this. They are in their infancy stages, but there is some hope there for a larger-scale effort. In my opinion, the last thing we should do though at this point is to just start building wireframes and/or design concepts for community votes. DNN is in need for "proper" UX work. This starts with establishing clear goals, developing personas, defining the ideal journey maps and then designing in alignment with those. Then we should do User Testing and iterate based on that testing. Rinse and repeat in harmony with the Technology Advisory Group (TAG) development life cycle.

[mtrutledge]

@nvisionative I am definitely not a UX expert and am glad there is a team doing this!

[ohine]

@nvisionative Any more insights into the team working on this and their goals? We need to get RFC items created an approved for the upcoming v9.4 release so work can begin.

I've got quite a few items and items I'd like to port over from my control panels.

It would be great if we could get some transparency on what teams exist and who is working on what to prevent any wasted and duplicated efforts.

[ohine]

@OllyHodgson

I really like the ever-present nature of the personabar. Editing a page or opening an admin pane is a one-click task. So if it gets folded away be default, I'd want to see some of "pin" or "latch" functionality to keep it open (and for that to last across sessions, perhaps using a cookie).

The idea would be if you click and pin edit mode (clicking the edit pencil twice), then the panel would always be visible. Otherwise it would collapse down back into the main gear. I also want to stay away from hover actions, tap/clicks would be required for anything I were to add in.

[david-poindexter]

@ohine as stated, this group just formed and it is way in the early stages (just one initial meeting). So far, no clear goals have been established, so there is nothing to share or coordinate at this moment other than awareness and helping to establish a protocol for collaboration, etc.

[mitchelsellers]

My customers all love the fact that the PB is always there, and the slight delay doesn't seem to impact them in any sizeable manner. Combining items into a sprite etc I think is a great performance optimization and is welcome.

However, I too would defer any UI/UX changes until we have a longer-term strategy in regards to the changes. We want to limit impacts to the ecosystem that has already had to "bend" to the wills of edit experience repeatedly changing in the past years. We also need to consider Mobile/Tablet users which I think would be more impacted by additional hover/open-close type interactions.

[valadas]

I made it show only the Dnn logo on top left but instead of pushing the site content, I made it 50% transparent over the site content. That only covers a 80x100 pixels top left corner of the site, then on hover the whole iframe becomes opaque and expands in height. Works nicely on a device with a mouse, but I did not submit a pull request because that would not work on mobile.

When this pull request is merged, I can submit another one with this idea for review now that it would work with keyboard too:
https://github.com/dnnsoftware/Dnn.AdminExperience/pull/110

[valadas]

I think this is really two separate issues. One is improving the performance.

I agree, however they kinda relate, I don't mind _too_ much that it takes like 2 seconds to load, but it really drives me crazy when I go to click on a page element and it suddenly moves right out of the blue because the PB pushes the page. On some modules that have the tiny delete button next to the tiny edit button, that is really dangerous too :)

[valadas]

Ok, so we have at this moment 2 PRs that related to this:

https://github.com/dnnsoftware/Dnn.AdminExperience/pull/110
This one brings accessibility to the PersonaBar container, it works very well but need an additional touch-up to add a skiplink to be able to return to the site using the keyboard, a simple screenreader only link that would go to the #body target of the parent frame. I can submit that after it is merged. I know this is not strictly related to this RFC but if we change how the PB loads, it will probably invalidate this very good PR.

https://github.com/dnnsoftware/Dnn.AdminExperience/pull/394
Solves the sliding effect by having a placeholder in place so that the site is "pre-pushed" before the PB slides in, thus avoiding the site moving issue. This one could be improved so it does not rely on 2 PRs (right now it depends on another PR on Platform).

Then another option that was discussed in Slack was to make the PB container render server-side, so it would avoid the delay altogether, we can just remove the animation and the PB is just there at the same time as the rest of the site. Bat that would be a larger effort and require to redo the accessibility because it would probably invalidate the existing PR.

I also had an idea to make it collapsed into just the Dnn logo semi-transparent and absolutely positioned. Hovering it or keyboard focusing it would expand the PB down and make it opaque (still absolutely positioned to not push the site at all. It looked nice at first but accessing the editbar by mouse would require hovering the logo, scrolling down inside the PB 80px down to the pencil. So after testing, I did not like my own solution much. I had another idea to leave the pencil on the bottom right when the rest of the PB is collapsed, but that would also be a larger effort and still invalidate the accessibility PR.

So, I see the following choices:

1. Merge the 2 existing PRs, improve them a little and call it day.
2. Discard the existing PRs and server-side render the PB container.
3. Discard the existing PRs and make the PB Dnn logo on top left and Edit icon on bottom left as overlays that expand the PB or EditBar on focus (hover or keyboard).

Option 1 would be quick and is pretty much ready to go (with 2 small improvements) it could even be part of the current RC if people agree, options 2 and 3 would be better but would require more efforts and would be pushed later. We could also go for 1 now and do 2 or 3 at a later version (or even a combination of 2 and 3).

Toughts, votes ?

[ohine]

I'm all for constant improvements, if something doesn't work we can adjust it in the following release or better yet hopefully have it identified in an beta/rc cycle and fixed before a final release. Anything is better then ignoring the issues.

I have a million ideas from developing and maintaining custom control panels for our clients over the last 10 years. I'd love to start working on getting them into the platform, it seems however the group is split and we're not allowed to make any UI/UX changes. This makes donating time into the AE project very difficult since we're not allow to really take ownership of this extension and make some much needed improvements.

As for your suggested options, I say we merge the current PR as an interim solution to the visual sliding/animation delay, and then work together on a more permanent solution that also address the poor performance out of the admin experience.

[valadas]

Yep, so the interim solution is at https://github.com/dnnsoftware/Dnn.AdminExperience/pull/394, just needs one more approver, and I would vote to include that in the current RC since there is not really any risk and it would make many people happy until we do something better with more time.
As for the accessibility PR at https://github.com/dnnsoftware/Dnn.AdminExperience/pull/110 I found a couple issues with it, so I would'nt let the fact that it may need to be redone block us from other solutions, we can keep it as a reference but rewrite it after we figure out how we do the PB initial loading.

So, my vote now would be to rewrite it to be initially rendered server-side, as we do so, we can implement accessibility at the same time (use buttons and links more than divs and spans; have proper labels or aria-attributes, etc).

[mitchelsellers]

Given the work that has been done on this effort already, I am going to close this RFC. We are tracking improvements to the PersonaBar for both build & accessibility in other channels.