Rather than request a new feature everytime I come up with a new concept I wanted to start a more helpful discussion to see how designers and developers work or the processes people go through when creating a theme and why they choose one design over another.
As a Graphic/Web Designer the kind of things that don't get thought about at a concept/PSD stage(not immediately) are things like: rounded corners, drop shadowing and ribboning, the sole purpose is to make it look pretty! The mentioned are then the trickier parts of coding when the concept moves to the first development stages. They are achieveable and in most cases image fallback can be used for older browsers that don't support some of the mentioned CSS3 features but can be a bit of a pig to workaround especially with Drupal's block structureshudder.
In Omega beta3 the first/last and odd/even classes were added which was a feature I asked Jake to implement as I am currently working on a theme that when finished will be contributed, one problem I was having was the ability to add a certain type of styling to blocks in the first and last regions only which has now become viable. I'm sure I will use this feature again many times in the future and I'm sure any designers coming to Omega will as well.
So that takes care of one issue, but what about the others? Is Omega capable of being a CSS3 viable solution? Will adding more classes fix the issues or will it make the base theme bloated?
I have been pondering all of the above for the last few days since initially coming up with the idea for my subtheme and I've also been paying attention to the lack of designers using Drupal and the groups that are trying to make Drupal more approachable to Graphic artists/designers.
Omega is a great tool and could be the thing that could make Drupal more approachable for designers, but because of how Drupal internals work I'm wondering how issues like rounded corners can be overcome with Omega.
I'd love to hear peoples thoughts on using Omega for really "out of the box" designs and whether there are ways around what I've mentioned by adding anything to Omega's base theme.
Comments
Supporting old browsers and poor methods...
Andy,
Great post. Very thought provoking. I look at it this way... and take some of it with a grain of sand as Omega is my baby.
I think some of the issues you touch on are something that ALL designers/themers/site builders have to deal with on each project/client. I have a very different perspective on some of this as I came first from the development side of things, then moved into the design/theme framework side in order to restore my sanity and invoke my creativity as often as possible.
When I work on a design that I know is going to be in Drupal (only thing I do these days of course) I have two advantages over some designer/themers.
I find that the above two items (mainly the first) are the limiting/troubling factors in ANY project, regardless if it's a client project, or a contributed project. I will speak first on a couple client projects I've recently worked on.
On one project (and another kicking off now), I did a theme project for a tech group that runs many web properties, and has been using Drupal for many years. Their designer is well versed in Drupal's abilities, thanks in part to the great development team they have conveying the limitations, the items where "it's not worth the time to do that", and the designs remain consistent between their sites to keep their theme budgets on projects within reasonable limits.
On one project, I worked with a client that hired a 3rd party design shop to build out a fantastical design for a website... notice what I said there... "a fantastic design for a WEBSITE".... The design group "claimed" to have used Drupal for quite some time, and also use the 960 grid. However, when designs came back (and I'm talking about like 15 rounds of revisions and 5-8 unique designs for sections of the site) the comps had SO many features implied that Drupal does not provide out of the box, the grid method was broken at best, and the project turned from what should have been an 80-100 hour design implementation into additional development on the backend, and advanced theming to even come close. The design was beautiful, and well thought out, but it had nothing to do with Drupal, and caused the client MANY headaches because of such.
That hits my first point of "understanding Drupal's core capabilities".
Now onto the dead technologies... I will NEVER work with a client that requires IE6 support... that is just a fact... I will probably be laughing as i hang up the phone. IE7 to me is almost as bad.... if not worse in some ways... And since IE8 is final, and IE9 is in beta (i think) I refuse to even really care about IE7. Now don't let me get to focused on Internet Exploder as that's not the primary issue here.
When it comes now to implementing cool new CSS3 features like text-shadow, box-shadow, border-radius (rounded corners), etc. I feel this way and will NEVER waiver from it unless a client is willing to pay almost triple my normal rate to implement in old browsers/technologies.
Rounded Corners, for example are nothing but a little touch of "fluff" at the end. In my designs, sometimes I include them, sometimes I don't depending on the client/project. I will implement ALL rounded corners with CSS3, taking me all of 5 minutes to get in place and working in the modern browsers. I will then explain that it could take a FULL day or even TWO to implement rounded corners in all browsers using an archaic method (the 4 div wrappers). Usually a client goes.... "okay, it's not worth 20 hours for everyone to see rounded corners". I feel the same way on ANY of the CSS3 techniques that can be implemented for some awesome effects.
Rather than taking all the time to write div wrappers around everything (blocks, nodes, regions, etc.) to give IE/Opera users rounded corners, I prefer the one CSS declaration to give it to those that have the "good stuff".
Personally, the way I work... I don't think most of your issues/points relate directly to any one theme... I think this could be said with Fusion, AT, and Omega...
Because of my long time working with Drupal, and my passion for clean designs and the theme layer, I can overcome any single issue in a theme usually with a little fancy CSS and maybe a line or two of code added in my subtheme if it pushes outside of core functionality, and needs to have some backend interactions.
My most important thing when creating my own designs is this: I understand for each tiny little item I put in a PSD, EXACTLY how I'm going to build it already. Not everyone has that ability, or understanding of how Drupal works, and what it's possibilities and/or limitations might be. It's a slippery slope, no doubt.
I'd definitely like to see this thread go on a little... and I hope I didn't hijack it and take it another direction, but I think my reply points to where I see the problems with implementing designs and overcoming some items.
Jake Strawn (@himerus)
ThemeGeeks | Development Geeks
Omega - 960.gs
Definately a worthwhile
Definately a worthwhile response.
Without breaking away from the initial idea of this discussion the industry generaly still has a big chunk of users still on IE6/7 and will do for some time, most government authorities still use these browsers as the inhouse developed software they use will cost too much to update so why change? This is the reason why I still haven't found one website being used by a government authority that "breaks away" from the normal mundane recantgular shell design.
Maybe I should employ your "take it or leave it" approach, why develop future technologies if people aren't going to use them right?
Back on topic though, Omega so far has been a pleasure to work with and as a designer I am finding it to be a great asset to my toolset, so much an asset that I'm rebuilding my current clients sites with it that was nearly finished, it's taken half the time to do so!
More opinions please!
I'm gonna start digging my heels in...
I've only been at this (web design) for a few years. And even less time with Drupal. But i'm finally coming around to a mindset where--the web is the future, so we should BUILD for the future.
I've spent an awful lot of time trying to please clients who want to have pretty designs, AND have them work on older browsers. And the one thing that is consistently true is that the process always takes too much time for ultimately inferior results... The site may look good, but the hacks and workarounds are compromises that undermine the function of the site. And the time spent working these "solutions" out is time lost to better, more interesting design.
So i'm with Jake on the forward-looking approach. With all that is happening with new devices/platforms, it just makes good sense to push the newer technologies and try not to look back. I just wish is was an easier sell with clients.
As far as development goes, I always start with the framework and design to that. With a good grid system like 960, there's little-or-no limit to what you can do. (I also favor clean, uncluttered designs that make it easy to use the content. Happily, those designs are easier to implement).
Roger
_________________
Art has gone to the dogs
GoodeGallery.com
A compromise ...
The approach I have is that I would want to make sure that people can at least VIEW the website in older browsers. But if they want pretty? Get a descent browser. Mainly for the reason Andy mentions, a lot of people are forced to use older IE at their work. And I still want them to see my site, and come back to it when they get home in the evening to watch the pretty :)
This still takes some effort, it's really easy to screw up IE6-7. So if Omega at least could provide that out of the box, and I think it has until now, then I would be quite happy.
And as for all the nifty stuff CSS3 brings: support is still lacking in other browsers as well: http://caniuse.com
I had the same issue, so I
I had the same issue, so I added this JS http://code.google.com/p/css3-mediaqueries-js/ to make it work with IE.
working with @import stylesheets....
I have looked at this code before, but how does it work with the @import stylesheets in D7??
the way the 3.x version is working is like this:
<style media="all and (min-width: 740px) and (min-device-width: 740px), (max-device-width: 800px) and (min-width: 740px) and (orientation:landscape)" type="text/css">@import url("http://omega3/sites/all/themes/omega/alpha/css/grid/default/narrow/narrow-grid.css?ljv2qw");
@import url("http://omega3/sites/all/themes/omega/alpha/css/grid/default/narrow/narrow-12.css?ljv2qw");
</style>
Now (unlike my test in 2.x omega) the media query is NOT in the actual CSS files that were @imported, instead, they are grouped by the media query, and then take effect as they would with the media query inside the CSS file(s).
Can you verify this script works/would work with this setup? If so, I'll reinvestigate, and include this in the package.
Jake Strawn (@himerus)
ThemeGeeks | Development Geeks
Omega - 960.gs
I am using the 2.x test with
I am using the 2.x test with media queries from github, and have not tried the 3.x version. I did not want to retheme. I can try it out on the next project.