Out of The Box initiative

About damn time we did something like this. I will be watching the progress of this issue with great interest.

I understand this is not the use case. And I am glad to hear that, because the scope is way out of the league of Drupal core.

Big companies demonstrating big wow features (but it could eventually become the starting point for such a thing)

If anyone is interested in that use case, something for this exists. Its a full-time job for 4 of us at Acquia to work on this. Its open source too, as a distro. http://drupal.org/project/df -- we'd love to get more companies contributing to the Drupal demo that's been landing deals with massive companies. Trust that if Acquia has released press about any major clients, this distro was used to show them Drupal.

Back to the issue at hand

As someone who has spent the last four years working on Drupal demos, I am very glad to see this initiative taken up. I do worry about projects like this though, because they tend to start very strong - everyone has content ideas, everyone has design ideas. The actual work of making things deployable for an install profile is much easier now than before. That said, it will at times prove difficult to do all of this with just Drupal core.

The one thing I have to try to block for this is usage of the default_content module. I believe it would be a mistake to include that module with Drupal core. Default content can be handled with migrations by simply folding migrate_source_csv (a single class) into migrate module in core. My argument against default_content being used here is:

We'd be setting a poor example for how to do scalable default content for install profiles. Why? Because unless you only have 5 or 6 "demo" nodes, it becomes unruly to edit json exports for all the different pieces of content. If you add or remove a field from a content type, then potentially hundreds of these default_content exports will need to be edited and updated. Its not a scalable system and this demo profile would certainly be one to point to best practices. With CSV, you add or remove a column and all the default data can be added in a single worksheet.

The kind of persona that would work on default content (content editor, BA, PM) can definitely handle a CSV. Yes, JSON is *somewhat* accessible but it still involves understanding the underlying structure of Drupal and understanding complex array structures as represented in JSON.

I implore you to use Migrate for this demo profile. Not only will this help stabilize migrate, but it will also prevent us from having to fold even more experimental contrib into core.

Aside from that, I am excited to see what types of things this initiative brings to the table.

Finally, welcome to the world of Drupal demos! Feels good to not be such a snowflake in the community anymore.

The one thing I have to try to block for this is usage of the default_content module.

I think even @larowlan is not suggesting we put default content module in core. IIRC what he suggested in Dublin was a more hard-coded solution specific to this profile.

The idea has been approved during one of the product management meetings, lets move forward and get the necessary plan(s) together!

This initiative has (at least :-) four parts to it:

- Show off new (experimental) features
- Introduce sample content to improve discoverability of core concepts and features
- Make all of the above look and feel good with a theme that supports the sample content
- Create a space inside core where all this can live: the experimental installation profile

Though all interlinked, we probably want to eventually create a plan for each of these.

Besides continue to plan all these things, the most concrete and actionable step would be to start working on getting the actual environment where all this happens in place: the experimental "Demo" installation profile. How is it presented in the installer, how can you tell that this is an experimental Demo that you should not use as a starterkit for something you want to use in production, etc.

Is a secondary effect of this initiative: (optionally) expose a web service and allow folks to create reference apps showing how to integrate other frameworks using Drupal's data? (ex: React, Angular, Web Components)

No. :)

Check out #2873748: Contenta CMS: An API-first Distribution which might share in the default content part of this.

@cosmicdreams but! in the mean time the folks working on the API-first distribution did connect with the work here and decided to work off of the content model we're proposing here for any decoupled demo apps they might want to make, so that "no" might well become a "yes" sooner or later :)

Awesome!

Hi all - are the meetings no longer at rotated timezones? Calendar seems to show them all at 4pm UTC?

Bumping to major since this is one of our top 7 targets for 8.5.0.

I really think this initiative is missing the point of UX problems in Drupal. The problem is that UX bugs don’t get enough priority on purpose: https://www.drupal.org/node/45111

- #296693: Restrict access to empty top level administration pages
- #2756331: Custom blocks cannot be properly exported and imported
- #2791405: When installing a site in a language besides English, the site name is not saved and reverts to "Drupal"
- https://drupal.stackexchange.com/questions/226263/how-to-resolve-configu...
- change the default language... boum! (so why I can do that?)
- edit field with admin in different language... boum! (so why I can do that?)
- Install Drupal in different languages than English, then setup multilingual -> welcome to config's langcode hell (so why I can do that? Why nobody tells me during the install it's was going to be painful?)
- And hundred others...

Those kinds of issues take a lot of time for site builders and make peoples feel Drupal is stupid. Personally, I think UX problem that affects site builders should be top priority.

I think nothing stops anyone (perhaps yourself?) from creating a new idea called "Improve site builder UX" with those types of things in the list. But that's not the problem this particular initiative is trying to solve.

This initiative is trying to solve the problem of when evaluators go to stand Drupal up next to literally anything else, it appears to be both dated design-wise and limited in functionality. It takes a long time to go up the learning curve of nodes, content types, views, entity relations, theming, and how all of it fits together in order to realize the power of Drupal, and so most don't bother and just reach for something that looks like it'll do what they want in 15 minutes. (A huge contributor to WordPress owning 25% of the web and us more like 2%.)

When this initiative is complete, evaluators will see within 15 minutes what a fully-featured and fleshed-out Drupal site can do, that they can then tinker around with and learn more about how it works under the hood.

Some time much later, they will run into site builder UX problems, and I would agree it's important to address those as well. But just because those problems exist and this particular initiative isn't aiming to tackle them, doesn't make this initiative any less valuable for the set of problems it is trying to solve.

Hi @gagarine, I absolutely agree with the point that Drupal needs this huge improvement in UX. But this initiative isn't about that, as @webchick explained.

However, it's actually happening in other places:
- Drupal UX: Weekly meeting where current UX issues are reviewed. You can follow https://twitter.com/DrupalUx or join the Slack channel #ux. There will be a BoF in Vienna: https://events.drupal.org/vienna2017/bofs/all-things-ux-drupal-core-and-...
- Redesign Admin UI. There will be 2 a BoF in Vienna https://events.drupal.org/vienna2017/bofs/redesign-admin-ui and https://events.drupal.org/vienna2017/bofs/redesign-admin-ui-part-2

It would be great if you could bring your ideas&thoughts to any of this places, we need people willing to help :)

Yep, sorry for the spam. But UX problems that users have don't get visibility so you have to hijack other-related issues.

I will joint the slack and see if anyone has the power to change how we assign priorities to issues. If not, there is no hop ;).

I'm not saying this initiative is useless, I'm saying their is a problem in issues priority. I do not agree with webchick on her analyses on this point, but I will give my argument on other channel.

EDIT: FYI the slack link on the UX team's twitter account do not works: https://screenshots.firefox.com/nXbtMD9zQahF7Dd3/yallkxkt-drupaluxteam.s...

Thanks for the work guys.
As a product manager, I have added comments to the User Stories in the Google Sheet for a technical evaluator. The comments cover:

1. Linking the installation profile to a demo video on YouTube
2. Showcasing the power of content classification through taxonomy
3. Showcasing the core functionality of site backups

Also adding at least 1 more language for multilingual and accessibility ready.

Also adding User Roles and basic management

Tagging it up.

I'd like to see how many of the new success criteria from WCAG 2.1 we can address during this initiative. I briefly discussed this with @kjay and @markconroy during DrupalCon Vienna. It's still at the W3C working draft stage, but many of the new SC's amount to formalizing existing best-practices around accessibility, in particular mobile design and focus styles. While it is still a moving target, it's proceeding on schedule, and is well enough developed that we can get started on it now. (There will inevitably be some follow-up/postponed issues, that's fine.)

Considering release timelines for WCAG 2.1 and our Out of the Box initiative, it seems likely they could both arrive within ~6 months of each other (whichever ships first). If we address it now, there's a real chance that Drupal could be the first enterprise/ambitious CMS to ship a specimen site conforming to WCAG 2.1. That would be a huge coup indeed.

Added my name to OOTB Initiative page.

Since we're nearing the wire on the Jan 15 deadline to get all the patches posted, reviewed, signed-off on, committed, etc. we discussed in Monday's weekly initiative meeting how best to prioritize the remaining time to get this awesome initiative into a shippable state. There's a Google Doc with a bunch of notes in it. I ran this past the core committers who were in our bi-weekly meeting today. (Which was a more limited subset due to the holidays, but nevertheless...)

Here's what came out of that:

• As of Drupal 8.5, we now require experimental features to be at least beta-level quality (stable data models/APIs) in order to ship in a minor release, and to provide BC + upgrade paths thereafter. This brought concerns up about what exactly that means in the context of this profile; for example, do we need to write copious hook_update_N()s, how do we deal with modules being added (or removed!) from core, etc.

  @catch (release manager/framework manager) pointed out that for this particular feature, the above bar doesn't really make sense. By its very nature this profile is meant to be ephemeral; stand it up, see how things work, poke about a bit, then tear it down and start your own using what you've learned. It also is always going to want to showcase the "latest and greatest" features of Drupal, even if those are not production-ready yet. So in that respect, this profile is kind of in a "perma-alpha" state, and we should be able to make changes to it iteratively Hooray! :D

• That means though that what we should focus on, in lieu of a robust API and data model that will never change, is making sure that if someone were to copy/paste stuff out of this profile into their own, that they will get standard best practices to learn from. This means removing any "hacky" bits, making sure stuff is in configuration in the expected way, etc.
• Unfortunately, this also means removing the CSV importer stuff, at least for now. Because even if it's contained within the profile, people will naturally gravitate towards using it for their own profiles, which means it needs to be solid enough for people to rely on. It's a wonderful feature, however, and we should start the process soon (maybe after alpha :D) of getting that split out into its own feature addition to the Migrate system, so that it's ready by the time 8.6 comes out and we can remove a ton of code/complexity from this profile in lieu of CSV files. But it's not required for an *M* VP, which is what we should be keenly focused on now.
• And again in terms of the "perma-alpha" state, there was also expressed willingness to relax some of the gates; focusing on "M" VP of those as well. For example, the theme has to be usable in a screen reader, but could perhaps have some challenges that we go onto fix in beta/RC/during release. It has to be minimally automated tested to make sure that the profile doesn't spew errors when it's installed. But "smoke screen" testing (e.g. making sure we get a 200 status from a URL) is fine; we can always layer in more detailed tests when/if we hit issues.
• The one last important thing is that this feature doesn't cause any breakage to other parts of core, but given everything is encapsulated in a profile, hopefully that one takes care of itself.

I think this was everything, so going to post this and then ping everyone so if I missed something we can find out in a hurry. :D I would SO SO SO SO *LOVE* to see this ship in 8.5, you have NO idea. :D

"Here are the steps to install"

Just 2-cents of low hanging fruit that can definitely help improve the image of Drupal OOTB is simple scripts that do the same thing. We saw major take off of Drupal at Penn State through an initiative called Nittany that boiled playing with Drupal down to "copy and paste this command". At the time it was Vagrant, but for today I'd say if there was a simple docker script that could accompany this it could really help people who don't have enough time to explore start to dip their toe so that they can jump once impressed.

I feel like to change someone's mind about Drupal (even hard core dev heads at this point) we realistically have 30 to 60 seconds of someone's time. If we can't get someone's interest in that window then we can get new people on board and as silly as it is, those little scripts can really sell in areas of DX the same way this effort sells in UX :).

So throw any cryptic commands (through eyes of someone new) into a single sh script (and making sure things like composer aren't even assumed) and this great idea can go that much further.

/2-cents

Please be VERY, VERY CLEAR that this install profile shouldn't be used as the starting point for real sites or we are going to end up with a new problem. Doing something similar to what Commerce Guys did to discourage people from actually using https://www.drupal.org/project/commerce_kickstart as the starting point for a real site by simply altering the demo content will still result in thousands of Umami clones. Even with a warning like...

Please note that the "demo store" has been built to demonstrate the capabilities of Kickstart and shouldn't be used when starting new sites.

...8,190 sites reportedly ignored that. While that is only 13% of the reported 61,190 Commerce installs and some of those are legit demos or have deleted enough of the demo configuration that is actually makes sense to run the distribution. But if 13% of Drupal installs ignore that, there will be ~130,000 Umami clones.

Related to the above comment... after discussions with the core committers, we need to add #2822414: Redesign the 'install profile selection' installer screen to allow for experimental profiles and more information to the must-have list. :\ Updated the issue summary.

See https://www.drupal.org/project/drupal/issues/2822414#comment-12404799 for more info.

Re: #42, Webchick's big initiative-meeting report.

there was also expressed willingness to relax some of the gates; focusing on "M" VP of those as well. For example, the theme has to be usable in a screen reader, but could perhaps have some challenges that we go onto fix in beta/RC/during release.

For accessibility, I'm fine with this. The initiative's progress has been great, and getting an MVP into 8.5.0 will be a great morale and momentum boost, so relaxing the gates a little sounds OK to me. The initiative team have been very positive about accessibility, including an awareness of addressing WCAG 2.1 as it stabilizes. So consider this my loose accessibility sign-off for the MVP Umami profile!

We now have an accessibility TODO list over at the Umami github repo, and there's been progress with one of the most serious concerns I had, about an invisible-but-operable button in the header search box.

@markconroy asked me to put the a11y TODO list in some kind of priority order, so I'll update the Umami github issues. Focus styles are the next main thing to address, but I won't insist on treating them as a must-have blocker to getting the Umami profile into 8.5.0

Ok, after the core committer meeting, we should probably assume that having something for both A and B above is required to ship in a tagged release (e.g. 8.5.0).

However, step 1 is still to get the profile + theme to RTBC and committed. Those still have an alpha deadline. A + B above have a beta deadline, so an extra two weeks. So maybe some of the designer-oriented folk can attend the UX meeting on Tuesday and we can get a spec together while the implementation-focused folk can get the patches reviewed.

Adding the "B" issue to the issue summary.

Also note that per @xjm, if the profile, theme, and A and B above aren't ready by the beta, then development will continue normally in the 8.6.x branch.

Okay... here we go ;-) Rachel told me on I needed to add this in the queue instead of Twitter..

Besides the obvious solution of moving everything into core, is there any thoughts on a alternative way of distributing this code? Some of our customers have rather strict policies on the code that can actually be on a production environment. And Drupal can be a rather though cookie to sell to the security / auditing team. But having an entire food publishing companies site with images, content and all in every single Drupal installation is beyond a hard sell.

I understand that composer is the opposite of what this initiative is about, so I've ruled that out for installation. But how about having the .zip version have all the bells and whistles needed to install a site using this initiative and the composer version still checks out core without the demo profiles code? That is something that sounds be rather simple and doable with a simple script that builds the distro zip file.

The other option remaining would be to maintain our own forked version of Drupal with a script that would do the opposite and removes all the code for this initiative. Not my personal favorite, mainly because I can't shake the feeling that we are the only one facing these strict 'limit or remove dead code' policies.

So something like https://www.drupal.org/project/demo_umami_subprofile ? We've strongly advocated maintaining Umami as a contrib distribution first and that being able to update the sites that use this install profile should be part of the initiative's requirements.

A demo site that blows up with each core update really only reinforces the opinion many people have that Drupal doesn't update well.

While many purists may see adding the code, content and files required for the Umami demo site as unnecessary bloat to core, I get why Umami ultimately needs to be in core to work. While a lot of effort went into the D7 Demo Framework project, it required knowing the Demo Framework project existed and installing a Drupal distribution other than core… something a new Drupal user is unlikely to do. Including a demo in core is a sneaky smart way to get the demo in front of users who spin up sites using a host that provide a core-only Drupal install including those prominently listed on https://www.drupal.org/try-drupal.

I think the answer to @Rene Bakx's concerns could be answered by install profile/distribution packaging and I'm surprised we haven't seen this already with how passionate people argued for small core. Just like distributions can add code to core for a specific use case (Demo, Commerce, Media, Farming, Churches, etc), distribution packaging can remove code as well.

At the University of Colorado Boulder, we harden the version of D7 core we use by removing the modules we'd never use. We've always done this in Github, but we could just as easily package a version of core minus Umami on Drupal.org.

I think that a hardened distribution is what security conscience organizations will start using while core continues to serve a variety of use cases including a great initial out of the box experience.

@Rene Bakx @kreynen While I can understand where you are coming from I realistically don't see this profile raising security concerns. For what it is worth, I've worked with Acquia for the past 5 years in a presales capacity. Myself and the team I'm on speak to a very large number of security conscious customers. Prior to this I also worked in a similar capacity at a Drupal agency. I can not think of any situation where some demo content would flag up concerns. It is common for other CMSs to also come with demos. Drupal is already huge considering all of the code being pulled in as dependencies. Some dependencies may even have their own demo content. There are bigger fish to fry and an installation profile is easily isolated for removal in any case. I do think there is an argument for Drupal being constructed differently now with composer (the old small core debate) but that's way out of scope for this issue.

What I'll also state is that I see Drupal having serious repetitional issues because it looks terribly dated and featureless on first install. If I was an independent CMS evaluator I'd almost certainly write it off based on first impressions alone. If there is one single issue that will erode Drupal's installation base or impede growth, this is it. Drupal simply does not sell itself to evaluators, which means you need agencies, Acquia or similar pushing it. That does not scale. Drupal needed to have this issue fixed years ago and (arguably) could have a meaningfully larger marketshare if it had done so. This may sound like hyperbole but this is honestly what I've seen day in and out for years. I'd hate to see this issue slow down or get derailed.

Plug: #2873800: Package Drupal both framework (essential core) and product (core)

Given the fact that it's already committed to the 8.6-dev branch we have no other option when 8.6 releases to do hat @kreynen suggests. Create a own package that removes it again.

@davidhernandez I'm all for that, there is a ton of energy moved into installer profiles, yet we (as in the Drupal community) once again fail to actually use that in a practical form. The Umami project would've been a awesome example of the power that comes with install profiles yet we still feel the need to cater to the 'dinosaurs' who fail to wrap their head around modern day practices of using a package manager over just downloading a ZIP file with code. What happened to the Drupal that once was on the frontline?

@rickvug Thank you for you response, I guess you had / have different kind of customers ;) And it's not that common for CMS's in the normal, read not so enterprise world that a CMS comes with a boatload of demo content.

The plan is for the images (and if we can, the content) of the new demo profile to be downloaded as part of the install process, rather than included as part of the codebase by default - #2936841 if anyone wants to help out :) But we've got to start somewhere, otherwise we'll be waiting for the subprofile work, we'll be waiting for module X to be stable, we'll be waiting for the ability to choose what to include in your version of Drupal, we'll be waiting for the ability to discover & download profiles during the install process...

In terms of it being additional bloat or needing to remove it for production, how much of the codebase is currently redundant for production usage? There are currently 6 profiles that are just for tests. The node module has 8 test submodules with it. Vendor dependencies can include whatever they want, including their own demos / tests - I notice the Zend framework has its documentation included, for example.

The addition of this profile gives us a use case for how we can improve packaging Drupal / choosing what we want to be included, so should be helping spur those conversations & developments along :)

Not a whole lot of waiting as far the profile inheritance piece goes. https://www.drupal.org/project/demo_umami_subprofile does it and removes the duplication of work that comes from forking the standard profile. The only issue I ran into was that comment is added because of standard. Adding responsive_images was as easy as putting that as a dependency on the demo subprofile. Unless you mean waiting for the patch to get into core (https://www.drupal.org/project/drupal/issues/1356276 also if anyone wants to help out).

Just added the triage doc to the issue summary.

Rewording the link to the Slack channel, adding the actual channel name.

Changed references to Out of the Box Experience Initiative -> Out of the Box Initiative

Updated initiative lead section to remove those no longer active and add myself.

Removed self.