Start with core-only, expand later?

Personally I am also on the camp that Core Drupal has a certain character, if you sample all content types that are in there, Jarek did a good job on this http://demo.kiwi-themes.com/drupal-dev/ (click "Pages")

But for people coming to Drupal the first time, a distinct use case may be more catchy and palpable. The notion in our brainstorming session was very strong that one of the main problems of Drupal is his lack of limitation: you cannot say what it is. So the step to define a use case was strongly supported.

Let's see what we come up with...

Subscribing. (I'm the guy with the American accent at DDC who had started making a module that sounded like Skinr.)

I think we can just choose one of the most common use-cases (blog, brochureware, etc), and jump in. Or do I misunderstand your use of "use-case"?

+1 for core-only (subscribing)
there would be too many scenarios if we include views and other modules. and as yoroy mentioned, a lot can be done with just core.

Would part of this package be a base theme too? With the common functionality that everyone will want to use (should we use zen, etc...) and build theirs themes upon that to make it even easier?

-1 for zen.
What I would find most useful is use just stark styling and add an empty theme.
This theme would already have an info file and a name (say "Starter?") as well as an images directory an empty style.css so the designers would not need to worry about this and could start hacking away at style.css.
Maybe we should also put a dummy screenshot in, so they can see when they switch on their basic theme.

I think if you put in no base theme, a theme is based on stark, right? If stark has anything that helps us beyond just core, let's make the empty theme a subtheme of stark.

-1 for zen as well. It became (well, powerful but) overcomplicated. If I'd look at zen first as starter point I'd never been doing drupal designs :)

+1 for stark subtheme. It may be empty, or with a very few populated classes, just to give the idea on best CSS practices in drupal terms.

+10 for many contrib modules! As i narrated on the last DUG Hannover meeting, installing all those different basic modules needed to make a working site is one thing that is most confusing to all newcomers...

Cheers
Chris

Hm I would say rather Audience A.
The designer builds a theme. All we want him to get past is the notion that drupal is difficult to theme. So I guess (hope) they will start out with a simple site instead of something overly ambitious.

Thinking of Views: Will they be confused when the views are just there and they do not have to touch it? Maybe yes once they start to wonder what all these strange classes are. So if we can build something that makes sense without Views it would be much better.

We think of designers that do not build sites themselves, and sure do not know how to do this in drupal. Comparing to myself: I started with Wordpress, chose Blix theme, and as I was scared of all the template variables and PHP, I just tweaked the colors a bit by changing the CSS and was perfectly happy.

So the profile should present a finished site (well, with some sample content, say a basic brochure site: products, about us, contact and three more pages) that can be styled right away.

What we should do is build from this and make it a usable install profile in the course of the process. Because in the end it should be only one profile: it should be usable for non-designers as well as for designers. Only difference is the designers profile lacks the beautiful theme that the end-user gets.

But as this is always a work in progress, the kinda "dummy" profile for the designers that does not have to be fully functional with all bells and whistles gets done first, and can be built upon to be more and more usable. Maybe even one of the newly-enthused designers contributes a theme that we can use for our kick-ass brochure-blog-whatever profile.

My opinion is and always was: If someone uses a software (CMS) and is happy with it they will automaticaly get attatched to it, become curious, play around and sooner or later want more, and more, and more...

More functions, more features, more (customized) design.

And thats the way we should roll: Catch some designers out there with an easy to set-up CMS, and then lure them deeper and deeper into the drupal community, so one day they wake up and say: "What the Heck, if been contributing to the community for years and suddenly can think API and didn't even noticed it!"

So YES! Of course Views, of course CCK (okay, its in D7 core) of course Images, Googtube Input format Filter, Backup & Migrate, Features...

I dont think designers will be satisfied with just an installation with basic modules. I think they want to have some sample content they can edit or delete rather than creating everything from scratch. We should keep in mind that some of the designers might have never created a website before, and don't know what content should be on a webpage:

"A contact form? Haven't thought about that! Okay, so whats with an Guestbook? Oh, thats 90's?"

A basic theme based on Stark with just CSS is a good idea. However, designers will want more control over markup. People need more roads into the the tutorials as well.

If you're considering a second theme to add, it would be ideal to have one that includes template.php, html.tpl.php, page.tpl.php, node.tpl.php, block.tpl.php, possibly also the comment, comment wrapper - and if you include Views, then include a pre-set view, and a views template, with a reference to the Views theming tutorials.

Then, include tutorials about overriding other core templates such as site maintenance template, user templates and getting them copied into their theme. Good module development practice means many modules are also outputting template files, so a designer can get more control over markup with altering the HTML in these files.

My unsolicited opinion ;)

I agree with Heather ...

We need to make sure the most common tpl-files are included in the theme even if they don't override any default output.

These common tpl-files could have a comment on top stating:

- they are overriding some core tpl-file (with the directory where it came from)
- That there are many other tpl-files available to override
- A link to the documentation page on d.o, explaining this process of overriding.

Perhaps including a a template.php file with the same principle would be a good ideia.

Override one or two core theme functions, leavinng them the same, and explain what's happening and where to find more information.

@Jolidog - good idea, like a "learning theme".

Have you seen Zenophile? It generates a Zen sub-theme, then the template.php which provides commented-out functions, which you can use to inject variables into your theme. Like this (and node, comment, block, etc etc).

/**
 * Override or insert variables into the page templates.
 *
 * @param $vars
 *   An array of variables to pass to the theme template.
 * @param $hook
 *   The name of the template being rendered ("page" in this case.)
 */
/* -- Delete this line if you want to use this function
function mytheme_preprocess_page(&$vars, $hook) {
  $vars['sample_variable'] = t('Lorem ipsum.');
}
// */

Yes, something like that would be good. As for the *.tpl.php, here is an example for the block template:

<?php
// $Id: block.tpl.php,v 1.10 2010/04/26 14:10:40 dries Exp $

/**
 * This template is overriding the one at /modules/block directory
 * Edit the code below to see the changes appear on your theme.
 * You can use the variables listed below anywhere inside this template.
 *
 * Search the /modules directory, there are many other templates available to override!
 */

/**
 * @file
 * Default theme implementation to display a block.
 *
 * Available variables:
 * - $block->subject: Block title.
 * - $content: Block content.
 * - $block->module: Module that generated the block.
 * - $block->delta: An ID for the block, unique within each module.
 * - $block->region: The block region embedding the current block.
 * - $classes: String of classes that can be used to style contextually through
 *   CSS. It can be manipulated through the variable $classes_array from
 *   preprocess functions. The default values can be one or more of the following:
 *   - block: The current template type, i.e., "theming hook".
 *   - block-[module]: The module generating the block. For example, the user module
 *     is responsible for handling the default user navigation block. In that case
 *     the class would be "block-user".
 * - $title_prefix (array): An array containing additional output populated by
 *   modules, intended to be displayed in front of the main title tag that
 *   appears in the template.
 * - $title_suffix (array): An array containing additional output populated by
 *   modules, intended to be displayed after the main title tag that appears in
 *   the template.
 *
 * Helper variables:
 * - $classes_array: Array of html class attribute values. It is flattened
 *   into a string within the variable $classes.
 * - $block_zebra: Outputs 'odd' and 'even' dependent on each block region.
 * - $zebra: Same output as $block_zebra but independent of any block region.
 * - $block_id: Counter dependent on each block region.
 * - $id: Same output as $block_id but independent of any block region.
 * - $is_front: Flags true when presented in the front page.
 * - $logged_in: Flags true when the current user is a logged-in member.
 * - $is_admin: Flags true when the current user is an administrator.
 * - $block_html_id: A valid HTML ID and guaranteed unique.
 *
 * @see template_preprocess()
 * @see template_preprocess_block()
 * @see template_process()
 */
?>

<!-- This code comes from the block.tpl.php file on your theme templates directory -->
<div id="<?php print $block_html_id; ?>" class="<?php print $classes; ?>"<?php print $attributes; ?>>

  <?php print render($title_prefix); ?>
<?php if ($block->subject): ?>
  <h2<?php print $title_attributes; ?>><?php print $block->subject ?></h2>
<?php endif;?>
  <?php print render($title_suffix); ?>

  <div class="content"<?php print $content_attributes; ?>>
    <?php print $content ?>
  </div>
</div>

Obviously the language should be better :P
Also notice que html comment, this could be used to direct people to the right file, when they look at the source of the page.

As for the theme functions, I tried to find one but I guess D7 changed most, if not all, of these functions to use tpl files! Very nice inded!

Great idea re having some tips in tpl.php files. But still, default drupal style like:

@param $vars
 *   An array of variables to pass to the theme template.

will really teach new designer (not coder who knows drupal) nothing.

Also some text like @see template_preprocess() should go with the link

@see template_preprocess() (http://api.drupal.org/api/drupal/includes--theme.inc/function/template_preprocess/7)

worry not with the theme level, let's look at it from a use case point of view.

can you see clearly what open atrium or drupal commons stand for? i guess they are very interesting distributions for designers to work on. there are lesser known drupal distros that could be themed as well, like tattlr.

once we settle on a distro (for use cases) the designers can have the time of their life theming them, improving on them. if they want to put their dirty little hands on the theme level, I guess zen is an easy starter theme. but any starter theme would do.

oh, i thought the idea was getting designers excited to start designing for drupal.
after all, even if you are designing for wordpress, you get down to use cases (education themes, movie critics themes, etc).

Nice to see this getting off the ground. I was also at the DDC session with my colleague. While driving back we discussed what would be the most designer friendly way this could be set up. We came up with the following, which seems to be pretty much inline with the rest of the comments:

• The kit is intended for experienced web designers who want to try out Drupal for the first time. It should provide a fully functioning site out of the box with everything in place, ideally with a choice between install profiles: brochureware, blog, portfolio, community site, ...
• The amount of configuration should be kept to an absolute minimum. Ideally you should be ready to start tweaking the CSS minutes after installation, and not configure anything at all.
• Provide two themes for each install profile: a good looking design which fits the install profile and can be used as a starting point for modification, and a base theme (eg. Stark) for designers that prefer a clean sheet.
• Instead of dummy text, provide step-by-step instructions on how to theme the various elements. A custom block in the sidebar would contain instructions "This is a block. Here's how to theme it". A node would explain node.tpl.php. A series of "getting started" articles on the front page, a Quick Tour of Drupal's features, ...
• The amount of contributed modules should be kept low so the project is easy to maintain. Some contrib modules may be necessary for certain install profiles. Modules that are trivial to install (e.g. Google Analytics) should definitely not be included. Modules that are difficult to set up and are genuinely useful can be included - I'm thinking about things like Wysiwyg and Views for the brochure site. The modules needed are different for each install profile.