starshot-prototype
starshot-prototype copied to clipboard
phenaproxima
Consider adding the Editoria11y module
It is a small but very useful module validating content for accessibility issues https://www.drupal.org/project/editoria11y. That validation happens automatically, the content editor doesn't have to activate anything by pressing a button or consult a dedicated dashboard. The checks happen for the rendered content which surface issues that only happen on assembled pages and it is solely focused on content related issues, completely decoupled from frontend or backend related issues in code, providing direct actionable feedback to the person editing the content. If you combine it with same page preview, that was raised for consideration https://github.com/phenaproxima/starshot-prototype/issues/17, you directly get the feedback about accessibility issues while editing a node. Without same page preview the content editor has to visit and view the node on the front end.
I don't have any particular objection to this, from my perspective. I'd love a +1 from @pameeela or @goba, though.
That said, if we add this I think it would maybe make sense to put it in a separate recipe that is in the recipes directory, but not installed by default. We could expose it to Project Browser as of #74, as optional functionality to be bolted on painlessly.
I reviewed this module recently. I really liked the way it worked and looked and it was low configuration. It would also have the side effect of enabling more people to test accessibility in starshot.
I agree with @phenaproxima that I don't necessarily think it should be enabled by default. It feels a bit heavy for a new user who may not understand what it is or why it's there. But I can also see an argument where this introduces the concept and best practices to a whole new set of users.
I haven't used the module before, just tested it out on a fresh Starshot install. The blog page is fine but it seems that the map on the event page is causing lots of issues. If the map is not accessible I guess we need to look into that! Or are these false positives? This is a very confusing experience even for me, if I were a new user I would be totally thrown by this.
We're currently defining the issue that would allow the user to install optional recipes. https://www.drupal.org/project/starshot/issues/3447749#comment-15601837
I agree, especially in that case, that it should be part of an optional a11y recipe.
@phenaproxima just one general question for my better understanding. should starshot have a similar approach like core? Core ships with a certain number of modules, depending on the install profile some are installed and the rest is in an uninstalled state. so with starshot there is an additional number of modules available to the site then, some installed and some uninstalled like core?
@pameela not really false positive but no real helpful reported issues either in this case. editoria11y is notifying you that the map tiles from openstreetmap dont have alt text. i have to admit i havent run into the case of maps in combination with editoria11y yet. but the easiest fix in that case would be simply adding .geolocation-map-wrapper *to the "skip over these elements" field on /admin/config/content/editoria11y . that might be one viable approach @itmaybejj confirmed on slack handling this issue, the better option in the long run according to him is adding a hook by which modules can inject selectors they want ignored.
@rpkoller Yeah, pretty much. Starshot shouldn't just provide you with everything everywhere all at once. It should give you a lot of useful stuff right out of the gate, but also make it very easy to bolt on more useful preconfigured stuff, even if it's not installed right away. So the approach is similar to core, I think, but the "gates" are different, and the effort to reward ratio is a hell of a lot more favorable in Starshot.
Since Starshot uses recipes, "adding more stuff" is a lot easier and more useful in Starshot than it is with core. With core, "adding more stuff" means an arduous journey of finding modules, choosing modules, and then configuring modules. With a recipe, that shit's all done for you and you pretty much just need to copy and paste a terminal command to get it.
@phenaproxima ah thanks for the confirmation and the further explanation! And I agree, recipes already at this point, right after phase 1, improve the experience significantly.
The only slight worry I would have is that having a certain number of modules already installed and having a few more added but not installed yet with starshot might be potentially overwhelming to stay on top of it, in particular for users new to drupal. I already followed along the plans about adding some sort of dashboard for installing additional recipes that were shipped with starshot. but i wonder if alongside providing those actionable items it wouldnt be mandatory to reflect the recipes available (installed and uninstalled) on the extend page as well on a dedicated page, same as modules.Then there is also the point about project browser (the discovery of modules, and then themes and recipes soon after) and then there is also the concept of feature flags modules like Layout Builder Expose All Field Blocks that got introduced. i've already raised the topic for one of the upcoming usability meetings. but maybe it would make sense to have a bigger group discussing that problem space. Cuz from my perspective the extend page with, project browser, recipes and feature flag modules definitely needs some discussion and further improvement to keep the user in control.
Sure. I say: who says we need to show every recipe to users?
I think it makes perfect sense to "feature" some recipes (a curated list) that provide the most bang-for-your-buck, so that new users are not overwhelmed. Put the most useful stuff forward, but be selective about it...and ensure that folks can browse the big ol' vault of recipes, if they want to.
It's a tangent, but my $0.02 is that it sounds like thinking about recipes as a place to put modules that don't make the cut means dodging the hard decisions needed to make a competitive out-of-the-box experience.
The competition here are things like WordPress and SquareSpace: you install it, you start using it, and the things you built from what you installed on day one will probably still work ten years later. Sure you can install modules/plugins, but there's a very strong and clear divide between "core" and "community."
Me fear is that featuring multiple recipes of things-that-aren't-core could reinvent the technical-debt-trap of things like Install Profiles and Lightning -- people installed a constellation of things they didn't understand, and when the updates stopped coming because some sub-module was abandoned, they were cooked, because they didn't have a real developer in their group.
I'd much rather StarShot have a much more binary gate: a really heavy and robust experience out of the gate, one that sweeps a large number of modules into this new "heavy core" that comes with a community commitment of long term support of everything therein, so that all the groups out there that don't have real developers never even have to learn what a recipe is -- the CMS that we think of as a constellation of contrib modules but they think of as "software" -- "just works." Maybe parts of it are disabled and enabled, and those are secretly recipes under the hood, but there's a strong wall between "LTS features of the StarShot core experience" and "the wild west that is the modules project browser," without a fuzzy "featured recipes that are cool but have many fragile dependencies, and featured does not imply there's any more community commitment than the wild west."
....thaaaaaaat said....as the new vertical admin toolbar and next gen layout builder UI mature, I'm available for the dev work to adapt Editoria11y to visually integrate more closely, and tune its defaults to play nicely with all the modules that will be in the new StarShot core.
when the updates stopped coming
To be clear, Starshot does not and will not have an update path. Recipes don't have update paths. Just to confirm we're all on the same page about that. :)
new "heavy core" that comes with a community commitment of long term support of everything therein
I wasn't aware that "inclusion in Starshot" guaranteed community commitment of long-term support. Obviously Starshot's governance is still undefined, but including modules in Starshot doesn't necessarily mean those modules will be maintained, nor does it have any bearing on who will maintain them. So the technical debt trap doesn't exactly go away -- it's just not exacerbated by the additional need to maintain a distribution.
I want to be very clear that Starshot is not a new form of core. There is no "Starshot core"; it's a starting point. It's meant to be a pile of recipes. There's a fine line we need to walk here between including many modules that improve usability and usefulness, and installing too many things that, to use your phrasing, will end up becoming a constellation of things that users either don't need, or don't understand, with no guarantee of long-term maintenance or viability for them.
I apologize if I'm misunderstanding any of your points here; Starshot is a very new concept, as are recipes, and communication on them is fuzzy even as those of us who maintain the system figure out the guidlines. :)
I wasn't aware that "inclusion in Starshot" guaranteed community commitment of long-term support.
I mean, of course nothing is ever guaranteed in the long run in an open source community, but if this project is working to make base and featured recipes pushbutton to install by sitebuilders in the GUI...it seems like that would give sitebuilders the expectation that updates would also be pushbutton in the GUI.
My $0.02 is that I think there should be a very clear "here be dragons" divide when crossing into recipes that may require a backend dev to update/migrate. And if there aren't any recipes with an LTS commitment, StarShot should be careful about marketing itself as something sitebuilders should use if they don't have backend devs on their team.
The idea of "an LTS commitment" is sort of contrary to the purpose and design of the recipe system itself. Recipes are not meant to stick around -- you're meant to apply them, and then immediately delete them from your code base. Drupal will have zero idea that they were ever there. Updates, as you're conceiving of them (I think), can only be done by modules using hook_update_N or hook_post_update_NAME(), just like it works today.
I do agree that Starshot needs to be careful in its messaging; it's my feeling that we should lean the hell in to the concept that Starshot is a starter kit, containing best practices and modules of a particular point in time, and once you start with it, it's Choose Your Own Adventure from that point onwards, same as if you'd started from bare Drupal core. The idea of having it be a product that is continuously updated is more of what a traditional install profile-based distribution does, and implies some lock-in. That's not something recipes can or should do, and by being built on recipes, I don't think Starshot should give people even the foggiest idea that it's something it will do.
But, making that clear to everyone is outside my pay grade. :)
To put it another way, Starshot (as I see it) is a launching pad. Not a generation ship.
Fair enough. Makes me sad but...
OK back to the topic at hand: yeah, as the recipes mature, please do consider Editoria11y, for the simple expedience that some sort of accessibility checker makes a big difference, and this one's turnkey. Plus, it has a large enough install base that I'll need to make it work out of the box with any of the featured recipes regardless, so the integration shouldn't take more work for y'all than throwing an occasional issue my way to map out a false positive in the base config.
I think one distinction is that Starshot can "feature" or "recommend" recipes, and therefore modules, but it won't ship with optional modules because they only get added when the recipe is applied. This is an important difference from core. So it wouldn't be the case that Starshot would add a bunch of modules that aren't enabled, even if it does ship with those recipes. Plus, the recipe browser would show you even more options to add recipes relevant to your use case, so there isn't that much need to ship tonnes of recipes within Starshot.
I do think that in some of the discussions, the idea of recipes is being conflated with Starshot itself, because they kind of both hit a wider audience at the same time.
No matter what, this module would be great as part of an accessibility best practice recipe that is available to the wider Drupal user base. (See #84 for a similar discussion.) Whether it is enabled in Starshot by default is a totally different question. I think, probably for now, it shouldn't, but my opinion is just one among many.
Using best practices for Starshot is mentioned a few times, and I agree. One of the best best practices in Drupal is to not install a lot of modules. As I see it, Starshot should be a robust starting point showcasing and exemplifying best practices, delivering a Drupal web site ready for production "Out of The Box", like WordPress and SquareSpace do. But I am not a LTS-commitment proponent: After install, the user has the responsibility for maintenance.
So we could have tier 1 recipes, which are included in the official Starshot, and tier 2 recipes which are more "nichy", for example a Commerce solution, or Editoria11y. Like @phenaproxima wrote, and I agree:
... I think it would maybe make sense to put it in a separate recipe that is in the recipes directory, but not installed by default. We could expose it to Project Browser as of https://github.com/phenaproxima/starshot-prototype/pull/74, as optional functionality to be bolted on painlessly.
and
I think it makes perfect sense to "feature" some recipes (a curated list) that provide the most bang-for-your-buck, so that new users are not overwhelmed. Put the most useful stuff forward, but be selective about it...and ensure that folks can browse the big ol' vault of recipes, if they want to.
Alright last argument from me in favor -- it's now included in a lot of distros for new sites.
Which is to say: as a maintainer I don't want to toot my horn. But in my other hat, as a developer and accessibility tester... it's a mandatory install on all ~1500 of our sites. And that is not reported. Same with many of our higher ed peers -- many disable the upgrade module in production, and have hundreds to thousands of sites each running Editoria11y.
So it might be interesting to ask around at the agencies and groups involved in StarShot, and ask "is your group already recommending X on your own new sites?" It might surface modules that are more recommended than realized.
To name a few -- I've seen pull requests or activity from:
- Many agencies, e.g. Acquia's own demo framework and marketing content, Varbase core, the Open Scholar platform, Evolving Web, Phase2, CrowdCG, Druid, Calibrate, Nerdery, Druid, Minsky
- Many higher ed institutions that have it in their distro, e.g. Princeton, Yale, Stanford, McGill, Penn State, UPenn...
- Government too, e.g. NCDC
So...all to say: I didn't open this issue, because I'm uncomfortable saying "hey my thing feels like it should be everywhere," but...since we're talking...I mean...I honestly don't think any new Drupal sites should go live that aren't running something like this, and if the point of StarShot is a recommended starting place...well...I do think this fits in well in a recommended starting place.
Just wanted to post here, if anyone is interested in leading a proposal for accessibility tools in Starshot, we are looking for you! https://www.drupal.org/project/starshot/issues/3461535
The brief is somewhat intentionally vague to leave open possibilities; it could be that the proposal is 'include editoria11y'. Or maybe there's a set of tools and config that would be beneficial. If anyone has questions, posting them in the d.o issue is probably the best place.
After removing some other items to be considered seperately, I have been left with a PR https://github.com/phenaproxima/starshot-prototype/pull/142 that adds Editoria11y to the project browser.
As it is in the PR, the module will be shipped with Starshot but not installed by default. It can be installed via the project browser and contains an specific configuration item to bypass the a11y check on the leaflet map, due to the amount of noise generated regarding the empty alt text on the tiles etc.
Editoria11y was added in #142, at least for now (it may or may not be part of the "real" Starshot product). Enjoy!