I released a new version of Writer (a Drupal blogging theme, for developers) over the weekend.
Here are some links if you want to learn more:
Happy Monday.
I remember the first time I got a "White Screen of Death" distinctly. I was migrating my personal site over to Drupal from Wordpress. I don't exactly remember where I went wrong, but all of a sudden I saw it. A wall of blinding white light void of meaning. Such sterile, hollow, emptiness.
I checked the source, hoping I would find some clue as to what was happening. All I saw was this: "<head></head><body></body>". Useless.
I had vaguely remembered seeing something like this before when I did some basic PHP programming in a class, but this was different. I was dealing with 14.9 Megabytes of Drupal. I couldn't just comment out chunks of code until the site started working again.
I had no reference points. I couldn't do Google searches for "White screen of death" because I didn't know that people called this a White Screen of Death. I couldn't get into the admin screen to uninstall modules or otherwise troubleshoot the cause. I wasn't about to start deleting chunks of a codebase I wasn't familiar with. For the life of me, I couldn't get Drupal to produce an error message. I did everything I could… I even contacted customer support with my webhost. After hours of frustration, I chose the only remaining option. I deleted my entire site and database, and did a fresh Drupal installation from scratch.
To the brand new Drupal Developer, the White Screen of Death is absolutely devastating. I don't know how, but there has got to be a way to prevent it. But only if we are willing to reject the status quo.
There's a lot of discussion around the topic of whether designers should learn to code or not. That's a valuable question, but why don't we ever debate about whether or not developers should learn how to do web design? Perhaps it's because the answer is obvious. They should.
Now I understand the value in focusing on your strengths as a programmer, but the truth is, understanding a few fundamental design principles can take you a very long way. Understanding how to use contrast, white space, and color balance are pretty simple principles. It isn't difficult to tell good designs from bad designs but being able to see why a bad design is bad, and how it can be improved… that's game changing. And it's within reach.
Maybe one day I'll start holding a course called "web design for the artistically inept." Until then, here are a few good resources to get you started:
- Hack Design: Design lessons for programmers, curated by top designers
- Team Treehouse: Aesthetic Foundations
- Design for Developers: Making your Frontend Suck Less [VIDEO]
- Design For Developers [SLIDES]
If you've found some other particularly useful resource then feel free to add it to the comments.
Drupal has this concept of "sub-themes" where you can take an existing Drupal theme and override it in a clean way. How does it work? Well, instead of altering the original theme files, you create new theme files that are automatically discovered and called in the place of the original ones. This allows you to continue using the original theme (and keep it easy to upgrade) while adding stylistic customizations of your own. For more details, checkout this explanation on how Drupal sub-themes work.
So, can you make a sub-theme of a sub-theme?
Yes. You can build sub-themes down as many layers as you want. To do this, the sub-theme to-be should be located in its own directory. Prior to Drupal 6, this directory had to be a subdirectory of its base theme; in Drupal 6 and 7 it can be placed outside of the base theme's directory. Personally, I find it more organized to nest each sub-theme as a subdirectory of the parent theme like so:
Theme
|
>--Subtheme
| |
. |
. >--Sub-sub-theme-1
. |
|
>--Sub-sub-theme-2
| |
| |
| >--Sub-sub-sub-theme-2a
| |
. .
. .
. .
Most importantly, each subtheme declares its parent theme in its .info file with base theme = theme_name. Ultimately, this is what determines the theme relationships, not the folder strucutre.
The main idea with nesting subthemes is that you never need to directly alter the CSS or template files in any theme. As you use them, I think you'll find they are a slick way to make your theming less redundant and more maintainable.
If you wanted to use an interactive US map on your website, you would find plenty of free options (like this, or this, or this). However, if you were looking for an interactive map of Africa, then you were out of luck. Until now.
Last week I combined a couple resources and built out an SVG map of Africa using the Raphael.js library. All the countries are accessible as HTML DOM objects and can be interacted with using CSS, Javascript, or the options provided by Raphael.js library. The path for each country is labeled, so you can easily delete paths and get a map containing a cluster of countries. Another small tweak to the transform allows you to scale the map to whatever size makes sense.
You can see the Africa Map demo here, or look at the contributed code up on Github.
After my years spent in Africa, I've retained a special place in my heart for the place. Hopefully this resource turns out to be useful to whatever Africa-focused business, non-profit, or government organization, happens to stumble across it.