DrupalCon London 2011: MAKING CORE USEFUL
Problem:
As Drupal has grown and evolved, the complexity of the average Drupal site has skyrocketed. Heavy reliance on contributed APIs and addon modules have put most site building tasks on the opposite side of a "learning ledge" for new users.
Usability research has shown us quite a bit of low-hanging fruit, but a larger challenge remains: the limited feature set of Drupal Core, and the necessity of engaging with the immense Contrib landscape before building a "real" site. The inclusion of FieldAPI in Drupal 7 has dramatically improved some aspects of the problem, but the only polished mechanism for displaying content is a global "front page."
Users do not need infinite flexibility when building their first simple sites, but they need much better than this if Drupal is to be a useful tool. How can we balance the dueling needs of simplicity and flexibility? Should we pursue a feature-rich Core despite the presence of a well-stocked contrib ecosystem?
These are hard questions we must answer together.
Proposed solution:
Regarding core functionality, several paths are open to us. One is to accept that Drupal Core cannot be used to build "real" web sites, that its primary purpose is to serve as a starting point for contrib-driven projects.
Another option is to begin the work of migrating the Views module and CTools into Drupal core. With those tools, custom core-only modules for many functions would be unnecessary. (Although much work would be needed to ensure that simple tasks for end users remained simple: building Views, as common as it is, is an 'advanced' activity.)
A final option is is to build focused pieces of key functionality into Drupal core. For example:
An optional listing page of teasers for each content type.
An optional sidebar block and RSS feed for each content type.
A 'View [type] content' access permission for each content type.
The ability to display children of a Book page as node teasers, rather than bulleted links.
While limited in scope, even these simple tools for displaying separate pools of content would give site builders a much richer palette while learning.
As Drupal has grown and evolved, the complexity of the average Drupal site has skyrocketed. Heavy reliance on contributed APIs and addon modules have put most site building tasks on the opposite side of a "learning ledge" for new users.
Usability research has shown us quite a bit of low-hanging fruit, but a larger challenge remains: the limited feature set of Drupal Core, and the necessity of engaging with the immense Contrib landscape before building a "real" site. The inclusion of FieldAPI in Drupal 7 has dramatically improved some aspects of the problem, but the only polished mechanism for displaying content is a global "front page."
Users do not need infinite flexibility when building their first simple sites, but they need much better than this if Drupal is to be a useful tool. How can we balance the dueling needs of simplicity and flexibility? Should we pursue a feature-rich Core despite the presence of a well-stocked contrib ecosystem?
These are hard questions we must answer together.
Proposed solution:
Regarding core functionality, several paths are open to us. One is to accept that Drupal Core cannot be used to build "real" web sites, that its primary purpose is to serve as a starting point for contrib-driven projects.
Another option is to begin the work of migrating the Views module and CTools into Drupal core. With those tools, custom core-only modules for many functions would be unnecessary. (Although much work would be needed to ensure that simple tasks for end users remained simple: building Views, as common as it is, is an 'advanced' activity.)
A final option is is to build focused pieces of key functionality into Drupal core. For example:
An optional listing page of teasers for each content type.
An optional sidebar block and RSS feed for each content type.
A 'View [type] content' access permission for each content type.
The ability to display children of a Book page as node teasers, rather than bulleted links.
While limited in scope, even these simple tools for displaying separate pools of content would give site builders a much richer palette while learning.