Expanded default install profiles

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!

This is an outline of suggested additions to the default install profile out of the box.

The idea is to showcase more Drupal features out of the box, as well as demo a site that is more targetted at a particular use case, which in this case is a community site. See this post for further background.

For bonus points, we might consider a "wizard" as part of the install profile that describes each content type / feature bundle and prompts people to include it or not OR choose an "express install" that enables and configures everything listed below.

Lastly, this profile would ship with a new core theme that is optimized for this use case or use case(s).

I firmly believe that an expanded core install profile will be part of the recommendations that M&L come up with as part of their work. Their recommendations will not get implemented without code and issue queue patches, so I am suggesting we use this space to get out ahead of them. When the time comes, we can refine this install profile and what has already been committed.

Refactored April 5, 2009: Please create a separate wiki page for a suggested default install profile if it is very different from any of the others. Please first review the existing ones and edit their wiki pages directly if it is close / similar to what you think Drupal should do out of the box.

AttachmentSize
expanded-installation-profiles.odt13.83 KB

Comments

Well, I disagree.. I haven't

lelizondo's picture

Well, I disagree..

I haven't created a single site with the forum module installed in more than 2 years. Not everyone needs a forum.

The same for blog, I love that module, but I don't enable it on every site.

About "Article", I guess where's changing story to article witch I think it's a very good idea, but it would be a better idea if there could be an explanation of what exactly it's a content type. With fields-in-core this would be so much easier since the user won't have to install cck.

About pictures, I don't know, I use pictures in all my sites, but I just don't know how the users will feel about this, some of them use the image field, some others like me, use the imagefield.

About, "we might consider a "wizard" ", I think wizards are a good thing, I once was setting up ubuntu on a fiends laptop and I was having some trouble with wireless, so his girlfriend said to me "you know why I use windows? because there's a wizard for everything"..

So wizards are good, but there's also users who want to skip the wizards because they know what they're doing. So the question here is how do we balance this equation? I think the admin should be able to create wizards for users related tasks, tasks like creating content, or previewing the site, it would be great if a user could add some text, then add an image, select the layout and then see how that looks before publishing the node. I don't really know, that's something someone asked for it.

Luis Elizondo

Luis

Disagreement is good :P

Boris Mann's picture

But I'd much rather see you write up a list of out of the box features that you would like to see AND what the target purpose is. Please add your own default install profile thoughts directly in the wiki page above, or start a new wiki page if you think there should be some other default install out of the box.

My list is above -- although I haven't written up the use cases yet, so the context is missing - is for a multi-user community. The blog module is appropriate for that, since all contributors can have blogs.

Re: wizards. I meant an install wizard, not end user wizards. So, the wizard can ask "do you want forums enabled on your site? yes/no" and configure the site -- at install -- appropriately. There would also be the option to say "No, just skip the wizard and give me the default community site out of the box". And just to underscore it again, there is also the "expert" install profile in core, that does virtually no configuration.

Well, now I think I get what

lelizondo's picture

Well, now I think I get what you mean. Maybe the way to go could be creating some configured profiles, and with plugin manager install those modules by default. Let me explain with some examples. Let's say that we could have 3 profiles and the user could choose one of those profiles in the install process, we could have a news site profile, a forum site profile, and a community site profile, if the users chooses to create a news site profile, then with plugin manager modules like imagefield and views could be installed, if a user chooses community site profile, then activity, imagefield, imagecache, imagecache_profiles and profiles could be downloaded and installed for the user.

The great problem with all of these is that those modules have to be ready when Drupal 7.x launches, and plugin manager would have to be part of the installation process.

Also, one of the biggest walls a new drupal user faces, it's the huge amount of modules. I remember when I started with drupal, I saw hundreds of modules, and I knew that was a good thing, but I also didn't know what modules to use to do what I wanted to do, I was lost for a few days in the ocean of modules.

Luis

Luis

Well it may sound radical

jeff1970's picture

Well it may sound radical but this is precisely why I think WYSIWYG API, Imagefield and Imagecache should be in core. My feeling is we should adopt an editor as default and keep it up to datef or an install profiles that include an editor, but out of core - something like Mark-it-up with preview.

I know this is a way old debate but every other major CMS has done this, WP have TinyMCE, Plone as the Kupu editor (very nice actually) and so on. Its time to stop fudging on this and just bite the bullet and include an editor in an install profile by default.

I agree we need multiple install profiles although I am not sure as yet how to define a profile - site type, by features etc. For exampel rather than asking "community site or single user blog" we ask "do you want to add images and use a WYSIWYG editor" - more wizard like so the install profile is built on the fly (more radical ideas...).

I think the WYSIWYG API

jeff1970's picture

I think the WYSIWYG API could be included with improvements to make it mind-numbingly simple to install & configure your editor of choice.

Images/media is more tricky, I'm not up with the current crop of modules but we need WYSIWYG + image/video/audio all playing together nice out-of-the-box. Well, at least images and video - and by video I mean adding Youtube videos aka emfield.

I would (hesitantly) believe that the "80%" would simply expect these things to be standard in a modern CMS.

Is the 'Social Publishing

yoroy's picture

Is the 'Social Publishing Platform' moniker catching on? If so, then yes, a community site profile is a very good idea. Whatever we make of it, we will have to manage expectations even (especially!) before downloading and installing.

What about abstracting this out further...

coreyp_1's picture

I would rather see this as a better installation processi that could handle complex installation/configuration at any time.

For example, let's say I'm a beginner and I want to install an image gallery, so I use image and the image gallery module. As it stands, the user still has to do some configuration before they get what they want, and that's only if they know where to look.

It would be better if there were an api in place where the image gallery module could ask specific questions about the config (ex. Do you want this to show up in your menu? Who do you want to be able to upload pictures? etc...). This is a separate idea from hook_install(), which just creates the necessary database tables. I see this as an option that could happen over and over again to set up different galleries.

Drupal core does this (ask questions on install) for core, but you can never get back to that screen. What good does a profile do if you can't access it again? What if you've been running a blog for 3 months and then want a forum?

I think Panels and Views do this to some extent, but wouldn't it be nice if there were a unified API that any module could access? The possibilities would be endless.

Allow me to go geeky and dream for a second: Suppose I want my users to be able to set up an image gallery using Views, CCK, Imagecache, Imagefield, and Thickbox. Yes, I can do it, but I don't want them to have to follow a long tutorial when they want to make their own. So I create a module that implements this new, as-yet-not-created api that asks them a few questions like:

  • What size do you want your thumbnails to be? (Maybe I'll use jquery sliders, too!)
  • Who can upload pictures?
  • Do you want thickbox enabled (with an explanation or demonstration of thickbox, of course)?
  • What do you want this gallery to be called?
  • Do you want to put a link to this gallery in the menu?
  • etc...

My custom module (which has views, imagecache, imagefield, etc. as dependencies, of course), could then set up the gallery programmatically. Moreover, they could run the configuration profile again to set up a new gallery. Of course, they would see the view that was created and could edit it, but the heavy lifting has been done for them already.

I think that the main reason that we never saw many installation profiles created was because they were a one-shot deal, and the user really didn't know what to expect, and couldn't get back to try out other profiles without wiping their current setup.

To sum it up: I propose that we create a configuration API for modules that the user can invoke at any time, which will walk them through the process of configuring some aspect of the site.

Thoughts?

-Corey

In progress

Boris Mann's picture

It's something I talked about at Drupalcon DC. And there are steps towards that, with Packages / Features / etc. See the Distributions and more specifically the Packaging and Deployment groups that are discussing how to make this happen.

Also, there are install profiles in use -- lots of people have private internal ones, and here is the list of profiles on Drupal.org. The reason we don't see more of them is that they need a fair bit of PHP / programming to get very complex. It is, however, about as hard as theming in order to cut/paste customize an existing profile.

Packages are unlikely to be ready for D7. So what I am focusing on is what can be done for D7. Which is to:
1) leverage the existing install profile that works today to build a better default out of the box experience - this includes a wizard of some kind
2) improve the install profile API and wizard to support #1

Some diagrams on "which drupal for me"

minesotaa's picture

Please see the attached image. Just a rough draft.

Fig. 2 more possible

Boris Mann's picture

This involves upgrading the packaging scripts on Drupal.org. I would like to see improvement there, specifically to enable better direct install profile downloads, but I don't think this will be ready in time. So, Fig. 2 is what I'm thinking.

I don't think we'll be able to get more than default + expert bundled with core. The rest of the list is great, and if people are passionate about those install profiles, they should build them and post them to Drupal.org. Nothing stopping them from doing that ... today!

What I am trying to do, on this page / wiki, is to get people to write up their requirements for what we want Drupal to do out of the box. There is some flexibility for a single wizard to support different types out of the box all under default: having to pick one profile at install, realize you've got the wrong one, and have to nuke your database won't be a very good UX.

I've suggested community, variants might be corporate or single user blog. Our additional challenge is limiting ourselves to what is available in core.

I would like to see

minesotaa's picture

I would like to see improvement there, specifically to enable better direct install profile downloads

I also think so or tend to think so

Drupal 7 will have probably the greatest user friendliness but despite that the fact will
remain how much you may try Flash cannot be given the simple interface of Paint

It can be made simpler, friendlier probably but there will still be existing in the market
further simpler thing which does "single" or "lesser jobs"

So if we have them in mind ( and want to compete ) this crux is to be kept in mind :
we need to have "lesser" versions for the multitude who are accustomed to this type and probably who are never going to make complex sites - this means now "Flash" now make itself straightway downloadable in three formats - Flash, Paint, Notepad :)

Whether there is time or not, unless this is done it will be hard to catch up with the real
life users who dominate the market.

I think this says it

lelizondo's picture

I think this says it all:

"the user still has to do some configuration before they get what they want"

that's very drupal. that's why I use drupal and not joomla, but that's also the reason more people use joomla/wordpress than drupal

the big questions here is:

is that what we really want? do we want a powerful cms/framework that does almost everything, or we want something easier that anybody can use/configure/install? finally, how can we make an easier cms without loosing it's power? I can't imagine a 'normal' user using views or cck, they are so powerful and that's exactly what I want and need.

Luis

Luis

Default things out of the box

minesotaa's picture

Default things out of the box

bold = the module that should come installed and enabled
subnote = default permissions that should come enabled so that the 'user' has not to enable it

Article(=Story)

Front-page promotion enabled for admin-written articles and admin-approved user-submitted stories
Comments by authenticated users enabled
Edit-delete by the admin and edit by the author enabled
Attachment, Inline image ( the most lightweight and core friendly way to show image) enabled for authenticated users

Blog

Blog for each authenticated member
blog owner only can edit or delete her/his single blog post
Attachment, Inline image enabled for authenticated users
Comments by authenticated users enabled

Books or wiki

by default any one can add/edit/delete/see revision/revert any Book ( wiki ) content
Comments by authenticated users disabled

Forum

It will be a (debatable) good idea to make Advanced Forum, at least a minimalistic version of it, part of such package.Many people do not need forum but many need too, and look for VBB, phpBB integration.
Adv Forum can show them they can get a forum of equal usabilty and features OOB.
In any case, usual forum permissions that is authenticated users can make new post and edit post.
Attachment, Inline image enabled for authenticated users
Comments by authenticated users enabled

Page

Prominent note to be shown to admin / author : 1.creating a page will not show up in site unless accessed directly by url or unless a menu-link is created for it, 2.page can be used for faq, help,
contact

Admin can create/edit/delete page
Comments by authenticated users disabled

Album - Insert any album/gallaery/image module here

That allows authenticated users to have at least one individual album
where she/he can upload/edit/delete Image
Attachment, Inline image disabled for authenticated users
Comments by authenticated users enabled

Profile

What should the profile ideally be?
The way other scripts and actual sites are making profile it seems that
now or after few years more and after few more "usabilty and redesign" tests
one has to agree that Profile should look more like Advanced Profile (APK)
If not anything else - Profile should provide:
Link to add that person to friend/favorit list, whatever
More importantly, link to block that person including pms
Comments on profile with privacy options

and others like .........

Polls, Calendar, Events

Should this be OOB or not ?

Wysiwyg editors

I personally prefer BUI editor but there seems to be great demand for
other fuller stuffs

useful sublinks to a node

and modules needed for these, should they be OOB?
Probably no, many will say. But real usabilty by actual end users or site visitors can be increased
if there are options already enabled below each node to
add it to favorit | send to a friend | print it

Presenting option to choose installer or wizard

minesotaa's picture

There is some flexibility for a single wizard to support different types out of the box all under default: having to pick one profile at install, realize you've got the wrong one, and have to nuke your database won't be a very good UX

Wizards have both pros and cons, perhaps. In things complex like Drupal wizard may
present the user with too many options while in contrast install options may make
him happily and easily choose any one, eg Blog when he is a single user and just going
to do that only. On the other hand Wizard can present more options to users looking
beyond one click options or wants to configure and tweak more at the very outset.

Please take a look at the figure below that presents BOTH the options.

The problem is that you're

coreyp_1's picture

The problem is that you're using radio buttons when many users need check-boxes.

This brings be back to my other comment.

I would rather have the system split into two: Profiles and Conguration wizards.

Profiles automatically enable specific modules, but a configuration could be run multiple times, both at installation and in the future.

In the installation example, suppose you ticked the checkboxes for Media Gallery and Personal Blog. Those would immediately run a configuration to set up a media gallery and a personal blog. But what if you wanted to set up another gallery a few months later? Well, by offering a Configuration wizard, the user could set up another Media gallery without even knowing how to create an additional taxonomy (if used), imagefield/imagecache options, and menu entry.

I really believe that a system like this would change the way that Drupal is used... by both Wordpress-esque users and developers like me.

-Corey

minesotaa's picture

Checkboxes and radio-buttons both have pros and cons.
Radio-buttons can give one-click simplicity, check buttons more versality BUT
if Wizard is also there ( or to frame the statement in another way, if Wizard is there along with Profile ) are check-boxes needed ?

"but a configuration could be run multiple times, both at installation and in the future."

Did you see Figure 3 above, I am not sure if it is showing to you or not. May be have to clean cache ? if the older figure is showing still. There is a fresh picture - Figure 3 above. Please take a look.

Yes -- off topic

Boris Mann's picture

I've replied already above. You are describing Packages / Features / whatever. This will not be done for Drupal 7, but is definitely something that people are working on now.

Please focus on "What should Drupal do out of the box?" and help work on the install profile above.

Yes

minesotaa's picture

"What should Drupal do out of the box?" - http://groups.drupal.org/node/19812#comment-72467
Please have a look.

I was responding to coreyp_1

Boris Mann's picture

I was responding to coreyp_1. I refactored your comment into a separate wiki page - http://groups.drupal.org/node/21014

Preserve the union

bingomanatee-gdo's picture

The issue is not your favorite form widget; the issue are are you going to channel the user towards one choice of many or allow them to choose the blend (union) of choices they want?

Letting them choose

minesotaa's picture

Let the users choose "one choice of many" or "blend" via wizard. Please see Fig 3 above.

Some thoughts about beginners who discard Drupal

minesotaa's picture

I was thinking today ( after seeing this post ) what are the reasons some people leave Drupal
and whether this can be addressed at the DOWNLOAD level ( see figure 1 above ) and how many
such factors can be handled at the INSTALLATION level. ( see figure 2 revised and figure 3 above )

While there are so called lab usability tests, I suggested data-mining of the forums and issue-lists at drupal.org - apprently there has been many studies and statistics recovery. Perhaps we have identified the most difficulty factors, but it would be, side by side to that, good to identify why
some folks leave Drupal, whether their dissatisfaction is justified or not.

If some of the factors are justifiable at all ( for example in the above post to which I have given link, I am not sure so much about modX for my experience was completely different and horridly difficult with modx while it was easy go from step one with drupal ) may be we can make a quick list of those, namely why some people leave drupal. We can discard any such post that are just b*s or show that the user has been too impatient.

Complaining of difficulty about usabilty, steep learning curve, jargon etc is a different thing, while totally discarding a cms is completely another thing. May be those can throw some light in our new designs of Download and Instlallation ?

Each Expanded Installation

delf's picture

Each Expanded Installation should come with own features that will require (on our, drupal developer end) customization of the following Drupal framework elements (correct me if I missed anything):
1. Modules
2. Module configurations (installation profile per module?)
3. Content types
4. User roles
5. Permissions
6. Themes
7. Default Input Formats (I assume that wysiwyg editor comes with all installation profiles)
8. Sample data

As I proposed here: http://drupal.org/node/418560#comment-1424084 Drupal must be able to replace the following products out of box:
1. Corporate websites (Joomla)
2. Personal blog (WordPress)
3. Online forum (phpBB/vBulletin)
4. Online shop (osCommerce)
5. Image Gallery/multimedia solution (replaces/integrates Gallery2)
6. Basic

I presume that wisywig & image support will come with every installation profile.

We need to develop requirements for each Expanded Installation Profile. End user should be able to install Drupal by only selecting "Features" and without drilling down to module installation, module configuration, setting permissions and generating data - all this will be taken care of automatically with default configurations. Of course, there should be a link on Expanded Installation Profile configuration page to advanced setting where user can modify any settings (modules to install, module settings, roles, permissions etc).

"Feature" is a concept unique to installation profile and consists of a combination of the above mentioned 8 Drupal framework elements. Novices are NOT FAMILIAR with Drupal framework concepts and for them even such trivial things as roles, permissions, input formats and content types will be confusing.

The goal should be to get users started with Drupal WITHOUT having to know underlying Drupal concepts and processes. Once they have their website up and running they will have plenty of time to tweak settings and start their learning curve.

Please see the file attached to the node (http://groups.drupal.org/files/expanded-installation-profiles_1.odt) for the grid representation of Expanded Installation Profiles.

Delf.

Too many for core

Boris Mann's picture

People -- outside of core -- can definitely build all these install profiles. It is not realistic to do all of those you list with only core modules -- even if a WYSIWYG + full Views + CCK were to be added.

So, my challenge to all - if you hit "install" -- what would you want Drupal to do out of the box?

From there, we can look at wizards to enable / disable some features. Each:

  • Forums
  • Blogs
  • Photos

Leaving them all unchecked would result in a site with Pages and Articles and a few other features, but be somewhat similar to what we have now - with improved UX to easily run a social publishing system out of the box.

Leaving them all checked would be the community in a box as I have described above.

Lets keep this discussion focused -- much of the discussion has been about future ideas that have yet to be built. Install profiles and the install wizard exist today, and we CAN build a better out of the box install profile.

When I hit install on Drupal

delf's picture

When I hit install on Drupal I want (and typical user will, I guess) the following out of box functionality:

  1. Blogs:
    Ability to post blog entries.
    Comprehensive comment system
    WYSIWYG
    Photos
    Polls
    Blog archive
    Statistics

  2. Forum:
    All the major features of phpBB and vBulletin, including:
    Moderators
    Banning
    Image/file sharing
    Content voting
    Polls
    Multiple comment actions: moderate, delete, unpublish etc - straight from the discussion thread
    Private messages
    Friends/foes
    Groups

  3. Photos
    Mass upload
    Albums
    Image Watermarking
    Image Resizing
    5-star rating
    Slideshow

I think we can also manage to provide a basic "Corporate Website" installation profile.
It will need some easy page publishing/managing tools, including WYSIWYG, Photos, News/Press releases, default front page, contact form, vacancy list and printer friendly pages.

The online shop then needs to be provided separately, because it needs lots of modules related to Ubercart.

Delf.

In my opinion, we should

Cyberschorsch-gdo's picture

In my opinion, we should keep the default install profiles as simples as possible. Giving too many options will only confuse the user. Instead of adding many features out of the box into drupal we should focus on improving the structur of modules, esp. finding the modules we need to do certain things ( this is another topic though).

We also should rethink the aspect of the install wizard as minesota described. Sure, the user would save a lot of time when he just check some radiobuttons and everything has been installed and configured but in the end we cannot create an automatic drupal install which does everything on its own and be individual at the same time.

What I mean is that the user has to discover drupal and its features on his own. If we make it too simple, the user will get frustrated really fast when he tries to do advanced site building.