- WordPress 2.8 Theme Design
- Tessa Blakeley Silver
- 3585字
- 2021-04-01 13:43:07
The solution: Rapid design comping
I soon realized the problem was me hanging onto a very antiquated design concept of what the mockup was and what production was. Before late 2005, I would have never cracked open my HTML editor without a signed design approval from the client, but why?
The Web was originally made for text. Therefore, it has a very nice, robust markup system for categorizing that text (that is, HTML/XTHML). Now with browsers that all comply (more or less) to CSS standards, the options for styling and displaying those marked-up items are more robust, but there are still limitations.
Photoshop, GIMP, and image editors have no display limitations. They were made to edit and enhance digital photographs and create amazing visual designs. They can handle anything you lay out into them, be it realistic for CSS or not. They were not designed to help you effectively manage layers upon layers of text that would be best handled with global stylings!
This realization led me to the ten step process I've termed rapid design comping. The term is a bit of a play on the term rapid prototyping which, taken from the world of manufacturing and applied to web and software development, had become very popular at the time this design process emerged for me in 2004-2005. This process is indeed inspired by, and bears some similarities to, rapid prototyping (as it is used in web and software development).
The radical, new process—is not so new or radical?
Turns out this approach, while it took me a bit to come around to it on my own, is not that new, radical or original. Many web-compliance and accessibility experts advocate a similar approach of starting with lean, optimized, semantically ordered markup created for the content and designing specifically for that content and markup, instead of "smushing" content into heavy XHTML markup and convoluted CSS styles that were created solely to handle design decisions (in some cases, poor decisions at that).
I'm often given the argument that this approach limits design creativity. However, I'd like to point out that this approach is the whole point behind the famous CSS Zen Garden site (http://www.csszengarden.com). Every single design on that site has been created using the exact same, clean, compliant, accessible, and semantically structured XHTML markup. There's no reason to feel limited creatively with this design process. If anything, it should push and spark your creativity.
Overview of rapid design comping
The following is the overview; we'll go over each step in detail afterwards:
- Sketch it: Napkins are great! I usually use the other side of a recycled piece of photocopied paper—the more basic the better. No fine artist skills required!
- Perk: Using this sketch, you can not only get your graphic interface ideas down, but you can already start to think about how the user will interact with your theme design and resketch any new ideas or changes accordingly.
- Start with the structure: I create an ideal, unstyled, semantically structured XHTML document and attach a bare bones CSS sheet to it.
- Add text and markup: Lots of text, the more the better! A sample of actual content is best, but Lorem Ipsum is fine too. Will you be taking advantage of WordPress forms? Be sure to add in those as well.
- CSS typography: Think of your typography and assign your decisions to the stylesheet. Don't like how the formatted text looks inline? Being separated into columns with fancy background graphics won't make it any better. Get your text to look nice and read well before moving on to the layout.
- CSS layout: Set up the layout. This is where you'll see upfront if your layout idea from your sketch will even work. If there are any problems at this stage, you can rethink the design's layout into something more realistic (and usually more clean and elegant).
- Perk: Your client will never see, much less become attached to, a layout that would cause you problems down the road in CSS.
- CSS color scheme: Assign your color scheme basics to the CSS. We're close to needing Photoshop anyway, so you might as well open it up. I sometimes find it useful to use Photoshop to help me come up with a color scheme and get the hexadecimal numbers for the stylesheet.
- Take a screenshot: Time for your image editor! Paste the screenshot of your basic layout into your Photoshop file.
- Visual design: Relax and have fun in GIMP, Inkscape, Photoshop, or Illustrator (I often use a combination of a vector editor and bitmap image editor) to create the graphical interface elements that will be applied to this layout over your screenshot.
- Send for approval: Export a
.jpgor.pngformat of the layout and send it to the client.- Perk: If the client has text changes, just make them in your CSS (which will update your text globally—no layer hunting for all your headers or links, and so on) and resnap a screenshot to place back in the Photoshop file with the graphic elements. If they have a graphical interface change, that's what Photoshop and GIMP does best! Make the changes and resend for approval.
- Production: Here's the best part; you're more than halfway there! Slice and export the images of your interface elements you've created and apply them to your XHTML mockup with background image rules in your CSS stylesheet. Because you worked directly over a screenshot of the layout, slicing the images to the correct size is much easier and you won't discover that you need to tweak the layout of the CSS as much to accommodate the graphic elements.
Note
If you start getting really good and speedy with this process, and/or especially if you have text overlaying the complicated backgrounds, you can also just export your images to your CSS file right away and send a straight screenshot to the client from the browser for his/her approval. Play with this process and see what works best for you.
For the purposes of this title, there's actually an eleventh step of production, which of course is coding and separating up that XHTML/CSS mockup into your final WordPress theme (we'll get to that in Chapter 3).
After taking all of the preceding items into consideration, I've decided that the type of theme I'd like to create, and the one we'll be working on throughout this book, is going to be an "online news source/magazine" type of site. Our site's content will be geared towards using open source software. Even though this type of site usually does very well by just focusing on the content, I would like to give users the design experience of reading a more trendy paper magazine.
The whole point of this step is to just get your layout down along with figuring out your graphic element scheme. You don't have to be a great artist or technical illustrator. As you'll see next, I'm clearly no DaVinci! Just put the gist of your layout down on a sheet of paper, quickly!
The best place to start is to reference your checklist from the steps I provided, which consider how the site is going to be used. Focus on your desired layout. Consider the following questions: Are you going to have columns? If so, how many? Will the columns be on the left or the right? How tall is your header? Will your footer be broken into columns? All of these things will compose the structure of your design. You can then move on to any graphic element scheme you might have in mind. This again may involve questions such as: Would you use rounded corners on the box edges or a particular icon set? Where will you use them and how often?
In the following figure, I've sketched a basic three column layout that features using the WordPress blog to manage and feature magazine-style articles on a particular subject, rather than just straight-up blog posts.
Because the design experience I want to give my site's viewers will be that of reading a paper magazine, the scheme for my graphic elements are going to focus on creating the illusion of paper edges and columned magazine-style layouts (particularly on the home page). I want the home page to feel similar to the "Table of Contents (TOC)" page in a magazine.
TOCs in magazines usually have big images and/or intro text to the featured articles to pique your interest. They then have listings of recurring columns such as "Ask the Expert" or "Rants and Raves".
Therefore, the graphical element scheme of my site that will make up the majority of the design experience, will focus on paper edges, curling up at the corners, just like a well-read, glossy, thin magazine paper tends to do. My layout is going to take advantage of the main WordPress blog, using the readily available text of the story as the intro text to pique interest. I'll use WordPress' categorizing feature to mimic a display of recurring columns (as in recurring articles) and the monthly archive list as a "Past Issues" list.
Tip
Start small
You may have a couple of ideas in mind; you can jot them down in quick gestures called "thumbnails". Thumbnails are a recommended and standard way to start any design mockup processes. They're a great way to be clear on the very basics of your layout before embellishing a larger (but still rough!) sketch with details.
Once you've created your sketch, based on your considerations, look at it for usability. Imagine you are someone who has come to the site for the information it contains.
What do you think the user will actually do? What kind of goals might they have for coming to your site? How hard or easy will it be for them to attain those goals? How hard or easy do you want it to be for them to attain those goals?
Are you adhering to standard web conventions? If not, have you let your user know what else to expect? Web standards and conventions are more than what's laid out in a lengthy W3C document. A lot of them are just adhering to what we, as web users, expect. For example, if text has underlines in it and/or is a different color, we expect that text to be a link. If something looks like a button, we expect clicking on it to do something, like process the comment form we just filled out or add an item to our cart.
It's perfectly fine to get creative and break away from the norm and not use all the web conventions. But be sure to let your viewers know upfront what to expect, especially as most of us are simply expecting a web page to act like a web page!
Looking at your sketch, do any of the just discussed scenarios make you realize any revisions need to be made? If so, it's pretty easy to do. Make another sketch!
Tip
Clean it up?
This might seem to defeat the purpose of rapid design comping, but if you're working within a large design team, you may need to take an hour or so to clean your sketch up into a nicer line drawing (sometimes called a wireframe). This may help other developers on your team to understand your WordPress theme idea more clearly.
The preceding usability scenarios deal with someone who will be looking at your content through your fully CSS-stylized WordPress theme. What if someone views this content in a mobile browser, a text-only browser, or a text-to-speech browser? Will the unstyled content still be understood? Will someone be scrolling or worse, listening and trying to tab through thirteen minutes of your sidebar blogroll or Flickr image links, before getting to the page's main content? To ensure such a scenario doesn't happen, we'll dive into our design comp by starting with the XHTML structure.
Tip
What's semantic?
Overall, I use the word semantic to refer to ensuring the unstyled order and structure of my content makes logical sense (header before main content, which comes before navigation, which comes before the footer, and so on).
Concerning strictly HTML, semantic refers to the separation of style from content by avoiding the use of presentational markup in HTML files. It also requires using the available markup to differentiate the meanings of various content in the HTML document. For instance, naturally you're familiar with headers being wrapped in header tags (<h1>, <h2>, and so on), images wrapped in <img.../> tags, and sections of textual content wrapped in <p> paragraph tags.
You can also define the content even further by taking care to place e-mail addresses inside <address> tags, acronyms inside <acronym> tags, quotes inside <blockquotes>, and citations inside <cite> tags (the list goes on). This lets anyone, as well as different processors (from browsers to other kinds of software), understand the document's content more easily.
You can learn more about semantic HTML from Wikipedia: http://en.wikipedia.org/wiki/Semantic_HTML.
For a comprehensive list of XHTML tags that you can define your content with, check out the W3Schools site: http://w3schools.com/tags/default.asp.
The HTML editors I recommended in Chapter 1 will drop these tags in for you. However, the more you understand about the XHTML tags and how to use them properly along with how they should look directly in the code view, the more solid, compliant, and accessible your markup will be.
We're now ready to open our HTML editor and start producing our design mockup. Again, I understand many of you are going to have a little trouble launching your text/HTML editor without a Photoshop or GIMP comp to work from. Trust me, we'll work through the layout in XHTML and CSS using our sketch and then the final visual elements will be a breeze in Photoshop and GIMP at the end. Open your HTML or text editor and create a new, fresh index.html page.
XHTML has two common DOCTYPEs: Strict and Transitional. There's also the newer 1.1 DOCTYPE for "modularized" XHTML. The Strict and 1.1 DOCTYPE is for the truly semantic. Its requirements suggest you have absolutely no presentational markup in your XHTML. (Though in Strict 1.0, any strong, em, b, i, or other presentation tags that slip in will still technically validate on W3C's service, it's just not the recommendation for how to remain "strict".)
You can use what you like, especially if it's your WordPress site. However, if the WordPress site will not remain completely under your control, you can't control everything that other authors will add to the posts and pages. It's safest to use the Transitional 1.0 DOCTYPE, which will keep your theme valid and have more flexibility for different kinds of users and the type of content they place into the system.
For our OpenSource Magazine theme, I'll go ahead and use the 1.0 Transitional DOCTYPE:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
You should note, while being integral to a valid template, the DOCTYPE declaration itself is not a part of the XHTML document or an XHTML element. It does not use a closing tag, even though it does look a bit like an empty tag.
Tip
Check your editor's preferences!
Some editors automatically place a DOCTYPE and the required html, header, title, and body tags into your document when you open up your blank file. That's great, but please go into your editor's preferences and make sure your Markup and DTD preferences are set to XHTML and Transitional (or Strict, if you prefer). Some editors that offer a design or WYSIWYG view will overwrite the DOCTYPE to whatever the preferences are set to, when you switch between the Design and Source (sometimes referred to as Code) views. Dreamweaver doesn't seem to have this problem, but you should set your DOCTYPE preferences there too, just to be safe.
Our XHTML mockup, like all XHTML files, requires a few additional tags, which we'll now add.
At this time, as we have our basic header tags created, I go ahead and attach a bare-bones stylesheet. This stylesheet just has the general items, matching div IDs and placeholders that I use for most CSS styling. But it's just the "shell". There are no display parameters for any of the rules.
In your index.html file, add your css import link within the header file.
<head>
<title>
OpenSource Online Magazine</title>
<!--empty script prevents un-styled content flash in older browsers-->
<script type='text/javascript" src=""></script>
<style type='text/css" media='screen"> @import url("style.css"); </style>
</head>
The following CSS "shell" contains empty rules for standard XHTML objects and IDs that I like to style for such as headers (h1-h4), paragraphs, anchor tags, as well as layout container IDs I'll use to hold my layout together.
Remember to apply the following CSS rules:
- XHTM objects (header, paragraph, list items,
divtags, and so on) can just be listed as a CSS rule—for example,div{...} p{...}. - ID names that are attributes and that can only be used once on a page, have a "#" hash mark in front of their CSS rule—for example,
#container{...} #sidebar{...}. - Finally, class names that are attributes and that can be applied multiple times on a page and combined with other classes, have a period (".") in front of the rule's name—for example,
.floatLeft{...}.
/*
Enter WP Design & Creation Comments Here
*/
/*////////// GENERAL //////////*/
body {}
#container {}
#container2 {}
#container3 {}
/*////////// TYPEOGRAPHY //////////*/
h1 {}
h2 {}
h3 {}
h4 {}
p {}
a {}
a:hover {}
a:visited {}
/*////////// HEADERS //////////*/
#header {}
/*////////// CONTENT //////////*/
#content {}
/*////////// SIDEBARS //////////*/
#sidebarLT {}
#sidebarRT {}
/*////////// NAV //////////*/
/*////////// FORMS //////////*/
/*////////// FOOTER //////////*/
#footer {}
/*////////// IMAGES //////////*/
/*////// FUN CLASSES ///////////*/
/*any little extra flares and fun design
elements you want to add can go here*/
Referring back to our sketch, we'd like our theme to have a standard header that stretches across three columns—the left column being the main content or blog posts, the middle column being our side bar, and a third column on the far right that will hold our own custom feature links and/or advertisements. A footer will run across the bottom of all three columns, naturally falling beneath the longest extending column, no matter which of the three it is.
Let's start off with some very basic code within our <body> tag to get that going. I've included relevant id names on each div in order to keep track of them and later to assist me with my CSS development. You'll also note, I've placed in XHTML comments <!--//-->, which explain what each div is meant to do and where it's closing div tag is.
... <body> <a name='top"></a><!--anchor for top--> <div id="container"><!--container goes here--> <div id="header"> <em>Header:</em> background image and text elements for header will go inside this div </div><!--//header--> <!-- Begin #container2 this holds the content and sidebars--> <div id="container2"> <!-- Begin #container3 keeps the left col and body positioned--> <div id="container3"> <!-- Begin #content --> <div id="content"> <em>Main Content:</em> Post content will go here inside this div </div><!-- //content --> <!-- #left sidebar --> <div id='sidebarLT"> <em>Left Side Bar:</em> Will contain WordPress content related links </div><!--//sidebarLT --> </div><!--//container3--> <!-- #right sidebar --> <div id='sidebarRT"> <em>Right Side Bar:</em> This will include additional ads, or non-content relevant items. </div><!--//sidebarRT --> <div id="pushbottom"> </div><!--//this div will span across the 3 divs above it making sure the footer stays at the bottom of the longest column--> </div><!--//container2--> <div id='top_navlist"> <em>Top Nav:</em> For reading through straight text, it's best to have links at bottom (css will place it up top, for visual ease of use) </div><!--//top_navlist--> <div id="footer"> <em>Footer:</em> quick links for CSS design users who've had to scroll to the bottom plus site information and copyright will go here </div><!--//footer--> </div><!--//container--> </body> ...
The following screenshot is not much to look at, but it can help recognize our semantic goals for content order at work.
Looking at the previous screenshot, we can see that if a search engine bot or someone using a text-only browser or mobile device arrived and viewed our site. The following is the order they'd see things in:
- Header: Because it's good to know whose stuff you're looking at
- Main content: Get right to the point of what you're looking for
- Left column content: Under the main content, we should have the next most interesting items—features list, category (sometimes referred to as columns links), and archives (sometimes called "Past Issues" links)
- Right column content: It is the secondary information such as advertisements and non-content related items
- Top page navigation: Even though in the design this will be on the top, it's best to have it at the bottom in text-only viewing
- Footer information: If this was a page of real content, it's nice to see whose site we're on again, especially if we've been scrolling or crawling down for some time
Note
Moving navigation to the bottom:
Some SEO experts believe that another reason to semantically push the navigation items down the page after the body of content as far as possible is that it encourages the search engine bots to crawl and index more of the page's content before wandering off down the first link it comes to. The more content the bot can index at a time, the sooner you'll be displayed with it on the search engine. Apparently, it can take months before a site is fully indexed, depending on its size. I have no idea if this is actually true, but it's inline with my semantic structure based on usability, so no harm done. You'll have to tell us at Packt Publishing if you think your content is getting better SE coverage based on this structure.
- CorelDRAW X6圖形設(shè)計(jì)立體化教程
- Microsoft Forefront UAG 2010 Administrator's Handbook
- Dreamweaver基礎(chǔ)與實(shí)戰(zhàn)教程
- 從零開(kāi)始：Flash CS6中文版基礎(chǔ)培訓(xùn)教程
- AutoCAD Civil 3D 2018 場(chǎng)地設(shè)計(jì)實(shí)例教程
- Photoshop CS6中文版基礎(chǔ)培訓(xùn)教程
- DWR Java AJAX Applications
- 下一代空間計(jì)算：AR與VR創(chuàng)新理論與實(shí)踐
- Illustrator平面設(shè)計(jì)立體化教程：Illustrator 2021（微課版）
- 印象筆記留給你的空間2.0：個(gè)人知識(shí)管理實(shí)踐指南
- Photoshop CS6實(shí)戰(zhàn)基礎(chǔ)培訓(xùn)教程（全視頻微課版）
- SPSS統(tǒng)計(jì)分析
- OpenCart 1.4 Template Design Cookbook
- 中文版Photoshop CS6經(jīng)典自學(xué)教程
- Photoshop+CorelDRAW平面設(shè)計(jì)案例實(shí)戰(zhàn)：從入門(mén)到精通（視頻自學(xué)全彩版）