Since the z5blitz has been backburnered, things have returned to normal. Today I am scheduled for a two hour Drupal training, and I've spent the morning writing up an outline to keep myself on track.
Part One: Your Server
Part Two: Drupal
Project Hewlett Martin is my codename for the three sessions in which I try to teach two of our fabulous designers how to do CSS.
This has been a long time coming. We need to be more web designers (not just print designers) and as such, we need to be more web savvy. They've been interested in HTML5 and CSS3, so I'm trying to get them more involved. The hope is that the web developers will be able to build HTML templates that the designers can style with CSS. If they can't, no harm in trying. And even if they can't it will inform their designs, probably irreparably.
So today was our second day. I started by going over the box model with them. This is best done on a white board. It really helps if you can draw nice rectangles, which apparently I cannot do anymore. I listed a few "block level" elements and a few "inline" elements and explained the differences between them.
And then I made them write code.
I figure, you can watch all the tutorials you want. I can wave my hands at it for hours. You're never going to get it until you have to do it. So I had each of them tinker with a CSS file for twenty minutes. They accomplished a lot, really. They got the gist of background and foreground colors, margin and padding, and we went over how CSS treats italics completely different than bold. They even changed an unordered list into something that looked like a real menu.
It's been interesting. Code and design are really two completely different mindsets. I understand code, they understand design, so we're trying to fuse our ways of thinking and produce something new. It's also been interesting for me to see how things I take for granted are actually kind of stupidly confusing.
Code consists of modules, plugins, themes, templates, stylesheets, javascript libraries, and things like that. Code is meant to do something. Data consists of usernames, page content, settings, and things like that. Data is meant to be something.
Code should live in files. Data should live in the database.
As an example, I'd like to talk about CCK. Any CMS presents the need to create your own content types (blog posts, events, slideshow slides) and your own fields on content types. Drupal has a very nice module called CCK to do this. It's very easy for anyone to create a new content type, or add fields of any kind (text, numbers, select boxes, dates). You don't have to be a Drupal developer to do this; you don't have to write any code. And this is where CCK begins to get confusing. Things like this should be code. CCK presents a sort of shortcut, an alternative for people who cannot write code. The tricky bit is that CCK stores all of that information (which is really code) in the database. Your code is now data.
So lets say you need to create Team Member Profiles. You use CCK to create a new content type and add some fields to it. You've done all this on a development server. How do you roll this out to the live server? You can't just copy some code to a different server, because it's in the database. And it's not even a "separate" part of the database, so you can't just copy that bit. What you end up doing is re-creating that content type and all it's fields on the live server. Ugh.
If you'd written a module, your content type and all it's fields would be genuine code sitting in files on a server. To roll it out to the live server, you just copy the files up. Done.
There are some other concerns with storing your code as data. One of those is code re-use. This is the idea that if you write a really nice module, you can re-use it somewhere else. On another website, for example. If your code is stored as data, you can't re-use anything because it's not stored in a re-usable format. There are also maintenance concerns. Backing up the filesystem would not include the code stored in your database. And how do you document code stored as data?
Tools like CCK allow people who cannot write code to do something code would normally do, but we can write code. As we build our new website I'm trying to maintain a distinction between our code and our data. This is just one of the facets of that.
Our current site is built with Drupal. I don't know how or why that decision was made; it was before my time. I do know that it's kind of like bringing a toolbox to the dinner table: sometimes all you really need is a fork and knife.
There's a lot to take into consideration this time around. Firstly, there's the timeline. I keep hearing the word "aggressive." If you want it done quickly, you need to make it simpler. If it's simpler, it doesn't need to be built with Drupal.
Secondly, maintenance. Our WordPress sites are far easier to maintain than our Drupal sites.
Thirdly, user-friendliness. WordPress has it in spades.
You can see where I'm leaning. Fortunately, most of Web Services is of the same opinion.
The sticky point is that we like to be able to go to a client and say "hey, our website is built with Drupal, too!"
Update: it looks like people think we'll attract as many clients by being able to say "hey, we built all these other great sites in Drupal, because they needed it, and our website is built with WordPress."
Tangentially, Project Fire Control.
We have embarked on a large, fast moving project. The outcome of which is to create a new website for Zone 5. The "blitz" part of this is the four days that have been set aside in April, at the end of which the new website will be live. Before that we're doing as much preparation as possible.
Over the next few weeks I'll be blogging from the Web Services point of view, specifically the web development perspective. I am hoping other people on the Zone 5 team (because everyone here is involved in this project) will lend their voices, either here or in the various social networks we've come to inhabit.
Last Friday there was a big meeting with the Creatives to discuss the sitemap from a responsive design stand point. We're looking at simplifying the entire website in order to make it easier for users to get the information they need.
I'm also interested in cutting a lot of fat from our website. One example being the "Culture" section of our website, which hasn't been updated in at least a year. Maintaining a complicated set of functionality to show recipes to which no one contributes is unnecessary. And a lot of this kind of thing can be moved to the blog, which, honestly, demonstrates the culture better than a mess of static pages.
Yesterday the Creatives presented their revised sitemap to the rest of the team, and it went over fairly well. We have some issues with terminology to work out, but once we figure out what to call "that section" we can move forward with actual designs.
The last version of the sitemap we had has 37 nodes. The new one has 16. Among other things we're doing is consolidating parts of the Graphics/Exhibits section. Currently they have their own gallery to showcase their work. Not only does this create a logical separation of their work from the rest of what the company does (which is bad), it's a completely different set of functionality the developers have to maintain. I was happy to hear that the Graphics/Exhibits people want to integrate their gallery with the rest of our work. This is great news because it means there will be one portfolio that shows all of our work, whether it's web, print, logos, or trade show booths. This is the kind of cohesiveness and simplicity that we need.
East Coast Office:
25 Monroe St •
Suite 300 •
Albany, NY 12210 •
518-242-7000
West Coast Office:
311 S First St •
Suite 204 •
San Jose, CA 95113 •
408-365-4450
Copyright © 2008 - 2013 by Zone 5
