Update: The final proposed session is a bit more focused. This is why I pretend there's a method to my madness.

While brainstorming narratives for a presentation for drupalcon on "the practical drupal architect", I started scribling notes about "schools of thought" for drupal architecture.  Interested in whether this kind of high level stuff is even remotely interesting to anyone. An actual presentation will use real websites with labels and overlays and big arrows to illustrate these points of course.

The Classical[1] School of Drupal Architecture 

Prototypical example of Classical Drupal Architecture: whitehouse.gov

From the builder's perspective[2]: 

The classical school is relatively conservative: you might use mini-panels to create clusters of blocks to ease the micromanagement of visibility settings, but not full on panels itself. The classical builder tends to pick modules which are the most tried and true solutions to the sites needs, and rarely uses radical new methods. For this reason, many people will call classical sites "standard implementations" - but the good builder knows there's nothing standard about knowing the right tool for the job.

Competence and experience is required from the builder in this style, and their failure to choose the right patterns, and methods will mean the building comes crashing down. 

From the themer's perspective:

Classical Drupal Architecture is easiest for the themer.[4] A themer who messes up a classical design is like an out of tune piano. 

1. Small number of page layouts and regions, usually no more than 2 or 3 layouts with 4 to 10 regions in total (10 at the extremes). 
2. A navigation system that works for all page layouts, and behaves consistently. 
3. The only distinct styles for nodes tend to based on medium: text, video, and image. Each medium tends to have a simple teaser, and simple page view. 
4. Each region tends to have one consistent style for blocks.

From the designer's perspective:

The classical designer must understand[3]: 

1. the functional purpose of the page they are designing

2. limits of html/css and what they can bend in special cases

3. how to design defensively (e.g. not every page is as ideal as a photoshop mockup with fake titles and text)

4. basic user interaction states (photoshop dude, remember every page needs to maybe display messages like "your password is incorrect").

5. development resources are limited, and that they only have a limited amount of "design bucks" on each project to invest in the various parts of the potentially tens of thousands of pages.

6. When a function requires a special touch, lazy developer be damned. 

7. the handy features in their tools that let them assign design attributes to common elements that can be shared by multiple pages. (I hope you found out how to do that, and don't tell anyone if you haven't.

Some common characteristics of classical drupal sites: 

1. An emphasis on mathematical precision, typographical hierarchy, as well as vertical rhythm. While the design doesn't have to be pure white, flourish is usually reserved for the background, header or other areas that aren't already being used by content.

2. Elements that's style repeats in multiple places for multiple types of content and pages, but serves a consistant purposes.

Many designers mistakenly equate "reusable" with "cookie cutter". They may even think developers who moan about building another curvy shadowed box as "lazy". The classical designer laughs at these people, and drives off in their new BMW. They are by and far the most rare, and highly valued web designers in the industry -- even if the industry doesn't realize it yet.

From the Chx's perspective:

The whole point of the style in a way is to make everyone more efficient at the basic crap which is where most drupal sites get hung up. Its tried and true for big drupal content rich sites with basic community features. Chx would probably get really bored, and have a lot of free time if he were working within the inherit constraints of this style. From his perspective, this style merely frees him up to spend time working on the development challenges that require a chx. 

Tangents I didn't want to completely delete:

1. I used classical because of the its emphasis on tradition, technique, and structure from the module/theme perspective, as well as the elegance, harmony, and mathematical precision that's evident in the final product from the design perspective. I haven't yet identified more with confidence, but am making up labels at least so the perspective is relative: drupal.org's current implementation is "neo-baroque",  and drupal 6 out of the box "traditional-folk". Neither are worth covering as neo-baroque is a style that has emerged from the special conditions of one place (drupal.org is a freak), and everyone can sing traditional-folk.  Baroque, I define as classical minus a great designer, the builder as the architect, and the themer being non existent. 

2. Understand that i'm treating terms like "themer", "designer", and "builder" like hats you can put on and take off at any point. 

3. It could be argued that this is just plain good web design in general. I 100% agree with this interpretation. Web design is constrained medium. Designing dynamic web sites is even more constraining. Don't design either if you are frustrated by constraints. In a sense i'm making a point of "stop blaming drupal and the developers, and embrace the inhereit complexity of designing giant websites.

4. I've never actually never met a themer. I've met builders who theme, and builder's who don't, but i've never once met a themer who doesn't built. At the same time, i've heard a lot of gossip about these themer folk and admit  I'm not inspired by what i've heard about their capabilities.