My previous post about web design for print designers, got me thinking more about what the “best” process, the best workflow, for designing and creating websites is.

Andy Clarke, a very influential British web designer gave a very influential talk about this a few years ago,  being a proponent of “designing in the browser”—that is, leaving Photoshop behind, and working straight in the medium that your client’s site will actually be living in—HTML, CSS, Javascript.

Here’s a sloppy summary of why:

• The way Photoshop treats type is totally different from the way browser treat it
• It creates a whole other step in the process, that can slow things down
• PS does not have any way of mocking up dynamic elements, such as hover-over behaviors
• You have to translate what Photoshop can do, into what a browser can do—why not start in the browser itself?

Meagan Fisher did another great article about this on 24 Ways. She goes into more depth about the process she uses to design in the browser—using HTML and CSS. (See the comments on this article for an in-depth discussion, by real designers, of the pros and cons of this method.)

A small company called Handcraft has even started to create a little web app to help you do this, Dan Lewis James wrote a post about his process, and 37 Signals wrote a characteristically great and opinionated piece about it, Why we Skip Photoshop.

Why it Matters

My previous post got me thinking a lot about the problems of using Photoshop—or Illustrator, or really, Fireworks.

• It encourages the client, and the designer, to continue thinking about the work as a static piece of paper, that only gets “converted” into a web page at the end
• It relegates any work on the dynamic elements to the end, if at all (if the designer doesn’t pay attention to them, and the developer doesn’t feel it’s his duty to worry about it, and the client doesn’t even know that it’s possible—where the heck is it supposed to come up?)

Drawbacks

There are a number of drawbacks of the “designing in the browser” approach:

• Many designers don’t know CSS and HTML, and don’t want to
• Working in the browser might make you think more “left-brained,” and limit your creativity (if you’re like that)
• It might make you think in “boxy” terms, because it’s so easy to make boxes in HTML and CSS; Photoshop lets you break out of the “box” and create things that people may not have seen before—then, you can go back and figure out how to code it

Moving Forward—Solution?

I don’t think there’s one solution here. Here’s what I think:

• It’s not just a question about tools; it’s a question about process—the process tends to drive decisions. For example, if the designer is the de facto driver of a project, and the designer uses a process of “I show the Photoshop comps to the client, and he signs off on them,” this will inevitably tend to downplay dynamic elements, and relegate them to the back burner. They may never get addressed at all.
• We probably need to think about a process that includes people working concurrently—let’s have a copywriter developing some lead copy, as the designer uses whatever creative tool they like to work with to open up their minds, and meanwhile, let’s have a “web expert” point out great examples of subtle dynamic behavior, or trends in web design, that could positively impact the design.

Let me summarize even more:

• I think we need a process that co-evolves with an expert writer, a web expert, a coder, a designer, and a marketing person, and an information architect, all co-creating the work simultaneously, so that the project ends up placing correct emphasis on everything, and design considers.. marketing. Design considers… the actual content. Design considers… the organization of the site.

Of course, you could have more than one person wearing some of these hats. But bottom line, I don’t think anymore that you can have just one person who understands the big picture well enough to create a work in isolation. I think you should use the tools that work for you, but you should incorporate any important considerations in the process. It’s unrealistic to make one person responsible for all of this—it’s just equally unreasonable to ignore the different factors.

What do you think?

What is your web design process like, and how does it work for you?

This article is copyright © 2012 

[This is part 3 of a 3-part series]

Part 1 | Part 2 | Part 3

This was originally a video (included below), and these words suplement and distill what I say in the video.

This series was originally inspired by a video, which you can see here:
Web Design for Print Designers — Videos.
.

Design Process

There’s a common web design process whereby a designer goes into her or his private place, works in Photoshop, and comes up with a series of comps. Then, s(he) gives these over to a developer or someone, who codes them into CSS/HTML/WordPress, etc.

This process probably parallels a designer producing work to give to a printer. But it leaves out a lot of magic that is possible in the web, or turns it into an afterthought.

My experience tells me that unless the web designer can integrate these things into her process, this will continue. By the time she’s turned her work over to be “coded,” it’s too late, unless we think of things differently.

The truth is, there are probably ways in which Photoshop is still a good design tool just because it doesn’t limit you to what’s “easy” on a web page; but then, it’s very limiting, because it puts off the specification of dynamic elements for way too long.

Furthermore, specifying type in Photoshop makes no sense at all—you need to do this using CSS and real browsers.

Also, in my experience, things like fine rules (see www.good.is again), are a bitch to render in Photoshop, and even in other tools, they’re not really going to look the same as they do in a web page. Note the use here of dotted rules (a CSS option), for example. Why take forever in Photoshop (or Illustrator) trying to make it look like it’s going to look in the browser?

The alternative—I think—is going to have to be a process where you do  part of your work in a tool like Photoshop, and part of your work in HTML and CSS. (If you don’t know how to use these tools, maybe you should learn, or work with someone who does.)

Furthermore, web designers—who are generally very visual—should generally work with someone else, playing the information architect role, whose job it is to think about the arrangement of the verbal information, and the navigation. (In conjunction with the designer, of course.)

Furthermore—this is something outside the scope of this article, but I have to say it—because many clients come straight to a designer as the point person to produce their website, and many designers don’t really know about marketing, the designer should really work in conjunction with a marketing person,always. (Unless, perhaps the client really and truly does not desire to get traffic from the site, or already has a marketing department and plan—in which case the designer should be working with that department.)

What do you think?

What is your experience as a designer? As a developer? What do you think? Tell me below:

This article is copyright © 2012 

[This is part 2 of a 3-part series]

Part 1 | Part 2 | Part 3

This was originally a video (included below), and these words suplement and distill what I say in the video.

This series was originally inspired by a video, which you can see here:
Web Design for Print Designers — Videos.
.

Principles (continued)

Delight

I could call this something different, but what I mean is things that do a little something when you hover over them, or somehow change occasionally.

Examples:

* The little hearts in Made by Water.com

* The way the Feedback tab in Get Satisfaction.com moves slightly when you hover over it

* The way links change color when you hover over them

I suppose I could include in delight, simply the way that small details are rendered, delicately, to create a gentle sense that things were covered; the i’s were dotted, and the t’s were crossed.

Neatness, Alignment, and Air Allow Deliery of Lots of Information without Overwhelm

I think another thing I’ve noticed with print designers is a desire to pare things down and eliminate unnecessary information—they don’t like a clutter of lines, words, etc.

I don’t either; but I think that here’s a way where a printed report and a web page vary greatly. When you’re holding a printed report (or magazine, or book, or brochure) in your hands, your most natural instinct is to turn the pages when you want to explore more.

While web pages do have an equivalent to “turning the pages,” they’re still not the same. In a web page, you can make things that are very faint (demanding not-too-much attention), that then darken (or gain color) when you hover over them, essentially coming into focus when you need them.

I think things like fine rules (lines), nice alignment (whether officially on a grid or not), and flexible color schemes make a site like Good.is (www.good.is) very easy to look at. There’s a ton of stuff going on here, and it’s good.

Information Architecture Matters

In all the examples I site, someone took a lot of time to think out how to organize that information. It means, considering how well the words on the page help you find what you want; how well it’s structured to make sense to your visitor—not to you.

I think all the examples have a good feel in part because of design, and in part because someone thought a lot about this.

Although note, as well, that most of the sites have a lot of different ways to find stuff—besides having nicely delineated categories, and featuring the most important things the most. For example, “active” footers give you a lot more space to lay out what’s on offer.

(See www.webmonkey.com/2010/02/information_architecture_tutorial/ for more.)

➡ Continue to Part 3

This article is copyright © 2012 

[This is part 1 of a 3-part series]

Part 1 | Part 2 | Part 3

This series was originally inspired by a video, which you can see here:
Web Design for Print Designers — Videos.
.

My Experience from Working with Designers

I work with a lot of designers, and I know that a lot of you came from the print world, and have gradualy made the transition into web design (or want to). Here are some things I have observed that will be helpful to think about.

Really good web designers understand the medium, and how it is different from print. They work out their design process so that it works in the way a web page acts, and the way it feels to interact with a web page.

Principles

Design for the Whole Page, Not “Above the Fold”

An old usability study from the 90’s convinced a lot of designers to design for “above the fold” (the area of the page you see when you first open a web page), concluding that visitors did not know to scroll.

Well, this is no longer the case, and probably a big differentiator of good web design is understanding that a visitor interacts with a web page, and happily scrolls down to the bottom.

Many designers design a comp that focuses on the first experience of a web page (“the top of the fold”), and do not even design a footer. They may not insert even dummy text to see what the page will look like once it’s a real page, with height in it, with content.

(Incidentally, it would be wonderful if designers would spec out the typography for the whole thing—H1’s (Heading 1’s), H2’s, H3’s, bulleted lists, numbered lists, quote blocks, etc. There are good templates to do this. But Photoshop is probably not the place to do it. The place to do it is in a browser, using CSS.)

In the video, I say “you don’t just have to design for above the fold.” But what I really should have said is, don’t design for above the fold.

Notice, in the examples in the video, how there’s a progression of meaning that is created through scrolling—at the top, you have the first big idea for the site; then, you have granular information, such as posts, messaging, etc.; and at the end, you have a footer that serves a number of purposes.

When your visitor has gotten down to the bottom of that trail, he feels that the whole experience was considered—not just the first impression when the page loads.

➡ Continue to Part 2

This article is copyright © 2012 

photo credit: Wyscan

At the WordPress Meetup … Our topic this evening is, your favorite WordPress plugins. Here’s my picks (somewhat randomly)…

[Click the headings to go to the respective plugins' sites]

Yoast SEO Plugin

Yoast has been doing SEO for WordPress for many years … but recently, he’s consolidated a lot of work into this one, very cool plugin.

Photo Dropper

Photo Dropper is a magical plugin that searches for you to find legally-usable (Creative Commons-licensed) photos for your blog posts.

Gravity Forms

Gravity Forms is a paid plugin, but it’s well, well worth it, if you need to have forms more complicated than a simple email contact form.

Analytics360

Analytics 360 pulls in your stats from Google Analytics, and also MailChimp, if you use that, and lets you see it all from within the WordPress dashboard, without having to leave WordPress.

Shopp and PHPurchase

Shopp and PHPurchase are two very highly-recommended WordPress plugins for e-commerce. Shopp is a little less powerful, but more usable out of the box. PHPurchase offers you a lot of control, but is also a little more work to set up.

This article is copyright © 2012 

Even though it is written in JavaScript, you can actually write it in CoffeeScript, a simple Ruby-like language that is compiled into Javascript, so the distance between it and the horrible old, incompatible Javascript experiences of the past become farther and farther away.

It looks wonderful, but I don’t know how to install it on my MediaTemple virtual host account, so I don’t care about it right now. I am too lazy.

On the other hand, maybe it would be good, because I am so lazy, to install it. It is loved.

This article is copyright © 2012 

Backbone.js

Backbone is a web app framework for the Javascript (server-) side of your application. Let’s say you use an MVC framework for your server side–something in PHP, or Ruby, or Python. Well, what do you do on the client side?

There’s jQuery, which is beautiful, but it’s more a system for accessing the DOM, but is not inherently designed to talk with the server side, or manage data. This was one of the things I kept running up against a few months ago–for any variety of reasons, I need the server side (PHP in that case) to talk to the client side (jQuery). How, exactly, should I do this? It felt sloppy and home-grown.

Furthermore, it felt somehow inelegant to relate the data I wanted to store, directly with a series of selectors in the HTML. Yes, it did seem that that was how people did it; but it seemed counter-intuitive to my training.

This would be very useful if you want control over your code, but you want to do things elegantly. Or, because you’re trying to do a lot on the client side, like for example, GMail.

Here’s a great article about it: Building a single page app with Backbone.js, underscore.js and jQuery, by Henrik Joreteg.

He also mentions a Javascript, client-side templating engine, for use with jQuery, called ICanHasJS. This goes beyond what I’d thought about all this, but it’s pretty cool. Let’s say you have a client-side app, and you know you want to populate it with a bunch of data–but not as you build the page (server-side), but later–why not use placeholders to populate it, like you would with a server-side thing, such as Smarty? Smart.

Backbone also provides a RESTful API to allow a standardized way for your server and client sides to talk. That makes a lot more sense.

This article is copyright © 2012 

If I had known about this a little while ago, I might not have had to build my own test RESTful server, but then, I would not have had a chance to learn about REST, so I might not have learned some very important things. The server I built was a test server, and it really only returns test data. But this jQuery plugin is a level of ease beyond that, because you only pretend to $.post, etc., and it pretends to send back data.

This article is copyright © 2012 

Comment out the ones you don’t want to remove.

function cbqc_remove_boxes() {
	// Remove boxes I don't like

	// *** For posts *** //
	// Custom Fields
	remove_meta_box( 'postcustom' , 'post' , 'normal' );
	// Excerpt
	remove_meta_box( 'postexcerpt' , 'post' , 'normal' );
	// Trackbacks
	remove_meta_box( 'trackbacksdiv' , 'post' , 'normal' );
	// Discussion
	remove_meta_box( 'commentstatusdiv' , 'post' , 'normal' );
	// Revisions
	remove_meta_box( 'revisionsdiv' , 'post' , 'normal' );
	// Author
	remove_meta_box( 'authordiv' , 'post' , 'normal' );
	// Categories
	remove_meta_box( 'categorydiv' , 'post' , 'normal' );
	// Tags
	remove_meta_box( 'tagsdiv-post_tag' , 'post' , 'normal' );
	// Publish
	remove_meta_box( 'submitdiv' , 'post' , 'normal' );

	// *** For pages *** //
	// Custom Fields
	remove_meta_box( 'postcustom' , 'page' , 'normal' );
	// Discussion
	remove_meta_box( 'commentsdiv' , 'page' , 'normal' );
	// Comments
	remove_meta_box( 'commentstatusdiv' , 'page' , 'normal' );
	// Revisions
	remove_meta_box( 'revisionsdiv' , 'page' , 'normal' );
	// Author
	remove_meta_box( 'authordiv' , 'page' , 'normal' );
	// Page Attributes
	remove_meta_box( 'pageparentdiv' , 'page' , 'normal' );
	// Publish
	remove_meta_box( 'submitdiv' , 'page' , 'normal' );
}
add_action('admin_init', 'cbqc_remove_boxes');

This article is copyright © 2012 

This just never occurred to me: That you might want to use plugins when developing custom features for a client, rather than simply include the code in the functions.php file (or an extension of same).

Now, because the plugin was not necessarily for general consumption, there could still be an awful lot less labor, in the form of testing, compatibility QA, etc. Probably still more than if you were including in functions.php, but maybe not.

Reasons why you might want to include features for a client’s site as custom plugins:

1. Including as plugins forces you to carefully encapsulate the code, into more clear, discrete units, based on function, which inevitably improves re-use.
2. .. It also inevitably encourages better maintenance.
3. It takes advantage of the plugin architecture, not as a means by which people all over the world could re-use very generic code functions, but more as a means by which a company (or independent developer) can re-use its own code and functions. The same cool, modular design that lends itself so well to contributions by the open source community, could also lend itself to flexibility within a company.
4. It could encourage the company to distribute said code to the world, with numerous benefits.
5. As the client requested more features, it could encourage me to add those features as the discrete, “pluggable” items that they are, rather than adding them as a sort of “spaghetti” of stuff to the functions.php file. An example is some custom post type code that a client has requested, and provides a very discrete new set of behavior to the site.
6. You might be able to include this new, discrete functionality, without interfering with the existing theme files. If the code for the new feature, and the existing theme files, are really two separate things, it could be very nice to keep them quite separate.
7. You can easily turn a particular function on or off. I am not sure exactly how that will benefit, but it might well.
8. You could provide access—for yourself, or for a client—to whatever particular configuration settings or what not that you might want to be able to easily change. —Perhaps while you were developing a site, or say, from one project to another.
9. If you do want to re-use code from one project for another, I think it will definitely be easier to see exactly what code you want to pull out and use, if it’s so well modularized as to be in its own plugin.
10. [9/13/10] If you were trying to utilize a development methodology, such as Agile, that took advantage of modularity, and possibly with a more junior, you could use plugins as a way to enforce modularity, much like using object-oriented methods do. You could clearly specify inputs and outputs, and even embed test cases into the “stub” code for that plugin. You could actually provide a stub complete with a framework of coding standards, test case, etc. Ooh… that could be beauty-full…

When you are developing a plugin for a general audience, you have to spend a lot of time managing the interface to the plugin—making appropriately user-friendly, pretty interfaces, that are fairly easy for the general user to understand, can take up a lot of extra time.

On the other hand, if I were developing plugins for internal use, I could make them less user-friendly, focusing on the specific user audience, and specific functions I needed to expose. For example, I might have a simple drop-down menu of options for the back-end (client’s) interface, and a series of configuration options within the code, that would be easy for a developer to change, and adapt to a specific project.

In fact, I could even have plugins that had no visible interface.

Disadvantages could include:

1. Having theme files and other aspects of the site’s behavior in different areas. This is definitely a pro/con balance situation. If you have all the code with within the theme directory, it’s nicely self-contained (and I use this a lot when managing project code with git). On the other hand, if it’s in a plugin, then it’s nicely kept separate. (And of course, it’s not as though I don’t already have a client’s site set up with any number of other plugins that I have included).
2. Even though I can keep the interface to my plugins simpler, there might still be a little more code required to manage a series of plugins, than just code stuck somewhere in a functions.php file.
3. You might easily end up in a situation where you still do need to modify the theme file code. Now, you have had to manage modifications in two separate areas of code, just to get the feature to work.

— Update, September 13, 2010 —

I know maybe nobody is reading this, but if only for my own edification or remembrance, I will note some more things down.

This weekend, I began trying an extension of this experiment.

I started a generic.local install of WordPress, with the barest of themes, a very generic installation. Then, I started adding plugins to accomplish various functions that I might want to do for a variety of projects—custom post types, custom “fields” (e.g., meta data for various write panels), etc.

I then stored this entire plugin directory as its own git repository. I developed the custom post type and fields plugins in the generic install, until everything worked pretty well, in a generic way.

Then, I went to the actual site I was working on, and cloned the same repo, becoming the plugins directory for that actual site.

Now, I created a site-specific git branch, and started working in there, making modifications to the various plugins, as needed, for the particular project.

Also, I would add any publicly-available plugins as needed, and yes—they become part of that branch of the repo. Therefore, this branch of the repo becomes a snapshot of the entire plugin installation I need for this particular project.

The idea here, is that (a) there could be a lot in common between projects; (b) starting off from a common “root” branch of code, could encourage the re-use of said code in an organized way.

I may start to include all the standard plugins I might use in the “root” branch, so then it becomes a kind of library of commonly-used public plugins.

Unlike having to release a plugin publicly, I am still able to tweak and modify the code by hand, commenting out options or features I don’t need, etc., all within the code. So, it’s sort of a best-of-both-worlds situation. It allows me to know a lot more intimately what a particular function does—say, register_post_type(), for example—without having to re-write it all by hand every time.

The disadvantage I can think of, so far, is that for each project, I’ll have two stores of code—one, the project-specific branch of the plugins directory, and two, the theme directory repo.

But I think it is very interesting how this encourages me to think in terms of re-used, and modularized, code. But thanks to the power of git, re-purposing this core library of code is very easy, because I can so quickly switch between branches.

—- Update, September 14, 2010 —-

Realizing that a real danger here, is that you end up getting confused about where which files are, for which project. There is a beautiful simplicity in having everything for one project, in one place.

There are always tradeoffs between re-use and simplicity.

Somehow, I need to come up with the way to have both. For example, still have one repo per project, but have it point to both the plugins directory, and the theme directory. Perhaps create a directory that contains symlinks to both places, thereby making the repo contain both, while having WordPress work the same way it always does.

This solution would be beautiful, except that it squashes the idea of maintaining all of the plugins for my projects as a sort of shared core of code. Need to think about this some more.

This article is copyright © 2012