Drupalcon writeup

eaton's picture

At Drupalcon Chicago, I organized a 'core conversation' about the Snowman (nee Tsunami) project and many of us (including Leisa, Dmitri, Bojhan, Yoroy, and others) met up for a BoF the next day. A couple of really valuable insights emerged and we believe that it's solidified our path forward.

  1. We shouldn't use a code-name that just killed a ton of people. See this post and for info about the new name..
  2. The original use case for the profile is a good one: a group of people collaborating on a project or participating in a single group, telling the world about their shared goal or activity, and inviting others to participate. We need to put together more concrete examples of this, but it's a very good match for what Drupal has always been good at and it gets us out of the 'Build a blog with some extras' rut.
  3. The user persona we're targeting is not an experienced Drupal site builder. It's someone who's a member of the group described above who is knowledgeable enough to install a piece of web software, but would probably hit Drupal's "learning wall" trying to build out all the functionality needed by the group. As Leisa put it, it's a step in the "dance of value exchange." They download and install Drupal, investing their time and attention. We want to give them something that is immediately useful and interesting for what they need to do with their web site, not just a set of tools useful for building their web site.. They can dig in deeper and customize it, but we want them to hit the ground running.
  4. Snowman will not attempt to hide Drupal's Drupaly-ness. It's a preconfigured Drupal site that gets people with the above use case to the 60% point, where they can understand what the site is and how it works, see that it is useful for their specific needs, and begin working with it.
  5. Anything created by the Snowman installation profile should be be configuration that can be torn apart by a motivated user with Core's own site building tools. This means no custom hook_menu tricks or sneaky theme hacks stuck in the .profile. If we must customize something and it can't be done via configuration, we file a bug against core and try to fix it.
  6. Really useful functionality for the use case that simply can't be implemented in core can be handled in two ways: propose low-impact core patches for Drupal 8 that add the capabilities, and/or treat the gaps as an "on ramp" to exploration of the contributed modules directory, engagement with the Drupal community, and development of site building skills. Examples of 'simple' stuff would be letting admins choose how many nodes appear on the front page. Examples of 'complicated' stuff would be adding mailing lists. Debate about what lies in between will follow, but shouldn't be our primary focus.
  7. The Snowman profile can serve as an 'R&D' lab for interesting core patches, generating ideas from real world use cases and pain points. It can also serve as an example of how Drupal's tools can be used for site builders learning the tricks of the trade. And finally, it can serve as a 'canary in the coal mine' of core development. If the choices made in Drupal core development make Snowman harder to implement, it can serve as a warning that we'll be making it harder for non-core profiles and distros. However, these are all happy side benefits. Our primary goal with Snowman is nailing the target use case and giving the target user persona something something that is genuinely useful.
  8. The profile is absolutely NOT targeted at experienced site builders or developers who want a base to start working from. Unless they genuinely want Snowman's specific functionality, and want to expand on it in particular, they should start with the Minimal profile and follow their own plans.
  9. Because the Snowman project will focus on relatively small sites (compared to, say, whitehouse.gov), it should be possible to provide sample content out of the box. We want to err on the side of Wordpress, which provides an example blog post, an 'about' page, and a sample comment. The Joomla! installer offers two options: no sample content, and too much, making it difficult to get one's bearings or difficult to remove the dummy data depending on the option chosen. Some good ideas to start with for us would be proper user roles for the use case, an example non-administrator user, and one or two easily editable nodes of each content type that guide the new site owner, rather than making the site look "full."
  10. The Snowman project, for the time being, can be built in contrib against Drupal 7 core. As Drupal 8 is branched and new patches and features become available, we can follow the changes and decide whether new features would be useful for Snowman's users.

Everyone who attended the group is welcome to post anything that I missed, or clarify anything I've misunderstood! Later today I'll be posting our "next steps" plan, where we can all dive in and start working!


Generic Vs Specific Use Case

ronald_istos's picture

Thanks for the writeup Eaton - I think you pretty much nailed the issues and good call on the name change.

Just one point (for now)

Re:2. I think the definition of the use case is a great one because it lends itself to a lot of different interpretations - e.g:

group of people = company
goal = inform and sell products / services
people joining = potential customers / potential employes

group of people = religious group
goal = inform people about righteousness of their path
people joining = new believers

group of people = band
goal = sell tickets and records
people joining = fans

Do we pick one of the above so as to ground example to real world concepts (band, tickets, fans) or do we keep the terminology generic (groups, goals, joining). The latter might be a more drupaly way of doing things but might be too generic for anyone to actually get it while the former might lead people to misinterpret what Drupal does ( i.e. "Yeah - I know Drupal - its for band websites").

How do we do this in a way that does not confuse people about what Drupal really is (a box of legos) as opposed to what this profile that comes with it does?

Maybe I am just not putting enough trust in people's ability to figure this stuff out on their own?

1- the next steps I'll be

eaton's picture

1- the next steps I'll be posting later this afternoon should help. In a nutshell, anyone interested in helping should start by coming up with a real story: their local little league team, a city farmer's market, a small open source project, etc. Flesh out that story as clearly ad you can, then build the best site for it that you can using core. Document the gaps you encounter that can't be filled with core. As we all do this we'll be able to look at the stories and the sites to determine the mist universal solutions for the underlying target audience, the best novel ideas by site builders working on the project, and the core tweaks that could bring the widest benefits. THEN we can start working on "Snowman" with greater clarity.

2- I think the best solution to brand dilution is channeling people to Drupal.org at every opportunity. That, and offering more than one install profile.

Hmmmmm... After further

eaton's picture

Hmmmmm... After further consideration, I realize you're talking about the end result: ie, should the install profile set up a "group site" or "a band site."

That's an excellent question and I'm not sure there is (yet) a good answer. I think nailing that down should be one of the first goals of the post-research phase.

The power of groups

gdd's picture

Clay Shirky's keynote on Wednesday was pretty inspiring in terms of outlining how governments and other offices of power respond to groups and not to individuals (link: http://chicago2011.drupal.org/live), and he discussed the ways in which tools empower these groups to form. I would love to see Tsunami be focused around a group organizing to effect change and/or improvement. Here are some bullet points aroung that

It does not have to be incredibly serious or heavy, my current brain space is around something like a neighborhood association. This would empower the kind of group that traditionally would have difficulty in this area and also tends towards the non-techie side. I am particularly attracted to this example because it also focuses on the local and community building. There are lots of cool opportunities to upsell contrib there. I vastly prefer an example like this than a band website, or even a farmer's market, because its more about bringing people together rather than marketing (not that there's anything wrong with marketing but you know, I'm just a wide-eyed idealist.)

I know the church website example has been brought up many times, and this would work as well, although it has a bit of a different angle. However I could recruit my parents as user testers.

There are a couple things that are key to any of these use cases and will be rough to do with core, I'm particularly thinking of event management and calendars, but I would think some really basic CRM tools would be core to anything here too (mail bombs in particular.)

It may be too early to be getting from 'what is this' to 'what specifically is this' but I had this in my brain and I wanted to make sure it got out before it got replaced.


eaton's picture

This also raises the possibility of temporary sites: things that a group of people throw together to accomplish a specific goal, like lobbying against a particular bill or gathering supporters for a petition.

+1 for community plumbing

R.J. Steinert's picture

Models like Front Porch Forum (yes, mail bombs are the key attraction) are showing that communities need and want to use collaborative tools they own: http://www.newschallenge.org/winner/2010/front-porch-forum

Local Wiki is another shining example: https://www.kickstarter.com/projects/455852114/localwiki-bring-collabora... (gorgeous video on this btw)

OpenOutreach profile a model ?

niccolox's picture

sorry to speak out of turn (I wasn't in Chicago)


there is already an interesting and relevant profile in D6 and D7 called OpenOutreach

Open Outreach contains features frequently used by organizations such as events calendars, image and video handling, and ways to engage with members, enabling small groups with limited budgets to become more independent in setting up and maintaining their own website. By making Drupal easy to use for small groups lacking technical staff or resources, Open Outreach will help groups to make the move to open source.

Open Outreach features are being developed as part of the Debut feature set. See the Debut page for a list of the currently available features. Please file issues related to Open Outreach functionality on the individual features.

Openoutreach is definitely

eaton's picture

Openoutreach is definitely interesting, but we're also committed to using ONLY the tools at our disposal in core Drupal. The approaches will have to be different for certain things -- I'm concerned that starting with a contrib driven profile will force some very uncomfortable workarounds rather than accepting what stuff simply won't be in Snowman.

Just Core (eeek!)

ronald_istos's picture

Hi Niccolo,

the huge challenge Snowman has placed itself is to just use Core - so, practically by definition, all existing distributions can't help us.

The idea is to do something just with what comes out of the box in core, see how far that can get us and then provide people to links to other modules (and I guess potentially distributions) that offer a more complete solutions.

Crucially, by the time the users of Snowman figure out they need more they will be into Drupal enough to care to go search for that extra carrot ;-)

i* , I Star

niccolox's picture

a ha, sorry, I missed the core-only constraint, true bio-mimicry of Stem Cell... just wanted to bring the OpenOutreach profile into the thread, it seems like a good-to-excellent, independently-developed distro... kinda rare...

btw, has anyone seen, heard, or used I*, pronounced, I Star... it seems to be a promising approach to requirements gathering, from soft goals... and its new, seriously technical and cool
Social Modelling for Requirements Engineering

Rather than focusing on the behavioral properties of software, as in a mechanistic system, we should raise the level of abstraction and ask how the system will advance the relationships that some actors have in relation to other actors. This perspective leads to a rather di¤erent approach to requirements modeling and analysis, one that is based on describing and analyzing social relationships.


"Strategic Actor Relationships Modelling with i*" (ppt slides part 1, part 2, part 3)

I think it would be nifty if

Grayside's picture

I think it would be nifty if at the other end of profile-building, we circled back around to contrib with explicit documentation or projects to take that 60% site to 85% or 90% in at least one direction, as that would help it actually be a competitive thing for people who really aren't going to embrace site-building, despite on-ramps to the contrary.

Another thought...

Crell's picture

Eaton, remember that "Community Leadership" site we built for the CMS Showdown at SXSW with caroltron? I know we used a fair bit of contrib for that, but that's another possible model to look at for a "target audience" for Snowman.


eaton's picture

...That could be an interesting one. I believe I've even got the writeup and documentation for that lying around. hmmmm!

Noyz's picture

Thus far, this is how we've looked at it. Much of the issues/goals I outline below map to real usage data in Gardens (which is Drupal).

  1. Getting around your site is too slow. What used to be 1 click, is now several. Plus, D7 has slowed down a bit. The experience is:
    Click Content. (wait for overlay). This step can be bypassed if you click the shortcut
    Click Add Content (wait for overlay)
    Click Add Article (wait for overlay).

  2. The toolbar offers up so many things at once. Setting up your site, adding content, viewing reports are usually performed at different stages in the lifecycle of a site, yet they're all grouped together making it harder to decide where to start. Additionally, the users and developers alike continue to struggle over the Content vs Structure problem. Is a block structure? A forum? Is a page Content?

  3. Help is not being found. Seems obvious to me, but lots of people are missing it.

  4. Users don't know where to start. What's the first thing they should do? The later problem is probably a little different for Gardens in that users come in with pre-installed modules/pages/content. But I'm not sure the problem space is that much different.

Custom code

catch's picture

While I'm very wary of Snowman including a lot of custom code in the .profile (let alone profile-specific modules), I think it's OK if there's a few bits of glue code in there (unless they really make sense as configuration/features in core). It's not a big deal but it's something I think we should look at case-by-case.

Some thoughts...

eaton's picture

While I'm very wary of Snowman including a lot of custom code in the .profile (let alone profile-specific modules), I think it's OK if there's a few bits of glue code in there (unless they really make sense as configuration/features in core). It's not a big deal but it's something I think we should look at case-by-case.

Yoroy summarized the reasoning for this pretty effectively: if we're committed to building something with Drupal's tools, one of the dangers is making a profile that can't be unbuilt, and that couldn't be reproduced by someone who simply studies the site configuration. IE, a bunch of custom form alter functions tucked into the .profile hiding form elements or somesuch.

There are a couple of specific things I think could still work -- for example, if there's a single custom block provided by the profile that is a terrible fit for Drupal Core, but would be a big boon for Snowman itself, we could make the case that it's still something that could be enabled or disabled by users from the UI. Any more than a couple dozen lines of code for something like that would probably be a real danger sign, though. It sounds like the vast majority of stuff that we are running into boils down to 'the /node page really should support content-type-specific subdivisions, and we need a latest nodes block that can be subdivided per content type.'

It would be interesting to provide a patch for Drupal 8 core and a set of default Views for Views 3 in D7 that would duplicate the core blocks. Just as Tracker and Front Page smoothly transition into Views, the 'transition' would be a pretty obvious one, too. Again, I don't want to jump the gun but that specific feature would probably make a lot of sense for general inclusion.


Group organizers

Group categories

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week