Related
I run a design firm and have frequent need for Drupal development. I'm looking for a bit of guidance on a Drupal workflow that will work best for my company.
My experience working with Drupal developers in the past has been great for back-end development, and chaotic for front-end development. Projects end up with multiple and inconsistent CSS styles, and doing quality control on the visual aspect is very time-consuming.
Moreover, I'm a front-end coder, and use HMTL/CSS/JS prototypes for all phases of projects. I would prefer if the front-end coding I do to was used by the developer instead of going to waste.
However, this workflow hasn't been compatible with Drupal dev partners so far. Because they use themes, and retro-fit them to the design I give them, they aren't able to use the HTML/CSS/JS work I do. Moreover, I have a responsive framework that I like (Foundation), and my developers want to work with the standard responsive Drupal theme (Omega). I don't like Omega because it isn't fluid.
Then there's things like my developer telling me they can't do a carrousel that uses CSS (background-image), because the available Drupal carrousel modules are all based on using the HTML img tag. Does everything have to be based on modules?
Going back to the HTML/CSS inconsistencies and the time-consuming design QA, I think this comes from trying to retrofit a theme. The code is very messy and it makes it hard to target elements for styling. It also makes it impossible for me to do my own CSS changes if I want.
So, in short, I'm looking for a completely different design workflow, and I'm looking for feedback on whether it's workable in Drupal without inflating costs.
Is it possible in Drupal to use front-end code (provided by me), throw in some PHP tags, and end up with cleanly-coded pages, instead of relying on themes? Would this reduce costs (because the HTML/CSS/JS is provided), or would it inflate costs (because it's easier to use a theme)? Are there any security issues involved? Are there update issues involved? In short, what's the big advantage with working with pre-fab themes?
I really, truly appreciate your comments.
We usually develop from the backend to the front end. Modules like Views add many div tags, classes and tags so the theme developer can make better use of them and fine tune the design.
I do not think that is a "messy" code unless you are doing all of the work in tpl.php files.
Modules simply processed the data. It should not heavily theme the output. For a better understanding, see the image below (from drupal.org):
If you want to do any database intensive work in the template level, you will have to load many stuff again that you could simply do in a module.
In my opinion, if your developer is not hardcoding the HTML stuff, he is doing it right.
Keep in mind that you can override most of the theme functions so you already have the flexibility if you want.
Is it possible in Drupal to use front-end code (provided by me), throw
in some PHP tags, and end up with cleanly-coded pages, instead of
relying on themes?
Yes. But you can't simply use slider-image.php like files for that. You will have to add necessary theme functions to and pass the variables to it. IMO, it's relatively more work if you need to completely rewrite the theming functions.
Would this reduce costs (because the HTML/CSS/JS is provided), or
would it inflate costs (because it's easier to use a theme)?
I do not think so. If you have multiple backend developers working on code, ask the theming team to make changes to HTML/CSS. CSS can make your site look worse, and a security bug can ruin your business, expose all your user information or even worse.
Are there any security issues involved?
Most likely. Default theme functions tend to come with much better security. Even though few bugs come out, they will get fixed soon by the community.
Are there update issues involved? In short, what's the big advantage
with working with pre-fab themes?
Because there is a whole lot of work that you can simply adopt. That will also block you from adopting others' CSS work though.
I work somewhere with highly stylized well thought out front end builds which are almost not compatible with the way Drupal theming is handled currently. Having front end developers track down bugs is also very problematic. It looks like there's some acknowledgement of this in Drupal 8 at least. At this point we frequently rework Drupal to work as an API and then build a lightweight PHP Framework app on top to pull content when we need it which gives us total flexibility to do anything we want with the frontend. Another alternative is to checkout Expression Engine where you are explicitly telling it what markup you want outputted and how you want your content to be placed in the markup.
The holy grail would be a very lightweight layer that was part of Drupal where we could use Twig to pull the content the way we want it and all HTML output was defined in Twig.
I'm designing an HTML newsletter that is supposed to load nicely including on mobile devices.
I found these links to sites that show blank templates:
http://www.emailology.org/
http://htmlemailboilerplate.com/#f2
But with both I didn't succeed in showing responsive design on my mobile Android 2.3.3
Does someone have a live example for such responsive email, so I can learn from it?
I tried to look for one on the web but couldn't find one...
Reading up on responsive HTML emails my self, I stumbled upon your question. Even though a bit late, I though I'd take the time to share what I've found so far.
I've found a couple of good resources to read, both provided by email newsletter web services.
Campaign Monitor provide a pretty extensive guide on how to design responsive HTML emails. It discusses different approaches to take, things to think about and shows a few handy "hacks". In the guide, they also reference a few downloadable examples of responsive emails that you can use as a starting ground, and build your own email upon.
MailChimp also has a guide on email for mobile devices. It has a broader focus and discuss everything from statistics to user behavior and best practices, but it also has a section on various design approaches.
To get live examples to learn from, I suggest you sign up for newsletters by some of the major companies, that has spent time on developing their newsletters. I'm not going to market any company in particular, but I know that both above referenced guides mention a few companies that they think have great HTML newsletters, that could be worth having a look at.
HTML emails are a different beast all together. There are a couple of websites dedicated to having HTML clients support standard markup, but that day is not anywhere close to becoming a reality. I doubt many email clients (if any) support the media queries needed for responsive CSS to work. My suggestion would be to make an HTML email template that is adaptable enough to work at a mobile resolution and still look good in an normal desktop resolution. Maybe some liquid widths.
For help with which clients support what and how well the support HTML / CSS features, check these two links out.
Email Standards Projects
Campaign Monitor Email CSS Support
I have a superb solution for this issue. Solution is that - you can opt to create HTML email newsletter using fluid technique. I mean that you should build it in percentages - so that all the devices out there can fit your email.
I have a tutorial on creating: Fluid responsive email newsletter.
Hope this helps many people out there.
Thanks!
Sumesh M.S
I have a form that needs to be emailed. I am currently using a table design and wanted to make it look better so decided to use css. I am really concerned about the fact that not all clients will handle css so I wanted to get some advice. If anyone of you had to email a form, how might you handle it? It pretty much needs to be rock solid, well, for I'd say at least 95% of the email clients out there, including yahoo and gmail. I already know that gmail strips the css out of the form. I am using rounded corners in this form and unfortunately inline css is not an option because of the sequence that the css needs to be in.
Please offer me some advice before I begin this journey. Thanks.
EDIT:
Inline css is not an option with the form I currently designed but could be an option for a different design that allows rounded courners.
The best advice for designing and building HTML for emails if you want "rock solid" as you say is to pretend you are living in 1997 and use <table>, image slices, and even the dreaded <font>.
Some CSS is supported, as seen in this chart of compatibility across different email clients at the Campaign Monitor site. The biggest hit is that if you have any users on GMail, inline CSS is your only option as GMail strips all <style> tags.
As far as the rounded corners go, you will have to use images.
Unfortunately, HTML support in email clients isn't at all standardized. If you're aiming to hit the majority (your 95%) of users, you're best off designing the email form using tables (without rounded corners...unfortunately it's not going to look great). Taking that approach with get you the widest supported user base.
Unfortunately there's a trade-off of good looks versus compatibility. You just have to decide which is more important.
I agree (and voted for above): The table with images circa 1997 is what I would recommend.
I may be mis-reading it a bit, but I'd push back a little bit on the "email a form" requirement. Emailing forms and expecting them to work at all is optimistic, if not unrealistic.
First, you may have problems getting form elements to display in email clients. I tested forms in email a couple years ago, and I can't remember whether it was the form tags that were removed, or the actual input elements. That was when I talked my client out of it.
If you can get the form to display, where is it going to submit to? Is the email client really going to allow this? What are you going to do if there are form validation errors? How does that work?
I know people have done this, but it will be an uphill battle. It seems like what is much more common is to provide links to web pages with forms. Perhaps you can provide customized links that get people through filling out most of the form (pre-filling email addresses, etc.), but have the actual form submit happen from a web page.
Good luck!
So just write the stylesheet in the page? Or is that not possible for some reason?
Images maybe not be be loaded though [automatically], and that's for the clients benefit, so depending on how you do your design, you may like to think that over.
I'm looking for best-practices for designing a site that with accessibility in mind. The site is going to have a lot of older and less-abled individuals visiting it, and I want to make it as friendly for them as possible. Is there a resource that describes all the right tags, and attributes to use?
There are many many resources depending on your goals.
Strongly suggest you start with:
Section 508 (US legislation, obviously US centric though)
W3C's Web Accessibility Initiative and Web Content Accessibility Guidelines
edit:
Forgot to mention that WCAG has come in for some considerable criticism which makes this guy's efforts very helpful.
Also wanted to add, from personal experience, to remember that WA doesn't mean "blind people with screen readers". There are all manner of access limitations which you have to think of as well: e.g. dexterity issues related to e.g. muscle control, unusual input devices, and simple screen magnification.
Good luck!
Here's a quick list I tend to follow
Ensure it uses clean XHTML markup ideally to AAA standards,
Try where possible to spilt HTML, CSS, Javascript into respective files,
Create different style sheets for print, screen, etc.,
Ensure you take into consideration colours and fonts for the hard of sight and colour blindness,
Try to only place the main navigation at the top of the code so that the actual content appears near the top of the code, this way people do not have to scroll to far to see the content especially if they are using a screen reader / low res,
If you do have a lot of navigation before the content then place a link near the top allowing users to skip to the content,
Ensure the very first link on the page is to a text-only / low graphics version of the site,
Ensure ALL pages and all Essential functionality will work without JavaScript turned on,
There are lots of plugins for firefox to assist with development including:
Web Developer
No Script
HTML Validator
Firebug
Ensure the page renders across all browsers including old ones even if that means it works though does not match design exactly.
Ensure HTML, CSS, JavaScript is kept to the minimum file size to aid downloading times e.g. Remove white space and blank lines,
Always use LABELS in forms and alt, title tags in links and images,
Only use Tables for tabular data and ensure data appropriately labelled,
Where possible do not use JavaScript to write content to a page but use CSS to hide it, that way is JavaScript is disabled or does not work properly then content will still appear,
Always ensure you use onkeypress as well as onclick events in JavaScript encase the user can not / is not using a mouse.
Finally if you have to use blank images on a page for tracking etc. then don't give them Alt tags. This is my own view and is one which is hotly debated on-line especially when 1x1px images used to be used for spacing. However as far as I see it, if you are using a screen reader then you don't what it reading out stupid comments for images it does not need to see.
Try looking at Wikipedia's article on Web Accessibility. It contains lots of links to various sources of information for different countries, which may be useful depending on your target audience. The W3C was one of the original standards, but has plenty of critics.
Among other things.. provide "alt" and "title" attributes for every "img" tag.
Get a text-only browser like lynx. If your site works in lynx, it's likely to work for people who need screen readers or have other handicaps. It's no substitute for looking up the regulations, but it's a quick and easy check.
For another perspective, see the Dutch Government Web Guidelines.
The government provides a standard called section 508 that lays out what makes a site compatible.
A good resource is found at W3C site: Web Content Accessibility Guidelines.
A few things to keep in mind:
have a CSS link on each page that easily allows the font size to be changed.
Visually try to have appropriate presentation that is easy to read in a backwards S fashion.. left to right, back down.. etc..
ensuring that all the alt tags, etc, as mentioned in the other responses is vital.
see if there are some disability websites out there that specialize in testing your site. no harm in seeing what they list as being important to do.
make sure things are easy to read and find. this alone will make the job much easier.
There are many many resources on this topic. In fact, the danger is of information overload, rather than not enough information.
But an alternative approach is to think about your HTML page in generic terms, rather than the visual output you see in the web browser. If you wrote a piece of software that interpreted the website what would be helpful? This is a round-about way of saying use good semantics. My top tips would be to use standard XHTML for content and CSS for design. Also look up topics such as "progressive enhancement" and "behavioral Javascript".
But for resources:
The W3C's Web Accessibility Initiative: www.w3.org/wai
www.WebAIM.org
www.Accessify.com
www.CSSZenGarden.com for inspiration on how semantic markup can be styled to look very different.
It hasn't been mentioned yet so I figure I would mention it. If you want blind users to be able to use your site avoid flash. At the most 1% of flash I find on the internet is accessible.
A good list of resources about accessibility (colourblind screen-reader,typography etc) is here in design way.
For validation of web site and general documentation I use the W3C.
If you're developing in asp.net the opensource NAAK tool might be useful.
A must read is Jeffery Zeldman's "Designing with Web Standards"
Not sure if you are using Dreamweaver, but he has also just realeased a toolkit to validate your site for accessiblity.
It seems like every time I try to create a pure CSS layout it takes me much longer than if I'd use a table or two. Getting three columns to be equal lengths with different amounts of data seems to require particular fancy hacks, especially when dealing with cross-browser issues.
My Question:
Who are these few tables going to hurt?
Tables seem to work particularly well on tabular data — why are they so reviled in this day and age?
Google.com has a table in its source code, so do many other sites (stackoverflow.com does not by the way).
Since this is stackoverflow, I'll give you my programmer's answer
semantics 101
First take a look at this code and think about what's wrong here...
class car {
int wheels = 4;
string engine;
}
car mybike = new car();
mybike.wheels = 2;
mybike.engine = null;
The problem, of course, is that a bike is not a car. The car class is an inappropriate class for the bike instance. The code is error-free, but is semantically incorrect. It reflects poorly on the programmer.
semantics 102
Now apply this to document markup. If your document needs to present tabular data, then the appropriate tag would be <table>. If you place navigation into a table however, then you're misusing the intended purpose of the <table> element. In the second case, you're not presenting tabular data -- you're (mis)using the <table> element to achieve a presentational goal.
conclusion
Whom does this hurt? No one. Who benefits if you use semantic markup? You -- and your professional reputation. Now go and do the right thing.
Like a lot of things, it's a good idea that often gets carried too far. I like a div+css driven layout because it's usually quite easy to change the appearance, even drastically, just through the stylesheet. It's also nice to be friendly to lower-level browsers, screen readers, etc. But like most decisions in programming, the purpose of the site and the cost of development should be considered in making a decision. Neither side is the right way to go 100% of the time.
BTW, I think everyone agrees that tables should be used for tabular data.
In the real world, your chances of taking one design and totally reskinning it without touching the markup are pretty remote. It's fine for blogs and concocted demos like the csszengarden, but it's a bogus benefit on any site with a moderately complex design, really. Using a CMS is far more important.
DIVs plus CSS != semantic, either. Good HTML is well worthwhile for SEO and accessibility always, whether tables or CSS are used for layout. You get really efficient, fast web designs by combining really simple tables with some good CSS.
Table layouts can be more accessible than CSS layouts, and the reverse is also true - it depends TOTALLY on the source order of the content, and just because you avoided tables does not mean users with screen readers will automatically have a good time on your site. Layout tables are irrelevant to screen reader access provided the content makes sense when linearised, exactly the same as if you do CSS layout. Data tables are different; they are really hard to mark up properly and even then the users of screen reader software generally don't know the commands they need to use to understand the data.
Rather than agonising over using a few layout tables, you should worry that heading tags and alt text are used properly, and that form labels are properly assigned. Then you'll have a pretty good stab at real world accessibility.
This from several years experience running user testing for web accessibility, specialising in accessible site design, and from consulting for Cahoot, an online bank, on this topic for a year.
So my answer to the poster is no, there is no business reason to prefer CSS over tables. It's more elegant, more satisfying and more correct, but you as the person building it and the person that has to maintain it after you are the only two people in the world who give a rat's ass whether it's CSS or tables.
Using semantic HTML design is one of those things where you don't know what you're missing unless you make a practice of it. I've worked on several sites where the site was restyled after the fact with little or no impact to the server-side code.
Restyling sites is a very common request, something that I've noticed more now that I'm able to say "yes" to instead of try to talk my way out of.
And, once you've learned to work with the page layout system, it's usually no harder than table based layout.
I'm of the thought that CSS layout with as few tables as possible is cleaner and better, but I agree that sometimes you just gotta use a table.
Business-wise, it's generally "what's going to get it done the fastest and most reliable way." In my experience, using a few tables generally falls into that category.
I have found that a very effective way to mitigate cross-browser differences in CSS rendering is to use the "strict" doctype at the top of your page:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
Also, for the dreaded IE6 CSS issues, you can use this hack:
.someClass {
background-color:black; /*this is for most browsers*/
_background-color:white; /*this is for IE6 only - all others will ignore it*/
}
The main reason why we changed our web pages to DIV/CSS based layout was the delay in rendering table based pages.
We have a public web site, with most of its users base is in countries like India, where the internet bandwidth is still an issue (its getting improved day by day, but still not on par). In such circumstances, when we used table based layout, users had to stare at a blank page for considerably long time. Then the entire page will get displayed as a whole in a tick. By converting our pages to DIV, we managed to bring some contents to the browser almost instantly as users entered to our web site, and those contents where enough to get the users engaged till browser downloads entire contents of the page.
The major flaw with table based implementation is that, the browser we will show the content of the table only after it downloads the entire html for that table. The issue will blow out when we have a main table which wraps the entire content of the page, and when we have lots of nested tables. For the 'flexible tables' (those without any fixed width), after downloading entire table tag, browser has to parse till the last row of the table to find out the width of each columns, then has to parse it again for displaying the content. Till all these happens users has to stare at a blank screen, then everything will come to screen in a tick.
If you have a public facing website, the real business case is SEO.
Accessibility is important and maintaining semantic (X)HTML is much easier than maintaining table layouts, but that #1 spot on Google will bring home the bacon.
For example: Monthly web report: 127 million page views for July
Monthly web report: 127 million page views for July
...
Latimes.com keeps getting better at SEO (search engine optimization), which means our stories are ranking higher in Google and other search engines. We are also performing better on sites like Digg.com. All that adds up to more exposure and more readership than ever before.
If you look at their site, they've got a pretty decent CSS layout going.
Generally, you find relatively few table layouts performing well in the SERPs these days.
Keep your layout and your content separate allows you to redesign or make tweaks and changes to your site easily. It may take a bit longer up front, but the longest phase of software development is maintenance. A css friendly site with clear separation between content and design is best over the course of maintenance.
One other thing I just remembered, you can assign a different stylesheet to a page for printing vs. display.
In addition to your normal stylesheet definition, you can add the following tag
<link rel="stylesheet" type="text/css" media="print" href="PrintStyle.css" />
Which will render the document according to that style when you send it to the printer. This allows you to strip out the background images, additional header/footer information and just print the raw information without creating a separate module.
doing a complete revamp of a 15 page web site just by updating 1 file is heaven.
This is true. Unfortunately, having one CSS file used by 15,000 complex and widely differing pages is your worst nightmare come true. Change something - did it break a thousand pages? Who knows?
CSS is a double-edged sword on big sites like ours.
In my experience, the only time this really adds business value is when there is a need for 100% support for accessibility. When you have users who are visually impaired and/or use screenreaders to view your site, you need to make sure that your site is compliant to accessibility standards.
Users that use screenreaders will tend to have their own high-contrast, large-font stylesheet (if your site doesn't supply one itself) which makes it easy for screenreaders to parse the page.
When a screenreader reads a page and sees a table, it'll tell the user it's a table. Hence, if you use a table for layout, it gets very confusing because the user doesn't know that the content of the table is actually the article instead of some other tabular data. A menu should be a list or a collection of divs, not a table with menu items, again that's confusing. You should make sure that you use blockquotes, alt-tags title attributes, etc to make it more readable.
If you make your design CSS-driven, then your entire look and feel can be stripped away and replaced with a raw view which is very readable to those users. If you have inline styles, table-based layouts, etc, then you're making it harder for those users to parse your content.
While I do feel that maintenance is made easier for some things when your site is purely laid out with CSS, I don't think it's the case for all kinds of maintenance -- especially when you're dealing with cross-browser CSS, which can obviously be a nightmare.
In short, your page should describe its make-up in a standards compliant way if you want it to be accessible to said users. If you have no need/requirement and likely won't need it in the future, then don't bother wasting too much time attempting to be a CSS purist :) Use the mixture of style and layout techniques that suits you and makes your job easier.
Cheers!
[EDIT - added strikethrough to wrong or misleading parts of this answer - see comments]
The idea is that Designers can Design and Web Developers can implement. This is especially the case in dynamic web applications where you do not want your Designers to mess around in your Source Code.
Now, while there are templating engines, Designers apparantly just love to go crazy and CSS allows to pull a lot more stunts than tables.
That being said: As a developer, i abandoned CSS Layout mostly because my Design sucks anyway, so at least it can suck properly :-) But if I would ever hire a Designer, I would let him use whatever his WYSIWYG Editor spits out.
Business reason for CSS layout: You can blow away the customers by saying "our portal is totally customizable/skinnable without writing code!"
Then again, I don't see any evil in designing block elements with tables. By block elements I mean where it doesn't make any sense to break apart the said element in different designs.
So, tabular data would best be presented with tables, of course. Designing major building blocks (such as a menu bar, news ticker, etc.) within their own tables should be OK as well. Just don't rely on tables for the overall page layout and you'll be fine, methinks.
*I would let him use whatever his WYSIWYG Editor spits out
I just threw-up a little...
*ahh hello? You don't think the graphic designer is writing the CSS by hand do you?
Funnily enough I have worked with a few designers and the best among them do hand-tweak their css. The guy I am thinking of actually does all of his design work as an XHTML file with a couple of CSS files and creates graphical elements on the fly as he needs them. He uses Dreamweaver but only really as a navigation tool. (I learned a lot from that guy)
Once you've made an investment to learn purely CSS-based design and have had a little experience (found out where IE sucks [to be fair it's getting better]) it ends up being faster I've found. I worked on Content Management Systems and the application rarely had to change for the designers to come up with a radically different look.
Besides being easily updatable and compliant...
I use to design all table based web sites and I was resistant at first, but little by little I moved to CSS. It did not happen overnight, but it happened and it is something you should do as well.
There have been some nights I wanted to toss my computer out the window because the style I was applying to a div was not doing what I want, but you learn from those obstacles.
As for a business, once you get to designing web sites by CSS down to a science, you can develop processes for each site and even use past web sites and just add a different header graphic, color, etc.
Also, be sure to embed/include all reusable parts of your website: header, sub-header, footer.
Once you get over the hump, it will be all down hill from there. Good luck!
:: nods at palmsey and Jon Galloway ::
I agree with the maintainability factor. It does take me a bit longer to get my initial layouts done (since I'm still a jedi apprentice in the CSS arts) but doing a complete revamp of a 15 page web site just by updating 1 file is heaven.
Some additional reasons why this is good practice:
Accessibility - the web should ideally be
accessible by all
Performance - save
bandwidth and load faster on mobile
devices (these lack bandwidth to some
degree and cannot layout complex
tables quickly). Besides loading fast is always a good thing...
When a screenreader reads a page and sees a table, it'll tell the user it's a table. Hence, if you use a table for layout, it gets very confusing because the user doesn't know that the content of the table is actually the article instead of some other tabular data
This is actually not true; screen readers like JAWS, Window Eyes and HAL ignore layout tables. They work really well at dealing with the real web.
I don't think there is a business reason at all. Technical reason, maybe, even so, barely - it is a huge timesuck the world over, and then you look at it in IE and break down and weep.
i actually can see Tables in Stack Overflow on the user page.
It even has heaps of inline styles...
There definitely is. If you are still striving for it, you are not getting it right.
DIV+CSS layout is actually much easier than table layout in terms of maintainability and productivity. Just keep practicing it before it's too early to say that.
Table layout is good too it's just not meant for layouts and have exceptional drawbacks when it comes to minor tuning.