🇬🇧United Kingdom @tonypaulbarker

liampower → credited tonypaulbarker → .

rachel_norfolk → credited tonypaulbarker → .

tonypaulbarker → created an issue.

@phenaproxima I’m not sure it makes sense to have a recipe for each media type. Potentially the image styles should go into the base recipe, even. I’m going by a very loose definition of recipe and keeping an open mind. I think we can make better choices when we see how the configuration and dependencies look. I intend to ask for feedback on that very soon.

@pameeela @phenaproxima thank you! The UX suggestion is a decision for core. Marking closed (works as designed).

Imprint is not a familiar term in the UK. I don't think there is a realistic proposition of a one size fits all solution to content for these pages. Depending on how an organisation processes data the wording will vary even within the UK.

I think that oftentimes default content will not be changed, so I think we should offer guidance and tools. Worst case scenario I believe is that well meaning individuals think they are compliant because they have generic content when it is not relevant to their case.

For UK websites, I would recommend people read and follow the guidance on the Information Commissioner's Office website and to use the privacy notice generator.

If we do have any desire to generate content that ICO generator would be a great resource to look at.

https://ico.org.uk/for-organisations/advice-for-small-organisations/crea...

https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-el...

I understand that the Content Strategy document does not specify technical information like widgets but they are being discussed. I expect that we will use media reference fields for all image fields. I have written up an issue to describe why I think we should not use image fields directly on other entity types like nodes → in Drupal CMS.

tonypaulbarker → created an issue.

I'm updating this from plan to task. We will ship the first version with Olivero breakpoints.

There are also some thoughts about breakpoints, containers and grids on this issue https://www.drupal.org/project/drupal_cms/issues/3468896 📌 Define a consistent set of breakpoints, contained layout rules and grid rules for rendering media Active to follow up later.

stella → credited tonypaulbarker → .

Thanks @jurgenhaas we did discuss image styles and also their limitations. I won’t expand on that here, as I will be covering that in some depth in action points 2 and 4.

Please let's also credit gábor-hojtsy for instigating and organising the discussion and thanks to @pameeela too for facilitating.

Thank you again to everyone for their guidance.

To add that we discussed possible approaches to creating instances / derivatives / copies / clones of media entities or media assets so that the same asset can be transformed in different ways in different places.

We think that for image manipulation tools a similar approach to experience builder, using React, may be taken. We expect that improvements to any such tools will be contrib.

The action points for me are:

1. Publish the discovery to date to a Drupal CMS issue
2. Outline the vision and long term objectives and publish to a Drupal CMS issue
3. Identify related issues in the issue queues that we would like to try to resolve to achieve success
4. Evaluate approaches
5. Make people aware as early as possible of modules and features we might need even if we are not sure we will need them so that we can make better choices

longwave → credited tonypaulbarker → .

gábor hojtsy → credited tonypaulbarker → .

@cosmicdreams on slack there is not a dedicated channel for the track so far, but there is the #starshot channel. I will check out the case in your linked issue when I'm back at my desk next week.

More planning is needed for both SVGs and CKEditor (also views and some other things) so I created a couple of issues to look at those: Topic Discovery and Planning: SVGs in Drupal CMS → and Topic Discovery and Planning: Media in CKEditor in Drupal CMS 🌱 Topic Discovery and Planning: Media in CKEditor in Drupal CMS Active .The first task is to identify the various ways that people are using them, challenges and opportunities. Any comments or notes you could add there from your experience would be really useful. Thanks!

tonypaulbarker → created an issue.

tonypaulbarker → created an issue.

tonypaulbarker → created an issue.

Here we need to consider that people add their own types so there can be many, many items on this list.

I think we have these three things to consider:

1. Navigation structure
2. Handling many / unknown number of items
3. Presentation and ordering

Navigation structure

@catch makes a great point that media and redirects don't belong here. From the top level of this menu, I would expect to select 'media' to create a media item. We should consider only having content types here. That being the case renaming 'Create' to something more informative for that scenario. I don't think 'Create' by itself is the right word because it can easily be confused with carrying out a creative task like setting global colour and theming parameters.

For figuring out the structure in the menu for these items, this is a perfect candidate for a tree testing exercise.

Without putting work into research, I think we would find that content types are a special case and if we have 'create' in this menu for other things it would fall below a top level item for the topic. For example, 'Add new redirect' should be under a top level 'SEO' menu item; 'Upload files' should be under 'Media' top level menu item.

For an entirely different approach, @ifrik might be onto something with the mockup in #4 if users could expand and collapse 'create' but I don't think we could have it always expanded, as it would increase the size of the top level.

Handling many / unknown number of items

If we only have content types here then it might also solve the many items problem but we might still think about what a user sees when there are 40 content types. 'More' links are the obvious thing or just the ability to endlessly scroll, but there might be other design devices.

Presentation and ordering

For ordering, the most useful thing for users I can imagine would be that the first items in the list are their individual most recently used or most used, the most used by all users of this instance, or the most popular based on some analysis.

I can see the use case but I'm (probably) not in favour of heavy duty configuration in core because the less cluttered the system, the easier it is to use. I think this would be for a separate issue, but we could add in place editing and handles across the navigation so that either users with elevated privileges could rename headings and reorder items in place globally or each user could set their own. If a majority of users do want to do more than this, it's an indication that we haven't got the default behaviour right.

I think icons would help - even for custom types there are popular names that we could provide icons for

Quick win?

With what we currently have in place I would suggest this for a quick win and then follow up with design and ideation:

Group the items by entity type with a heading (Content Types, Media Types) just as described in the 'Proposed resolution'
Decide on a sensible limit for items in each group
If more than the limit, print a 'more' link

tonypaulbarker → created an issue.

Thank you to all the contributors to the questionnaire and for help with research

@jonathanshaw I think that https://www.drupal.org/project/media_alias_display → might help you with 3? If you try this, please let me know how you get on.

Thank you for your thoughts too @guptahemant

The questionnaire is published and currently open for responses at: https://docs.google.com/forms/d/1OkOZDnHT06-s9nkz-nEnz_4hYJtlQRcNuDtGTKK...

The issue for the research and discovery component of this track is at https://www.drupal.org/project/drupal_cms/issues/3468901 →

Thanks @jurgenhaas @scott_euser

The media types have different properties as you point out so I am keeping a very open mind about how we classify media and will not only follow the defaults. I would be surprised if we decided not to have some form of remote video.

#8 I think as we create more recipes over time facets it is likely to be included for other things, an example use case is for filtering documents. Just now it's early days so we don't have a roadmap but I think eventually we will have different flavours and if your use case doesn't require any filters, or it doesn't even require search, then you won't have that feature and you won't have its dependencies either.

tonypaulbarker → created an issue.

Some notes:

Initial suggestion for breakpoints based on optimised media.

Breakpoint 1 - no media query - 1x and 2x
Breakpoint 2 - all and (min-width: 640px) and (max-width: 767px) - 1x and 2x
Breakpoint 3 - all and (min-width: 768px) and (max-width: 1023px) - 1x and 2x
Breakpoint 4 - all and (min-width: 1024px) - 1x and 2x
Breakpoint 5 - all and (min-width: 1024px) and (max-width: 1199px) - 1x and 2x
Breakpoint 6 - all and (min-width: 1200px) - 1x and 2x

Initial suggestion for grids is a set of rules based on a subset of the same breakpoints.

Initial suggestion is to define a width for contained layout for content (based on the breakpoints, either 1024px or 1200px) and a contained layout for text fields for readability, usually around 700px depending on the font size.

tonypaulbarker → created an issue.

tonypaulbarker → created an issue.

I like everything I read. I can think of plenty of ways that it can be extended but it makes a lot of sense to start simple. I would like to understand the JavaScript front end in detail at some point, but since you're providing a standard front end display that sounds as though it can only be a big bonus.

@jurgenhaas please could we add the Media Management track to the list of tracks for attention? https://www.drupal.org/project/drupal_cms/issues/3461533 →

In particular, we need to consider privacy and compliance for embedded media, such as embedded YouTube videos that track users. I am conscious too of identifiable data relating to media such as names, faces and location especially if we have exif data uploaded or at some point we use features like face detection AI.

@pameeela thanks for the clarification.

I haven't seen Squarespace and I haven't seen Wix Studio or many of the others mentioned in an RFP. WP and Umbraco along with Drupal would be much more common in the UK market. But - it depends a little on what we are including in the figure. I think the scenario for a quickly launched conference website could easily fall into a lower budget range. If that budget - I think we should clarify too whether that number is for year 1 - includes some things like design, marketing input, content creation, photography, SEO support and so on then it can exceed the lower end of the budget for start ups no matter the technology choice. Small agencies that are focussed on branding and design rather than engineering are an example where the cost of the technology platform and hosting might be a smaller component of the overall budget. Squarespace has quite a large market share so I don't think we should overlook it. See also https://www.squarespace.com/designer/home

I think these design focussed small agencies could adopt Starshot where currently there are barriers to being able to select Drupal Core.

Hope this helps!

A little bit of early feedback. I think the competitor list needs review. Leaving out the enterprise competitors, I was surprised to see Squarespace omitted given that Wix is included. I think Umbraco should be included at this level. WooCommere and Elementor likely merit inclusion as part of the WordPress family.

#28 worked for me. I do not have the cases described in #29. I think those cases are less common than my case, which is no dots in the filename and converting JPEG to WebP. This issue describes a problem for webp images and I don't think a problem has been reported for other file types. As long as we don't introduce new issues, could we improve this for the majority of cases and then other potential cases be handled on follow up tickets?

If we think there is scope to do more than minimal work on this then maybe it should be an additional track?

tonypaulbarker → created an issue.

Will this dashboard persist after the site has been packaged up for hosting? We might want two different sets of messaging for the 'trial' step of the journey before the site is exported and the more permanent 'hosted' version. Perhaps we don't have answers to all this just yet.

This may not be the right place for the discussion about naming (there are several issues referring to this dashboard).

Could we think about the words 'finish your site'?

If we think about continuous improvement, we could say that a site is never finished.

I think the language is important to get correct early on, because the title of this dashboard is going to describe what it is intended to do, that might inform what features it has.

What is that? 'Personalize your site' ? 'Customize...'? 'Manage...'? or truly 'Finish'?

Some of those words might seem a bit uninspiring, can we come up with something that sparkles?

Will this dashboard be the same to come back to later at some other point in the future, or is it a one off post install screen? It looks like a place I would keep coming back to.

John Cook → credited tonypaulbarker → .

@larowlan yes the update seems to have all applied fine and I see the new code in the codebase.

I will see if I can reproduce the issue on a fresh copy, run some tests and do some debugging and see if I can spot anything.

Hi @larowlan

I think this was released in 9.5.4 but I am observing it in 9.5.5.

The log message is:

Error sending email: Email xxxx does not comply with addr-spec of RFC 2822

Remove comma from the 'From' field and the mail sends.