Here are the word posts: Part 1 | Part 2 | Part 3

Click here to view the video on YouTube.

Click here to view the video on YouTube.

Click here to view the video on YouTube.

Here is another one he did about personas (again—important idea, hard to explain and sell to your team): http://thinkvitamin.com/design/how-to-understand-your-users-with-personas/

I’m thinking this is really a key—cartoons.

• Encapsulate everything easily
• Make it appealing and gettable

The new info-overload world has highlighted peoples’ impatience. It’s made information so available, but still as hard as ever (more or less) to see the important stuff. But what’s been coming out are means that are easier, simpler, for conveying info in ways that work. (And that’s—kind of—all that matters.)

The Duplicator plugin is designed to give WordPress Administrators the ability to migrate a site from one location to another location in 3 easy steps. Just create a package, download it and install. No need to change all your settings and re-run import/export scripts. The plugin also serves as a simple backup utility.

wordpress.org/extend/plugins/duplicator/

Here’s the code to do this:

add_action( 'admin_init', 'clean_unwanted_caps' );
function clean_unwanted_caps(){
	$delete_caps = array('edit_issues', 'publish_issues', 'edit_other_issues', 'read_private_issues',
		'delete_issue', 'edit_issue');
	global $wp_roles;
	foreach ($delete_caps as $cap) {
		foreach (array_keys($wp_roles->roles) as $role) {
			$wp_roles->remove_cap($role, $cap);
		}
	}
}

For  $delete_caps, just include whatever capabilities you want to delete.

Be careful with this, of course!! Backup first!!

You have to do it this way, because the data is structured like this: $wp_roles->{role name}->capabilities->{array of all capabilities}. So each capability is listed separately for each role. That sounds redundant, doesn’t it? But I guess they figured it was more elegant than creating yet another table in order to store the capabilities, and I’ll bet they were right.

When you build a “bespoke” theme, you build in what the client actually needs. In contrast, this theme builder had to build in what thousands of different customers might want. That may make it easier for them, but to modify it, makes the simplest change much harder.

Here’s the snippet:

<?php
                 $xcol="theTopSecond";

			if(get_option($xcol.'select')==$xcol."-1") { ?>
				<?php custom_html(get_option($xcol.'htmltitle'),do_shortcode(get_option($xcol.'content'))); ?>
			<?php } elseif(get_option($xcol.'select')==$xcol."-2") { ?>
				<?php	contact_form($xcol.'',get_option($xcol.'mytitle'),get_option($xcol.'contactdesc'),get_option($xcol.'contactemail'),get_option($xcol.'contactmsg'));	?>
			<?php } elseif(get_option($xcol.'select')==$xcol."-3") { ?>
				<?php	pages_list(get_option($xcol.'pagestitle'),get_option($xcol.'pagesexc')); ?>
			<?php } elseif(get_option($xcol.'select')==$xcol."-4") { ?>
				<?	recent_posts(get_option($xcol.'recent-title'),get_option($xcol.'recentcat'),get_option($xcol.'recentnum'));	?>
			<?php } elseif(get_option($xcol.'select')==$xcol."-5") { ?>
				<?php	categories(get_option($xcol.'cat-title'),get_option($xcol.'cat'));	?>
			<?php } elseif(get_option($xcol.'select')==$xcol."-6") { ?>
				<?	meta_information(get_option($xcol.'metatitle'),get_option($xcol.'meta1'),get_option($xcol.'meta2'),get_option($xcol.'meta3'),get_option($xcol.'meta4'),get_option($xcol.'meta5')); ?>
			<?php } ?>
	</div><!-- / panel-wrap -->
	<div class="panel-wrap">
		<?php

                 $xcol="theTopThird";

			if(get_option($xcol.'select')==$xcol."-1") { ?>
				<?php custom_html(get_option($xcol.'htmltitle'),do_shortcode(get_option($xcol.'content'))); ?>
			<?php } elseif(get_option($xcol.'select')==$xcol."-2") { ?>
				<?php	contact_form($xcol.'',get_option($xcol.'mytitle'),get_option($xcol.'contactdesc'),get_option($xcol.'contactemail'),get_option($xcol.'contactmsg'));	?>
			<?php } elseif(get_option($xcol.'select')==$xcol."-3") { ?>
				<?php	pages_list(get_option($xcol.'pagestitle'),get_option($xcol.'pagesexc')); ?>
			<?php } elseif(get_option($xcol.'select')==$xcol."-4") { ?>
				<?	recent_posts(get_option($xcol.'recent-title'),get_option($xcol.'recentcat'),get_option($xcol.'recentnum'));	?>
			<?php } elseif(get_option($xcol.'select')==$xcol."-5" || get_option($xcol.'select')=="") {  // ********* Default Option ?>
				<?	categories(get_option($xcol.'cat-title'),get_option($xcol.'cat')); ?>
			<?php } elseif(get_option($xcol.'select')==$xcol."-6") { ?>
				<?	meta_information(get_option($xcol.'metatitle'),get_option($xcol.'meta1'),get_option($xcol.'meta2'),get_option($xcol.'meta3'),get_option($xcol.'meta4'),get_option($xcol.'meta5')); ?>
			<?php } ?>
	</div><!-- / panel-wrap -->
	<div class="panel-wrap last">
		<?php

                 $xcol="theTopFourth";

			if(get_option($xcol.'select')==$xcol."-1") { ?>
				<?php custom_html(get_option($xcol.'htmltitle'),do_shortcode(get_option($xcol.'content'))); ?>
			<?php } elseif(get_option($xcol.'select')==$xcol."-2") { ?>
				<?	contact_form($xcol.'',get_option($xcol.'mytitle'),get_option($xcol.'contactdesc'),get_option($xcol.'contactemail'),get_option($xcol.'contactmsg'));	?>
			<?php } elseif(get_option($xcol.'select')==$xcol."-3") { ?>
				<?	pages_list(get_option($xcol.'pagestitle'),get_option($xcol.'pagesexc')); ?>
			<?php } elseif(get_option($xcol.'select')==$xcol."-4") { ?>
				<?php	recent_posts(get_option($xcol.'recent-title'),get_option($xcol.'recentcat'),get_option($xcol.'recentnum'));	?>
			<?php } elseif(get_option($xcol.'select')==$xcol."-5") { ?>
				<?	categories(get_option($xcol.'cat-title'),get_option($xcol.'cat'));	?>
			<?php } elseif(get_option($xcol.'select')==$xcol."-6") { ?>
				<?	meta_information(get_option($xcol.'metatitle'),get_option($xcol.'meta1'),get_option($xcol.'meta2'),get_option($xcol.'meta3'),get_option($xcol.'meta4'),get_option($xcol.'meta5')); ?>
			<?php } ?>

	</div><!-- / panel-wrap -->
	<?php } ?>
</div><!-- / content -->
</div> <!-- / panel -->

I was going to reduce it to the code I actually need–but to be honest, I’m not even sure what it does. And the investment to understand what it did, would not be worthwhile.

If I were to write this for a particular customer, it would be a few lines of simple code. Easy to write, easy to maintain, easy to understand.

Not that it might not be a good theme for consumers, but working in this, is just a bloody mess. That’s why I feel very strongly that you should either build from scratch (or a framework), or use a pre-built theme with all its options–but trying to combine the two, is very foolish.

Responsive Design CSS

So I have been looking a lot at Responsive Design. If you are not familiar, my brutish summary is:

• Fluid layouts are (a) manageable, (b) cool.
• You can use the CSS @media queries feature to rearrange elements on your page layout, based on different window widths, and this means making things easier to read on iPhones and Androids, etc.

There’s a bunch more, such as responsive images, where you try to serve images that are appropriate to the bandwidth of the visitor, and their screen size. But, that kind of sums up a lot of it. The term responsive design was coined by Ethan Marcotte, borrowing it from a term responsive architecture, which refers to a movement to make buildings adapt to their users. I guess that’s where we get somewhat dis-contiguous concepts, such as adapting to mobile devices, and providing fluid layouts, bundled in the same concept. But—both are cool.

Anyway, this leads me toward looking at CSS responsive frameworks, such as the Less Framework, that  give you some cool magical things about adapting to different screen widths using @media queries.

See 15 Responsive CSS Frameworks Worth Considering, for a list of other good, juicy-looking things like this.

WordPress Themes

But what, I thought, about using a WordPress theme framework that already incorporated some of this stuff? So, I discovered:

• Bones
• Reverie
• Foundation
• Roots

My instinctive choice, for whatever variety of reasons, is to play with the Roots Theme. When I started to unpack this, I discovered that it has a lot of things in it, that I need and want. And actually—it reminded me, that nowadays, there is such a long list of best practices to remember, that I am just—quite frankly—glad that they remembered so many of them here, that they reminded me about them! —Much better to have these things baked into your initial install, than have to cobble them all on top of it, where possible.

And, I feel they have done a good job of balancing the needs to add sensible defaults, with allowing people freedom and flexibility. That’s always an interesting balance. And, they have included a number of other sub-elements that I have been interested in using for a while. Some, like Modernizr, I have been using for a while, but I am soo happy to have other good people include this for me!

Here’s a list of things Roots covers / includes:

HTML5 Boilerplate

Bootstrap also uses LESS—a compiled CSS that allows you to include variables, calculations, and re-usable chunks. This is another “best practice” that is growing and growing right now, and it is lovely. Note that you can use the pre-compiled bootstrap.css and bootstrap-responsive.css out of the box, if you want to. When you run Roots, it does not do anything with the .less files that are included—if you want, you can modify these, and recompile them into bootstrap.css.

Other Nicifications

• Path nicifications—they shortcut a bunch of common theme paths, like /css for /wp-content/themes/<my theme>/css. I think that’s handy
• Combining all Javascript plugin code into a single plugins.js file, as a default, to save requests
• Pre-creating a script.js file for you to use
• Lots of language support built in
• A stylesheet for the TinyMCE built-in editor, so that you can make the text when someone is managing the site, look like it will when it’s published; this is the first time I’ve even seen someone address this!
• Creating a very nice /inc/roots-*.php framework of functions files, to neatly manage configuration, including a roots-custom.php place for you to put your own code

I feel intuitively, that these guys have done a very nice job of balancing making this thing too structured and rigid, with a zillion files for every possible eventuality, or making it so bare-bones that the moment you start, you have to do all this organization of your own, just go get things set up in a good, basic way. The structure of these /inc/roots-*.php files, as an example, is such that you can clearly see where you might want to add your own custom code, and keep a default t thing intact—or, you might want to modify something in the structure of what’s already there. This applies to a lot of parts of this framework.

The documentation is also pretty good, and there is clearly a lot of support and activity for it. As of this writing, there are 26 open issues, and 354 closed ones, since the project was first added to GitHub, about a year ago.

There is documentation on how to use it with Nginx and Lighttpd (=non-Apache, more optimized) web servers.

Very Nice Out of the Box

iPhone-y (narrow width)

Lastly, a very important thing in a practical life, is that this theme looks very nice out of the box, as the example screen shot shows. Furthermore, it is already “responsive,” so that if you narrow the window, the top menu becomes an iPhone-like button menu, and the sidebar stacks below.

Installation and Use Notes

A few things I noticed:

• Installing the theme copies the inc/h5bp-htaccess into the document root, adding several optimizations provided by HTML5 Boilerplate. But for whatever reason, this totally crashed my local Apache (maybe its just old). So, I had to comment a number of those things out. You could probably just delete the generated .htaccess file, and then go do WordPress Settings > Permalinks to rebuild it as the default.
• At first, understanding Bootstrap was a little intimidating, until I realized that I could let 95% of it just be as it was, and just learn what little @variables I needed to modify, and then recompile bootstrap.less. (And in fact, I could leave 100% of it alone, if I wanted). For the most part, you can just allow its basic goodness to influence your site, and override it as needed, and utilize the classes to make it do special magic things.)
• Roots calls 4 CSS files:
• css/style.css — This appears to just be the HTML5 Boilerplate baseline. I believe one would not want to modify this, normally
• css/bootstrap.css — The compiled Bootstrap file. Again, if you wanted to modify anything here you could, but you’d want to modify the .less files, and recompile that
• css/app.css — This is a nicely-organized skeleton which is mostly empty, and provides a nice place to add your custom CSS, with some reasonable sections

Process Management

So a very big part of all this, in considering a framework you might use, and thinking about the implications for the future, and long-term use and so on. So a great part of using the Roots Theme, is that they have built it on a bunch of other best-practices work—HTML5 Boilerplate, Bootstrap, etc.—that, themselves are taking advantage of other good best-practices code.

Now, we want to balance efficiency of developing our own themes, with being able to take advantage of code updates in the Roots Theme. The theme is set up so that you could really do it either way. It includes a bunch of hooks, which you could use in a child theme. But, the author does not just praise the use of child themes, acknowledging that the tradeoff is, that while using one makes it easier to update the core Roots code, it makes development slower and less intuitive, as well.

Personally, I could imagine that if I was doing a simple project, then perhaps I might use a child theme. But overall, I am with them—I’d rather use Roots as a starting place, and modify the code as it worked for me.

Now, having said this, there should be a good development process in place. Perhaps one should decide which files were “sacrosanct”, and make them read-only, and decide on a standard about how and when files were to be modified.

Another thing that would be smart to do, is keep a snapshot of an unchanged version of the code, from when you started the project (e.g., by using a Git tag). This way, when Roots was updated, you could see what changes between that and what you have now, were a result of updates in the core code, and what changes were a result of your modifications. I guess you could use Git to merge the Roots core updates into your project … it would be a bit sophisticated, but it would make a lot of sense to do learn how to do that.

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?