I was looking at the Omega 960gs theme, and came across the assertion that using it would preclude any need for using panels. After looking deeper into what the theme does, I'm fairly confident that while there is overlap, the theme doesn't do offer everything panels does. Not that it should...it -is- a theme.
I'm starting the conceptual design of a site that will be D7, with OG and Drupal Commerce and many other distinct sections, so a strong need for intelligent contextual layouts. I made a first-pass module list (stopped counting at 100), and of course it began with panels. The reading I did about Omega raised an abstract question... what considerations should there be when selecting a theme to use in conjunction with a site controlled by panels and panels everywhere in terms of what would make a theme work best with them, and what advanced layout capabilities (grid? dynamic regions?) would still be useful, and which would cause problems?
If there's a D7 theme that's minimal and clean that would behave better with panels than others...
Comments
Are there Panels optimized themes?
Given that Panels replaces much of what used to be required by manual themeing, it seems basic themes can be used quite effectively when designing with Panels by making the necessary theme mods quicker and more straightforward.
Starting with the assumption Panels is used as much as is practical (eg. using layout, CSS class, ID tags, etc.), what elementary theme elements do you feel are essential, which are nice to have, and which are superfluous?
What common theme simplifications are being made by heavy Panel users?
Have any Panels heavy designers published optimized themes?
Background
I'm D6 focused and now quite comfortable and sold that panels, panes, and associated features are sufficiently robust to greatly reduce the need for theme modifications. Panels can not control the entire page but it enables a great deal of customization to be done within Drupal.
It seems like a Panels optimized theme could be very stripped down primarily in the blocks area. Is it possible to have ONE block and everything defined in Panels? Of course, this is extreme and defines one bookend to having Panels do all the lifting. And not using Panels at all defines to other bookend.
Check Out
Take a look at :
Panels Everywhere(Panels takes over your whole site)
Precision: http://drupal.org/project/precision
and also NodeStreams Theme(NodeOne D6 Platform-panels driven) http://drupal.org/project/ns_theme
Fusion(http://drupal.org/project/fusion)
I also still use Fusion quite a bit, nice Skinr support, Superfish built in. Any theme can be used with Panels really, you can choose to disable Theme Blocks and Regions or leave them.
For Panels theming look into Skinr( http://drupal.org/project/skinr )- it's awesome-reusable skinsets, totally integrated with Panels. Topnotch themes(Fusion) has started some skinr theme snippets downloads: http://fusiondrupalthemes.com/snippets
Prevailing best practice on placement of custom markup code
Thanks for those excellent links. They hit at the heart of where I am considering moving my base toolkit and workflow approach to building Drupal sites. Skinr seems pretty popular but Panels Everywhere is hardly referenced which triggered some musing over what prevailing best practices address defining and applying custom markup.
Features enabled within Drupal such as Panels link CSS classes and ids to customized elements. Skinr takes that further and seemingly allows far greater definition of customized css elements from within Drupal. Panels Everywhere allows more definition and customization of layout from within Drupal and less need to dig into theme files.
Is there a strategic architectural movement toward having Drupal become the control for driving all layout, theme, and skinning; ultimately, arriving at the point where the majority of site building can be done without touching any of the theme files directly? Surely, there will always be cases where custom tweaks will be required but far less than what is done today.
Panels Everywhere is great,
Panels Everywhere is great, but most themes have to be altered to support it. If you're starting from your own base theme, then it's definitely worthwhile to make it PE compatible.
I'm not sure that I'd use Skinr over making custom Panels layouts and styles plugins. Sure if you're not using Panels then Skinr works with the Drupal block system, but if you're going full Panels then layouts and styles plugins allow greater flexibility, the ability to define html markup in addition to css, selective loading of css files, and a settings interface. Panels and Ctools plugins take more time up front to learn, but they're worth it.
for what it's worth
I'm glad you liked the links. I forgot to mention that the NodeStream theme is for the NodeStream Drupal Platform, but it is based off of Precision and would be worthwhile to take a look at as far as how things were implemented in Nodestream.
I think Brian brought up a great point and option: Panels Style Plugins. I am not a coder, other than what applies to design/theme and patching module code here and there. I came to Drupal from a designers perspective and quickly realized that I had to learn Drupal to design/theme in Drupal. I have never written a style plugin, so I am not one to ask about that. I have it on my "more things to learn" list that never ends:). I know Skinr is it's own Style option in Panels and when writing skins or skinsets you can define where it applies(block,view,panel pane, panel region, or all of them). I am not in any position to have an opinion or input on style plugins v/s skinr, or even using them both. I do think that alot of what you choose to do and why depends on many factors such as 1)what is my experience/comfort level 2)what type of site am I building 3)will this site likely evolve/grow on a continual basis 4)Am I maintaining it, how much is the client involved with managing the site and design etc... 5) Am I rolling out alot of similar sites and maintaining them and need to create a development environment where standard reusable design and code exportables are of upmost priority. I think these questions and others apply not only to choices in design, but also how the site is built. I also think everyone has there own preference and way of approaching things, which is a good thing. You can see it all the "design tools" available for drupal nowadays: Skinr, Sweaver,LiveThemer,Design Kit ....... Personally I think Skinr/Sweaver integration would be pretty interesting. I also remember reading someone's input that they wished Skinr would be implemented through Ctools Panels Style Plugins. and I think Sweaver is really cool, but sometimes it's easier for me just to write the css code myself, only because I am used to it, not because Sweaver isn't an awesome tool(because it is).
The same kind of v/s thing came up with Context v/s Panels, because it would be really nice to have 1 best way to do Drupal, but there is not. Now I love Panels, and I am familiar with Context, so if it had to be a choice I would choose Panels. But again, it's my preference, my comfort level, etc.. But there was a "Panels v/s Context Cagematch" Interview, which was great, because I think a lot of what came out of it was: what kind of site are you building and what is your approach? Development Seed expressed they wrote Context for use in conjunction with Spaces and Features because they primarily build web applications, not other things like community sites. they said they pull out the "big guns"(Panels) when it's needed on their projects. I also have seen companies choose to use both Panels and Context together. Panels is written with such flexibility in terms of design and layout(without sacrificing incredible functionality and unrivaled power) because it seems quite evident that Earl Miles has the designer as well as non-coders in mind. I don't know what else to say, other than give him a big "Thank you!"
I apologize for getting off topic, but my point is, sometimes there isn't a set in stone "best practice". Sometimes alot of different modules do a specific thing very well and you just have to find out what works best for you and what makes sense for the project. And when I say "what makes sense for the project" I also mean looking at the future of the site. A good example would be having a client who initially needs a 10 page brochure-ware site put up ASAP for a quick web presence, but you know they are making plans to expand the site, it's design, and it's features. A quick 10-page site could be thrown up with no Panels, no Context, just the yucky Drupal Block system and a basic template with a custom header and few css tweaks. But if you know the site will be growing, build it to be scalable from the get-go. Make every page a panels page, then you don't have to re-do it later. If you use Context, create the contexts, even those not initially needed. For design, go with Panels everywhere, write custom Style Plugins, start building some skinsets, create a Fusion subtheme(even it's initially a copy of acquia marina or acquia slate or whatever).However you want to approach it, but if you know your in for the long-haul, build it and design it for the long-haul.
Okay, I have been rambling far too long here. I hope it helps. Keep in mind, it's just an opinion. All I know is the more I learn, the more I realize how much I don't know:)
sorry:)
I noticed quite a few typos in my comment and had edited my comment. I apologize if everyone received multiple notifications.
learning more but knowing less
"Okay, I have been rambling far too long here. I hope it helps. Keep in mind, it's just an opinion. All I know is the more I learn, the more I realize how much I don't know:)"
The classic sign you actually know a lot more than you did before, of course a good thing. I've rummaged around the vast drupal "toolkit" just enough to sense a basic grasp of the various toolset groups and discovering and collecting the generally accepted workhorses.
Now I stumble across these tools that seemingly can replace many tools while doing more. The super toolkit of Panels, Panels Everywhere, and panels style plugins seems a very powerful set of capabilities. Personally, I feel more comfortable using fewer tools and knowing them better, as my overall proficiency and productivity is greater than using a broader tool palette while struggling more each one. For example, when I did not know Photoshop much, I had a bag of point tools to do various things and always thought PS was overkill for doing simple things like resizing a picture. Over time, as I developed basic competency with PS, it is nearly the only tool in the box because I can do so much more with a single tool since it is so familiar.
One of the subjects I still search for constantly is drupal best practices. Although I agree there are many tool and techniques to accomplish tasks and each person develops their own style and approach, there are common experiences which collectively make up a general set of best practices: things to do which generally have proven to work well and things to avoid which generally turn out poorly. This is a subject to itself but good to know that Panels and related tools are likely in the green check list. thx
great point(s)
Good analogy with PS. I do have a standard set of mods that I use on every site(Panels is one of them), and a whole other list of ones I make available to all my sites in the case the need arises in the future. I guess I was making the assumption that since Panels is the topic, that for a D6 site, that at the very least CCK(in D7 core) and Views are being used. Also Filefield, Imagefield, and Imagecache-(in D7 core as well).These are great examples of modules that I think everyone could agree no Drupal site should be built without. There are modules that provide the same functionality and I have a definite preference of one over the other. An example: Node Relationships over Nodereferrer modules. But then again, I am sure that there is someone else out there who could present an argument for the opposite. As far as site building(D6) I prefer not to use the body "field" on content types, but instead create a separate CCK text area field.That concept was taken into D7 with everything being a core cck field.
On the topic of using less modules and employing modules that do more, I think Rules is another perfect example. There is so much that can be accomplished with Rules that can actually replace the use of some other modules, or forgo the need to customize(extend features) of existing ones.
Also I agree that taking the time and not being afraid of the learning curve is important. For me a great example would be Panels and Views and utilizing all they have to offer. Getting a good handle on views arguments and relationships. Utilizing Panels Views Content Panes and panels fields. Using views modules: VBO, Views Slideshow, Draggable Views, Semantic views, etc..Yes, it's a learning curve, but the flexibility, power and huge time-savers they are make it not only worth it, but I personally feel essential. I would also highly suggest the Features module and Strongarm.
and yes there are definitely things to avoid, like using the core drupal block system as is:). I think that's a perfect example of a general consensus no matter how anyone approaches things:)
If it would be of any help to you, I could post a list of my personal top modules. Some could be considered "can't live without"(i.e. the simple yet necessary, admin role for D6), some are for specific purposes depending on the type of site and functionality(i.e. og,user-relationships,ubercart...), and some I am sure could be debatable, again depending on preference.
There are also incredible resources out there for learning all facets of Drupal. Video Tutorials from NodeOne, Mustardseed Media, GotDrupal, Lullabot, Drupalcon(s) videos. For module development training: BuildAModule.com. All great resources. It's definitely worth watching hours of video and initially getting your brain fried:)
Again, if there is anything I can do that would be of any help to anyone, please let me know. That's the reason I posted on the topic to begin with. I think this is the first time I ever went into a big dialogue on things.
Thanks, all, for the useful
Thanks, all, for the useful dialogue. It was helpful to get others' perspectives on things. I feel like some thoughts such as the notion that it is important to do what works best for you, given the kind of site you are and will be building, are explicit forms of things some people have said to me that indicate those might be best practices. It's nice to hear them reiterated across a couple more people. Anyway, I found this thread due to seeking out a comparison of Versatile vs. Precision, but is a useful thread nonetheless. Thanks again!