why blueprint is not the right theme for d.o

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

Hey Drupallers
So this is my pro/con list of the blueprint framework that mark bolton used for the prototyping of the new drupal.org

First up: Im a big fan of finding a unified way of doing the frontend work, but im not in it for any course - a frame work isnt good task B just because somebody else uses it for tast C.
Mark Boulton uses blueprint for their prototyping, which makes a lot of sence. Theres a lot predefined classes that makes it really easy to quickly build up a bunch of pages in html.
In prototyping its not the beauty of the mark up code thats the point, its the functionality of the pages, and getting everything sketches out with the client. (and btw is a huge help for the theming planning)

So know that we are at the point where we have to theme this beautiful design, the argument were made in cologne that we should just use the prototypes that Mark Boulton (MB) already had done, so we could be faster on our way to get the design implemented.
I know it makes sense to just use what somebody else already has done, but people this is our new home! we should go for the best possible frontend we possible can get, and remember one of the lessons that we have learned the last couple of years. - The theme should not be on 1 man/woman's shoulders.

We should NOT use the blueprint based markup & style that MB has created for the protostypes because:

  • Blueprint basically sets up a ton of region sizes, and by looking at the designs we need 4-6 basic widths - so to load 200+ classes would be total overkill - we have more than enough classes in a drupal site as it is, and we dont need to confuse the themers more.
    Bloat is not only the 4-5k's of stuff we load to the end user, its also the ton of css files & classes that the themer has to know there is

  • Non semantical naming - its more or less impossible to read the code and figure out what is what in the markup.

  • Blueprint is not build to put the content first :/
    yeah lynx still rocks, and the accessibility people are gonna love us, not to say the seo freaks.

  • The blueprint framework (and others) builds on the idea of adding classes to every piece of markup that needs a width

<

div class="grid-14"> Theres a lot of places in drupal thats not so easy to get a hold of and add a class to that specific markup, so we will end up at one time or another with width settings in the .css files, and again make it less obvious for the next themer to figure out whats going on.

  • Speed - i Guess the Gerhard & the server guys would be happy if we didnt end up with a ton of markup that every visiter on the sites ends up downloading?

  • Theres no reason to make a quick & dirty solution thats gonna haunt us the next 4 years.
    lets find the right way todo this, and yes we will have a version to show the drupallers in DC

  • As i see it MB really build it on the 960 grid system, that a couple of themers are working on now to get into d7 (), and they only used the 24 grids based blueprint as a prototyping tool (so at this point i have som questions to the prototypes, where it dosnt follow the 20px gutter, but only have a 10)

..."Please note: These prototype files are to indicate and demonstrate functionality only. They are not indicative of the final design of the website."

  • This is the drupal site! - we should go for perfection and not just a quick solution!

I really cant se any good reasons for jumping on the blueprintCSS framework - unless were cutting it down to a bare minimum and change the way the grid is set up.


What we should do IMHO:

Set up hte basic css& markup rules:
* reset.css
blueprint & 960.gs both framworks have really got stuff, more or less the same - no surprise there.

*layout.css
The basic pages are all using 2,3,4 & 5 colums , these are based on the 960 so we gonna reuse som of the the width definition, and the aplha / omega
(btw 960 in drupal -> http://groups.drupal.org/node/16457) - so here we can cut out all the crap and just work with the basics

*Define classes & regions so they make sence for us all (and in a year)
header footer, left bar, menu etc you know the drill?

In the next couple of days im gonna sketch up the classes & markup that can provide us with the setup that we need, unless somebody is gonna oppose on this?
or have a really good reason to why we should use blueprint for all our css needs

rock on
/morten.dk

Comments

I agree

caroltron's picture

Morten,

I completely agree with you that a theme primarily focused on rapid prototyping is not what d.o needs. It needs something much more sustainable and also flexible enough to tap into what core is throwing out at the theme. In my experience, a Drupal site (especially one as large as d.o) is much easier to maintain and extend when you don't fiddle with the markup, when you instead let Drupal do what its going to do and theme what you expect: theme the core pieces first then layer in the possible layout options i.e. theme all blocks, then adapt all menu blocks, then view blocks, then custom clocks, then menu blocks by region, etc. The more you theme those basic pieces, the more you save time in the end and the more the site is prepared for future functionality.

I've been working with Zen for the last 2 years and it is by far the best tool for achieving a workable, extensible theme. In fact the items that you listed above: resets, typographay, SEO and semantic layout...these are all things that JohnAlbin has focused on with Zen. Not only is the markup layout optimized for SEO, it also has an entirely em based font layout with predefined values for you. On top of all that JohnAlbin has gone through extensive work giving you every class that is needed to "tap" into core. I think am important goal for this theme implementation is to preserve drupal admin configurability and to reduce if not remove all need for theme tweaking down the road.

Here are just a couple of sites that we at Palantir built using Zen subthemes:
http://herron.iupui.edu/
http://graycor.com/
http://alumni.northwestern.edu/
http://www.artic.edu/aic/collections/
http://www.imamuseum.org/

-cc

-cc

But what way to go then?

mikl's picture

But what way to go then? Isn't Zen a good starting point, since it already has the content-first stuff we need. Only issue is grid-stuff, which Zen currently does nothing about. Perhaps some Zen/960.gs hybrid?

Implementing a grid layout

caroltron's picture

Implementing a grid layout in Zen is definitely something JohnAlbin and I have already started talking about and I think is feasible. What I think is also important is to understand why some themers prefer Zen over a Grid layout and vice versa. I think a lot of designers balk at Zen because of "how bloated or difficult it is", i.e. how "confusing" it is to set up, when in fact it is the opposite. It is probably so overly documented, that no one actually reads the directions (pointing the finger at myself), and there are so many optional pieces that a new themer doesn't want to assemble them together. From the little bit of experience that I have had with grid themes, the installation process is what is preferred here...the plug and chug to get your layout and CSS right away. I know the first time I looked at Zen I thought, man thats a lot of files. Then I took a second look and noticed that it was a lot of empty css classes leading me down the easier path to theming. That said Zen has been more of a tool for advanced themers, ones who need complete control over every moving part. I think that this can be adapted to welcome in grid layouts. I really believe that there is a fantastic foundation to build off of in Zen.

-cc

-cc

From my perspective the

gdemet's picture

From my perspective the other issue is that grid-based layout systems like Blueprint and YUI Grids (I don't personally have experience with 960, but my understanding is that its concepts are similar) are great for quickly and easily creating a design, but they're not so flexible when it becomes necessary to be able to change layout elements.

The style guide that Mark Boulton Design has created for Drupal.org is more than just a set of static templates, it's an entire visual language that's intended to be adapted and extended for the wide variety of use case scenarios on all the d.o sites, not just now, but in the future. To that end, it's important that whatever theme is picked be one that can easily be adapted and extended while still remaining consistent with the guidelines that have been established. It's also vital that the theme be one that's designed to work well with Drupal's out-of-the-box approach to page layout.

Zen was designed from the very start to integrate closely with Drupal, and as established in the other comments, has shown that it's incredibly flexible and able to be used to create a wide variety of layouts, including ones that are designed to a grid. My fear is that attempting to shoehorn all of Drupal.org into a Blueprint or Blueprint-like theme would only lead to frustration on the part of the site's themers as they ran into use cases that didn't fit cleanly into the grid system's assumptions, and would ultimately lead to a site that was far more difficult to maintain and extend.

Another vote for Zen

yoroy's picture

Zen was designed from the very start to integrate closely with Drupal, and as established in the other comments, has shown that it's incredibly flexible and able to be used to create a wide variety of layouts, including ones that are designed to a grid. My fear is that attempting to shoehorn all of Drupal.org into a Blueprint or Blueprint-like theme would only lead to frustration on the part of the site's themers as they ran into use cases that didn't fit cleanly into the grid system's assumptions, and would ultimately lead to a site that was far more difficult to maintain and extend.

Totally agree with this. Zen has so much "ready to go" Drupalisms built in while remaining very flexible to adapt to various layouts. And, with Zen being very (most?) popular amongst themers, it has the largest group of potential workforce that could help out in maintaining and expanding it.

There are a few "griddy" pages in the style guid, but none seem overly complex. And there will be a lot more pages that will adhere to the simpler layouts of content + right sidebar

I'd love to help out, but for me Zen would be a prerequisite to be able to work productively on this.

If Zen...

ceardach's picture

If we go with Zen, I would say that the best course of action would be to add Zen as a core theme for D7, and have the Drupal-as-a-brand theme as a sub theme. That system could prove to be quite portable.

As for using a grid system... I personally don't think it is important. Maybe I'm just an old fart here, but this new fangled system-as-structure as opposed to system-as-meaning thing doesn't appeal to me.

The idea of creating the theme in a fixed-width layout truly saddens me. I've always loved how all the Drupal themes were flexible and breathed. I think of front-end web design like fashion design. Sure, it looks good on that model with the perfect body as she holds herself just right while walking down the catwalk. BUT, will it make you look good as you enter the meeting room? Will you still look good when you sit down at the table? Like clothing, web design is best when it can move with you and look good in a wide variety of positions. Exact pixel widths and positioning just can't do that.

I'm with you on this one.

caroltron's picture

I'm with you on this one. And in fact I am a huge proponent of adding Zen (or parts of Zen) into core for d7, and even ideally in combination with the 960 layout. Work is already in progress: http://drupal.org/node/364777

-cc

-cc

Zen doesn't have to be in

yoroy's picture

Zen doesn't have to be in Drupal the product to be able to subtheme it for Drupal the site. And the design for d.o. will certainly not be distributed with core because it is only meant to be used for d.o. and it's sub sites.

I'm a fan of liquid layouts, too but I'm not sure if we should open that can of worms now. I tend to think that for now we should first focus on consistency and start building the fixed width layout.

Liquid layouts FTW!

Senpai's picture

Liquid layout FTW. Why are people talking about a 960px fixed-width grid just because that's how we used to have to do things for IE5? /me ponders the days left until 2010...
______
Senpai


Joel Farris | my 'certified to rock' score
Transparatech
http://transparatech.com
619.717.2805

some thoughts

criz's picture

The new d.o. design by Mark Boulton, as a grid design evangelist, is based on a 12 culomn grid. You can read more about this in the already mentioned Style Guids.

As every d.o. page layout has to follow this style guids it would be very helpful to provide a grid based theme, to assure consistency and accuracy.

Yes, there will be quite a number of people be involved in maintaining and extending d.o. IMHO another argument to reduce layout flexibility. If the theme just supports this 12-culomn-layout you have enough flexibility to create all various subpages, but it is also providing a framework for all themers and sitebuilders to get a site-wide consistent layout. And as Dries stated at the first redesign session in Cologne we will have to stick to MB's Style Guide, px for px. Makes sense of course.

I like Zen very much and have used it for various projects, but Zen is not capable of providing this flexibility limiting framework. So in my opinion we should think about using a grid based theme such as blueprint or 960.gs as starting kit or building a simular one from scratch. Maybe we can reuse some of the zen functionality though.

You also have to consider that this theme only will be used for d.o., it will be not the case that this theme has to be adopted in another way than specified.

And I totally agree to mortendk that using just blueprint is not the right decision. It is far too bloated and has some other limits. Personally, I like 960.gs more, not only because it has been built inspired by Mark Boulton's grid design articles. But maybe putting the best out of zen, blueprint and 960.gs and assembling our perfect d.o. theme this way would be a good idea? Anyway, looking forward to see mortendk's first theme setup proposal, rock on...

I agree with you 100% about

dvessel's picture

I agree with you 100% about maintaining consistency. The limits in this case is an asset. Without it, you can throw MB's style guide out the window and have another mess in a few years. There are many who have their own ideas on what is best which is great. I wouldn't use a grid framework in all situations but it makes a lot of sense here.

Cutting down 960.gs sounds like a good idea. It's specific to the site so that makes sense to me too.

But I personally don't understand how Zen would fit into this. It was inspired by the Zen garden where the markup is constant. It doesn't exactly fit into 960.gs. I don't know how John Albin expect to roll in a grid system but the only option I can see is having the style sheet grouped by styling rules instead of the selectors.

960 GS FTW

EclipseGc's picture

Having worked pretty extensively with 960 gs at this point (I'm one of those folks trying to get it into D7) I have to jump in at this point.

First off, let's talk about style. MB designed with a 12 column grid in mind, all his work is based off of it, and re-creating that within zen seems kind of obtuse frankly. If we'd like to reuse zen's markup, great, but I see no reason to custom build our own css file for this purpose. Furthermore, while I agree, a design DOES need the ability to breath... margins on the sides and between elements is what establishes that, and in this case we'll have plenty of both. Breaking from the wireframes to implement a liquid layout strikes me as a mistake, UNLESS we can maintain a grid, and the level of control we need, which is, I think, a discussion for another time.

960px constraints are MUCH easier to format properly for all screens, it's the current static width max based upon desktop resolution usage, and frankly, if 2 years from now we find that to NOT be the case, extending the grid to take up more space should be relatively painless.

Which brings us back to 960gs. 960 has both 12 and 16 column layouts. BP is built on a 24 column. With only the need for a 12 column layout, we could potentially delete all unnecessary css within the 960.css file and this would probably save us (my guess) 30-40% of the existing code. If MB provided a text.css for our usage already, that's a huge boon as it allows us to start adhering to more progressive enhancement workflow. Beyond that, 960 is laid out EXACTLY as the style guy is expressed (BP isn't from my understanding though I've not used it).

I'd just like to mention that 960 is really elegant. Using it has been a joy, and extending it shouldn't be difficult. dvessel has even implemented some improvements that will allow us content-first layouts within the grid system. I personally find that adding a simple class to a container (which we have access to virtually all of within a page.tpl.php file) is so easy for us to do. This doesn't affect our id tags, and is imo rather low impact (even on a complicated layout, we're looking at a single class in the main container for the site, and a single class for each pluggable region... in a 3 column layout we would have a class on the main container, header, footer, left, right, content for a total of 6 class declarations that are responsible for size, position, and consistency. This increases slightly for content first layouts, but again is extensible and easy to use.)

As an example of extending this further... if we take my 2 year screen resolution example, and assume the world jumps to 1280 in the next 24+ months as the defacto default, we can simply do the following math:

1280 - 20 px (for browser scrollbar etc) = 1260px
1260 - 240 (10 on each side, and 11x20px margins between columns) = 1020.
1020/12 (number of columns) = 85px.

85px would be our new base, extending MB's original style guide appropriately for our system. From there we simply update the existing classes to reflect this new base as necessary. Admittedly this takes a little bit of experimentation, but the upgrade is pretty easy and should easily scale to our next design (this would get hairy in the 2000-3000 px range, but I doubt we'll be looking at that any time soon, and liquid layouts have the same problems at these resolutions)

Anyway, I'd heavily encourage us to go with a slimmed down 960 to just 12 columns with the addition of the content first css work dvessel has already done, and I'd be happy to lend my knowledge here, though frankly, anyone good with css is going to figure this out is about 20-30 minutes.

Eclipse

Column Layout & Liquid

ceardach's picture

Column Layout & Liquid are not mutually exclusive. Here is an example of a liquid 12 column grid.

Supporting a column layout & custom roll are also not mutually exclusive. It is quite possible to build an extensible column layout that leaves the layout in the stylesheet, and keeps the HTML and its CSS classes and IDs to remain meaningful for its purpose, rather than its positioning.

Liquid grid layouts are

dvessel's picture

Liquid grid layouts are unreliable. I've tried working with that example and IE has large rounding errors. Try to compensate for it and the grid is thrown way off with gaps.

What versions of IE have the

mikeytown2's picture

What versions of IE have the rounding errors? Just tried the above link with 6 & 7 and didn't see any errors. IE 5.5 is dead http://www.w3schools.com/browsers/browsers_stats.asp

...

Jeff Burnz's picture

Better late than never... every version of IE has this issue, its called sub-pixel rounding, this explains it pretty well: http://ejohn.org/blog/sub-pixel-problems-in-css/

Just doing some background reading and catching up on old threads...

Absolutely, I'm just saying

EclipseGc's picture

Absolutely, I'm just saying that what MB designed was specifically to a 960 width layout. Changing that to a 100% layout (grid/columnar or no) I think is a mistake as it will require a not insignificant amount of work to do so, and will ultimately look quite different than what he designed. Just my opinion.

Eclipse

Designing to a grid != Requiring a grid-based CSS framework

gdemet's picture

I've seen a number of posts here arguing that we should use a grid-based CSS framework because the new Drupal.org was designed around a 12-column 960 pixel-wide grid, which is what 960, Blueprint, and other frameworks use.

The reality in my experience is that most professional designers design to a grid, but that doesn't mean that a grid-based CSS framework is always the right choice for building those sites, especially when you're dealing with something that needs to be as flexible as Drupal.org. Morten and others here have provided a lot of really good reasons why using one of these frameworks would be a bad choice for Drupal.org.

There have also been a number of arguments that it's not possible to implement a grid-based design in Drupal using Zen. I can tell you that this is categorically not true. We work with tons of interactive and graphic designers (including our own in-house team) who design to a grid, and we have never had trouble building any of those designs in Drupal using Zen.

As I said before, I think there is definitely a place for these grid-based frameworks, but I do not think that Drupal.org is one of them.

Just to make a quick comment

EclipseGc's picture

Just to make a quick comment back on that:

Simply because we're using a grid based layout doesn't mean we're locked into it, you could potentially build sections that are completely freeform/custom css controlled. I bring this up because in one instance (using an existing grid structure like 960) we get to perform with a net under us (so to speak). If we choose to do our own thing, each developer is responsible for learning anyone else's work and understanding how to implement it (instead of having a well understood system to begin with).

I know we could potentially build our own system that takes all our major regions, their sizes, etc using zen and makes this happen. It just seems like an awful lot of extra work imo. Furthermore, the only thing preventing us from using zen output right now is exchanging the 960.css for zen's typical layout css, and adding classes to the containing div, and all relevant regions. (which is like 5 minutes of work if I'm not mistaken) I'll try this shortly to prove it.

Eclipse

Liquid/fixed is already answered

Gábor Hojtsy's picture

The goal of the theme implementation is not to revisit questions answered by Mark. He already settled on a fixed width layout with given grids, image sizes, and so on. The stye guide I posted a link to before (accessible at http://infrastructure.drupal.org/drupal.org-style-guide/ and now also linked to from the group header) already has explanation on the grid to use, its width, etc. If you disagree with this, it should have been done months ago, when Mark asked for feedback. If you voiced your opinion back then, now go back to what he answered, or if he did not answer, look for other similar suggestions and looked at what he answered there.

The Drupal Association accepted this style guide, and we are about to implement what it says. If we are to debate on its findings and content then we'd not come to and end, so I'd like to call for the help of those, who can work with these goals, and for the others to find other places to contribute to Drupal instead of holding those back, who'd actually implement the redesign.

We could probably keep arguing for months on different parts of the theme, but please only do so where questions are left unanswered by Mark.

Please not Zen...

jeff h's picture

I'm honestly surprised to see Zen being thrown around as an option for the foundation theme for this. I've tried to like Zen, honestly — but I don't! :) Maybe I'm too purist or too minimalist or something, but inevitably on our projects I feel I can code a custom Drupal theme from scratch with far less "cruft" than what Zen introduces. On a theme as important as this one, surely we're not out to cut some corners in the interest of development speed?

I for one am a big fan of 960.gs, but even there I admit we're attempting to do something quickly by using something that probably provides a heap more code than we'd really need in the end. So I very much agree with those suggesting we use a "pared-down" 960.gs — let's take out all the classes that Mark B hasn't used in the design, and run with the rest.

If you're not familiar with 960.gs, check it out — a pared-down version wouldn't really leave us with any redundant code at all.

How many themers are needed? It seems to me that experienced themers should have no problems whatsoever picking up the concepts of a grid-system and/or working with an existing fully-custom theme, so Zen wouldn't really introduce any advantage in terms of themer availability? I've already volunteered myself and Josh who works with us at Marmaladesoul, so there's two to start with :)

Jeff

New d.o theme is 960.gs-derived

Todd Nienkerk's picture

The new d.o theme is based on a 12-column 960.gs implementation. All 16-column stuff has been pulled to streamline the CSS.

Todd Ross Nienkerk
Co-founder, Four Kitchens | IRC: toddross

Todd Ross Nienkerk
Digital Strategist and Partner
Four Kitchens: Big ideas for the web
IRC: toddross

Subscribing...

paganwinter's picture

Subscribing...