Define how wireframes links block on the right should be created

I'm theorically inclined to 2) Use shortcuts, but in practice 4) Provide a new Dashboard "CTA" block looks like the best solution as-is right now.

Related: ✨ User Experience (UX) Review of the SEO Dashboard Active as it will affect how users interact with that dashboard too.

I'm going to touch on #2 regarding shortcuts, and adding the relevant issues I posted related to my dissertation with my findings, the main issue is 🌱 [PLAN] Users should be able to configure their own shortcut sets Active

- The initial survey is available in 📌 User Research: Survey regarding bookmarking features on Drupal Active and it gathered primary data regarding how useful having shortcuts might be for Drupal users.
- 📌 User Research: Interviews to evaluate improvements on the shortcut module Active focuses on user interviews with the improvements done (added a per-role and per-user shortcut set).
- The rest of issues are more related with actual implementation: 📌 Shortcut set default plugin Needs review , 📌 Users should be able to customise their own shortcuts Active and 📌 Users with enough privileges should be able to customise shortcut sets per role Active

It's worth noting that the same way that shortcuts can be created sitewide, per user and per role, there could be a per-dashboard plugin.

The ability to sort shortcuts was unveiled in this research, see Next steps/Further considerations in the extinct Drupal core ideas issue queue: 🌱 Improvements on Shortcut module Active

The code of my research is available in https://www.drupal.org/sandbox/pcambra/3421093 →

This are the relevant parts from my paper conclusions to this issue:

(..) while enabling bookmarking inside of Drupal is seen generally as a positive feature, there’s a valid point on the overlap of a Drupal module that provides bookmarks with the built-in bookmarking capabilities of modern browsers, there’s also a healthy contributed ecosystem outside Drupal core that provides advanced features such as quick access through keyboard shortcuts.

(...) share collections of bookmarks (shortcut sets) to users based on their role seems like the most wanted and expected feature, one that the current module doesn’t provide.

Due to time constraints, there were some parts left on this study that would need to be covered in future work, for example the user interviews show that sorting shortcuts is a desired feature.

There is a clear response from users and this study agrees with it, that the module in its current form doesn’t belong to Drupal core. However, an improved shortcut module can find its space, either in Drupal core or in the recently created Starshot initiative, providing that it provides sharable, customisable shortcut sets that can be private and per-role. (...) This has a major impact in this project and its recommendations, as the Shortcut module might be a better fit for Starshot than Drupal core.

The architecture and structure displayed on Chapter 4 could be revisited after seeing the results of the mixed methodology research. Given that users are expecting to reorder, but also edit their set of shortcuts, this project wants to wrap up by proposing an alternative database structure that could support these demands. Figure 21 below shows a variation that adds a multiple field for shortcut links, so the user would, instead of creating new shortcut entities whenever they bookmark a page, they would add a link to their new or existing shortcut entity.

This is the ER of the figure mentioned:

Happy to discuss/engage forward if shortcuts is selected as the desired option for dashboard pieces.

I think we should avoid using Shortcuts because, for reasons outlined by @pcambra, the current implementation is not quite what users want or expect and it is likely that the desired approach would be a rewrite.

In the last conversation with the core committers, Shortcut was identified as a module to remove from core in D12 and move to contrib. That doesn't mean we can't use it, but if we are going to prefer a new implementation, it would be a shame to be tied to it for this.

Plus, it seems like menu links and shortcuts have similar pros and cons so I would choose menu links in the head to head.

If the above makes sense then I think that leaves us with options 1 and 4? Overall 4 makes the most sense to me but understand it also has tradeoffs.

tl;dr: I’d suggest taking a route that can eventually provide sets per role and per user, or at least that makes it easy an evolution towards that.

Summary’s pros and cons are based on the existing solutions, and the existing UIs that we have have a really bad UX for the user on all cases. So I wouldn’t base the technical direction on the UX that each solution provides nowadays, even if one if slightly less bad than the others: I’d base it on research around actual user needs or requirements.

For example, I would love to take into account @pcambra’s suggestion coming from his research about builders wanting to have a different set of options per role. That, and the possibility to have private / per users sets.

Our goal is to eventually provide the best version of the features we can (even if it’s for Drupal CMS v1.5, v2 or beyond), and if a technical direction draws out future improvements I’d advise against those tradeoffs. For example, maybe having a set per role could be archived with menus, but I doubt it could provide per user sets eventually.

an improved shortcut module can find its space, either in Drupal core or in the recently created Starshot initiative, providing that it provides sharable, customizable shortcut sets that can be private and per-role. (…) as the Shortcut module might be a better fit for Starshot than Drupal core.

It's worth noting that the same way that shortcuts can be created sitewide, per user and per role, there could be a per-dashboard plugin.

I’d love to highlight also that @pcambra offered to write end evolve the existing Shortcuts implementation towards the direction we decide (at DrupalCon Barcelona 24’). So even though nowadays it might not be what we want, it could evolve to that (inside or outside core). So that wouldn’t imply the Dashboard team having to take on all that extra work.
The definition of that ideal user flow and UIs that would provide a better UX than what we have would need to be defined and implemented over time.

How much of a priority it is to have sets per role would need to be probably more research, but I would dare to say it is not a requirement for v1. That takes out the pressure to get it ready for January, but it should inform the technical direction beyond the initial set of pros and cons.

I spoke to @lauriii about this and we think it makes the most sense to use menus initially. The main reason for this is that menus won't require any new/custom work and will always be supported. So in the future when the new shortcuts are available, users could opt to switch over to use it, or not; they could keep using menu blocks forever if they want.

If we were to go ahead with option 4 that's something we'd have to worry about supporting and then deprecating and forcing users to move at some point.

So we totally agree that the proper shortcuts with per user and per role is the ideal future, but we also recognise there is no way we'll have this for v1. Meaning that the decision is what is the least problematic in the long term, and we think that's menus.

Based on this I created 📌 Provide a "Dashboard CTA" menu for the content creation CTAs Active for v1. I will leave this open for future evaluation, but marking Postponed for now.