search

phenaproxima / starshot-prototype

Prototype of a new kind of Drupal, based on recipes and loaded up with contrib's best modules and themes. Not a fork or a distribution.
https://drupal.org/starshot
117 stars 46 forks source link

Support some default block types #12

Open larowlan opened 7 months ago

larowlan commented 7 months ago

Operating under the assumption that we're likely to have a landing page content-type we probably want some block content types for inline use in layout builder.

Some that feel obvious

Could ship with two display modes for the cards, e.g horizontal (two-col) and vertical (single col)

phenaproxima commented 7 months ago

Definitely like the idea of shipping components like these.

The problem lies in the underlying implementation. Do we want to rely on blocks for this? If we do, I'm not sure the AX is what we'd necessarily want. We could rely on Paragraphs, at least for now, since we explicitly don't have an upgrade path.

The lack of a community-consensus component-based page building system is a huge liability for Drupal, and we do need to address it, but it's unclear what ecosystem (Paragraphs or LB/blocks) we should support in the near-to-medium term.

thejimbirch commented 6 months ago

Feels like an add-on recipe from the work that is starting in this initiative: https://www.drupal.org/about/core/blog/working-toward-an-experience-builder

Robbt commented 6 months ago

I think this highlights the sort of challenges that Drupal site-builders have experienced for quite some time and that is the choice of which Drupal ecosystem to invest in and what are the potential gotchas that come along with making certain choices. Experience Builder sounds like a great idea and this quote from the article shows the direction they are planning to take - "Based on our research, evolving Layout Builder, and enhancing it with capabilities that exist in Paragraphs today best meets these criteria."

I think one question to answer is what can be built without relying upon paragraphs and what are the drawbacks in terms of usability. Layout Builder is still pretty clunky to use out of the box and while there are a few add-on modules that do improve things (and could possibly be easily configured and installed via recipe), they still leave quite a bit of gaps in terms of your average site builder experience. Bootstrap Layout Builder is one of those modules but it needs refinement out of the box as it does things like provide duplication of columns as well as exposing absurd choices such as 11 column layouts. (It exposes the options for 1-12 column sections which is impractical for most people and clutters the UI). It would also require choosing a bootstrap based theme (which in my opinion might not be a bad idea but is another place where finding the best starting theme to build from isn't obvious).

phenaproxima commented 6 months ago

Frankly, I kind of like the idea of relying on Paragraphs for now, and changing to Experience Builder when it's ready for that. Paragraphs is what enables the most complete page building experience right now, and we should be pragmatic about that fact if our goal is to deliver as much value as possible as quickly as possible. (And that is one of our goals.)

Starshot has no upgrade or crossgrade paths, and support for those is not part of its concept, so I think it would be viable to change from one system to the other, and maybe fund a migration path in contrib, independent of Starshot itself.

Robbt commented 6 months ago

I agree that the project should move forward with as much value as possible but it's probably useful to pay as much attention to Experience Builder as possible. They're discussing what components should be included here

larowlan commented 6 months ago

I strongly disagree with recommending paragraphs because of the N revisions issue. I think if we can't agree here we shouldn't chose either and wait for experience builder

catch56 commented 6 months ago

Sites that install starshot will need to update and maintain their sites over time, once they're on paragraphs, it will be hard for them to get off it again. We know that core isn't going to adopt paragraphs, already has blocks, and that https://www.drupal.org/project/drupal/issues/3440578 is actively being considered to fix various problems with all the current solution.

It's one thing for starshot to not have an upgrade path itself, it's another to disregard the fact that potentially tens of thousands of sites per month will be installing each version of it, and 'temporary' solutions will become permanent for those sites, especially given the low code audience.

https://www.drupal.org/project/drupal/issues/3365551 will significantly improve the UX for blocks too (by not crowding the sidebar as much). If we don't want to use blocks because that's also likely to be temporary one json storage is implemented, that's fine, but I strongly disagree with choosing solutions that actively work against the direction core is taking.

phenaproxima commented 6 months ago

I think if we can't agree here we shouldn't chose either and wait for experience builder

I think this would be an extremely dangerous strategic mistake for Starshot. By "extremely dangerous", I mean I think it could sink the entire initiative.

It's my opinion that we are kidding ourselves if we think we can really launch Starshot, and have it succeed in the world, without some kind of page building solution that appeals to real-world users. We have to deliver something, and we'll probably have to deliver that something before Experience Builder is "ready".

To be clear, I'm not saying we necessarily need to go with Paragraphs, for any amount of time. But we DO need to have some kind of plan -- soon -- for what we will go with, and what the path forward will be. Even if it's not what we'd ideally like, it needs to be significantly better than LB's OOTB experience right now.

To me, this is a critical strategic problem. Making the decision on it is beyond my pay grade, but I heartily encourage us to take the risk very, very seriously.

phenaproxima commented 6 months ago

I talked with @larowlan today about this. I think it makes sense for us to ship a Card block type - it's such a widely used design pattern that it feels like a total no-brainer. Let's at least build the data model, and then in subsequent PRs figure out how to integrate it into page layouts.

Even if we don't bother with LB as a page layout solution, I can 100% see a use case for creating card blocks and placing them in, say, the sidebar.

The Card block type should have:

All of these fields should be optional.