Background

Drupal doesn't demonstrate that it's possible to create beautiful websites using Drupal. During the development cycle of Drupal 8 design best practices have changed drastically, and therefore the user experience that you get is outdated. In this idea, we are proposing to create a new theme that would be set as a default theme for the new experimental installation profile.

Usecases where the new theme tries to be useful:

  • To convince a technical evaluator that Drupal allows them to build modern and beautiful websites
    • IT department inside a big company
    • A self starter inside a smaller company or smaller Drupal agency

Usecases where the new theme is not trying be useful:

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

The problem

Users who install/try Drupal are faced with a theme that looks outdated and bland, which is not up-to-date anymore with today's standards in typography, layout, and overall styling. Making Drupal seem like a less modern system, than competitors which thrive on beautiful out-of-the-box themes. The target audience for this would be anyone who is fine with throwing away what they have built.

First impressions are extremely important, to consider Drupal as a worthy solution to both a technical and communication/branding challenge they would be looking to tackle.

Proposed solution

Design and develop a theme that demonstrates for a technical evaluator trying Drupal for the first time that it is possible to make beautiful websites with Drupal that are also accessible, responsive and follow current best practices such as component based theming.

The new theme will not be built for Drupal, but it would be instead created to showcase a real use case using Drupal as a tool. All Drupalisms will be left out of the new theme, including the blue color. This is done to make sure that there is a separation between branding of Drupal and demonstrating Drupal.

The goal of this idea not to built a framework for people to built things on top of it. The new design is created to solely demonstrate how Drupal as a system allows creating sites with modern design.

This idea would benefit if following ideas would be bundled with this:
#2809635: Create experimental installation profile
#79582: Add example content to the experimental out-of-the-box demo install profile

Process

  • Drupal Twig Slack, #new-core-theme-design
  • Weekly meetings at rotated timezones. Check Drupal 8 core calendar for details.
  • Google Drive will be used for storing designs

Discussions will mainly happen outside of Drupal.org, but issues will be updated while decisions are being made.

Describe what kind of feedback the team is looking for, whenever asking feedback from the community.

All technical discussions should happen after design has been created.

Requirements

Must have:

  • Modern design
    • Component based design
    • Responsive
  • Flexible, to allow site builders do interesting things
    • Responsive menu
    • Support LTR and RTL
    • We could make the them more Interesting by doing some of the following:
      • Horizontal regions examples
        • Dark background + light color text
        • Light color text background + dark color text
      • Icons to highlight ideas/concepts
      • Call to action
      • Hero regions
  • Accessibility
  • Support for front page, node page, user page, contact form, and taxonomy pages.

Should have:

  • A lot of inline documentation to support new themers.

Won’t have:

  • Support for Color module
  • Adding a new base theme.
  • Adding new themed admin pages.
  • Adding CSS preprocessor to Drupal core (e.g. adding SASS).
  • Theme system improvements (e.g making it possible to add dependencies to modules from themes).
  • Policy changes for theming in Drupal core (e.g starting to use different CSS architecture).

Proposal roadmap

  1. Community Kickoff and forming a team
    1. Agree upon a lead for the initiative.
    2. Selected lead chooses a team to assist with the initiative.
    3. Get agreement by committers and official buy-in.

    Phase A: Choosing a designer & creating initial design

  2. Find potential candidates and choose design lead for the initiative

    Intent: To get initial ideas and impressions of designers to chose a design lead. We should limit any spec work, primarily focused on understanding motivations and style.
    1. Create briefing for the designers:
      1. Process
      2. Timeline
      3. Budget
      4. Team & Roles
      5. Constraints
    2. Sent in initial: motivation & portfolio. (2 weeks period):
      1. Provide e-mail to the team.
      2. The team will periodically update the plan issue.
    3. Team discusses and chooses lead.
      1. Feedback session with a short list involving the product management
  • Help the designer succeed by discussing the process and work involved (e.g. iteration of designs).
  • Go through conventions
  • Create a backup plan

Phase B: Creating initial design

  • Create initial proposal for the design
  • Phase A: Design

    1. The formed team will create proposed design(s) for the new theme:
      1. Design principles and values.
      2. Page concepts.
    2. Feedback on proposals:
    • Public feedback phase (2 weeks) allowing the community to provide feedback.
      • Design community sign-off before going to issue queue
      • General gist
  • Team decides to proceed with one of the concepts and chooses what to iterate on.
    • Lead designer now transitions into art direction role, the larger team/community gets involved in the execution of the design.

    Phase B: Prototype

  • Create prototype of the chosen concept.
    • Homepage, Article detail, (taxonomy) listing using teaser view mode, contact form? Style tiles? Pattern lab-like?
  • Validate technical viability, by prototyping concept in the browser.
    • Receive feedback on prototype (2-4 weeks).
      • Technical implementation feedback primarily.
  • Detailed design / Implementation plan
    1. Create a style guide with minimal items to allow us to start technical implementation as early as possible. Style guide should include following items:
    • Design values & principles
    • Typography
    • Color palette
    • Graphic elements
  • Get feedback on the final style guide (2 weeks)
    • Feedback on the implementation of the style guide primarily.
  • Team decides which parts of the style guide should be iterated.

  • Phase C: Creating experimental theme

  • Create Drupal theme integration for the theme design (MVP)
    1. Implement the first deliverable theme where minimal amount of views has been themed.
    • Theme will leverage an existing component based base theme (added through other means, not part of this initiative).
    • Includes: basic form styles including buttons, inputs and selects, front page, node page, user page, and taxonomy term and vocabulary pages
  • Get feedback on the implementation and add the theme to core as experimental
  • This phase uses existing core processes, to split up the work and implement it enabling many contributors to take part.


    Phase D: Bringing this theme to Stable

  • Make changes for the installation profile to better fit with design.
    1. Adjust installation profile to allow new theme to really shine.
  • Mature to stable frontend theme.
    1. Review and decide on steps needed to make it a stable front-end theme.
    2. Flip the switch marking it stable.

    Additional views can be themed in the theme and added in minor releases

    Contributed projects

    After the design process, we will discuss the best approach for actual implementation. Using a contrib theme as a base can be evaluated.

    Dealing with bikeshedding

    Discuss controversial topics with a smaller group, and after consensus with the smaller group create proposal for the community. Team will try to address all the relevant feedback from the community.

    How we are gonna solve it. TBD

    Team and resources

    Team:

    • lauriii, Project management
    • Bojhan, Usability
    • ckrina, Visual Design, Implementation
    • DyanneNova, Visual Design, Project Management
    • Preston So, Implementation
    • yoroy, Usability
    • kjay, Art director
    • mariohernandez, FE Developer/themer

    Signoffs

    Signoffs needed

    • Product leadership (Angie & Dries)

    Signoffs given

    • Usability maintainer
    Membership dollars fund testing for the Drupal project. Drupal Association Learn more

    Comments

    lauriii created an issue. See original summary.

    rachel_norfolk’s picture

    Would be fab it the end result was a base theme that implemented good practice right now and then, inside that, an implementation of that base theme that applied the contemporary look we choose.

    Is that asking too much?

    colorfield’s picture

    Indeed a base theme implementing up to date best practices should keep it's main purpose : provide a tool that acts as a guide and a time saver, without adding overhead.
    Another purpose is more about making a first good impression on another kind of adopters. It can also be co-developed / shipped with solutions like Demo Content.

    markconroy’s picture

    Hi Laurii,

    This came up in the DrupalTwig slack this week, in the #components channel, specifically in relation to adding a new theme that is based on a component-based approach. I don't see any mention of taking a components-based approach here in this proposal.

    Is this proposal to simply have a new theme (as a base theme of classy or stable) or is it to have a modern-approach components-based theme or something else?

    Jeff Burnz’s picture

    Folks, we have a base theme in core, in fact we have two - stable and classy. These are the current best practice. I'd imagine Classy would be the base theme if one of those is selected.

    You need to add someone from the accessibility team to sign off compliance, e.g. Mike Gifford or another volunteer. I'd imagine this is not to arduous task, mostly color contrast compliance since core is doing most of the heavy lifting already.

    lauriii’s picture

    Issue summary: View changes
    lauriii’s picture

    Issue summary: View changes
    davidhernandez’s picture

    Indeed we discussed briefly the idea of a base theme. I don't think the base theme should have any look and feel to it, but could have the functional elements of the component base theming idea. The main theme would have a fresh design and can focus on implementing the components.

    Wim Leers’s picture

    Agreed with the concern mentioned in #4, but I see lauriii has already addressed it in #6 & #7 :)

    […] but could have the functional elements of the component base theming idea. The main theme would have a fresh design and can focus on implementing the components.

    I agree with this assessment, although I personally think it's rather important for the base theme to use components. Otherwise it's still difficult for other themes to see how they can do this. And it'd mean redoing quite a bit of what the base theme does. Part of the power here is precisely that subthemes can reuse (and optionally refine) their base theme's components.

    I think https://micah.codes/a-new-design-system-architecture/ gives a pretty good summary of why this approach is:

    1. solid
    2. has consensus (two independent teams at Red Hat and John Albin each arrived at this same solution/conclusion — that's triple confirmation)
    3. doable (there are no hard technical blockers!
    davidhernandez’s picture

    it's rather important for the base theme to use components

    I don't think there was any disagreement with this?

    Wim Leers’s picture

    Oh, I misread then. Cool :)

    markconroy’s picture

    Hi Guys,

    Can I ask for a clarity on this in terms of the base theme vs nice looking theme (excuse this phrase please).

    Are we talking about having a component-based base theme with no styling to show how components can be best used AND THEN a nice looking theme using that as its base theme?

    Or are we talking about the new theme being a nice looking theme that can be used as a base theme as is?

    I think I prefer the first approach - less to override when implementing sub-themes. But I also see it as more work (which doesn't usually seem to bother us Drupal folk).

    Wim Leers’s picture

    #12: I think that's exactly what needs to be discussed, so we can come up with a plan. I prefer the first approach too, and I know others have indicated the same. But let's discuss that in the components meetings.

    yoroy’s picture

    I would love to see this happen!

    From the problem statement in the issue summary the main objective here seems to be to create something that makes Drupal look better right out of the box.

    It's about making a better first impression. Wether or not that new design is arrived at through a components based approach seems very much secondary to that main goal of better aesthetics. In that sense a ham-fisted 2000 lines of too specific CSS that looks fantabulous would be a better solution than a components based base theme with a not so great looking implementation on top of it.

    Of course a components base theme AND a great looking subtheme is entirely possible. Not sure how much impact that would have on which 8.x version to target though.

    Either way, we're at step 1: Set the design brief (principles, vision, content/functionality requirements) :-)

    davidhernandez’s picture

    Yes, two themes. A functional, componentized base theme that others can use, and a pretty theme that leverages the new base theme.

    Wim Leers’s picture

    Of course a components base theme AND a great looking subtheme is entirely possible. Not sure how much impact that would have on which 8.x version to target though.

    Indeed!

    I'm no designer, but I could take on the bulk of the work wrt the base theme. That'd allow most contributors to focus on the subtheme that actually brings the better looks. And in doing so, I'd be getting feedback of what subtheming aspect feels painful/annoying/wrong.

    In other words: I'd be happy to take on the role of unblocker of all the blockers so front-end developers/themers can focus on what really matters, whether those are bugs or missing capabilities, in either the base theme or Drupal core.

    cyb.tachyon’s picture

    +1 to Wim, and I'd like to volunteer a little time for that as well.

    has consensus (two independent teams at Red Hat and John Albin each arrived at this same solution/conclusion — that's triple confirmation)

    Quadruple: The team at Mediacurrent has been using variants on this build system on projects for over a year!

    Some opinions about the proposed roadmaps and processes:

    Proposal roadmap

    1. Set the design brief (principles, vision, content/functionality requirements)
    2. Invite proposals from designers (no full theme/design, just ideas)
      Could we specifically call this, "Design Language Proposals"?
    3. Decide on the best proposal (closed, not consensus based, team decides)
    4. Prototype the proposed design & get feedback on implementation (not design)
      Could you explain this a little more?
    5. Create a implementation plan
      I'd like to suggest:
      1. Wireframing/Greyboxing
      2. Design Mockups based on winning Design Language
      3. Component Builds (KSS etc.)
      4. Theme integration (presenter twig etc.)
      5. Testing
    6. Develop a experimental theme for inclusion

    Create design for the new theme:
    Could we cleanly separate creating the Design Language and Design itself? I'm concerned that we'll get hung up on them if they're tied together. IMHO the design should progress out of a chosen Design Language entry. If we need to have to separate proposal sessions for each, then I feel that would be cool too if needed.

    Not in scope

    • Adding CSS preprocessor to Drupal core (e.g. adding SASS)
    • Could we discuss a standard preprocess build process for the theme, even if it will not be committed to core?
    • Theme system improvements (e.g making it possible to add dependencies to modules from themes)
    • I'd like to discuss this more in depth with Wim's vision for component support in core. I'm not suggesting we do everything in https://www.drupal.org/node/2702061 , just that the new theme helps us prepare for it.
    • Policy changes for theming in Drupal core (e.g starting to use different CSS architecture)
    • What about experimental policy changes for theming in Drupal Core related to implementing components? I'm just concerned with experimental components features, not changing any core policy on existing themes.

    I'd like to argue that wim-leers, John Albin's, etc. work on components is integral to building a new top-of-the-line base theme and that if we discard some of these items marked Not in scope that we could be just putting a new pretty face in without useable progress for supporting components in Core.

    Gábor Hojtsy’s picture

    Drupal 8 really needs a new default theme to shine IMHO, so huge support for this effort. Even better if there is a base theme to support component based theming and the design implemented on top of that.

    dawehner’s picture

    I think a nice looking default theme would be huge! It would let people believe that actually something changed. I think a good initiative for 8.3/8.4 would be to provide default content / an installation profile on top of that.

    Regarding the discussion about a base theme, I guess this theme would be marked internal as well, so it doesn't necessarily matter that much, but providing best practise would be worth for itself that's for sure. Back in D7 stark used to be sold as a base theme for CSS only theme. Is this still a thing? Having a css only theme sounds kinda cool to be honest.

    On top of that I'm wondering whether the user facing theme could be developed in a similar way than a experimental module aka. an experimental theme. Not fully fleshed out yet, possible to iterate etc.

    davidhernandez’s picture

    The themes would go in as experimental first. After they move out of the experimental group, I don't see how the base theme can be marked @internal. It will become part of the api and require BC, just like the others. But the user facing theme can/should be internal, just like Bartik and Seven are now.

    Jeff Burnz’s picture

    @ #19indeed, provide default content / an installation profile would be grand. IME CSS only themes are a bit of a pipe dream, and were never a thing, but for core it definitely could be, it just depends on how much fruit we want in the user facing theme, e.g. being fully responsive is pretty difficult without at least some JS (e.g. Seven).

    Wim Leers’s picture

    Note for later: we should look at these for technical inspiration:

    1. https://github.com/aleksip/shila-drupal-theme
    2. https://www.drupal.org/project/zen (8.x-3.x)
    dawehner’s picture

    Is there a reason this work could not already start in contrib? I'm just wondering, because I could imagine that a lot of people would be able to chime into this project.

    Wim Leers’s picture

    Yep, totally.

    tkoleary’s picture

    Re: many of the comments above about base theme or "pretty" sub theme.

    Traditionally the way we've done this in the Drupal community is the reverse of the way things happen in real life ie. we first attempt to make a fully abstracted framework that has no opinion about implementation, then we make a half-hearted example implementation that really does not map closely to anything in the real world.

    In this case I suggest we take the reverse approach. Design a theme that emulates current best practice patterns from real-world sites, get consensus on a pretty high fidelity comp fleshed out with several use cases before we begin to code or even make architectural decisions.

    Connection to the real-world use cases will not cover every single possible permutation of component structure, but it will inform the process enough for us to avoid many potential wrong turns.

    @gtsopour has several examples of good real-world components in his themes here: http://www.morethanthemes.com/drupal-8

    almaudoh’s picture

    +1 to this initiative. I really like the idea of a componentised base theme and a nice modern default theme to demo how it should be used.
    I'd like to also support the "heavy lifting" coding where possible to make this happen soonish.

    Wim Leers’s picture

    #25++++++++++++++++++

    markconroy’s picture

    There's some nice general purpose Drupal (7) designs here as well:
    http://www.sooperthemes.com/#Drupal_Themes

    SKAUGHT’s picture

    Looking at the demo shots form sooperthemes and morethanthemes they already appear to be packed with their own features already (dental site, photo site..etc) assuming they have either required modules or complex theme settings for related landing page regions . possibly/probably they are already complete distro's.

    Although Color module gives general site builders a great power to change the look in general terms. Even I have to say..its' almost too bad that core doesn't have something like skinr for more flexibly to push one theme to different looks.

    But, back to where we are now:
    Currently i'ld say, what Bartik mostly lacks as a modern theme is a great truly responsive menu. I think this is a major aspect that any new theme in core needs to be on top of.

    markconroy’s picture

    +1 for a decent responsive menu.

    lauriii’s picture

    Thank you everyone for your comments! I'm thrilled to see how many people are supporting this initiative! Also sorry for the delay on my response. I was out on a holiday for the past few weeks and didn't open laptop at all during that time. :)

    I discussed with Wim on one of the components chats the criteria for this theme. I think we had consensus that creating a base theme into Drupal core would be amazing and many of us would want it to happen. However, it should not be the main driver of this initiative because I still believe this initiative could and should happen even if we couldn't make that new base theme happen.

    This initiative was proposed to be about creating new design and implementing that. Not about making Drupal's theming experience better. However, right now it seems like we all agree that we want to add a base theme, so nothing should prevent us from doing so at the same time as developing the new theme.


    Replies for specific comments:

    #14: Agreed!

    #17:

    • Could we specifically call this, "Design Language Proposals"?

      What is required from the design proposals haven't been fully discussed/decided yet. Probably at this point we would need both, design language and design. Anyway the idea is to have low barrier for designers to propose their design ideas. It is not very motivating to create design for multiple different layouts and displays knowing that likely it will be thrown away since it is just a proposal.

      We talked about the assessment criteria quickly in NOLA and we figured out that there will most likely be criteria also outside the design. Because of that, the proposals might also need something else than the design.

    • Could you explain this a little more?

      This stage is about creating prototypes for displays with responsiveness and creating feedback of that.

    • If we need to have to separate proposal sessions for each, then I feel that would be cool too if needed.

      I hope we could do this all in one proposal

    • Could we discuss a standard preprocess build process for the theme, even if it will not be committed to core

      I don't believe there is as much benefit to use preprocess build process if it cannot be committed into core. Adding preprocess build process to core has been discussed earlier for multiple times and so far we have always decided not to do so. I don't think the arguments has changed why I'm not sure why we should renegotiate this. Anyway I don't think this is in the scope of this initiative.

    • What about experimental policy changes for theming in Drupal Core related to implementing components? I'm just concerned with experimental components features, not changing any core policy on existing themes.

      Policy changes to experimental policies are not excluded and can be considered if needed. This might need more thinking since I'm not sure if component based theming will need some policy changes i.e. on the folder structure.


    #21: I hope by this initiative we will get more people working on Drupal theming in core and therefor have more resources to add some more shiny things on the new theme.

    #23: Demonstrating component based theming and creating the base theme could start in contrib already. However we could start to work in contrib with the main theme, but to get full exposure for the design proposal stage it would make more sense to do it in the core namespace.

    Wim Leers’s picture

    Title: Create new user facing theme » Create new-user facing core theme

    Minor clarification.

    almaudoh’s picture

    Title: Create new-user facing core theme » Create a new user-facing core theme

    I know it's a nitpick, but I just couldn't resist ;)

    Wim Leers’s picture

    #33: hahahahaha that's exactly what I intended to do :P Thanks!

    mortendk’s picture

    ok not to be an asshole but.. ;) heres my braindump over the morning coffee on getting a new design into core.

    Its the design that matters

    If we want a new theme, what were really want is a new DESIGN. its not a theme, its not preprocess-postprocess best practice etc etc etc its a new design. oki says every drupal developer then lets build a new theme, cause we know how to do that right! ... wait what - Nope, sorry we need to have something to theme first -> we need a design manual for "a drupal site".
    That will not happen in a group effort, it will not happen in a design by committee. We have tried that before & got shut down...

    If were serious about this there needs to be some fundamental changes in how we solve the deisng by comittee :
    There needs be 1 (only one) design lead on it - that have the authority + the trust + the time to lead this forward, and we need to accept that first, if were not willing to accept that then it will never happen, yes you can quite highlander now.

    I would suggest that the discussion about a design gets completely removed from any engineers that is not design geeks - seriously i love you guys n girls, but your force is not in the little details that makes a design great, its not to grasp in the look and feel of something that should be able to stand the test of time. We have tried it before & belive me its not gonna work

    getting design proposals...

    That have been tried a few times before, and surprise nothing shows up, why cause drupal isnt a designers paradise / or even better some designers gets pissy cause - wtf you want me to drop 1-200 hours into a design proposal that im not gonna get paid for + not even sure is gonna be used -> fuuuuuuuuuuuuu..... that

    Again back to highlander there can be only one, pick a designer and then rock it.

    Who has a say in the design

    Here's another thing cause honestly getting you design shut down by grumpy developers the next 2 years is not a thing anybody wants to experience, the process needs to ruled with an iron hand & having design choices gettting hammered from ppl who should not be in those issues is gonna be a real pita. - yes i said it, not everbody shoud get their saying in how drupal-new-theme should look, like little dumb themers dont get their say in how the database structure should be build.
    - theres many lessons we learned from when mark & lisa was working with us around Drupal7 & one of them was the resources & time that was misspent on having never ending disucssions about color tones etc in an issueque.

    Sorry but not to sound like the old man in the bar, but if we want to get a new design (not a theme a design!) then we first need to set up some playing rules and how its gonna be done.
    One thing i have learned after 10 years in drupal is that its build by engeneers for developers, and design thinking dont fit in there - So unless were willing to change the culture of how we do some things, then its gonna be a lost cause.

    Besides of that AWESOMESAUSE - hope it didnt come off as complete crap

    Gábor Hojtsy’s picture

    @morten: A discussion on this was started in two core conversations in New Orleans by @yoroy and @webchick+myself. The issue queue version of that is at #2729061: [policy, no patch] Agile process for bigger changes in core (Part B: Implementation) and the pretty picture version of it is this (google drawing link there):

    This allows for ideas and high fidelity work to start without needing patches and implementation to happen in possibly different completion levels (experimental => stable), so a new thing could be "ready" in terms of "idea", "design", "prototype", etc. at different times. Does that help?

    mortendk’s picture

    @gabor - yup sure does, hope it can solve some of the deep problems we have with an "engineering community" that have to embrace design, lets see what happens.

    im just afraid that were jumping to the easy part & start talking about "how can we make this amazing theme" instead of keeping our eye on the price: The Design, which is the real issue here :)

    lauriii’s picture

    @mortendk: thank you for your comment! I discussed about these problems in NOLA with @Bojhan, @yoroy and @tkoleary and we tried to make a proposal that would try to solve very similar problems as you've described on your comment.

    The plan is that we try to keep proposing as easy as it possibly could be. I think all of us could see that designers won't be willing to spend hundreds of hours on something that might never be used. We also discussed that we would try to encourage organisations by explaining them how they could benefit from contributing to this. Hopefully we could get them to give their designers some time for working on this initiative.

    The next step after proposing designs is to open an issue where people can express their opinions about the designs. We are not trying to find consensus at this point, since we won't. There will be instead a small committee choosing the design / designer after this step. It won't be an open discussion. The chosen designer will be given the responsibility to work as a design lead with the help of other designers involved.

    We know that we haven't had many successful experiences of creating a design as a community, so we don't know if what we are proposing is going to work or not. At least it has been changed based on the knowledge we have from the past, and will be improved once we gain more experience.

    mortendk’s picture

    @laurii glad to hear, cause we have had the same issues for the last 8+ years, and something need to change for this to happen.

    Wim Leers’s picture

    Its the design that matters

    +10000

    This is exactly why I labeled myself as technical unblocker: I want to make sure that you guys, and specifically the person who is "the design lead" (or whatever it's called), doesn't need to waste any time on what we could call "code crap". I'll deal with that, so you can focus on what matters.

    axaios’s picture

    I can totally agree with @morten on his point of view. Design is a very important aspect of every product and Drupal sucks at it. Both in terms of UI & UX and both in frontend & backend. If we want to step into 2010+ era we need to let go of a few traditions, embrace change and reimagine or even copy (doesn't hurt) a few good paradigms from other products or platforms.

    Doing that cannot be an ever community-debatable process but instead should follow the clear vision of the person who drives it. Once we have a great design in hand geek-devs can debate all they want about what is the best way to implement it. I am sure that when this happens both usability and adoption of Drupal will skyrocket.

    markconroy’s picture

    Hi Folks,

    Just to chip in here on the "let the designer get on with the job" and let the developers figure out how to implement it later. Can we be careful on this. As a frontend developer I'm often given "signed off" designs to implement and quite frankly some of the design decisions are just bonkers.

    For example, if the designer is going to add a large hero slider for example, well we can't create the fields needed for the slider in the theme (this isn't Wordpress, y'know). So we'll need to ship a new core module with the theme to accomplish this, but then we must remember theme's can't have module dependencies - so we'd need to create all the JS to make the slider work. P.S. I hope there is no sliders in the theme - this is just by way of example.

    So, while I am all for "let the designer do their job", we must impose constraints that all design elements must work with Drupal Core only.

    lauriii’s picture

    @markconroy: I agree that creating a design should happen in co-operation between the developer and the themer in the sense of what is possible and what is not possible. This doesnt mean that the developer would have anything to say about the design itself but maybe give feedback that maybe some of the ideas cannot be done.

    Happily we are not as restricted as you are describing on your comment since we can also use installation profiles to install modules and fields. I know this was just one example but just wanted to clarify. :)

    ptocco’s picture

    For my part, I would love to see Drupal approach design from an "html-centric" point of view, rather than a "render array" point of view. Give me a blank slate and let me compose a page or block with html. Not in all cases for all pages, but for maximum design freedom in certain cases. Just give me a blank slate and I'm happy. However, as we all know, Drupal often makes us work very hard to achieve this blank slate, much preferring to run the code through filters and build pages with render arrays etc. All well and good for many pages, not so good for others.

    To quote the Render API page (//api.drupal.org/api/drupal/core!lib!Drupal!Core!Render!theme.api.php/group/theme_render/8.2.x):

    "In order to ensure that a theme can completely customize the markup, module developers should avoid directly writing HTML markup for pages, blocks, and other user-visible output in their modules, and instead return structured "render arrays" ..."

    That says it all. Only an engineer would think of such an approach.

    I for one would love to see an elegant out-of-the-box default theme for Drupal 8. Maybe there could be a contest or something.

    cyb.tachyon’s picture

    For my part, I would love to see Drupal approach design from an "html-centric" point of view, rather than a "render array" point of view.

    Drupal design has always been approached this way. I believe what you're thinking about is module and theme code development.

    But I think I get what you're saying - you want a place to see the desired HTML output of each item, and that's what using components allows us to do.

    Thanks for your comment.

    cyb.tachyon’s picture

    FileSize
    80.79 KB

    I'd like to suggest a final road map that incorporates most of the suggestions and concerns here. I know @laurii is working on one as well so hopefully he can take the best out of both and we can move forwards.

    New Theme Road Map

    Community Kickoff

    1. We agree upon a lead for the initiative
    2. That lead chooses a team to assist with the initiative
    3. For one month we accept community proposals for the Design Language of the new theme
    Project Lead
    • One lead for the project
    • The lead may or may not be the lead designer on the team
    • The lead has final say on all items for this initiative
    • The project team may have specialists assisting

    It seems obvious that @laurii is the initiative lead - if we don't see any objections I would say that's how we should go. I nominate @wim-leers and myself @cybtachyon as backend specialists. I would like to request an accessibility specialist as well as a UX specialist for the team, as well as additional designers of @laurii's choosing (@mortendk, @johnalbin ?). A small team that has dedicated time to devote to the initiative on a weekly basis seems the most sound approach.

    Design language Deliverables
    • Theme Principles (text)
    • Example content requirements (text)
    • Palette (indexed palette filel)
    • Example graphics / logos (vector/scalar images)
    • Design Placement Rules (text)
    • Example code snippets (html/css/js demo site link)

    One or more of any of the above deliverables would constitute a valid submission. The design team will not be submitting design language, and instead will evaluate and create a final design language inspired by the best of the community submissions.

    Theme Design

    1. The team reviews the proposals and creates a final design language
    2. The final design language is published on d.o
    3. The team creates and publishes wireframes for the new design
    4. The design is created and published
    5. A component model is created and published
    6. Issue tracking is set up for creating components and the backend necessary to theme them
    7. Work begins on implementing the design as a theme
    8. A demo site is published that contains the WIP of the site, along with a static HTML style guide
    9. The final theme is submitted through the initiative process to become an experimental addition to core

    This process should occur privately, with notes and deliverables shared with the community. It is important to note that while feedback is critical to the process, the design team should not be beholden to approvals by the community, and instead works entirely within the Initiative process. This means the final product goes through an approval/revision process to be added to core as experimental, and is not bogged down by bureaucracy during design.

    It is a massive time and skill commitment by the lead designer and it would be disingenuous to require a designer to await community consensus for each individual step in the initiative. Instead, I would expect the team to keep an eye on community feedback and respond where and when prudent.

    Design Deliverables
    • Design Language (.pdf)
    • Wireframes (.pdf)
    • Design (.pdf)
    • Component Model (.csv / google sheet)
    • Private Issue Tracker (d.o contrib/trello/jira/pivotal etc.)
    • Demo Site with Style Guide (acquia/pantheon/etc. demo site)
    • Component Builds (committed to repo & generated to Style Guide url)
    • Theme integration (committed to repo)
    • Theme Issue & Theme Patch (d.o)

    I would like to recommend using the Component Issue Workflow:

    Noting that if we do not use SASS for the project, this precludes the use of KSS node for generating the style guide and we'd have to adopt another approach (manual or otherwise).

    ckrina’s picture

    My comment is a little bit late, but I completely agree with @morten, @yoroy, @wim & others: design is what matters. The goal is to give a better first impression of Drupal 8 for those who are testing it, so they stay.

    And as @morten said, the visual design processes are kilometres away from an issue queue. Finished proposals can be there, but not the process itself. So we should assume that there will be a part of the process that the community won’t see, and we should be OK with that.

    Another point that we discussed with @laurii in NOLA was the who and how the feedback for the visual design should be addressed. My concern was mainly that visual design discussions in a public issue queue can be endless and paralysing. Also, some kind of feedback can even be very self-defeating. I’m sorry but as @morten said not everybody should/is prepared to decide about design.
    So I am in favour of what finally gets showed to the community is something that has already been discussed in a closer “committee”.

    And +1 to having a design lead.

    About the confusion between create a new base theme “component-based” and a new theme with a newer look&feel, if the design is created with the components in mind it will be able to be adapted without refactoring the design when the base theme “component-based” is finished.

    markconroy’s picture

    Hi Mark,

    Thanks for your input here. This is the first mention that there has been of utilising a present (contrib) base theme as a starting point for this (besides my mentioning of a wish to have Zen part of core in a Slack conversation).

    Your thoughts are interesting and I'm certainly going to think on them some more. That said, your language is very harsh here. I'm not sure 'everyone in core' is 'actively ignoring' the bootstrap theme. It might just be that lots of people are actively involved in other areas of Drupal/theme system development and bootstrap hasn't gotten the attention that it might deserve. Now with this comment, perhaps it will.

    Again, thanks for the contribution - always great to have extra voices on board.

    darketaine’s picture

    @markcarver I think that you 're missing the point of this plan/issue.
    It's another thing that an existing theme should probably get into core and another thing that we 're trying to create a new core theme which is also the new 'identity' of d8 (like bartik is now) and includes some good practices.

    dawehner’s picture

    Maybe actually dropping the best practises from the proposal then is a valueable answer. Best practises are created over time and change.

    mortendk’s picture

    Reading through the comments can see that this is gonna end up beeing engineers discussion about how to implement something that looks like [something-we-dont-know-but-lets-discuss-how-tocode-it]

    this is not about how to implement but how it should look: The design ?

    sorry but that's the reality over the last 10 years I've tried multiple times to think desgin into drupal & every time it got shutdown by all kinds of interesting "issues" - cause drupal developers will jump into their toolbox & try to solve a design problem with engineering tools - not cause they are evil (and I'm not blaming anybody) but that's how we solve issues, even the smallest discussion on designing drupal, will be over flooded with engineering yadi yadi so designers have run away screaming - don't believe me then look into how seven theme.

    Im personally think it's a lost cause - unless designers get the room to actually design a look for drupal 8.x - which I can't see happening :(

    What I wanna know is if the drupal community is ready to have a "group of designers" making visual changes to things they are used to look x way & if we are willing to accept that it's not gonna be a never ending discussion, cause that will kill the process completely - that there need to be a clear leadership & weight behind the design project.

    If the drupal community is not ready for that - then we can keep on talking about whatever way we should implement the non existing design - instead we should focus on optimizing & making the theme experience better.

    Tbh I think this needs to be done outside of core & the issuesques - then maybe get adopted later into core - cause our community is not ready & will never be ready to accept designers doing what they do.

    Sorry - but let's be realistic about this.

    Bojhan’s picture

    Its great to see all the passion here. We are working on a revision of the proposal.

    I think all the very passionate responses, is also in line with a design focused initiative :). The initiative will set the design direction in collaboration with the design lead. The front-end technology, that is chosen depends on what the team thinks is mature and appropriate at the time of the design completion. The technology is not part of this initiative itself.

    @mortendk I dislike the idea of it being a zero-sum game. We're not a lost cause, neither is it build a theme or improve the front-end experience. But what is key, is that this is not a consensus approach - the team will design, and its not a technolgy-centric approach - the team will chose the appropriate technology at the time a design is complete. I honestly, don't understand the Seven reference. All of this is outlined, in the initial post and the following comments from the people involved in the initiative :)

    markcarver’s picture

    It would appear that, despite it's title, this issue has absolutely nothing to do with everything I have seen or discussed about a "new theme in core".

    And apparently creating a design doesn't need any real world constraints of an established front end framework. One that's homegrown, or external, to create a practical Drupal theme using proper components? Seems like an extremely counter-intuitive approach, but hey... whatever. It would seem that I don't know a single thing about theming in Drupal.

    Abstract design and tons of "Design shows X, but Drupal does Y" issues it is then.

    Sorry for hi-jacking the issue with my crazy ideas of a more stable and sustainable approach.

    edit: P.S. I'm aware of how dramatic and "harsh" this sounds. Please accept my sincerest apologies if anyone takes this the wrong way. I just have to vent my frustration of how backwards this all sounds to me using technobabble that y'all can actually follow.

    It is not directed at any one in particular, seriously.

    We're all great people and developers. I, like @mortendk, share the same type of frustration... just on the other side of the themer spectrum.

    Gábor Hojtsy’s picture

    What I wanna know is if the drupal community is ready to have a "group of designers" making visual changes to things they are used to look x way & if we are willing to accept that it's not gonna be a never ending discussion, cause that will kill the process completely - that there need to be a clear leadership & weight behind the design project.

    Morten you know The Drupal Community (at large) will never agree on anything ;) As per what I posted above in #2759849-36: Create a new user-facing core theme initiatives like this would need to have an idea and very high level plan. https://www.drupal.org/about/strategic-initiatives has a list of current strategic initiatives and https://www.drupal.org/governance/core/initiatives says Dries himself would bless the VEYR HIGH LEVEL plan. In practice I would think that is discussed between all the core committers.

    So (a) the community (at large) will never agree on anything (b) there needs to be some high level plan written down first for discussion for committers to give a go-ahead and then have your back supporting that the decision was already made and not to be reiterated.

    David_Rothstein’s picture

    even the smallest discussion on designing drupal, will be over flooded with engineering yadi yadi so designers have run away screaming - don't believe me then look into how seven theme.

    Here's the issue where the Seven theme was added to Drupal core: #484860: Initial D7UX admin theme

    I'm not sure it matches your description - overall my recollection from that issue was that it was a relatively frictionless process. What specific problems are you referring to, and how could they be improved in the future?

    It's also worth looking at the process for Bartik as well as some other themes which were proposed for (but didn't get into) Drupal 7 core:
    #683026: Add a new theme to D7 core: Bartik
    #686410: New core theme for Drupal 7: Corolla
    #695292: Add new theme to core: Busy

    I think the clear lesson there is that it's best to work on a new theme as a contrib project on drupal.org as early as possible (even if it's intended for core). That's a natural way to give the designer as much control as they want, while still allowing others to contribute.

    (And although there was some friction in the above, at least https://www.drupal.org/project/corolla and https://www.drupal.org/project/busy wound up as relatively successful contrib themes in the end, and of course Bartik wound up in core.)

    mortendk’s picture

    @mark yup we do share the same frustration - honestly i dont care for an inch what way we put it in (please dont use node ) I only care at this point about making sure that we give designers room to breathe and create the design, then we can create issues to slug it out & fight over implementations.

    @bojhan the reason im hammering this a bit harder than normal (you can say aggressive) is that we have been down this path before & we have never been able to get anywhere, in case of "design" its been remarkeable the work that have been done on refining seven, but honestly have anything changed over the last 7 years of how our community work with "design" - why in my doomsday world see it as a lost cause, unless were willing to take some hard decisions - and for one cut engineering completely out of the design process + change the way were doing stuff as it looks like gabor is pointing out.

    @gabor - yup exactly but heres the problem, not everybody can have an opinion about database cache structure, that requires knowledge about that, but everybody can have an opinion about design - and i mean everybody dosnt matter what background cause you can just say "i dont like brown" / i think its ugly etc. The problem is that that part is so draining for anybody working in the visual space it can be completely draining.

    @david im not talking about when stuff was done and ready to go. Im referring to the never end battles that mark had with the community even over the smallest issues, the time and effort that went into explaining everything, to ppl that... if i put it a bit on the edge was not qualified for being in the discussion, like im not qualified for a discussion about database-cache-optimization ;)
    Mark was paid as i recall it to create the design. Were gonna see a hard burn-out from designers that probably will die on having to explain why a font is not #000 black but #666 etc. The problem was the cultural clash from hard engeneeing to fluffy design. It cost a lot of resources & headaches.

    yes i do think our right about starting a design out away from core - in contrib, that do gives way more room to move + less noise.

    I know im putting on a bit thick here. But im not doubting for a second that we need to change how we look at design all the way down to our own geek culture, if we really wanna make this happen, else we did succed in one of drupals original goals "kill the designer" ;)

    ...ups sorry for the rant, but i guess im back from my burnout :P

    mccrodp’s picture

    Hey all. This was more a popcorn issue on an interesting topic until I saw some of the above comment, so here's another 2 cents to be thrown into the pot:

    I'm from an engineering background and by trade, but I have a design background also. I agree with @morten and feel it's a culture change that is needed and us engineers to release the control over things that are aesthetic / design for the greater good of the community. Designers are closer to end-users and even if a design forces us to rethink the structure / what is possible with Drupal, maybe that's a good thing, as our end users will likely want something similar.

    For me the post that made me comment was actually from @David_Rothstein, so thanks for that. Nothing personal to the theme designers, but when I look at the example themes that nearly made it into Drupal, they just look like they were designed by engineers. I'm sure they are structurally and technically sound and can be overridden to look great with not so much work for a qualified themer. However, I can see why less tech users come to Drupal, see Busy as one of the themes available and run straight to Wordpress. From the screenshot anyway, it's on a par with maybe Kubrick, the first Wordpress theme or maybe even twenty10 from Wordpress 1.5. I know these were for D7, but we're talking about Drupal 8 here. We need to take our engineering glasses off and let some professional designers do their job ;)

    I remember at one of Dries' keynotes him talking about gaining these less tech Wordpress users. We won't do that with the current default themes we have and this opportunity is a fork in the road where we can choose to change this I believe. I believe we can do it also, as some of the proposals to get it out of the issue queue and into a design committee sound great. So, following @Gabor's advice sounds like a good start, get our blessings and green ticks from the decision makers and proceed with a goal to let the designs flow and change a little for the better in the process.

    When it comes to the tech process, maybe it's best to get these progressive themers, @markcarver, @johnablin, etc. to see if there's a middle ground, to implement components, both Drupal specific and those applicable to the greater community and also reuse frameworks like bootstrap where appropriate. We went with Symfony on the backend and it's proven to work, maybe it's time to do so on the front-end, at least in the go to contrib theme / core theme, if not core itself where appropriate.

    Exciting times ahead anyway, looking forward to seeing the signed off designs at whatever milestones they are made available.

    EDIT: +1 to @dawehner's comment in #54 too, and maybe even going further to separate tech implementation conversations from design (almost) entirely to keep things on point.

    markcarver’s picture

    Title: Create a new user-facing core theme » Design new user-facing core theme comps (not technical)

    Making this issue's title a little more explicit and less confusing

    yoroy’s picture

    Title: Design new user-facing core theme comps (not technical) » Create a new user-facing core theme

    This is the plan issue for the whole process, from design to implementation. Nothing is off the table for discussion. We’re just getting a bit ahead of ourselves in wanting to discuss All The Things right here right now. We will have many discussion, we just need to have them in the right order.

    A revised and updated outline of the plan is forthcoming. Once that is in place and agreed on we can create specific, focussed and actionable issues in a sensible sequence.

    markcarver’s picture

    Whatever... this is absolutely ridiculous...

    Jeff Burnz’s picture

    My major concern is how we engage the designer. I think it's a mistake to have any sort of public process that allows the general public to express opinions about the "design".

    Instead I think we need to consider very seriously paying a designer. Instead of calling for spec work the team should short list a few designers and engage one to be the "designer". A solid professional designer will get the job done, there's no need to ask for spec work to prove they can do it, that would just be rather insulting and unproductive.

    If we ask for spec work most of it will be crap, and we won't engage the really top designer to participate (they will just move on knowing full well the massive amount of work this will entail). Remember that spec work is, for the most part, universally panned as unethical by the professional design community. That's how they roll, and given this job is probably hundreds of hours of work, I don't really blame them.

    Even the actual build should be in private, done by a couple of experienced Drupal theme developers working closely with the designer and Wim to run the un-blocking issues. Honestly you gain very little from a public process (been there, done that, twice).

    Another issue to consider is open source. PSD/AI etc are not open source, so consider carefully about distribution of design files. Yes we can of course have design files in non open source vector format, but we should probably also have them in a format that is open source and can be distributed. I think thats a thorny issue and will leave that it the geeks who specialise in that area, but unless we design in the browser and there are no actual files, then we don't want another Seven debacle over design files.

    Jeff Burnz’s picture

    And apparently creating a design doesn't need any real world constraints of an established front end framework. One that's homegrown, or external, to create a practical Drupal theme using proper components? #57

    I'd like address Marks comment here because frankly it's highly relevant. I may be misinterpreting it a bit but I think I get what he's on about. Bootstrap is a component based system. For example it has things like a drop menu component, breadcrumb component, media object component etc. Pretty much everything you need is represented as a component. A very well honed component based system like Bootstrap provides very solid set of constraints for the designer.

    While the current proposal does mention component based theming, there are no constraints for this. What components? I'm not saying this as a criticism, it's early days, but we need to detail this.

    Developing a component library is a truly monumental task. I'll see you in a year or two should we do this from scratch, which is no issue IMO actually, however I would say that something like Bootstrap offers a really, really good guide. I have no qualms in saying that I think one of the most important contrib project for D8 right now is Bootstrap theme - it's dragged in an entirely new crowd and gives dev teams that rock solid component library that zillions of designers work with every day - they know how to design for it and its all the vast majority of sites need to implement their front ends.

    I know someone is going to say, oh yeah, thats an implementation stage decision - if you say that you are missing the point that designers need component constraints - we need to say "we need a media object, we need drop buttons, drop menus, pagers, etc".

    Please don't get the idea I'm advocating for the Bootstrap drupal theme to go into core as a base, I'm not - what I'm advocating for here is detailing our component library for the designer so they know what to design for. We could pull one off the shelf, or home grow it. I'm agnostic, but I'm with Mark when he says the process looks topsy turvy. When I hear things like "best practice" I think component library, so lets put some meat on the bones of what we are talking about with regards to those components - first.

    markcarver’s picture

    Thank you @Jeff Burnz. Yes this is exactly what I have been saying, for years.

    I know that Bootstrap isn't "popular" amongst Drupal front-enders, however that is more or less irrelevant. This isn't about us. It has always been about the other 99.998%; as evidence by it's continued growth and external popularity.

    It is literally everywhere.

    It's why I gave up my preconceived notions of what a "theme ought to be" years ago and started helping develop this one into a proper base theme here; focused both on the novice and the experienced users.

    Developing a component library is a truly monumental task. I'll see you in a year or two should we do this from scratch, which is no issue IMO actually, however I would say that something like Bootstrap offers a really, really good guide.

    One to two years is a very optimistic estimate IMO. I would imagine that it would take much, much longer. Also, we would still be left with the problem of "maintaining it ourselves". This has never been a strong point of core, especially considering how big it is now. I, for one, would really like to get away from this mentality.

    David_Rothstein’s picture

    @david im not talking about when stuff was done and ready to go. Im referring to the never end battles that mark had with the community even over the smallest issues, the time and effort that went into explaining everything, to ppl that... if i put it a bit on the edge was not qualified for being in the discussion

    I remember that happening with D7UX, but not with the Seven theme specifically. That's a big difference, since D7UX was about making large changes to how Drupal is used so it made sense for more than just designers to weigh in on those proposed changes.

    I think that if this issue just sticks to visual design changes (as I assume is the goal, since it's about creating a new theme) it's not likely to have too much of a problem with people nitpicking every small design decision... or at least I hope not... I agree that would be a problem.

    Version: 8.2.x-dev » 8.3.x-dev

    Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

    cosmicdreams’s picture

    Hi all, I deeply care about this issue. But more than that, I deeply care about having a finished new design for Drupal. A question for everyone who wants to participate in the issue:

    How should we proceed?
    How do we share work?
    How do we iterate and improve?

    I have ideas of my own on how this could be but am interested in your (you the person reading this) ideas.

    mdrummond’s picture

    Any good design needs constraints.

    A design is a visual solution to a problem, a way to guide someone towards certain actions, some of which are more important than others. Going to a designer with a brief of wanting something that looks modern and fresh may well be challenging when the ways this design will be used are so open-ended.

    I think there could be an advantage to saying we'd like a design for a blog, or a news site, or a product site. Just... something. Some sort of guidelines and direction. Then over time, perhaps we add additional designs geared towards a variety of purposes.

    I'm less keen on going to a designer and saying that the goal is to skin the pre-existing components for a particular framework. I'm also really, really not interested in rehashing that discussion of putting a framework like Bootstrap or Foundation in core. We've had those discussions, it didn't happen, and I don't want to stall this new effort by bringing that discussion back.

    I'm glad there are lots of people that enjoy building sites with Bootstrap and Foundation. Those are tools a lot of people have found useful. There are also lots of people that build great sites without those tools. That is also cool! It is okay to have multiple ways to build websites on the front end.

    I'd much rather that we discuss what kind of goals we'd have for a design, what sort of qualities would a successful design have, then to dig the trenches anew on a front-end framework discussion. I do understand the concern that trying to design blue sky and then fit a framework in the implementation phase would be problematic. But I do not think there's a consensus that using a framework would be a good thing, and I do not think that is going to happen. So I'd rather we explicitly decide that we will not go down that road, rather than preventing any work on a new theme just because there's a desire to bikeshed this again.

    webchick’s picture

    Usually when we start getting passionate emotions going in a thread like this, it's a good time to take a step back and start documenting things. For example:

    - What are the points we're all aligned on and can all find agreement with? It seems like "Bartik is soooo 2009" is one of them. Let's refocus the discussion back onto that.
    - What are the points of contention that we need to make sure we hammer out in the process of implementing the things we agree on? It sounds like component based vs. not is one. base theme/framework based is another. contrib first or core first is a third. Let's get a list of these together and spin off sub-issues for them so that once we agree on what we're doing, we can have dedicated discussions for those.
    - Who of the people discussing here want to be involved in the actual creation of the theme? Vs. who are not interested in helping, but want to make sure their concerns are documented and addressed?

    ...and so on.

    Let's put a brakes on the intense discussion until we have an updated issue summary here that outlines some of this stuff.

    Jeff Burnz’s picture

    #71 Indeed all good points regarding rehashing a framework in core debate, we don't want to do that again!

    Perhaps we can put in dev speak so people get it - a component is like a Class, with methods. You can instantiate a component and call methods on it. E.g you have a navigation menu - you can call the drop_menu method on it. You can place this component anywhere in the page and it looks the same - i.e. it's encapsulated. How you build DRY component libraries is by using CSS preprocessors with functions, mixins and variables.

    An assemblage of components is called a framework. Some of these have names, like Foundation or Bootstrap. However - for a great many projects the front end developers will assemble their own framework. For this we use package managers like NPM (Node) and Bower. E.g. we might import Susy for layout duties, Enquire for easy media query handing etc. Bower is particularly useful here because it can pull packages right off Github. Want drop menus, accordions, slideshows, no problem, just pull them off Github selecting from a zillion projects that suite your framework.

    If you want a definition for modern front end development - it's package/version management of existing components assembled into bespoke frameworks for a particular project.

    Once you have assembled the components you design for them, then build the CSS/JS customisations to make it look like the design. To help you do this you pull even more tools, use task runners etc.

    Compared to modern front end development Drupal is prehistoric. All I am saying here is lets bring Drupal, kicking and screaming, into the modern world.

    Now in respect for Webchicks post above, I will leave it at that.


    1. Bartik is old school, both in design terms AND how it's assembled as a "theme".
    2. We either make a pretty theme (fast, easy) or theme against a component system (vastly different issues). A scope issue.
    mdrummond’s picture

    Different strokes for different folks. Do some people start from picking pre-written behavioral code and then add a design on top? Sure. That's not at all how I work on client projects. There typically is a design created for a particular site to accomplish a set of goals. My job is to implement that design. Sometimes I find pre-existing code that can help with that. Susy and the Breakpoint mixin, for example, both of which are component agnostic. A more opinionated framework often gets in the way for me as its assumptions and defaults may diverge pretty sharply from what has been designed, which means more overrides than is worthwhile.

    Not all sites have the benefit of a custom design, so I am not at all knocking alternate approaches.

    I do think the people who proposed this work would like to try a design led process. Design for certain goals first, decide on implementation later, probably with custom markup and styles.

    Personally I enjoy working with modern tooling like autoprefixer: I never want to manually write a vendor prefix again. BUT as much as I'd like to work with modern tools that too has been rehashed ad nauseum to no avail.

    I like the idea of design first, implementation later. I think it would be great to give that a chance and see how it works out.

    Jeff Burnz’s picture

    I like the idea of design first, implementation later...

    Component library is about design, the implementation is irrelevant. E.g. UX does not care about how a component is implemented, only that the component is implemented true to the component. I think you have missed the point.

    Not all sites have the benefit of a custom design..

    I don't understand what you mean here, what has this got to do with this conversation?

    Personally I enjoy working with modern tooling like autoprefixer: I never want to manually write a vendor prefix again. BUT as much as I'd like to work with modern tools that too has been rehashed ad nauseum to no avail.

    That is because there is a group of people in Drupal who are totally convinced that all front end developers are idiots and have no idea how to use the technology they work with every day. Go figure. This is similar the absurd argument that we should not use SASS because it might, and I pretty much quote, it might "be a barrier to contributing", which is hilarious when you consider most front enders user preprocessors! Who writes CSS these days? No one.

    markcarver’s picture

    #71 Indeed all good points regarding rehashing a framework in core debate, we don't want to do that again!

    Except that almost all the "cons" for not putting one in are irrelevant and outdated now. Like I said, this has been going on for years... things have changed, dramatically.

    I think the most compelling argument "for" and external framework (and one people often dismiss) is all the external documentation, examples, tutiorials/how-tos, plugins, etc. This literally allows anyone to pop in whatever they want and it just works. They don't have to worry about "adapting" it to their theme. Any homegrown solution will still be "in a bubble" subject to core, and only core, support.

    Do some people start from picking pre-written behavioral code and then add a design on top?

    Yes, 99.998% of users. Especially ones that aren't themers, let alone the Drupal theming wizards that are in currently writing in this issue. I honestly don't understand the rational behind this argument. This issue isn't about "us", it's about everyone else who doesn't know how to theme.

    This biggest misconception is that "all __insert framework here__ sites look the same". You don't build "on top of a framework". You build with the framework. implementing a framework without a proper design isn't the fault of the framework.

    ---

    Regardless, this issue is primarily about design. I still believe that any good design should be aware of the fundamental base and component implementations of a framework. Simply designing something "willy nilly" because it "looks good" isn't practical... especially in Drupal.

    "Oh crap, we forgot about X. How should we style it? There's no specific design for it."
    "I don't know, just style it so it doesn't look like crap."

    ^ This happens all the time in Drupal, in part because there's no framework that governs anything, just a "design".

    ---

    Oh and BTW, Bootstrap is now officially the #1 theme on d.o.
    https://www.drupal.org/project/project_theme

    cyb.tachyon’s picture

    Yes, 99.998% of users. Especially ones that aren't themers, let alone the Drupal theming wizards that are in currently writing in this issue. I honestly don't understand the rational behind this argument. This issue isn't about "us", it's about everyone else who doesn't know how to theme. --markcarver

    If we're going to consider this as an important tenet of this discussion centering around creating a new design first and then building the theme behind it, I personally would want to see some data behind the arguments. I'm not dismissing your claims - I'm saying that any practical technology discussion needs to center around research-driven conversation points.

    To that point, again, the consensus seems to be that we need to focus on design first, and once the team has results there, to move forwards with a team-internal decision process for how the theme will be built.
    @markcarver if you feel strongly about the technology implementing the design, I would like to suggest that you volunteer to join the initiative team in order to help better shape the theme technology decisions and execution.

    I appreciate all the passion and insight that have been contributed here and I think at this point the most important thing for us now (as webchick says) is to be patient for @lauriii to update the issue description and see if we have a consensus on the MVP items for this initiative to move forwards. Much thanks to everyone for their time and involvement!

    markcarver’s picture

    It's a general known "rule of thumb" on the Internet:
    https://en.wikipedia.org/wiki/1%25_rule_(Internet_culture)

    In our community (especially in core), it's even smaller:
    http://www.jenlampton.com/blog/breakdown-drupal-community

    I go even further to give light to the fact that the number of front-end [core] developers there are in Drupal is even smaller, as I outlined in:
    http://www.drupalwatchdog.com/blog/2015/8/drupal-should-use-external-fro...

    @markcarver if you feel strongly about the technology implementing the design, I would like to suggest that you volunteer to join the initiative team in order to help better shape the theme technology decisions and execution.

    I would love to. Seriously.

    Yet, no one has asked me. In fact, my reasoning and points have, historically, always been casually "dismissed" by the other front enders in core.

    Why?

    From my perspective, it's because they have a huge distain for external frameworks (specifically Bootstrap) and prefer to do it all themselves. Thus, I'm left to being labeled as "passionate" in issues all across core about this subject. I'm tired of repeating myself, especially when I have outlined this all already. People seem to just skim over things instead of actually reading with comprehension.

    mdrummond’s picture

    I'm annoyed that this issue is being hijacked to bring up issues that have been discussed over and over and over again, and yet apparently need to be discussed yet one more time.

    Who writes CSS these days? No one.

    Do a lot of front-end developers use Sass? Sure. Do some people still write straight-up CSS with no preprocessors involved? Sure. Most of writing Sass is CSS with some extra logic, but it also comes with varying degrees of command-line tooling overhead, and there are definitely people who are not into that. Getting that set up on everybody's locals consistently in order to write CSS can be complicated even when multiple people are working on the same client project with good channels of communication. It's better now that Compass and Gems are typically not needed, but there would still be a fair amount of effort.

    Would I prefer to work with Sass? Yes. Are there others that might find this intimidating and thus not want to help out. Yes.

    Do some people start from picking pre-written behavioral code and then add a design on top?
    Yes, 99.998% of users.

    That's users of a site, not people working to implement a design for a site.

    The 1% rule of people who use a site actively contribute to a site, and the other numbers cited, are describing the overall landscape of how many people contribute to a project, rather than any sort of hard numbers about how people make a website look a certain way.

    I'm glad for you, that you've worked hard on Bootstrap, and that a lot of people are using it. Cool! I'll note that having the #1 theme on Drupal means that while a lot of people use it, that does not by any means that a majority of users use it, much less nearly all users use it. For those who are having a good experience working with it, great! I'm glad it's meeting your needs.

    The goal of this wasn't to put a new theme into core that others could build off of to create their own themes with their own unique designs. The goal was just to create a theme that would look nice out of the box with a Drupal site.

    Do we need to make sure we theme all the elements of the site? Sure! We absolutely need a good design system that is comprehensive. Some sort of style guide would be helpful in making sure that everything is covered.

    Can Bootstrap provide basic design elements that can be restyled to varying degrees? Sure. If Bootstrap were to be used, should the designer keep that mind from the start so as to not create designs that work cross purpose with Bootstrap? Yes, I'd say that's a good idea. Is that the way every designer is going to want to work? Probably not.

    The designers I know get a good understanding of the goals of a site, the content that will be on it, the look and feel desired for the site, then start sketching, wireframing, creating style tiles, maybe build some prototypes, and eventually build out comps in Photoshop/Illustrator/Sketch and/or a pattern library of the site's components and how they all fit together. Designers and front-end developers may have discussions during this process to make sure a design is implementable, possibly helping with building prototypes and style guides/pattern libraries. Once the design is finalized, front-end developers will start work on implementation, writing front-end code, as well as working on massaging Drupal's output into using the desired HTML and such.

    I've gotten the impression that there's a desire to create a theme similar to that.

    We've also had discussions of how maybe there could be multiple themes added to core. If so, then maybe a separate team forms to work on a Bootstrap-based theme, while another team uses a different approach.

    Honestly that's probably the best way to avoid us just going in circles over and over again. If Bootstrap is used to make one theme amidst many available in core, I have much less of an issue than if the goal is to make Bootstrap the default option for Drupal output, for example.

    So maybe that's the best way forward. Have a couple of different efforts that move forward on different ways to build some themes. Multiple good design options in core would not be a bad thing.

    That's better than trying to force a technical implementation to drive a design process when the people who proposed this explicitly did not want to go down that road.

    davidhernandez’s picture

    Completely agreeing with @mdrummond. The intention from the very beginning was to make a newly designed theme, because we are sick of looking at Bartik. It is specifically in the summary problem statement:

    If they have used Drupal in the past the lack of significant visual difference between Drupal 7 and 8 leaves the false impression that Drupal has not changed. If they have never used Drupal the outdated and bland look of the default install gives a false impression that Drupal is not a modern system. The importance of this needs to be stressed. First impressions are extremely important and the first impression we are making now is not good.

    This issue is constantly getting derailed into a theme system discussion. We don't need to reinvent Drupal theming. That is a different discussion. What we need is an updated visual look for D8. Not a framework, method, learning tool, etc. We've been stuck with Bartik for a very long time, exactly because this is what always happens when anyone tries to touch design in core. It gets hijacked by engineering. As far as I know no one has even attempted to put paintbrush to canvas yet and people are already arguing about implementation. God friggin forbid we let some designers experiment first and come up with different ideas, which is often the exact latitude developers are afforded.

    Jeff Burnz’s picture

    I'm saying that any practical technology discussion needs to center around research-driven conversation points

    jQuery UI is in core - did we ask for objective usage data when that happened, or did we do it because it made sense to have a consistent framework of UI widgets that we did not have to build and maintain ourselves?

    I agree with markcarver about maintainability - clearly Bartik has been impossible to maintain (there are many bugs and frankly it's quite broken). If I were the maintainer (which I was), I would want (and I did, but I was laughed at when I wanted to throw all the CSS away and start again) to do it in a framework, and have 50 people in my issue queue knowing that framework backwards, instead of 5 fumbling around trying to get to grips with a hundred different weird and bespoke ideas (the other 45 left in frustration).

    Jeff Burnz’s picture

    This issue is constantly getting derailed into a theme system discussion.

    No it's not. You and others are framing it that way - I am discussing a design process and how to constrain the design and provide core with a consistent design and how to have a maintainable design.

    Please explain to me where the engineering and "theme system" is mentioned in the above?

    mdrummond’s picture

    I'm 95% of the way to calling this issue dead.

    If you want to design a theme around a front-end implementation, rather than finding a front-end implementation for a design, and we're just going to go around and around and around and around on that, then nothing is going to happen. Once again, Drupal's design will be stuck in the mud because it starts with engineering rather than starting with design.

    markcarver’s picture

    LOL.... we're all such divas.

    ---

    I agree with everything that @Jeff Burnz said.

    I'm not making this about the theme system either (which is a whole other can of worms).

    Nor am I making this specifically about Bootstrap. Granted, this would likely be the obvious/best choice given: [everything I have ever mentioned].

    finding a front-end implementation for a design

    All I'm trying to do is help guide this issue with the understanding that: regardless of whether or not a "designer doesn't work within constraints", they would have to.

    There needs to be constraints.

    There needs to be a framework.

    If history has proven anything, it's that.

    Anything else isn't a viable approach for this issue or for core.

    There will never be a "front end implementation for a specific design". Designs are creative in nature and often abstract. This means we'd have to create our own said "front-end implementation". That is unlikely to ever to be fully "successful" for the following reasons:

    1. Extremely time consuming
    2. Requiring a specific skillset (front-enders, which are the lowest common denominator in this equation)
    3. Bikeshedding amongst said front-enders
    4. Often buggy
    5. Difficult to maintain or improve

    It would be different if said framework is all we ever worked on, but it's not. This is core. There are thousands of other things that get priority.

    This issue isn't dead. It's being realistic.

    darketaine’s picture

    You and others are framing it that way - I am discussing a design process and how to constrain the design and provide core with a consistent design and how to have a maintainable design. Please explain to me where the engineering and "theme system" is mentioned in the above?

    The fact that the exact words are not mentioned doesn't mean they aren't implied. Be constrained according to what, consistent to what and maintanable in what context and all these in cost of... design. Cause all the restrictions (verb and adjectives) apply to the design. No wonder why designers run scared from Drupal. It's like describing a framework, which sorry, but -by definition- is not design driven.

    Jeff Burnz’s picture

    OK ok everybody calm down, the issue is not dead it's just having some misunderstandings I believe. Look, I can summarise my arguments very simply and you will see I am not talking about engineering at all.

    1. Design needs constraints - check, we agree on this. OK, how do we do that? What approach should we take? How do we ensure we get everything we need and done properly? I.e. by what objective measure do we have a "design"?

    2. Component are in the brief as "nice to have". All agree on that one?

    3. Component based approach could be considered a best practice - do we agree/disagree?

    4. To discuss component based approach it might be worthwhile understanding what those might be/are. Lets make a list so we know what we're actually discussing.

    5. Are their existing front end tools/libraries that implement component based approaches we can look at as a guide?

    6. Cores front end theme is not for the 0.02%, it's for everyone else. Agreed?

    7. Maintainability is hard - how can we solve that problem? If anyone disagrees please look at Bartik and note how broken it is.

    And thats it.

    I'm not jumping to engineering at all - I'm presenting real world problems that actually exist in Drupal right now and asking hard questions about how we might solve those issues, and how we might avoid making mistakes - again.

    markcarver’s picture

    Implied or not, it does not change the fact that Drupal is a CMS.

    Drupal isn't "design driven", It's logic driven.

    This doesn't mean an awesome design still cannot be accomplished.

    I know because I have created several themes from truly amazing designs.

    However, to simply ignore a fundamental aspect of something when it's being designed is ultimately counterproductive.

    There needs to be some sort of a solid foundation (pardon the pun) for the design to work from.

    This does not imply it will "restrict or box in the design".

    Frameworks are not "bad", they're necessary; especially when everyone and their dog has an opinion.

    ---

    Regarding #86:

    1. Yes. Either a) choose and external framework to provide these constraints or b) create a homegrown framework which is a monumental task and would effectively postpone this issue
    2. Unclear what this means. It sounds like "components are a 'nice to have'", which I disagree with. They're a necessity and, conceptually, likely the future of the web.
    3. Yes, but redundant by above statement
    4. #1804488: [meta] Introduce a Theme Component Library
    5. Several, you know where I stand
    6. Yes
    7. Outsource the majority of CSS/JS into frameworks/plugins for consistency and maintainability. Only worry about/maintain the Drupal/theme design specifics
    Jeff Burnz’s picture

    Be constrained according to what

    The requirements of the project.

    Consistent to what

    To the style guide - over time. Redesign and improvements are good, however over time the design can drift/suffer and even compromise UX. Bartik is a classic example - note how the primary menu was updated to be responsive, but in the process the design now has flaws and is actually broken.

    maintanable in what context

    Maintainable in the context of core development and the forever changing demands of the web. People come and go, people write half a patch and leave it up to others to complete. It's constant flux and hard to maintain projects over time. Again, Bartik is a classic example. The theme actually diverges from Jens original design by a quite a bit and is much worse off as a result.

    @darketaine pehaps you don't know this since you've been hear only about a year - I was the maintainer for Seven and Bartik themes until Lewis and Emma took over. I spent countless hours building both those themes and preparing them for D7's release. I did a lot of work on preparing Garland for D7 also. Look, I know the pitfalls and ins and outs of building and maintaining a core theme - I've seen many mistakes and made many of them myself.

    darketaine’s picture

    Oh I know it, don't worry. I 'm working with Drupal more than 7 years, so that 1 year you saw there is a bit irrelevant.

    But tbh I don't need to go and have a background check on you or anyone. I'm commenting according to comments not previous experience, because as you said people in their past can make several mistakes so that experience may even not mean anything at all. And not all people learn from their mistakes :)

    Since you are though so experienced in Drupal theming and contributing and as you are a front end developer, not a designer, you have to admit that something must be really wrong if you consider how many designers are still here... almost non existent (and those few still existing I hope they are somewhere far from this issue's comments, really moving forward a great design).

    The comments in this issue actually prove it. Most people just try to make their own point and inject the engineering part - which of course will come in a later step though - while design, to me at least, is a much more creative process.

    I'm stepping back though now, as in my 1 active year here I've learned that there are some points that waiting and acting are much more important than keeping on just to have the last word.

    mortendk’s picture

    ... is this now i point to My first post & countless of times where i argued why a design Will never happen if theres engeneers in the room ... ;)

    Sorry but there is a cultural issue we need to Solve first & anybody saying that "a design is easy"
    Then why is it havent happend the Last 10 years ?

    Im not surprised this thread have taken on a pure technical character thats now is a circle around x or y system but it makes it even clearer why we need (another) fundamental change to make drupal a designer friendly system, which is still my goal.

    The neverending need this community to have intellectual discussions will kill any desire for anyone that's not deeply devoted into the "art of dying in the issuesques" too provide any kind of design into drupal.

    trying to solve design issues by using technical solutions is not how it works.

    I'll go and play with my crayons over in this corner :)

    Jeff Burnz’s picture

    @morten, actually I have been trying to discuss how we define our design requirements and avoid past mistakes, I actually don't care about the specific technology used in implementation phase.

    timmillwood’s picture

    It sounds like this issue needs to be broken down into sub issues to answer some of the key questions. I think we all agree there is a desire for a new core theme but it doesn't seem clear who are we designing it for and why (other than "the old one is so 2009").

    Maybe we need to come up with some personas and look at how these personas would interact with the new theme?

    Or are we not doing this for a functional reason? Is it more for a fresh lick of paint?
    If that is the case we should look at putting together criteria that a new theme needs to hit to look fresh and last us until D9.

    Fabianx’s picture

    So let me join in here a little:

    First of all we have some grand goal we all agree as far as I can see:

    - Create a user facing core theme that "WOWs", is professional and fun.

    Ensure that what Dries talked about in his keynote (that this non-profit site used Drupal and then had Bartik as design) never happens and that instead of someone taking Drupal and then choosing something, they can take Drupal and it looks good and works good out of the box. No tweaking needed.

    --

    Then there is the debate of framework vs. custom base theme:

    I think we can again reach some kind of consensus "peach" here (the banana is already taken), and at least ensure that whatever technology gets used in the end makes it simpler to implement bootstrap / foundation / etc. instead of even more difficult.

    However that is and must be a separate discussion.

    --

    A very little thing to: "But Symfony is a framework and we used that and that worked out great."

    The more core inside background is (at least in my own opinion):

    It worked out overall "okay" to "great" with varying degrees, but there had been lots of cases where we had to bend the framework or Drupal in various quite different ways.

    And the more opinionated the framework was in certain parts, the more difficult it became in parts to implement.

    The reason is that Drupal also has a "place" (else there would be no Drupal) and has its own opinions and not all of those "opinions" are necessary bad - just different.

    What worked out very well however is to take the concepts the framework introduced (Dependency Injection, Routing, HttpKernel, etc.).

    Without going into the details, the abstract concepts and the "Why did they do it like that?" are often more worth than the implementation itself.

    However that again is implementation phase.

    --

    Some more background:

    The reason components and the kinda-agreed-upon "presenters" (Model-View-Presenter) approach "should" be used for the new theme is that it would be a first implementation of components and this is an area we just need to explore. No one can tell that it works or not works, without trying it out.

    An abstract version just does not work. We need a living example. If in the end, this theme cannot be component-ized, that is also fine with me and we will find another way.

    And again that is implementation.

    --

    There is strong voices of giving the designer free reign (and you can count me in for that approach as well), but some people have expressed concerns that:

    - Designers will implement impossible elements (e.g. like a slider) that core cannot support (right now)
    - Designers need constraints so it is easy to implement in the end
    - Designers need constraints to ensure that the design does not go out of the boundaries

    And while those are all valid points, I do not think we should follow the road of giving the designer any constraints.

    Yes I have been there as well, disagreeing with design decisions and yes I myself have caught myself openly disagreeing and even swearing on it. And yes I also pushed back on truly impossible elements before.

    But in the end I got the job done to implement the design as close as possible.

    And that in the end is what many front-enders face in their day-jobs.

    A design agency gives a design and the dev needs to implement it. Period.

    And I do think we should do this painful process in core as well.

    To make it less painful.

    To identify during the implementation stage:

    - How can we make implementing this more efficient?
    - How can we make it easier to theme $arbitrary design with Drupal

    I think that is the challenge to solve, but this challenge we will only experience if the design is given completely free hand.

    And yes in a way it also scares me a lot. (But the designer could totally screw up!!! But why should they? They could also do something really nice and shiny.)

    But in another way I find the challenge of what will come there extremely exciting. Lets give the designers some trust, freedom and empower them.

    And also as many have pointed out already:

    - If we do it again as we had always done it, nothing will change. And we want change.

    Because:

    "If we don't do it different, we will end up with the same as before - again and again."

    TL;DR:

    Extremely excited about this initiative, give the designer free reign and experience the pain everyone has when implementing $arbitrary design for Drupal. If possible experiment with components and other "hot tech" - if and only if that is an efficient way to implement the design.

    davidhernandez’s picture

    6. Cores front end theme is not for the 0.02%, it's for everyone else. Agreed?

    I'm not sure I agree, depending on what this means? Does a core theme need to be usable and approachable by 99% of users/site builders? Yes. Does it need to be catered to 99% of themers so they can copy it or base theme it? No.

    #93 per usual, Fabian gets it. :)

    - Designers will implement impossible elements (e.g. like a slider) that core cannot support (right now)
    - Designers need constraints so it is easy to implement in the end
    - Designers need constraints to ensure that the design does not go out of the boundaries

    And while those are all valid points, I do not think we should follow the road of giving the designer any constraints.

    I think that is the challenge to solve, but this challenge we will only experience if the design is given completely free hand.

    And yes in a way it also scares me a lot. (But the designer could totally screw up!!! But why should they? They could also do something really nice and shiny.)

    Thank you. This is the point many are trying to get across. Why must we start with constraints just to make implementation easier? If a design ends up with something we don't know how to implement, we'll figure it out. Maybe that means bending Drupal in a new way. Maybe it means we've identified a pain point that needs fixing. Or maybe it means we can't do it and have to revise the design. It happens. But telling people they have to design within this little box is frustrating.

    This is one place we should be able to push boundaries and trying some things. It isn't a client project. And it has always been frustrating when this talk came from engineers. People often say this is why they work on core. To try new things, push boundaries, tackle interesting technical challenges. That is what makes it "fun". Then why are people so afraid to try the same approach with a design? People are afraid they'll design something "out there" or "impossible"? Why does it have to be easy to implement or follow the same practices as other things?

    Honestly, what are people afraid of? It's colors and shapes on a page, but treated like a caged animal. "Oh no! Don't let the designers loose. They'll ruin everything." I have my own ideas of how a theme should work and be structured and all that, but I'm interested in this because I want to see what someone else comes up with. I want to see something challenging. Arguing over how to build it just puts us in a box we don't need to be in yet. It's not foolish, and no one is dismissing implementation concerns. We just want to let the design be the lead for once.

    mpdonadio’s picture

    I have read this thread a few times. I think we all need to reread #93 and #94.

    I am a mostly back-end developer. I want to get my business cards reprinted with "Technical Unblocker", because that is what I do. I review comps / wireframes, provide feedback, and then then work with my team to make them come to life.

    If we hadn't tried something new, Drupal 8 would never have happened. That was a painful experience at times, but in the long run we are going to have a better experience for everyone. The decoupled Drupal issue got totally derailed by details by which framework to use instead of discussing how we could actually support a decoupled experience.

    It's also not like we would place a Craigslist ad and pick the first person who responds. We can assume that a careful decision would go into who we engage, and they would at least have some experience with Drupal. If they come back with a image carousel on the home page it's not like we are bound to implement it. That's why you iterate on designs with feedback from the implementation team.

    I'm with @davidhernandez: What are we afraid of? Let's have some fun with this.

    ptocco’s picture

    For what it's worth, I agree with those who have expressed frustration with Drupal theming and design. What passes for a Drupal theme is actually a framework of methods and classes, reusable components, and basic css, just a crude starting point actually. This goes for all the core themes as well as Bootstrap, Omega, Zen, and others. I think that many people would like to see at least one core theme that takes more of a Wordpress approach, with some basic niceties such as stock images. To make it really user-facing for the designer, I would include an optional child theme with plenty of training wheels: ready-to-use sample components, kind of like a distro, a recommended list of contrib modules and cookbook solutions, and of course a coherent users guide (worth its weight in platinum).

    Let me just say that I miss the purity of hard coded html pages. Drupal gives us powerful tools but at a cost, namely, the difficulty of implementing pure design, and understanding how to implement the complex functionality at hand, which can seem beyond the scope of human comprehension at times. Kudos to all the technical gurus who make it happen, but I often remind myself that a technically perfect site that doesn't deliver the right user experience is really not such a great site.

    I'm currently working with a Drupal site that is exquisitely designed yet very hard to manage due to a complete lack of documentation and disregard of standard Drupal methods such as views, blocks, and regions. There are almost no views displayed as views, almost no blocks in regions, and very few regions at all. The backbone of the site is 150 template files and about 25,000 lines of css. (Yes, people actually do write css these days.) Views are used to supply data to render arrays. It would seem that custom templates were the only way for the designers to gain the freedom they needed. Blocks, views, and regions were just too clunky! This realization would seem to support the push toward a more "decoupled" solution, where the front end is platform agnostic, drawing from a RESTful backend or whatever, subjects that are definitely above my pay grade! Again, kudos to the wizards who make Drupal as good as it is, though I'm sure it will get better.

    Perhaps Acquia or Pantheon should get serious about marketing a $25 premium theme. I'm sure tens of thousands of people would find it a worthwhile investment. The user community doesn't seem like the best environment to produce a collaborative product of this nature, IMO. Too much debating in circles, without an iron fisted project manager to guide the creative forces.

    Jeff Burnz’s picture

    I'm not sure I agree, depending on what this means? Does a core theme need to be usable and approachable by 99% of users/site builders? Yes. Does it need to be catered to 99% of themers so they can copy it or base theme it? No.

    Yes, that is what I mean.

    - If we do it again as we had always done it, nothing will change. And we want change.
    Because:
    "If we don't do it different, we will end up with the same as before - again and again."

    I realise what you are mostly talking about is how we communicate with the design community, as in, doing that differently, but lets not forget we have done this before. Bartik was a free hand, there were no constraints (in the beginning) on the D7 theme initiative.

    Not until after Bartik was chosen did the heavy burden of it actually having to work as a Drupal core theme come to bear, things like accessibility, RTL, Drupals settings, marketing requirements & cross browser compliance etc - all those things had a profound impact on Bartik and changed it, a lot, from what it was.

    The original design was monochromatic minimalism, instead we ended up with Blue Marine with a gradient and serif font.

    rikki_iki’s picture

    Huge +1 for this initiative.

    Would be good to step back from the technical/implementation discussion though and get back to what needs to be done first in order for there to be something to implement.

    The only constraints on design should be;

    1. Audience/purpose (user research/personas - who/what/why)
    2. Content (IF the audience do expect to see a slider what would go in it?)
    3. Accessibility

    Frameworks, maintainability and how Drupal does things are constraints for the front-end developer, and only considerations for the designer. They should work as a team and respect each others expertise. A front-end dev can alert a designer to something that might be problematic but they shouldn't try to come up with a solution.

    I do agree the team should be small and the community needs to trust them to get the work done with very little oversight, otherwise it will go on forever and alienate designers from this community even more.

    joelpittet’s picture

    Big +1 to #98 Thanks @rikki_iki, way to boil it down, first person to mention audience, though @timmillwood touched on it too.

    And +1 to small team too with all the trust and encouragement we can give them!

    Thanks for opening up this idea @lauriii!

    Jeff Burnz’s picture

    #98 summed things up very well ++.

    I do agree the team should be small and the community needs to trust them to get the work done with very little oversight, otherwise it will go on forever and alienate designers from this community even more.

    Indeed, we all have our oar to push but that the end of the day you win some, loose some, but the end product has to be completed and it's only possible as you suggest, at least that is my experience. That's actually why I pointed out how much Bartik changed from original design to finished product, after so much meddling it was watered down and imo ruined.

    jensimmons’s picture

    A few things about Bartik and what I intended when I designed it.

    I did not expect very many people to use Bartik as a theme for their website. While a handful of Drupal contributors used Garland (the default core theme for Drupal before Bartik) for their personal websites, total usage seemed to be something like 0.00000000003% of all Drupal websites (not a scientific number). It wasn't not my goal to get more people to use the default core theme, but instead to design and code a better theme to replace the core theme — and do the job it was doing.

    If I'd been designing a theme for WordPress or another system, I would have made a theme for a certain usecase. A blog? A publication? A store? A musical band? (Well, I would have been stuck trying to choose one usecase for the default theme, not a dozen variations, and that is impossible.) You can look at Squarespace to see how they define potential usecases for content-unknown-templates and create variations to fulfill those usecases. I don't think this is what Drupal needs. Contributed themes could fill this need, and even they don't. Contrib is full of front-end frameworks, not useable design templates. I think that's the nature of Drupal ecosystem. It seems almost every Drupal project has the budget for a custom theme (even if it's a tiny budget). If it doesn't, people don't use Drupal.

    So what is the job of the default core theme? I'm sure some people argue that Drupal doesn't need a default theme. Just use Stark (or something like that.) But I disagree. The default core theme does an important job. And we need something doing that job. So what is that job, if it's not to be a pre-packaged suggestion for how a new website should look?

    There are a few:

    1) To be the theme that's used while a site is being built.

    Every project has a long phase where content types are being built. Displays are being sketched out. View modes and views being built. Menus and blocks being added. The custom theme hasn't been started, and won't be ready for months. Site building comes first. Front-end dev comes later.

    Sometimes only developers see a project in this phase, and they are building a site based on a clearly-articulated fully-complete plan. Many times, however, clients / stakeholders / executives / designers are taking a look at things in progress, and design decisions are still being worked out. The site itself can function as a prototype, and having a theme that's as simple as possible to keep people from being confused or distracted can help.

    I'm not sure how well Bartik does this job. That bright blue header gets in the way, imposing a strong sense of the Drupal brand on things. I wanted Bartik to be more neutral, but failed.

    2) Teaching. / To give Drupal a look while people are learning about Drupal.

    The default core theme is used most while teaching Drupal. It's onscreen at conferences. It's used in demo videos. It's screenshots are printed in books. You can't learn anything about Drupal 7 without seeing Bartik.

    So default core theme must look good on screens — projected. Many things that look good on the web look terrible on projectors. Please, make sure a new theme does not.

    It needs to look good when printed in books — both in CMYK and in Black & White. That's why Bartik was originally intended to be black & white (a decision that was overruled later). It needs to have high contrast. And if it uses color, those colors must print well in CMYK. (Which is a whole different thing from RGB. Make sure whoever is designing things understands how to design for CMYK.) And those colors should print well in black & white. If you don't have enough contrast in luminosity, black & white screenshots of a color web page won't be readable.

    3) To be an example of how to make a theme — for beginners.

    I drastically changed the code from Garland so that anyone forking the default theme would be in a good place — and not stuck with a mess. The code should show off simple, easy-to-understand best practices. And in my opinion, not be biased towards multi-million dollar teams. Make it simple for beginners to understand. People using BEM / Sass / etc don't need to learn from the default core theme's code. They won't look at it. They'll learn from Zen or something else. Keep the core theme simple — for the very newest newbies. It's ok if it's architected different than Drupal core. Show people they can make their own choice of how to structure code. Drupal is so powerful, it can handle any methodology.

    4) To ship — as the default core theme.

    I made a lot of design decisions very early in the process for political reasons. I was on a mission to replace Garland. I knew if I changed things too much, the switch would never happen. And well, as the only person in 10 years to successfully get a new theme into core as the default, I was apparently making very good political choices. But that doesn't mean those decisions should stick around.

    I used a gradient header because Garland had a gradient header. I used Color Module because Garland used Color Module. I never would have make those choices if the designer of Garland hadn't already made them for me. I wanted to use an open-source web font, and not specify system fonts, but I knew in 2009 a community of PHP developers weren't going to go for it. It would have added too many Kbs to the download package.

    This is what you need to hire a professional design for. They will gauge the current political reality, and figure out how to design something that will succeed in the current climate. Don't hold onto things that don't make sense. Let them go.

    On Branding

    Realize the job of this theme is to be a stand-in for future potential — as a real site is being built, or as people are learning how to make Drupal sites in general — not to be an actual website itself.

    I've heard over the years many people articulate the belief that the Drupal default core theme should be an ambassador of the Drupal brand. It should look Drupally. I couldn't disagree more. By the time someone who's building with or learning Drupal gets to the point of seeing this theme, they are already in. They've decided to try Drupal out. They don't need the Drupal brand smeared all over their new site potential. Let the brand be seen along the journey — on drupal.org, when downloading, even when installing. But when someone gets to the point in the journey when they are either building a site or learning to build a site, their focus in on their site. Not yours. As Kathy Sierra would say — it's time to help them be awesome at their thing, not to ask them to think Drupal is awesome. Help them make something great. Don't require Step 1 of their work to be to get rid of the Drupaliness.

    I think this is the weakest thing about Bartik, and it's only more so in D8. There's a subconscious tension over why in the world it's Drupal branded.

    I hope the new default theme does not have Drupal branding on it. And I know from past discussions this debate will be a long and painful conversation. A neutral theme is considered "boring", "ugly", "too plain". Some people think it's important to have some kind of strong visual impact after the installation is complete — despite the fact the site is empty of content. Some people even want to add content / add more content types because they worry about this first impression moment. I also disagree with this.

    Please design while thinking about the real user — the Drupal site builder & their team. When Drupal is first installed they don't have a website, they have website potential. There are no users for that website. There're just the developers, thinking about what to do next. Their empty site should be empty until they start to fill it up. (The question of whether the tool should provide more hints about how to use the tool is a different question. Maybe that would be good. But adding dummy content so that the default theme doesn't 'look ugly' on an empty site is a bad idea.)

    The default theme should show off whatever site builders do next, as they add their content, move blocks, build menus... not as a theme that they will choose to keep and show to their users, but as a theme that helps them focus on what they are doing. Helps them see what's been built and what hasn't been built. Helps them show their work to their team / boss / client. The default theme will likely be used for many months, as the site progresses. This is not a time to be shoving Drupal branding onto that new site in progress. Trying to make it so only weakens the Drupal brand. You've got people in meetings asking "why is it blue?" and other people muttering "Drupal" like it's a curse word. "That's just stupid Drupal. It won't be like that later. Please just try to ignore that." And why? Because Drupal core folks want new installs to look peppy for the first few hours? This is a confusing mismatch between some kind of idea of what branding is for and the reality of living with the default theme as a site is being built. And it's unnecessary. Bartik would be a much better theme if the logo were hidden by default and the default header color were black, grey or white, and much shorter.

    I hope the new default theme takes this idea to a new level — to be a neutral base on which to build a website, for months, going through team reviews, knowing the 'real theme' will get coded later. Or the neutral base on which to learn about how to use Drupal, imagining a day when the tools are second nature and anything is possible. That's the job of the default core theme. (For more on what I meant, see #105. By a "neutral base", I don't mean a wireframe theme.)

    Crell’s picture

    Excellent points Jen, thanks.

    I will partially disagree with the last one; there's 2 different audiences for the default theme, which get conflated. You describe one, which is the site builder of a yet-to-be-designed/themed site. For them, I can see the argument for a more "Wireframy" default theme that they can pour their own stuff into.

    However, there's also the first-time Drupal evaluator. Someone downloading Drupal for the first time to kick the tires. They DO need more than an empty shell into which to pour stuff, since they don't know what stuff to pour. A super-basic grayscale theme for them is going to be an immediate turn off, and they could benefit from some default configuration and content.

    We tend to conflate those two into the same "Default theme" discussion, but I think that's an error. This also ties into the long-running discussions around more/better core profiles. Standard and minimal really don't do a good job of handling the above split. Perhaps if we had a better "demo" profile in core, we could let it have the "branded" theme (be that Bartik or something else entirely) and let standard default to a more minimalist, Wireframy, "empty" theme and configuration.

    mpdonadio’s picture

    +1 to #102.

    Those two themes are ones that Drupal shops typically have their own versions of for various projects while bringing sites to life.

    jensimmons’s picture

    After I wrote my comment, I read through the 100 comments that proceeded it. I see that a lot of people want to make a default theme like a successful WordPress theme — something with opinions, something prepackaged with a hero carousel or ready to display a certain kind of content. I know the WordPress ecosystem has many hundreds of such themes, and the strength of that theme library is a big reason people choose WordPress.

    I believe Drupal is different. I stated this above, in the third paragraph, but not very well... so I thought I'd try again to be more clear.

    I have never met anyone who chose Drupal expecting that they could download a contrib theme, build a Drupal site, and be ready to go. I can imagine that the people on this thread are likely to be the people who want such a reality the most. We all have expert-level knowledge in how to build a Drupal site. And want to be able to build some quickly, on the weekend... and maybe would love to have more themes on drupal.org that could be used, that are beautiful, that have a strong visual sensibility, that are ready with pre-packaged items like a hero graphic carousel. I get that. I just do not believe creating an core theme with that kind of a strong visual sensibility is going to solve this desire.

    It's interesting that the Drupal contrib theme world has never built up such a stable of workhorses. We have no such ecosystem. Perhaps what I said in comment 101 is true. Drupal is so hard to learn and complex to use that people who do choose it only do so when they have the budget to do a custom theme. It may be that core contributors are the only market on the planet for such themes, since you have the skills to easily spin up a Drupal site. Other people know a Drupal project takes months, and they aren't going to use Drupal unless they have a complex project, with complex needs, including the need for a custom theme. When faced with a need for a quick site that has a finished theme, they turn to WordPress, Squarespace, Tumblr, etc. No matter the reasons — this is the reality. There are few contrib themes of this type.

    Bartik is not the only non-site-specific theme I've designed. From around 2006-2010, I made dozens of themes that would be reused by strangers for sites I'd never see. All of them (except for Bartik) were intended to have a strong visual sensibility. One was dark, red & orange — a great look and feel for a fancy restaurant. Another was a clean generic slate for posting videos, with lots of white space and thin grey lines. I didn't have a specific client site in mind. I didn't know the name of any sites that might choose my themes. And couldn't design for specific content. But I could, and did, make assumptions about what type of project might choose each theme. I could make such assumptions because I knew all of them were going to live in an ecosystem where there were lots of choices. If someone wasn't making a website with video, then they weren't going to choose the theme for video.

    The Drupal default core theme does not live in such an ecosystem. If the new default core theme is 'fun for kids!', site builders don't just choose a different default core theme. You can't assume people will want a hero carousel, because most website do not want that. The core theme must work equally for all Drupal projects. And if you attempt to shove something deeply opinionated into a core theme, it's not going to work. You will make it seem like Drupal is only good for certain kinds of websites, and not others. Suddenly it'd be like Drupal were trying to tell people they should make a kids website, or should have a hero carousel. And that's a bad road to go down. The strength of Drupal is that it is a non-opnioniated toolkit for any kind of content website. The opinions and options live in the module library, not in the themes.

    It's literally impossible to make a default core theme that is fabulous for fancy restaurants and simultaneously perfect for a university science department. Those themes are the kind of themes that belong in contrib.

    People will not choose Drupal because they like the default core theme and they want their website to have that branding.

    I do think Drupal will benefit from having a professional, well-designed core theme, that looks like 2017 with great typography and solid layouts. I do think it's possible to style all the HTML elements, and most common variations of block placements. Every core field and block should be well styled. Most contrib modules should look good when styled by the core theme CSS. You accomplish this by being as generic as possible. You can't possibly come up with a design system that has custom CSS for every contrib module in every variation. You've got to have universal CSS that works (unless the contrib maintainer has done something to make it not work), because that CSS is not specific.

    That said, it is impossible to design a default core theme that does what those WordPress contrib ecosystem themes do. It's not possible.

    And even if it were, that would not compel new people to start choosing Drupal over WordPress. That's just not how things work.

    If people are interesting in providing more themes of the quality WordPress has — with the visual voice and strength that those themes have — then that's a different project. See if there are ways to build up the Drupal contrib ecosystem. (I don't think there's demand for such a thing, and I believe you should test out your assumptions before putting in a lot of wasted effort — but that's my opinion. I could be wrong.)

    I believe Drupal will do best if the default core theme fits well with what Drupal is best at, the strengths of Drupal. (See everything I wrote in comment 101.)

    jensimmons’s picture

    Re: Crell in #102

    there's 2 different audiences for the default theme, which get conflated. You describe one, which is the site builder of a yet-to-be-designed/themed site. For them, I can see the argument for a more "Wireframy" default theme that they can pour their own stuff into.

    However, there's also the first-time Drupal evaluator. Someone downloading Drupal for the first time to kick the tires. They DO need more than an empty shell into which to pour stuff, since they don't know what stuff to pour. A super-basic grayscale theme for them is going to be an immediate turn off, and they could benefit from some default configuration and content.

    We tend to conflate those two into the same "Default theme" discussion, but I think that's an error.

    Actually, I'm not a fan of having a wireframe theme in core, and definitely not as the default. I do not envision that being a good idea. I can see how it might seem like that's what I meant, but hmmmmm, no I don't like that idea. I agree with you, that doesn't work for a lot of people. I think the default core theme should look like "a real website". And be usable as a real theme for a real website. Just not one that's super opinionated visually. Which is hard. But possible. It should be polished and nice. Beautiful typography, but generic typography. Beautiful layout and spacing, but generic use of whitespace and layout. Decent set of regions, but something generic — not something particularly groundbreaking.

    To me, a wireframe theme looks very much like a wireframe. It sort of screams "I'm not a real website. I'm a draft!" And while I think that would be a great contrib theme, and I can see how bigger shops would have such a private theme for their own process, I don't think that's something that works in core. I think that's simply another example of something that's for a subset of users, and isn't appealing to a wide enough range of needs to deserve a place in core.

    Thanks for the chance to clarify. I do mean generic, but not wireframey. It's likely hard for me, a designer, to explain to people who don't think this way all the time... but there's a clear difference in my mind's eye.

    JakeWilund’s picture

    @jensimmon #105:

    That description screams Bootstrap/Foundation/etc, and in my opinion, I think that's exactly what a default theme ought to be modeled after. One of the things that makes themes like Bootstrap and Foundation so appealing is that you can get your site to a state that "looks good" very quickly, but they essentially lay the framework for themers to quickly expand upon, while also be presentational from the get go.

    It alway struck me as odd that for all of the external libraries and tools that Drupal leverages in core, that a base theme framework (like those mentioned above and others) wasn't picked up as the default theme for Drupal. Drupal site building is all about not reinventing the wheel, so why not take the great work of the base theme contributors and work to make one of them a part of core as a default theme?

    Fabianx’s picture

    I think we need to split the issue, teams and initiative in two halves:

    • - There is the "framework camp"
    • - There is the "demo / design camp"

    Because the missions have very different goals and that is not compatible.

    Framework:

    "We want a framework in core as good as bootstrap or foundation and it follows best practices of 2016"

    => Nice for site builders and during development

    I personally think we already have enough of that in contrib there, but I am very happy if those being happy with bootstrap / foundation or whatever start their own initiative to get one of those into core and give site builders a great tool.

    And if its really good, it could become the standard theme for "standard".

    This is all very technical and has in the best case some UX considerations as the design usually is already pre-selected by the frameworks anyway.

    However I feel this is not what _this_ initiative is about.

    Demo / Design Camp

    - This is about: design-first.
    - This is about: No-restrictions.
    - This is about beauty, not technique.

    This is about that you have Drupal + Mockups and need to create the theme - just that here we have the core process and such can come up with the best solution for doing so.

    "We want nice and shiny opinionated core theme that looks great and can be used out of the box"

    Yes, of course it would tailor to certain use cases for like others, but I don't think that is a bad thing per se.

    If with squarespace you can have any website up and running in 5 min, if the same is true with wordpress and then you use e.g. Acquia Gardens (RIP I liked you) and it looks ... interesting, then this is not about "endless possibilities with Drupal", but rather about something missing, because a blank slate is just not that interesting.

    Wordpress is now used for small to big site websites, authenticated or not and it still looks by default like a blog and is tailored to this use case still primarily.

    So a good first impression does not mean it is limited to that use case.

    So again:

    This is (as far as I understood from laurii) about a nice, great looking beautiful design that in _addition_ follows best practices and core standards.

    It is not meant as an educational theme that is easy to use for beginners (though it will be kept in mind as we want to make it easy for everyone), it is not meant as a theme you develop your site with (there are already so much better things for that in the contrib space).

    It is a theme you might want to modify a little (with some custom templates), but use else out-of-the-box for your blog or small website or mini-site.

    One theme from the commercial WP space that comes to mind here would be "thesis", which many used just out-of-the box and it looked good. Even for different use-cases.

    So it is not impossible and the default wordpress theme IMHO does not look that bad either.

    mortendk’s picture

    thank you fabian for cutting through yes it needs to be separated, else any kind of design will be buried in political issues etc (as jen mentioned) and were gonna end up with a concensus on some framework that is believed is answering all the problems with magic ...

    tbh the culture around drupal is one of the biggest hurdles. Doing this means at the end of the day that its gonna be people that have not build the system - that will decide how it will look. Which i know is "terrifying", and will cause a lot of reactions, how we figure that out needs to be adressed, cause this is not a technical issue that can be measured, so we need to change how we work on this.

    Personally i could not care less about the whining i heard all the arguments when we started out 4+ years ago to make Drupal a "Designer Friendly" system by removing phptemplate & getting a more designer friendly system into core - this is the next step of that evolution.

    webchick’s picture

    Issue tags: +Drupal core ideas

    Hi there! This is an issue that we'd ideally like to move to the new "Drupal core ideas" queue when/if #2785735: [policy, no patch] Agile process for bigger changes in core (Part A: Ideation) goes through (hoping for the next week or two). If you could read that issue and provide your thoughts on that, that would be great!

    webchick’s picture

    Project: Drupal core » Drupal core ideas
    Version: 8.3.x-dev »
    Component: theme system » Idea

    Moving over to the new Drupal Core Ideas queue while we get this into shape.

    lauriii’s picture

    We have had multiple meetings around this topic at DrupalCon Dublin. I have summarized the contents of these discussions into the issue summary. Some good news is that we are going to proceed together with the default content initiative which makes our design work a lot easier.

    I also created a new issue about adding new experimental installation profile. The plan is to enable this module inside theme inside the new experimental installation profile, instead of standard.

    markconroy’s picture

    Great to see movement on this. Sorry I couldn't get to any of the discussions about it in Dublin, I was held up all week on other tasks.

    Also, great to meet so many of you here.

    dasjo’s picture

    Really liked following the discussion during #drupalcon sprints, here's a photo :)
    https://twitter.com/dasjo/status/781882462439870469

    lauriii’s picture

    I wanted to list the key points that we are proposing here:

    1. It is proposed that team would be working on creating a new design for Drupal. Do you agree that there is a need for creating a new design?
    2. It is proposed that new theme would be added to the core as experimental. Do you agree that it is possible to include experimental themes in Drupal core?
    3. It is proposed that the new theme would not be built for Drupal, but it would be instead created to showcase a real use case using Drupal as a tool. All Drupalisms are proposed to be left out of the new theme, including the blue color. This is done to make sure that there is a separation between branding of Drupal and demonstrating Drupal. Do you agree that the new theme shouldn’t be built to brand Drupal but instead to demonstrate it?
    4. It is proposed that the new theme would not be built as a framework for people to built things on top of it. The new design is created to solely demonstrate how Drupal supports people building sites with modern design. This is change from the current goals that has been set for Bartik. Do you agree that the new theme shouldn’t act as a framework?
    5. It is proposed that Drupal would include in future have faster phase for including new themes to lower the barrier of creating a new design. That would change the current mindset which assumes that when something is created, it is there for forever. Therefore we would clarify that the theme is just temporary, and we agree on adding a new theme in x period of time. Do you agree that there could be faster phase in including new themes in the core?
    6. Many contributors have requested the product management to be involved in creating the new design. How would you like to be involved in the process?
    tkoleary’s picture

    @laurii

    I'm totally on board with all of that.

    davidhernandez’s picture

    Do you agree that the new theme shouldn’t be built to brand Drupal but instead to demonstrate it?

    One question - does that preclude it from eventual consideration as a new default theme?

    tkoleary’s picture

    cosmicdreams’s picture

    #5 actually begs two questions, only one you're making explicit. Not only are you asking if we agree with a faster develop phase for including new themes in core but you're also asking if themes should be temporarily included into Drupal 8.

    Never have we had a theme included into core and removed in the same major version. Is that what your aiming for?

    lauriii’s picture

    Never have we had a theme included into core and removed in the same major version. Is that what your aiming for?

    Most likely we won't be able to remove themes in the same major release because of BC issues. We can mark them deprecated if that would make any sense and then remove on the next release. The main point here is that they wouldn't be installed by any installation profile and would be hidden on the appearance page. Therefore these themes wouldn't get as much exposure anymore.

    Removing needs issue summary update tag since I think all the points on #72 has been addressed.

    lauriii’s picture

    Issue summary: View changes

    #117

    One question - does that preclude it from eventual consideration as a new default theme?

    We discussed this on today's bi-weekly meeting and this feels like a very valid point. We discussed that there is not really a default theme of Drupal anymore since there will be multiple installation profiles. There is three installation profiles that all set one theme as a default theme. This theme would be enabled by the installation profile that is built for demonstration purposes. Besides that there would be two other installation profiles; essentials (old standard) and minimal. I will update the installation profile issue with the detailed idea.

    Gábor Hojtsy’s picture

    Right, there is already no default theme, we have two profiles and a different theme for each. This is a new profile with yet another theme. Also given the theme is not built to represent Drupal's brand but rather to represent the brand for the use case it covers, it sounds unlikely to me that it would be the default theme of Drupal. Eg. https://www.whitehouse.gov/ has a great theme, if there is a "government site" use case in core, such a theme would be fitting but its not a theme that represents Drupal itself, it represents what Drupal is used for in that scenario. The goal of this proposed theme in my understanding is to fill that gap and is going to be built in tandem with the sample content for that scenario., that is #2816775: Add example content to experimental install profile.

    Fabianx’s picture

    #122: Top notch comment! :)

    I think that is exactly what the theme is about / should be about.

    davidhernandez’s picture

    there is already no default theme

    There is a default - the one that belongs to the standard installation profile and is seen/used by evaluators, trainers, authors, and anyone new to Drupal. Do we then pose a different question - will we change the "top of the list, default selected on that form" installation profile to be "demo"? Or, make that selection screen more crucial and elaborate. "Chose your own Drupal adventure."

    It sounds like what Lauri is saying at least, is the new theme will not be the default theme for the "essentials" install profile (which will replace standard?)

    lauriii’s picture

    #124: Essentials is just an idea that we could rename that installation profile to something else than standard since that as a name doesn't explain what that installation profile does.

    Most likely the theme we are creating here will not be set as a default theme for the standard/essentials installation profile. The issue we are tackling here is that Drupal's first-time user experience is poor. Standard installation profile is meant for more experienced people and it is fine if ships with Bartik since will just replace it with something else in most use cases.

    lauriii’s picture

    Status: Active » Needs review

    I feel like we are getting a consensus in the community so setting this as a needs review.

    markconroy’s picture

    +1 for this idea.

    Great to see it moving forward and getting a lot of support. This could be a real game changer in terms of drupal adoption when new users can see how powerful drupal can be, but will also be a great tool for helping them to learn how to build websites when coupled with the farmers market.

    Well done everyone.

    ckrina’s picture

    +1 for it too.

    The way the scope has been limited makes the new theme more viable and focused, and reaching its goals will probably be easier now. Also, it will be a great way to open the path for introducing a new theme in the future and we can learn a lot from it.

    Fabianx’s picture

    +1 to the new approach, I think we are close to RTBC, but I think it is good to wait for a while still.

    lauriii’s picture

    Issue summary: View changes

    Copied the questions for the product management from #115 to the issue summary.

    Xano’s picture

    Bartik's getting a little dated, and the fine folks here have done a great job at documenting the requirements and process transparently, so I support the creation of this initiative. I do wish to propose we do not commit to including this theme in core prior to evaluating the final result and confirming it does not only meet the requirements listed in this issue's summary, but also meets the future requirements by the time the theme will be presented for final inclusion, as requirements can change, and some may have been missed here.

    TLDR; I am not a themer, but from a community and process perspective, I support this initiative (+1).

    davidhernandez’s picture

    Just looking at signoffs, should accessibility maintainer be added as well?

    mgifford’s picture

    This would make sense to me @davidhernandez

    It would be good to have an overview of accessibility for this new theme. Certainly ARIA, color contrast & keyboard focus issues come up often enough.

    mpdonadio’s picture

    Instead of just saying color, contrast, etc, would be make sense to just say that the theme will be WCAG 2 Level AA compliant? That will give us concrete details and a checklist to work to (eg, specific contrast ratios), and also be a "selling point" for the theme to be able to demonstrate that this is possible. Saying WCAG 2 Level AA lessen workload/back and forths so that the the accessibility maintainer input could just focus on the fuzzier aspects of compliance.

    Gábor Hojtsy’s picture

    Right, we'll not have anything concrete to sign off on in term of accessible implementation in this issue, so we can set targets to shoot for and get signoff on them at best.

    ckrina’s picture

    Yes, committing to WCAG 2 Level AA makes a lot of sense.

    mpdonadio’s picture

    Issue summary: View changes
    davidhernandez’s picture

    Status: Needs review » Reviewed & tested by the community

    There doesn't seem to be much else to discuss without product team involvement. A lot of thought has been put into the proposal, direction seems clear, I'm not seeing any major objections. Any adjustments needed can be made later, after official product approval to move forward.

    Wim Leers’s picture

    Awesome consensus building here!

    Drupal community++

    clo75’s picture

    Hi everybody

    Disclaimer: English is not my native language, so I hope to be clear.

    First thanks for having this interesting discussion about having a beautiful theme in core. But as some people says, there nothing new under the sun; it was almost the same at the time of Drupal 7 and I remember back in 2007 having discussions about that.

    I'm a web designer and I always regretted the non-friendly Drupal theme solutions for non-programmer (I have some skills in HTML/CSS). But also, I've always liked the Drupal power, allowing me to be able to use granularity fields, SQL requests, maps, semantics features, advanced search, users directory, conditional templates...without any programming knowledge.

    What I mean to say that there is two parts in the problem:

    - 1/ having a theme with a beautiful design. Indeed, emotional design is very important, it's the first contact with the site (web or mobile). Often this is the most important part for non-techies clients. So it could be the same for some people looking after a friendly solution among the ocean of CMS (CMF) solutions: "Hey this new Drupal 8 core theme looks fantastic, so Drupal 8 is fantastic."Yes beauty coulb be interior ans this is the case of Drupal right now. We need to attract people with exterior beauty in order to see more the interior beauty.

    - 2/ but don't focus only on a beautiful design. The aesthetics part is just a little part of a global solution. You can have the prettiest core thme design in the world but it' doesn’t matter if this design can't be easily and deeply modified, structured or if this design involves slow performances, etc. Often UI designer are not UX designer, so even if their creations are beautiful they rarely are efficient or worse… useful.

    So be aware to focus only on beautiful UI. Yes it's very important as indeed Drupal was always behind some other CMS. But we know also that the real beauty of Drupal is often hidden, mainly in the power of the toolbox.

    So let's say with D8 we have a very good motor, one of the best in the world for motorize the web. Question is : we need a designer to make a car like a for example a Lamborghini. OK but the immediate question who comes in mind is "hey why a Lamborghini design?, I prefer the beauty of Aston Martin... oh wait... no Jaguar is better in term of classics design..." and so on. In fact all of this car design are wonderful, if you choose one you make no mistake. But the choice depend of the purpose of your needs or your tastes. It's always better to have some choice (even among the prettiest things in the world) because each case is different..

    So having a beautiful design core theme inside Drupal 8 is indeed a very good idea... but having just one is a dangerous idea. First you have only one choice, even if the design is beautiful this is a question of choice. Second, beautiful design often doesn't resist well to time. And third UI designer makes UI and in most cases aren't not aware of structure, content, performances, UX, Drupal advantages...


    So it’s easy to make critics what could be good solutions? (sorry for the caps but this is the important part)


    1/ OFFER IN DRUPAL 8 NOT ONE BEAUTIFUL CORE THEME BUT A COLLECTION OF BEAUTIFUL CORE THEMES (ALMOST 2). ONE COULD (!) BE CHOOSE AS THE DEFAULT.


    2/ MAKE THIS AS A VISUAL SITE BUILDER THEME SOLUTION SYSTEM (hey forget about Panel who is more a powerful dev solution with a non-friendly interface). AND INDISIDE THIS SOLUTION MAKE THE POSSIBILITY TO SAVE DESIGN. SO OTHER DESIGNERS COULD MODIFY OR MAKE NEWS DESIGN PROPOSALS. DON’T FORGET PERFORMANCES (IT COULD HAVE PERFORMANCES METRICS WARNING) AND WEB, TABLETS AND MOBILE DESIGN FEATURES.


    3/ USE DRUPAL POWER ENGINE. ASSOCIATE THIS SITE BUILDER THEME FOR EXAMPLE WITH PARAGRAPH IN ORDER TO HAVE A BETTER STRUCTURAL CONTENT (AND NOT JUST A BEAUTIFUL DESIGN).


    The best example is in WordPress with the Elementor plugin: it’s a FREE visual Open source site builder, with a good UI, a good UX with modern and soft animation effects and a strong set of features for the non-techies designer. With Elementor you go beyond the target of a simple beautiful designed theme. You construct your design (form and content), possibilities are endless and you can save parts or the whole thing to reuse it later. And performances tested in Google Page Speed are rather good. The only drawback currently with Elementor is the lack of starting base themes but it’s a very young project (first release in June).
    https://elementor.com/
    https://github.com/pojome/elementor


    In Drupal 7 and 8 we saw a lot of things “not invented here”: jQuery, Backbone.js, Symfony, Twig, etc. So why not to start with Elementor concept and improve it with the Drupal Power? I’m not affiliated with the Elementor team, so it’s also possible to just use this idea.


    We need a wise council: there is inside the Drupal community some strong voices and very advanced theming people who knows Drupal and theme design, UX and content. If not, UI designers will make beautiful but very unuseful theme.

    SO THE IDEA COULD BE UNDER THE LEADERSHIP OF DDCE (DRUPAL DESIGN COUNCIL OF ELDERS)… (sorry for caps once again but promise it’s the last time I will use it in this post)

    - START WITH THE ELEMENTOR CONCEPT
    - IN THE BETA PHASE, CONTACT DESIGNERS AMONG THE BEST DRUPAL AGENCIES AROUND THE WORLD TO PROVIDE SOME BEAUTIFUL BASE DESIGN. IT COULD BE THE CONTRIBUTION OF THEIR COMPANIES TO DRUPAL.
    - OK BEAUTIFUL DESIGN, BE SURE NOT TO FORGET DRUPAL POWER, STRUCTURE, PERFORMANCES, MULTI PLATFORM EXPORT, ETC.

    Don’t misunderstood me, my proposal is not the ultimate solution. For complex projects Developer and Designer will still work together. I talk about “seductive solution” to attract the UI designers world to Drupal. And of course it will attract more users…
    So we need to go well beyond the idea of just include in Drupal 8 a beautiful core theme: this is a dead end road idea.

    jmuzz’s picture

    +1 for creating a beautiful theme for core.

    @clo75 These are some good ideas but I'm in favour of point 4 in the issue summary. I don't think the new theme needs to be a framework. I disagree that creating a theme is a dead end. It wouldn't prevent a more flexible system from being developed in the future, but it would demonstrate that it is possible to make beautiful websites with Drupal.

    Fabianx’s picture

    #140: Thanks for your ideas and input.

    The scope of this issue is the beautiful theme as outlined by the issue summary.

    The best way to get your ideas implemented for getting the UI designers on board would be to start a new issue in this Drupal core ideas project. (On top of page click on Issues, then on the next page on "new issue").

    It is a good idea, but not related to the outlined scope of this issue and will likely get lost here, while in a new issue it could get the attention it deserves. :)

    mortendk’s picture

    +666 for the laurii suggestions - even more for not using the issue to scope creep.
    So hey ho Lets go!

    Cottser’s picture

    I am +1 for this overall (can't speak to all the specifics just yet), I think this would be a big win for people evaluating Drupal.

    webchick’s picture

    Status: Reviewed & tested by the community » Needs review

    We talked about this on our bi-weekly Ideas queue call today. Most people had initially favourable reaction, but we ran out of time to really dig in and discuss. So we owe you some feedback on your questions above. In addition, some other things came up from Dries:

    - Does this get in the way of other work that's maybe more strategic? For example, will we end up slowing down the Media or Layouts initiative, which we have firm survey data backing up the need for, in favour of this?
    - There seem to be lots of dependencies -- farmer's market documentation, default content, new design... It feels like this might be too big of a "bite" and it might be better to "chunk" it.. phase 1, 2, 3, 4...and only target some of the "infrastructure" bits for 8.3, rather than the initiative as a whole.

    davidhernandez’s picture

    Does this get in the way of other work that's maybe more strategic?

    Do you mean that people will have their attention taken away from the other initiatives? I don't think there is much overlap in people. (Roy is probably the main overlap?)

    There seem to be lots of dependencies...

    The only blocker I'm aware of is the experimental installation profile. (Which we can proceed without, but probably wouldn't release without.) Farmer's market was brought up as an example use case to make the point that this wouldn't try to serve every use case. What dependency would be there? Default content is something we'd like to use, but shouldn't be a blocker. But there has been discussion between the two teams to work together as each initiative progresses. So phase 1, 2, etc are all about building a team, creating a design, and begin implementing. Since this has been split from the "components" initiative, it should just be a disparate theme, with no immediate need for infrastructure changes.

    tkoleary’s picture

    Just to amplify what David Said.

    A lot of work and consensus building has been done here by Laurii et al to really approach this as an MVP including:

    1. Agreeing to not make this a framework theme, and *only* focus on theming the content of the farmers market example.
    2. Agreeing not to attempt to solve the problem of the theme component library.
    3. Setting aside any potential bikesheds around this being the "face of the Drupal brand" by making it part of an additional experimental profile, not a replacement to standard.

    Additionally:

    1. Creation of the content is not part of this and is being worked on by a different team in parallel
    2. The 'farmers market' model is already pretty documented because we chose to borrow that from the user guide.
    3. The example content team has already made significant progress towards getting the content ready including arriving at an agreed model and schema, and down to the level of actually sketching out voice and tone examples for several aspects of the 'brand' captured in a multi-page pdf doc.
    4. Any potential scope-creep around programmatically generating example content or creating a 'profile browser' (platform initiative) has been explicitly removed so we can focus on the single task of having at least on realistic example install in Drupal core.

    Having said all of that there may still be ways to further reduce scope to make certain we can get this in to 8.3. A few possibilities could be:

    • Make the theme a subtheme of Bartik. Bartik is pretty well componentized already (not to mention responsive and accessible) and a sub theme could quite easily be created that looks quite different from base Bartik.
    • Rather than pursuing designers from outside the community and undertaking a lengthy review process, work with experienced designers from within the community who have already expressed interest in working on this, notably @kjay.
    lauriii’s picture

    Issue summary: View changes

    Updated the meeting times to the issue summary.

    New meeting times are rotated weekly:
    3PM CET (European meeting), starting from this week
    4PM EDT (US Meeting), starting from next week

    tkoleary’s picture

    Good to know. Thx!

    lauriii’s picture

    Thanks for the feedback @webchick!

    - Does this get in the way of other work that's maybe more strategic?

    Agreed with #146. I'd also like to add that I don't believe this will add the amount of work needed to get those initiatives done.

    I also believe this is a fairly good opportunity to gain new contributors for core since there are no other initiatives focusing on this area.

    There seem to be lots of dependencies...

    Agreed with #147.

    I'd like to add that those are not necessarily dependencies but things that will help to make the work in this initiative easier. Even though all of those other initiatives would be failing, this initiative could be done. That would add slightly more work on or plate but it wouldn't be a big problem to deal with. Also, all of those initiatives can be build after this initiative as long as we have good coordination across initiatives.

    I still think that we can work on these things parallel since it is mostly different people working on these and we have already set up a pretty good coordination across these initiatives.

    Make the theme a subtheme of Bartik. Bartik is pretty well componentized already (not to mention responsive and accessible) and a sub theme could quite easily be created that looks quite different from base Bartik.

    Good suggestion! Let's discuss the implementation details once we are closer to implementing the theme!

    Rather than pursuing designers from outside the community and undertaking a lengthy review process, work with experienced designers from within the community who have already expressed interest in working on this, notably @kjay.

    I think there's still value in evaluating the designers using the process proposed in this initiative. That ensures that we are all on the same page who is going to be responsible for that (especially product management). It also ensures that everyone has been given an equal opportunity to participate, which is important since this is a more closed process than we would generally find.

    tkoleary’s picture

    @laurii

    It also ensures that everyone has been given an equal opportunity to participate, which is important since this is a more closed process than we would generally find.

    That's fine, as long as we are also clear that we are not excluding designers from within the community from the process

    lauriii’s picture

    Status: Needs review » Reviewed & tested by the community

    That's fine, as long as we are also clear that we are not excluding designers from within the community from the process

    Great! I'd be more than happy to welcome a designer from the community and believe that our process is fair in a sence that they shouldn't feel being left out.

    I think all the feedback from #145 so marking this RTBC again.

    webchick’s picture

    Status: Reviewed & tested by the community » Needs review

    Discussed this on the Ideas Queue meeting today:

    1. It is proposed that team would be working on creating a new design for Drupal. Do you agree that there is a need for creating a new design?

    Yes, Drupal looks pretty dated compared to competitors out of the box. Bartik was designed in 2009.

    1. It is proposed that new theme would be added to the core as experimental. Do you agree that it is possible to include experimental themes in Drupal core?

    Yes, but... we need to have a firm way to solve this from an implementation side prior to accepting the theme in core. We also need some way to handle the editing/removal of default content after install. (not this initiative)

    1. It is proposed that the new theme would not be built for Drupal, but it would be instead created to showcase a real use case using Drupal as a tool. All Drupalisms are proposed to be left out of the new theme, including the blue color. This is done to make sure that there is a separation between branding of Drupal and demonstrating Drupal. Do you agree that the new theme shouldn’t be built to brand Drupal but instead to demonstrate it?

    There was general agreement on not trying to tackle the re-branding of Drupal as part of this initiative. However, the theme should be generic enough to handle different content modifications; e.g. swap out images of apples for images of space ships, and still have the theme look/work nicely.

    1. It is proposed that the new theme would not be built as a framework for people to built things on top of it. The new design is created to solely demonstrate how Drupal supports people building sites with modern design. This is change from the current goals that has been set for Bartik. Do you agree that the new theme shouldn’t act as a framework?

    For MVP, we don't need this to be infinitely flexible (e.g. be able to accommodate Forum module sneaking in suddenly). When it becomes stable, we would need to make sure it doesn't break other basic 80% use cases.

    1. It is proposed that Drupal would include in future have faster phase for including new themes to lower the barrier of creating a new design. That would change the current mindset which assumes that when something is created, it is there for forever. Therefore we would clarify that the theme is just temporary, and we agree on adding a new theme in x period of time. Do you agree that there could be faster phase in including new themes in the core?

    No. :) We should choose to revamp designs based on when they start to feel dated. (Like we are now.)

    1. Many contributors have requested the product management to be involved in creating the new design. How would you like to be involved in the process?

    Given that this will not become the default theme, we'd love to have sign-off on the designs prior to implementation with 1-2 rounds of feedback in between.

    Some questions that were unresolved from our call were:

    - For sample content + theme, are we building a demo, or a tutorial? A demo to be really good needs to be very full-featured to *really* integrate with the scenario. A tutorial would be more generic, and easier to modify.
    - Are we optimizing for a workflow where people use this for 15 minutes and then reinstall after getting the hang of it, or are we optimizing for what other CMSes do, which is start from the default content and build their own site from there?

    What direction are you heading on with these questions? (Based on the answers, we may need to revisit the default content initiative; for example, Dries questioned whether, if we are indeed doing a starting point use case, if farmer's market is the best approach. Clearly it's not; there's almost no overlap between what a typical site will want (About Us, Our Team, Contact, etc.) and a farmer's market. OTOH, there's also very little need for some of the more complex data relationships to showcase in generic 80% content.)

    larowlan’s picture

    Based on the answers, we may need to revisit the default content initiative; for example, Dries questioned whether, if we are indeed doing a starting point use case, if farmer's market is the best approach. Clearly it's not; there's almost no overlap between what a typical site will want (About Us, Our Team, Contact, etc.) and a farmer's market. OTOH, there's also very little need for some of the more complex data relationships to showcase in generic 80% content

    In my opinion this torpedoes the ideas queue. What is the point of seeking and gaining approval if it can be taken away again? We're back to the same 'throwing code and effort into the wind' scenario all over again.
    There is no intention for the farmers market profile to be a starting poin, unless you're building a farmer's market site. It's for showcase and education.
    The idea was approved, people have put time and effort into it. If we've done all the right things by going through the process but still end up in this scenario, people will find other things to do with their free time.

    Fabianx’s picture

    Yes, and this theme is also for showcase and education (to demonstrate what can be done) and not a starting point or framework.

    A farmers market example is needed in Drupal as many still think it looks and works just like 'bartik'.

    If you want a base to build upon, that is 'bootstrap' or the bootstrap framework initiative OR pattern lab OR components + zen OR ...

    It is not what this initiative is about however (see the framework question, too).

    For sample content + theme, are we building a demo, or a tutorial? A demo to be really good needs to be very full-featured to *really* integrate with the scenario. A tutorial would be more generic, and easier to modify.

    I think a demo is what is sought here, not a tutorial. (Laurii can clarify though)

    Are we optimizing for a workflow where people use this for 15 minutes and then reinstall after getting the hang of it, or are we optimizing for what other CMSes do, which is start from the default content and build their own site from there?

    We optimize for the showcase and education, not the starting point (else this would end up being a framework instead again), but there is already enough frameworks out there.

    You could definitely for more simple sites just use the farmers market example as a starting point, but the primary goal is to WOW and showcase and not be a framework.

    If a framework is needed, that is another initiative and zen+components, bootstrap, pattern lab are all candidates for inclusion in core for that.

    There is many that would like to see that, but it is another idea completely.

    --

    While it might feel like waste to create something just for demo purposes, it is not. It is an important part missing to ensure Drupal looks fresh and nice out of the box for those still evaluating the system and being able to play with it. (increasing market share in the process)

    And as said already it might uncover core limitations that we can fix during the building of the more complex site theme.

    Usually during client development there is neither time nor budget to thoughtfully find the absolute best technical implementation, so this initiative is also about the "process" and learning in core itself and not just about the end result.

    lauriii’s picture

    Issue summary: View changes

    The idea was approved, people have put time and effort into it.

    I think there has possibly been a miscommunication on this. There was an idea issue for creating experimental installation profile to make it possible to facilitate two initiatives happening (default content and new theme). As far as I know, the example content specific ideas should be discussed here: #2816775: Add example content to experimental install profile.


    Yes, but... we need to have a firm way to solve this from an implementation side prior to accepting the theme in core.

    I created an issue to address this #2829101: Make it possible to add experimental themes into core. I'd assume that we don't have to postpone accepting this idea with that issue since these could be worked in parallel?

    There was general agreement on not trying to tackle the re-branding of Drupal as part of this initiative.

    Awesome!

    However, the theme should be generic enough to handle different content modifications; e.g. swap out images of apples for images of space ships, and still have the theme look/work nicely.

    I certainly do agree that we need to create a design and implement it in a way that users can switch images on the site without making it look totally awkward. I believe that we would get a better design for the main use case if we agree that the design wouldn't have to look as good on a secondary use case (but would still look reasonably good). Does that sound reasonable?

    For MVP, we don't need this to be infinitely flexible (e.g. be able to accommodate Forum module sneaking in suddenly). When it becomes stable, we would need to make sure it doesn't break other basic 80% use cases.

    I'm quite sure that we are on the same page with this. It would be still nice if we could define what 80% use case means since this could help us on scoping later on.

    No. :) We should choose to revamp designs based on when they start to feel dated. (Like we are now.)

    I removed this from the proposal. I think this was a good idea because it would have helped us mentally not to make everything better than is needed. However, this could also be figured out later in case we start feeling like this is a good idea.

    Given that this will not become the default theme, we'd love to have sign-off on the designs prior to implementation with 1-2 rounds of feedback in between.

    This sounds good for me!

    I think a demo is what is sought here, not a tutorial. (Laurii can clarify though)

    We have been targeting this to be a demo instead of a tutorial. We discussed tutorials quickly on one of the meetings at DrupalCon Dublin, and we agreed that tour module could be used later on to create tutorials if we feel like it would be useful.

    Are we optimizing for a workflow where people use this for 15 minutes and then reinstall after getting the hang of it, or are we optimizing for what other CMSes do, which is start from the default content and build their own site from there?

    I think it's a valid use case that you are introducing here. However, this wasn't the intention of this initiative, and I'd like not to add that to the goals of this idea since it makes things a whole lot of more complicated. I would leave this bit out for now if we'd like to see something happen soon.

    Also, IMHO this is not something we've had earlier in Drupal core, so we are not making a regression. I'd be happy to discuss this after we've implemented this idea!

    davidhernandez’s picture

    I want to clarify something, since it seems the whole "farmer's market" use case is muddying things. This use case is an example, not one to be obsessed over, but it serves an important purpose; to intentionally unshackle us from the idea that the theme and default content has to work for every use case, and be uberly generic and flexible. Which is something none of us ever do when building a site. This is the main reason why it is so hard to get themes into core. It is hard, arguable impossible, to make themes that do everything. So a fair use case was picked, and people ran with it.

    To that, the design will not (better not) have dancing tomato backgrounds, and corn husk favicons. The default content will probably have "content added" images of happy people buying produce or whatever, but the theme should look perfectly fine if the subject matter of the content is changed to something else. For example, use for a pet adoption site, chamber of commerce, or your small business selling candles online. It shouldn't matter. If it's red, it's going to stay red, but that is somewhat arbitrary to the subject matter.

    What does matter is there will be inherent limitations, and we want people to understand/agree that that is ok. If the design has one sidebar, that's what you get. If the design calls for the main navigation to be in the header, don't expect it to magically look right if you move it to a different region. But, if your content architecture matches reasonable well with this use case, and you work within the limitations of the design, there should be no reason why you couldn't build your site with it. We're just not promising that everything from CNN.com to a local knitting circle can use it to rebuild their site. It's a Popeye theme. It is what it is, and that's all that it is. And what it is is a free theme that looks good when used like "this".

    ifrik’s picture

    My ideas on this matter - coming in a bit sideways after a discussion with dawehner.

    Farmers' market and default content
    The farmers' market wasn't chosen for the User Guide as a typical site, but as a very generic and flexible example to teach people all kind of things about how to use Drupal.
    So using the farmers' market as example content can work as a tool to explain how Drupal works. If this example content and its configuration closely follows the User Guide then users can look at it and instead of having to guess how the configuration works, they could check in the User Guide and see how these fields were added or why a tickbox is ticked.
    So in short: using the farmers' market as example content would be a tool to learn Drupal sitebuilding - not a show case.

    Learning theming for Drupal 8
    Theming is the other thing users have to learn again for Drupal 8. So what would be great would be a another guide that teaches people how to build a Drupal theme, what current good practices are, which bits are relevant for accessability etc. And if that would be also based on the farmers market example then it would result into a theme that makes the farmers market look good and accessible.
    It would make it possible to explain choices and practices to people instead of letting them try to understand it by randomly dissecting an existing them without guidance.

    Tour
    Just a quick note: Tour is unsuitable for making any tutorial like that. It's static per page - and wasn't even remotely suitable for a site building guide, so it will be even less suitable for at theming tutorial.

    Demo, show case, not to be used to be build on...
    Maybe I'm seriously misunderstanding this: But why should there be anything in Drupal core that is not be be used?
    We should have show cases and demos, but they should be separate. First of all: then they are accessible when you show what Drupal can do - before you start building a site.
    And second: if a theme is in core, then people will use it for their own sites - no matter whether that's the intention or not. Even more though: the less people know about theming, the more likely they are to do so (Because hacking an existing theme can be easier then starting from scratch, and because we can't stop people from doing something without knowing how to do it properly, be it configuration, code or theming....)
    If we put a theme into core without the option to tweak it from the UI or without the option to make a subtheme - then that's simply inviting people to hack core.

    So: if some good designers and themers can put their heads together and write up how they go about to make one impressive design, instead of just presenting the end result: That would be great.
    If that ties in with the same farmers' market example as the user guide (and hopefully example content): that would be even better because then we got resources that complement each other.

    And if people want to make demos to show that Drupal can look beautiful: yes please - and preferable even a few to show a range - including an extremely accessible theme. But put them somewhere on drupal.org to see, not into core.

    tkoleary’s picture

    @ifrik

    Interesting ideas, can you also add this to the example content issue?

    We should have show cases and demos, but they should be separate. First of all: then they are accessible when you show what Drupal can do - before you start building a site.

    What we are talking about is the 'out-of-the-box' experience for a user who has never seen Drupal. Think for a moment about the various paths by which someone might encounter Drupal.

    1. I am a marketing manager at a mid-sized biotech company looking for a new CMS for my main corporate site. I google CMS and find Pantheon, I sign up for a free trial and I install Drupal from their console.

    2. I am an IT person at a university. I also need to look into what's new in CMSs for one of the university departments. I happen to already know about Drupal from other projects but i have not tried out Drupal 8, I go to my Acquia Dev desktop and download and install Drupal 8 from there.

    3. I am the CEO of a non-profit and I am looking into options for a CMS for our site. I like the idea of open source and someone told me Drupal was good. I already have my domain parked at a network solutions and I remember seeing something about Drupal there. I open my account and I see that they have a one-click Drupal 8 install so I click and install Drupal to see what it can do.

    4. I am the Director of a government agency, we have a bid out to several contractors to build our new CMS but I am pretty technical and I want to try out some of the CMSs they are recommending myself so I can get a sense of whether the salesmen are over-promising. I type 'try Drupal live' in google and the top result is simplytest.me, I go there, select Drupal 8 and spin up a demo.

    In none of the above cases did the user ever even go to Drupal.org so none would have the opportunity to find or view a hosted demo there, even if there were one (which there probably should be). The fact is that in many many cases the first impression that users will have of Drupal is simply installing it. If the goal of the user installing it is to demo and try out Drupal to see what it can do, as it is in all of the above cases, and they see an 'Example' or 'Demo' profile that is what they are going to choose.

    The question of how 're-usable' we make the demo is a detail of implementation. The fact that we need to provide a better out-of-the-box experience in core for all of the above users is, at least to me, pretty clear.

    ifrik’s picture

    Just a quick reply:
    It will also be a very bad user-experience for anybody who as worked with a framework or configurable theme (either in Drupal 7 or any other CMS) if a new theme is not reusable or configurable.
    Because then you basically tell people "Take it as it is or start from scratch - we don't care about your experience of using it - we only care about you looking at something."

    Fabianx’s picture

    #160: You can do it. In fact I even purchased some themes for Drupal 7 that had been very very opinionated and managed to use it for my own purposes.

    It just is not its primary purpose to be a framework to build upon.

    But e.g. if random non-profit (without budget) has the choice between using bartik out of the box and e.g. the farmers market demo theme, then likely they would use the farmers market, exchange some images and just use it. Like they do with bartik now.

    So that use case is definitely taken care of.

    However the new theme can't be infinitely flexible, it can't be customizable to no end, because then it could no longer be opinionated and every client theme I have ever worked on is opinionated to its use case. This is like a client theme.

    I totally agree that we need a theme framework to build upon (also components initiative) in core, too.

    So I again urge those that want to see a framework (theme) in core to start their own ideas issue for getting a new framework theme into core, which is flexible can be build upon and customizable.

    But there is also a place for a demo theme that can be customized in limited ways, too. (see #159) And this is what this issue is about.

    And there is a pretty strong community consensus within those people that originally started the Twig Initiative and improved the theme system over the years (Morten, Laurii, David Hernandez, myself and others) to do a design first approach.

    The goal here is better marketing, not easier development (that might be a side effect) - as again the process of implementing a client theme in core is as important as the end result itself.

    So please give this initiative a chance, too.

    joelpittet’s picture

    I agree with @lauriii #156, @davidhernandez #157, and @Fabianx #160. (I agree with @tkoleary #159 too but seemed more about defining types of audiences).

    Impressive designs have constraints, we are trying to shape these constraints with a small/explicit scope and dedicated primary audience to make this goal achievable and delivered in a reasonable amount of time.

    Gábor Hojtsy’s picture

    @ifrik:

    It will also be a very bad user-experience for anybody who as worked with a framework or configurable theme (either in Drupal 7 or any other CMS) if a new theme is not reusable or configurable.
    Because then you basically tell people "Take it as it is or start from scratch - we don't care about your experience of using it - we only care about you looking at something."

    Well, we don't have any demonstration of Drupal core now in core. You install it and it says you have no content (duh). I think a fundamental question is by adding a demo do we make this and other core uses worse or are we just not improving quite enough with an ideal scenario in mind? How does a purpose built theme with purpose built sample content to demonstrate Drupal make Drupal worse, so we can address those while building this out. If we ever get to build this out that is. We can infinitely argue about an ideal target plan, but that discussion itself could take as much time as building an interim MVP where we actually get market/user feedback after that instead of strategizing within our own bubble here. Are we making Drupal worse with this or just not making it better enough (yet?).

    Fabianx’s picture

    Status: Needs review » Reviewed & tested by the community

    Yeah, lets send this back to core committers.

    @Governance Team: Please also read the discussion feedback after your last comment. And please take into account that the process to implement an opinionated theme is as important as the end result, too.

    Maybe we want to adjust the title to explicitly state 'for demo purposes'. It seems that might be a good idea and according to the last posts it seems the direction, but I am leaving that to laurii.

    lauriii’s picture

    I have invited a group of people to build consensus between the community and the governance team on this idea. You can find the details of the meeting here: https://docs.google.com/document/d/1liipNcl-uPIppmNclci1pC6P9UjPsstdOCF-... . If you have suggestions for the agenda, please don't hesitate to make any suggestions for the doc :)

    lauriii’s picture

    Issue summary: View changes
    Status: Reviewed & tested by the community » Needs review

    Issue summary update based on the discussion with the product management that happened last week.

    Gábor Hojtsy’s picture

    Component: Idea » Plan

    Moving to a plan type since the details of the idea are being discussed.

    webchick’s picture

    We talked about this on our ~weekly Ideas Queue Review meeting: http://youtu.be/ssZ2k4KsHJo (might take up to an hour for the recording to be there in its entirety)

    Thanks to @kjay who led the meeting and presented two possible directions for starter theme/content: Farmer's Market website, and Food magazine. Both examples were STUNNING, but there was consensus around pursuing the magazine use case, since it is more common to what Drupal users need.

    We also discussed target audience of the install profile, and generally agreed that this is a (relatively) technical evaluator.

    Next steps: Decide what's needed to showcase the "killer features" of Drupal. There is a Google Doc for this at https://docs.google.com/document/d/1ArG_wUpDxD-YPqfzGx-grWF_UUDRrjVft7EZ... We talked about breaking this down in a "must-have/should-have/could-have" list of high-level killer features / user stories (vs. module names). Alongside, flesh out what the ideal "demo" experience is of these things, and through both we can probably arrive at an MVP that's fairly quick to implement as an experimental profile, hopefully early in 8.4. We could then accompany this with written/recorded documentation which could be translated, ala Demo Framework.

    Going forward, @lauriii is going to create a "meta" meta issue to track the overall "evaluator experience" initiative (better name TBD), and we'll be posting updates there!

    sprite’s picture

    See #25 above ...

    Regarding this excellent initiative ...

    For existing examples of real world "use case" modules that may provide inspiration for the form of what this project might take, the morethanthemes products, including their several Drupal8 offerings, already provide excellent "use case" implementations, including their approach to packaging/distributing them (using an automatic install profile).

    Based on working with the MTT products, it doesn't seem like a "use case" needs to be too specific. As the MTT products demonstrate, what is important IMO, is to show potential Drupal8 users how a variety of real world site UI/UX features are implemented. For example, they have "team members" done with custom content type, View(s), and theming. They've implemented dozens of such general site features with similar sophistication. The MTT examples also demonstrate various types of popular block styles, and more. The existing MTT products provide a starting point for what this project could be like, but serving a general role to showcase what Drupal/Drupal8 can do.

    kattekrab’s picture

    Is there somewhere we can see the farmers market and magazine presentations without having to sit through video? Are there screengrabs? or slides, or demos?

    rootwork’s picture

    @kattekrab I wondered that too, but the demos are really early in the video -- basically the first thing. I watched it to see those, and it didn't take long.

    It'd be nice to see the demos somewhere else, though.

    kattekrab’s picture

    Thanks @rootwork - good advice.

    I snapped a couple of screengrabs.

    Farmers Market

    Farmers Market

    Magazine

    Magazine

    kattekrab’s picture

    I do still reckon it would be good to have the farmers market theme to go with the farmers market focussed user guide.

    lauriii’s picture

    Issue summary: View changes

    Updating the progress to the issue summary.

    lauriii’s picture

    I do still reckon it would be good to have the farmers market theme to go with the farmers market focussed user guide.

    On the call where we discussed this with @kjay, @Dries, @webchick, @Gabor Hojtsy, and @Bojhan many of us thought that it would be beneficial to build the demo for the same use case as the user guide. One of the main reasons was that it would be possible for the user to first download Drupal and then could look the user guide for how the demo has been put together, therefore understanding the underlying concepts better. There was also other reasons backing up using the farmers market user guide as a base for the initiative.

    However, since the main purpose of this initiative is to convince a technical evaluator that Drupal allows them to build modern and beautiful websites, we wanted to choose a solution that the user can easier relate to. We strongly believed that it would be easier to create a good looking design that is more generic for the publication site. This allows users to try out changing some of the content and see how their use case could work on top of Drupal, therefore immediately seeing how easily their site could be built using Drupal.

    I personally believe it would be great if we could also build the farmers market demo! I hope that this is just the first initiative where we solve problems around these topics. Maybe farmers market could be the use case for the next similar initiative.

    lauriii’s picture

    Issue summary: View changes

    We have finished reviewing the application and have decided to appoint @kjay as an Art Director for the initiative. Next step for us is to proceed to create the initial design.

    webchick’s picture

    Excellent!! :D Congrats, @kjay! Looking forward to seeing more of your awesome work!

    Gábor Hojtsy’s picture

    Yay, amazing, congrats!

    yoroy’s picture

    Component: Plan » Proposed Plan
    dkre’s picture

    I have to probably start off by saying sorry for being negative and perhaps unproductive, but I'm honestly left really let down by Drupal - and I guess by extension the community and business interests involved in it's progress and development.

    I wrote a massive rant on [discussion] Theme/render system problems before removing it because yoroy pointed out that Unify & simplify render & theme system: component-based rendering (enables pattern library, style guides, interface previews, client-side re-rendering) was the postponer of the issue which in turn was postponed by this issue. I've only now had a chance to read this issue and get a grasp on what is going on, or the lack thereof.

    So we know we have a useless frontend platform. It doesn't work as specified in some instances because of hard-coding and gotchyas, it's slow and requires some major developer investment to make good markup (this is a bit one in the same, you have to loop around in the output stage to create the right output which is inherently slower). There are so many LONG issues about this over MANY years and yet there are major pushes into crazy, resource hungry additions like automatic updates.

    WTF.

    Seriously. This is a CMS, it makes websites, pages. Why is this still so hard, so ugly, so slow, and most vitally - so uneconomic to use? I was honestly hoping to read this issue and be like, 'right this is a great move forward, shit is getting sorted'. Instead it's the same same argument between developers and designers not deciding on anything. Ultimately I believe that Acquia and the product owners aren't willing to allocate the same development time on frontend as they will for DX. Full Stop.

    I'm a 'website builder', with a frontend/designer background. Like #140, I started with Drupal because I liked to be able to 'do stuff'. So after 4 years and about 40 Drupal 7 projects, I felt confident to recommend Drupal 8 as an in-house developer (I build, maintain websites that my employer owns). D8 had lots of bling and what we needed over Silverstripe which was being recommended. Until I started on my first D8 project I don't think I had ever posted on the core issue queue but with D8 all the problems are with core. Sure the move to twig and Symphony were going to create some teething but not a constant headache - but more importantly, I didn't see any benefits. Nothing was better realistically.

    *Deployment time was longer
    *Time overruns are almost expected
    *Everything frontend takes longer to achieve<
    *A cache flush is like a 1 minute outage (we run a 6 core, 12 gb ram server with bugger all hits) and this required so so often
    *Some development tasks are better - (eg. forms)

    From myself to my employer the critical argument for Drupal over Silverstripe was the reliance on hard code by Silverstripe. How wrong could I have been. Despite 2 months of research all of the Drupal 8 issues weren't discovered until we were knee deep in development based on either doing what I always did in D7 or did what was expected would be the outcome. Drupal 8's further splintering of everything into more and more templates is an example and the inaccurate theme suggestion output.

    Yes, I 1000% agree Drupal needs a new frontend theme but this issue doesn't really even focus on the core issues around theming which it's postponing. I'm sure I'm not alone in Drupal frontend development of expecting to write a couple of 1000 lines of shit to make it look OK, regardless of the theme. That's just how Drupal is, but can we please move forward?

    As it is now this issue will likely create another Bootstrap which hacks things so far from core (eg. Classy) that modules need to rework everything to work with it. It's not hard to make a site look awesome, but it is bloody hard to change output in Drupal.

    Design? Whatever. Create a nice show piece like http://drupal.org/8 and sell it like it's a prize pig. This isn't going to help the longevity of this CMS. If we have to keep creating multiple preprocesses/functions and an array of templates for a single page render just to get the right value in the right place then what's the point? Why should frontend require so so many developer resources? I really don't feel like it's 2017 when I explain the requirements to change the look of an element sometimes.

    Having now spent quite a bit of time reading and following core issues I'm amazed by the dedication and work put into to Drupal by so many (and thank you from the bottom of my heart!) but I really can't feel anything but disappointment in the way everything frontend is dealt with and I have to see this as being driven by the priorities of the product owners/Acquia.

    This is a fancy toy but it's honestly sadistic for a designer to work. If it ain't pretty it's not relevant. If someone's grand mother can't use your site you've failed.

    I wish I read more into the quote research I did in 2011 before I picked up Drupal that showed a 60-100% increase in cost (locally) working with Drupal. You want a good designer, not more development time for the design.

    rootwork’s picture

    @dkre I'm not totally sure why you thought the rant was off-topic on that other issue, but on-topic here. This issue is about building a new core theme. When you write things like "Design? Whatever. Create a nice show piece like http://drupal.org/8 and sell it like it's a prize pig," that's not helpful to the development of this issue, that's just throwing feces. And when you wrote "Yes, I 1000% agree Drupal needs a new frontend theme but this issue doesn't really even focus on the core issues around theming which it's postponing," it seems like that should have been your signal to stop. Indeed, this issue doesn't focus on those issues. So why are you posting to it?

    More concretely, your long rant doesn't give any insight as to why you think Drupal's theming system is awful, or how you suggest making it better. Personally, I've been using Drupal for 10+ years as an independent frontend developer and had to completely re-learn most of my theming with D8's Twig templates -- and after that learning period, find that my frontend development is faster, DRYer, and more maintainable than it ever was in Drupal before. John Albin's comment on the other issue you mention actually speaks to a lot of the experience I've had too. Clearly, you haven't had the same experience, but other than finding new creative ways to talk about how much you dislike Drupal's theme system (and apparently Acquia), you don't seem to have taken on any responsibility to even determine why you feel that way.

    The issue summary of #2702061: Unify & simplify render & theme system: component-based rendering (enables pattern library, style guides, interface previews, client-side re-rendering) is a good example of what your rant could have been. It's not shy about pointing out the places in which the theming and rendering systems don't make sense (abundant use of "WTF") but drills down into how or where it needs to be improved. Reading through the comments on that issue will show you that you have many friends in wanting to improve these systems. Please consider joining them constructively in that issue and sub-issues writing patches, reviewing patches, and offering specific feedback. And please don't continue to hijack other issue threads.

    dkre’s picture

    Fair call on all points. Apologies if I've offended anyone, I'm just trying to express my exasperation.

    I posted this here because it is the current blocker of progress on the issues which will bring about more fundamental changes to the theming system. I don't understand the prioritising of the theme over the fundamentals.

    I haven't been specific about my personal experiences and my perspective about the faults in either the theming system or the core themes because this is very well tread ground where realistically there isn't any debate needed. There are many thorough posts in an array of issues going back a few years which don't need to be regurgitated, especially by me when I have less experience.

    The proposed purpose of this issue is to both make something which is more visually appealing but as a technical validator. This would suggest that the overall position is that the current theme system is good and will be the 'Drupal way to theme' for the long term. As mentioned this, in my opinion, leaves Drupal as an uneconomic option compared to alternatives. A theme won't resolve this.

    SKAUGHT’s picture

    hopefully i'm pointing to the right links here:

    is where work is happening toward this currently happening. it doesn't require a complete overall to do this..PROFILES will let us do this now. The conversations about overhauling the theme system are there own issues, let them be.

    We all appreciate your feelings about things but remember it's what we all do to make it happen. I'm just a developer out in the world too..I have times when I lose sight of that too. We all need to use our skills; gather and focus our other friends -- who have different skills and in-sights to make it better.

    You outline several devOps and dev sprint process issue you've been having.. they are certainly not simple due to the theme system. Keeping realistic perspective on our own deliverables is key. Yes, you (your company) could buy a system that 'does it all out of the box' (assuming that exists..or where, they just have their own internal team that does the work in the background anyway..) or use core and contrib and customize as your projects require.. Don't overextend yourself. Patients is key. 'Open Source' doesn't happen overnight.

    droplet’s picture

    No offense.

    All of the team members are well-knowing Core Developers. I don't know what making them can't bring the best experience to Drupal at the first place. The same group of people (or same Drupal Policy) may ban same great idea or make a similar product.

    Highly recommended adding 2 or 3 secret reviewers to the team (Or an anonymous channel). Allowed them to say F-words. And I hope the team be stronger and listen to it.

    As an outsider, I always think Drupal Contributors are too positive. They trending to say Yes more often. People won't share their words from heart in this atmosphere.

    Also, I hope the team making the development period shorter. Don't publish an old product in the future day.

    Good Luck!

    ---------

    I don't think Drupal missing a nice look theme or sites to demo it. But it missing a way to demo how easy to get the thing done well and quicker. Also, a solid and same user experience to all of their Drupal sites developed by different agencies.

    ----------

    Few more, I know many of features are impossible in Drupal CORE. I hope the team able to beat the limitations and making things in the theme without many contrib modules

    Re:
    https://docs.google.com/document/d/1ArG_wUpDxD-YPqfzGx-grWF_UUDRrjVft7EZ...

    Content creation
    - I expected a single click from Toolbar to create Article Or Page.
    - I expected I can design the menu router before creating all pages
    - I expected I able to add a featured thumbnail
    - I hope my inner page with a diff top banner than featured thumbnail ( with parallax scrolling effect will be good)

    Entity references

    WYSIWYG (at least use CK moono-lisa)
    - I expected able to insert images into WYSIWYG easily
    - Showing image with captions (HTML5 way)
    - Lightbox of image like medium.com

    Different Views displays (unformatted, html list, etc)
    - A list showing recent articles with thumbnail

    Comment
    User profiles and referenced profiles

    Default contact form
    - with map/location area

    User login form block and page
    - open as dropdown / modal to demo code skill of using block

    Search form/block
    Search results page
    - with filters

    Dialogs o error/status messages (ex. Content successfully created)
    - I expected it's more themeable and adopt other cool libs rather than Core things only.

    Responsive primary navigation (dropdowns FTW!)
    - off-canvas better than dropdown, open a full-screen menu is even cooler

    Views block
    Taxonomy terms
    Breadcrumbs

    Addtional:

    Theme Setting
    - something like allows the LOGO show in the left or center..etc
    - social icons

    FAQ / Help pages:
    - with tabs / accordions

    Anime
    - I expected few more CSS3 anime around the things.

    yoroy’s picture

    Thanks @droplet. We do want to find creative ways to make this work as nicely as possible within the limitations of core. Some of your points about entity references, view modes etc. are definately part of what we want to do: #79582: Add example content to the experimental out-of-the-box demo install profile

    Things like "I expected I can design the menu router before creating all pages" are also very worthwhile UX improvements, but not necessarily in scope of this initiative. I think there's already an issue for that specifically.

    yoroy’s picture

    mariohernandez’s picture

    Issue summary: View changes
    mariohernandez’s picture

    Added my name to team to be considered when theming process starts.

    andrewmacpherson’s picture

    Issue summary: View changes

    Adding WCAG 2.1 to accessibility requirements.