General thoughts on Snowman project

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
patcon's picture

I’m worried that I’m bringing this input to the table much too late for it to be of any use, but what the hey. The Core Conversation session was great, but unfortunately, I was flying majestically through the air while the BOF was happening, and am just now finding time to catch up.

Firstly, I'd just like to bring up a few big picture concerns that kept running through my mind while listening to Eaton's awesome, passionate pitch.

Big picture

Re: Using only core modules

I'm not sure I grasp the importance of the focus on using exclusively core modules. Before I lose you all in a sea of groans, let me take a shot at explaining myself. With the looming possibility of an improved plugin manager in D8, with the potential for downloading installation profiles during the installation process itself, I wonder whether we're looking at this project in isolation of anticipated D8 developments... Should we really be focusing on creating a limited install profile exclusively with core modules, or should we anticipate an era when this core-contrib division will be irrelevant as far as new users are concerned?

I'm not saying that we should open the gates to use as many contrib modules as possible in this initiative. Leisa's notion of a minimal viable product has huge merit -- we don't want to over-complicate. I'm just wondering whether this line in the sand between core and contrib is relevant going into the future. Not to state the obvious, but a new site admin doesn't care whether a showcase install profile was created with core modules or not. If the Drupal project as a whole makes it easy to jump into any installation profile (as a D8 plugin manager might very well do), there's not particularly any merit in showing what "core" can do on it's own. If you tried to explain our logic to a new site admin, they might ask "What's 'core', and why does it mean the official install demo is so much more limited than the ones I can get by clicking there?"

And yes, I understand that having an install profile with only core modules would be useful to developers as a "canary in the coal mine", but should this project try to be both? A technical litmus test of the base essentials, and a LOOK-WHAT-WE-CAN-DO project? In supporting the former, are we cramping the style of the latter?

Specific thoughts

OK, with that out of the way, here are my thoughts on the smaller scale. I've been trying to think critically through a few angles, and just lay it on me if these thoughts are out of line with the goals of the Snowman project. I'm totally alright with that :)

Consequence of limiting ourselves to core modules

DEVELOPER POV: Given that we're currently limiting ourselves to core modules, then it's a given that as soon as someone starts a real install profile targeting our niche (complete with contrib modules), it's going to make our efforts somewhat obsolete. The real install profile will almost categorically be "better", and for anyone who fits our use-case, ours will be the second-tier recommendation. And the worst part is that this will have nothing to do with how hard we've worked on it. Realistically, how will this affect our momentum and enthusiasm for the project? We all contribute to this community because we feel what we do is relevant, and without that, it becomes less fun. If/when a better contrib install profile rears its head, our canary now exists not to sing, but simply to die on command in the aid of core developers. That awesome analogy may very well make me want to high-five myself, but the implications certainly do not.

Consequence of choosing a specific user story

SITE CREATOR POV: Even if they wish to learn Drupal's capabilities, will a user have any interest in setting up a site that serves a very different purpose that what they're looking for? If someone is looking to create a site for their baseball team, will they see the benefit of using a Farmer’s Market install profile to understand Drupal? Even if they wanted to test out the specific Snowman install profile, they might not know the difficulty associated in "rolling back" after they've checked it out. They've just slogged through setting up a database and FTP'ing all their files onto the server, and they'll likely just want to choose the option that sounds like it will let them create their real site, right?

Regardless of the approach we take on the install profile, perhaps we should consider how we might make it simpler for a user to choose a showcase profile, then roll back. Maybe this is a candidate for how a core patch might improve the install profile experience? It would be nice if we could tell a new drupal user, "Try out this showcase install profile, and even if it isn't what you want, you can just click a button to get back here as if nothing had happened." Dave Reid wrote a simple script to reset a Drupal website during development by deleting all database tables. Could we not put forth a proposal to include in core a module that did something similar? It would certainly make it much easier to convince a new user to dive into Snowman's install profile, whatever it turns out to be. Not sure the lgoistics, but perhaps an automated SQL dump could accompany the process, just to be safe.

DEVELOPER POV: We talk about this effort being something to help rally the community behind a common cause (showing what Drupal can do), but we also speak of user stories that are pretty specific, and so not relevant to everyone. Perhaps someone is totally jazzed about creating a foodie install profile, but a government-specific install profile just doesn't engage them? Or maybe it's the reverse?

Perhaps we could still tackle an install profile for a specific purpose, but also have it work at a "meta" level that anyone can get into? (Oh shit, he just used the word "meta"...) Before I say anything else, check these out, as they help illustrate what I'm going to suggest:

Sliderocket inline tour Grooveshark tutorial theme
Only local images are allowed. Only local images are allowed.

Notice how both of these tactics provide an immersive tutorial, while remaining essentially functional? Grooveshark just themes their background so that it provides clues to how it all works, while Sliderocket walks you though an example project tutorial that takes place within the interface that you'll be working. Could we not do something like this for Drupal? Have an install profile that works at the level of functionality, but also at the level of a walkthrough.

I'm just starting to think on how we might be able to use the theme/subtheme system to do some cool stuff here. We could have a base theme that looked like the fully functional site would, and then have a subtheme with tons of CSS "overlays" (for lack of a better word) and blocks specific to that subtheme. So little helper/explanatory blocks could lead a first-time user through a tutorial, and the final steps could involve having the user themselves delete all the demo content via the Content listing (easy to do if we tag it all with a "demo content" taxonomy term), and then switch the theme to the base theme. This leaves the site admin with a fully functional site ready to be used, should they so choose. Not sure if we'd want to get this in-depth, but we could even create demo accounts with specific roles, and instruct the site admin to log into these demo accounts as part of the tutorial flow. Since blocks can be visible to specific roles, and users can be assigned different subthemes, this offers more opportunities to tailor the instructions based for the which demo user account that the site admin is logged into during the tutorial flow.

Not sure how everyone else feels about it, but perhaps this would give the community a greater stake in the Snowman project? It's no longer about a specific use-case, although that's important to nail down -- it's about walking new users through how drupal works. We're all rooting for that persona, and we're all vested in that specific person being taken care of.

Another little aside here: There's a lot of talk of choosing the persona we want to make as the primary one. The above approach would make the site admin the de facto primary persona to target, but perhaps that's fitting. After all, the truth is that this install profile won't be suited to the vast majority of use-cases. If it's installed a site admin, it will largely be for them to see how Drupal works. They're probably not going to keep it online and invite all their future users and content editors to check it out. The vast majority of those who install it will test things out, then uninstall and start working on their "real" site. For this reason, it seems most important to prioritize the site admin persona most highly, as by-and-large, they'll be the only ones who take it through its paces.

So what say you guys? Am I dream-stomping right now? I've genuinely tried to put as much thought as I can muster into this post, and hopefully it doesn't come across as meddling or a perversion of what we're shooting for. I realize I'm arriving late, and many decisions and much effort have come previously, so I understand if some of these concerns aren't relevant at this point :)

Comments

You have a lot of good

Grayside's picture

You have a lot of good thoughts in there, and I'll have to go back, reread and respond to more later.

There are so many different wavelengths at which Snowman is a good idea, that it can be hard to keep them all in mind at once and have a coherent discussion. One of the things I think are most worthwhile is this notion that Contrib and Core have different communities of developers and different goals, and that Snowman will operate to funnel Contrib impulses into Core development.

If Core and Contrib blur together to end-users, that is a fine usability improvement–for endusers. But it shouldn't be taken as UX that can excuse the advancement of Core's support for Contrib. In fact, I think Snowman is an example of something which will help push some of that blurring as a distribution that seeks to facilitate the use of Contrib.

One of your points that I reacted to most strongly was the concept of competition from Contrib distributions. I don't think Core /features/ ever really compete with Contrib. They are a baseline set of functionality that Contrib can extend or replace.

From the point of view of a minimum viable product, I think Contrib will do very well to extend it. How many modules are there with the word "Book" in their name?

I don't think Snowman is intended to provide a tutorial wizard, but there is the idea of example content to help demonstrate what everything does. The overlay idea would be an interesting Contrib project. Especially if it could adapt to multiple themes based on DOM selectors...

patcon, thanks for the

eaton's picture

patcon, thanks for the writeup!

There are two sides to what you're discussing. Tthe first is (at least, as far as I can see) a misunderstanding. The second is a question that really gets to the heart of the Snowman project.

Perhaps someone is totally jazzed about creating a foodie install profile, but a government-specific install profile just doesn't engage them? Or maybe it's the reverse?

Perhaps we could still tackle an install profile for a specific purpose, but also have it work at a "meta" level that anyone can get into?

You're correct! As the FAQ notes, the goal of the overall project isn't to make "A foodie site in a box," or "A profile for NGOs" and bundle it with Drupal. Rather, the goal is to build a useful tool for small groups that are doing something together together, telling the world about their project, and inviting others to join in. That's a broad enough goal that it can cover a lot of ground, but it's definitely more specific than "A Drupal Site."

The sample sites that are being built aren't "candidates for the final build," but R&D exercises. We're trying to suss out the common patterns that appear across a variety of different sites that fall under the overall goal of the Snowman initiative, to better understand what functionality is needed and what challenges are encountered across a variety of use cases.

There are two great dangers. The first is building a site profile so specific that only a tiny niche audience would be able to use it. The second is falling into the same trap that today's "Standard Install" does -- it is a purposeless, halfhearted "Drupal starting point" that gives experienced site builders too much cruft and newcomers too little direction.

If it's installed a site admin, it will largely be for them to see how Drupal works. They're probably not going to keep it online and invite all their future users and content editors to check it out.

I think that statement is really the heart of the discussion. For better or worse, what you're describing is how Core's standard install profile has always worked, and it's an approach that is demonstrably bad. Simply piling on more "demo configuration," settings intended simply to show off specific Drupal features, doesn't help anyone with the real challenge: figuring out how to decompose real world problems into Drupal solutions.

If we target an actual use case and build a Drupal profile that caters to the people who'll be using the site, rather than the person who would build the site and hand it off to them, we're building something real that can actually be used. In addition, it provides a better example to potential site builders.

The final point -- the issue of using only core modules -- is ultimately a political one. The standard Drupal download is not going to ship with non-core modules anytime in the forseable future. Period, end of story. There is also a strong push-back against removing functionality (like Forum module or Blog module) from Core because that would make it "impossible to build real sites without using Contrib." This leaves only two options: allow Drupal Core to remain a baffling "here are your tools, go build a house" exercise for new users, or figure out how to get things rolling with the tools that come with core, and direct them towards contrib as they encounter gaps in core functionality.

Building a "contrib" profile that uses contrib modules, and can be downloaded separately form Drupal, doesn't actually solve the underlying "welcome to Drupal" problem that the Snowman problem is seeking to improve. It just adds yet another third-party tool that newcomers won't know about, and will probably only discover after they've climbed the really steep part of the learning curve.

Not the usual distribution

juan_g's picture

At first sight, Snowman sounded to me like a community distribution, maybe similar to VoiceBox (a 29.5 MB distribution based on Drupal 6, that is 3.31 MB core; see Comparison of social and community distributions). But if Snowman uses only core (D7, etc.), then it's a different kind of project, indeed.

Perhaps it can be, as the FAQ suggests, "a starting point for experienced site builders, a demonstration of Drupal's capabilities for exploratory site builders, and a useful tool for people who simply need a web site". Truly interesting...

Too bad this thread ended so

Joav's picture

Too bad this thread ended so fast...

Snowman

Group organizers

Group categories

Group notifications

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