Posted 01.12.2015

Designing before the Design Phase

When I was in college, I was told that one of the most healthy disciplines I could pick up was to sketch everything, first. Pen and paper are your friend. My professors would make us turn in our preliminary sketches to try to enforce this mentality. Even though, no one is forcing me to do that now, it’s still a good habit that I continue to practice.

Sketchbook


Visual Research

When I start each project, I start with visual research. I know this sounds like a fluff term, but it’s probably one of the most defining steps in the process. If I’m working on a piece for middle aged women, I’ll might pick up Real Simple, O, Vogue, and Martha Stewart magazines. These are things that these women are paying attention to. Each of these magazines have spent millions of dollars in research to determine trends. Why not take cues from them in determining what’s popular?

Visual research doesn’t have to be all about the audience, though, it can also be about content. For example, if I’m working on a site that’s copy heavy, I might look at other sites (CNN.com and USAToday) that face the same “problem” and take notes on how they solve it. How many columns did they use? Do they show the full article? excerpts? or headlines?

I’ll take all the images that I find and post them on my wall in my office. This helps me think in a particular stylistic direction, as well as, make connections based on what I’ve seen.

Mood board of Inspiration

A secret about creativity:

“Creativity is just connecting things. When you ask creative people how they did something, they feel a little guilty because they didn’t really do it, they just saw something. It seemed obvious to them after a while. That’s because they were able to connect experiences they’ve had and synthesize new things. And the reason they were able to do that was that they’ve had more experiences or they have thought more about their experiences than other people.

“Unfortunately, that’s too rare a commodity. A lot of people in our industry haven’t had very diverse experiences. So they don’t have enough dots to connect, and they end up with very linear solutions without a broad perspective on the problem. The broader one’s understanding of the human experience, the better design we will have."

Steve Jobs

It’s true. I take screenshots all the time. I’ll take pictures on my phone when I’m out and about. I keep everything in my Evernote account. (I wrote a post about it, too.)

Evernote Screenshot


Create a Moodboard

With a few of my clients, I’ve started making mood boards. It’s essentially what I’ve done for myself in the visual research phase, so it’s just a matter of sharing what I’ve found with the client. I’ve found that a lot of times the design vocabulary I use is different than theirs. So, if we have actually images we can point to, it guarantees that we’re both talking about the same thing. By getting their feedback early on, it let’s me know if I'm moving in the right direction. Do they like large, bold typography? large header images? muted color palette?

mood-board

I submitted a mood board to a client a couple of months ago and they came back and said, “This looks great, but it’s not at all what we want.” I said, “Perfect! The mood board did exactly what it was supposed to. It prevented me from spending a bunch of time designing something that you didn’t want.” From there, the mood board was able to launc us into a healthy conversation about what they really did want.


Sketching Everything

I design everything in my moleskine first. I’ll write down all the elements that we already agreed need to be on a particular page. I’ll write down on all the main navigation items. I’ll sketch different layout ideas, getting everything out of my head and onto paper. I’ll draw design elements: chevrons, rules, squares. I’ll make notes about how things will work responsively or if I want a section to animate in. I’ll write out the good and the bad. –Even if I know an idea is bad ahead of time, I’ll still write it down just to get it out of my head. Then, mentally, I can move on to other, better ideas. I can process a concept so much faster on paper than I can on the computer.

Moleskine Sketches

Moleskine Sketches

All this happens before a pixel is created in Photoshop or a single line of code is written.


What are some things that you do to prepare or inform your designs?



Updated 02.18.2015

How to install WordPress Plugins with Composer

What happens when you’re working with another WordPress developer, both developing a site locally, and someone updates the plugins on their local version? Their syntax and implementation may be different than yours if it was a major release. Suddenly, your local copy is broken. No fault of your own, just inconsistencies within the project.

What do you do? How do you prevent that from happening?

Let me present another scenario. Maybe this one will hit a little closer to home. Everytime you set up a WordPress site, you have to go through the same motions of downloading, installing, and activating a set of plugins. Maybe you’ve upped the ante a little bit and have a set of files on your local machine you just copy and paste everything over. Regardless, it’s still a pain when those plugins are updated. You have to visit each individual site, download the revised plugin code and replace the existing copy on your hard drive.

There must be an easier way…and there is!

Composer

I’ve started using Composer in my workflow, now most of those headaches have evaporated.


First things first

Let’s get Composer on your machine (COUGH Mac).

If you visit Composer’s site, it will explain your options in more detail. My preference, though, was to install it globally so that the composer command can be run anywhere on your system.

Open the Terminal and from the command line, run:

curl -sS https://getcomposer.org/installer | php
mv composer.phar /usr/local/bin/composer

NOTE

If the above fails due to permissions, run the mv line again with sudo.


On to the fun part…

Within your WordPress project directory, create a file called composer.json.

Wordpress Project Structure

As the extension suggests, this is a preference file, written in json that describes the plugins you’ll be installing and their version numbers.

Here’s my broilerplate. Feel free to copy it and use it as a stating point for your own projects.

Let me walk through it line by line.

The first few lines are pretty obvious. Name is the name of your project. You can replace ahaywood/PROJECTNAME with your information. Ideally, this should reflect your repo name.

Under authors, you can change “Amy (Haywood) Dutton” and “email” to include your name and email address respectively.

I’m going to jump down to line 27, where it reads extras. This defines the paths for both plugins and themes. As you can tell, I have a wp-content folder within the root that includes sub directories for plugins and themes.

On line 33, I’ve listed all the plugins that the project requires.

WP Packegist makes this easy. They mirror all the WordPress plugin and theme directories as Composer repositories.

What does that mean?

If you got to WordPress.org and find a plugin you want to implement, you can also find it on WP Packegist.

Take the first plugin I have listed: Backup WordPress. The part of the URL that comes after /plugin is the name of the WP Packegist repo.

Backup WordPress on WordPress.org

If you’re still not exactly sure what the name of the repo is, WP Packegist just implemented a search on their site. (Quick Note: I searched for “Backup WordPress,” first, and it did not return any results. But, searching for “backupwordpress” returned what I was looking for.)

Backup WordPress on  WP Packegist

Line 34 includes the full name of the repository: “wpackagist-plugin/backupwordpress”.

Screen_Shot_2015-01-08_at_6_27_33_PM

You can also see there are several other plugins from Wp Packegist that I’m referencing:

"wpackagist-plugin/backupwordpress" : "3.0.*",
"wpackagist-plugin/intuitive-custom-post-order" : "2.1.*",
"wpackagist-plugin/wordpress-seo" : "1.7.*",
"wpackagist-plugin/wp-help" : "1.3.*",
"wpackagist-plugin/user-admin-simplifier" : "0.6.*"

See the Pen Highlight WPackgist by Amy Dutton (@ahaywood) on CodePen.

The number following the name is the version number. The star serves as a wildcard. This means for Backup WordPress, versions 3.0.1 or 3.0.4 would both qualify. You also have the option of being explicit when you define the version number:

"wpackagist-plugin/backupwordpress" : “3.0.4”

NOTE

Just checking to see if you’re paying attention here. One of the cases I made for Composer was that it would lock down your plugin files. How does that work with wildcards and version numbers, obviously 3.0.1 and 3.0.4 are not the same. — For now you can just trust me or if it’s really bothering, skip down to the section where I talk about the composer.lock file.

The only reason that Composer knows to look at WP Packegist for these packages, is because it’s defined as a reference on line 11 and 12.

"type" : "composer",
"url"  : "http://wpackagist.org"

See the Pen Reference Wpackagist by Amy Dutton (@ahaywood) on CodePen.


Setting up a Premium WordPress Plugin (or a plugin on a private repository)

You’ll notice several other repositories are referenced on lines 14 – 25:

{
     "type" : "vcs",
     "url" : "git@bitbucket.org:ahhacreative/ahha<em>plugin</em>acf.git"
},
{
     "type" : "vcs",
     "url" : "git@github.com:ahaywood/ahha-gravityforms.git"
},
{
     "type" : "vcs",
     "url" : "git@github.com:ahaywood/ahha-wp-db-migrate-pro.git"
}

See the Pen Reference Repositories by Amy Dutton (@ahaywood) on CodePen.

and implemented on lines 39 – 41:

"ahaywood/ahha-gravityforms" : "1.8.*",
"ahaywood/ahha-wp-db-migrate-pro" : "1.3.*",
"ahhacreative/ahha<em>plugin</em>acf" : "5.1.*"

See the Pen XJpeYw by Amy Dutton (@ahaywood) on CodePen.

The reason these are different is because they are premium plugins and unavailable on WordPress.org. I still want to use Composer, though, so I’m hosting them in private GitHub and BitBucket repositories

First, I tell Composer what type of files they are (vcs) and where they are located (url).

{
     "type" : "vcs",
     "url" : "git@github.com:ahaywood/ahha-gravityforms.git"
},

See the Pen EaZwRq by Amy Dutton (@ahaywood) on CodePen.


NOTE

The URL is the SSH address, NOT HTTPS.

Then, I reference them as project requirements:

"ahaywood/ahha-gravityforms" : "1.8.*",

That takes care of our composer.json file. Woo hoo


Now let’s talk about actually getting that plugin set up correctly on your BitBucket, GitHub, Beanstalk, or whatever account.

Here’s what I do: Download the plugin code. Create a folder on my computer where this code can live. I actually have a folder called COMPOSER for this exact purpose.

Composer Files in Finder

Within the plugin folder, create a composer.json file

Screen Shot 2015-01-08 at 9.13.24 PM

This file is a lot smaller than before:

  • name is the name of the repository
  • type is the type of file it is. — It could be “wordpress-plugin” or “wordpress-theme”. (Remember, when we talked about installer-paths in our first composer.json file? We defined the install paths for both a wordpress-plugin or wordpress-theme. Line 29 and 30. It actually looks at this line to know what the type of file it is and to make sure it gets installed in the right place.)
  • require this line refers tothe version of composer we’re running, NOT the version of the plugin. (Can you tell I’ve gotten that mixed up before?)

Add this folder as a local repository. My app of choice is Tower.

Add a Local Repo in Tower

Run an initial commit.

Then, create a remote repository and link it to your repository.

Adding a remote repository in Tower

Now, you’ll also need to create a tag for your commit. This relates to the version number you’re referencing in your composer.json file. I like for my numbers to match the develpers’ release numbers.

In Tower, you can click on the branch, then right click on a particular commit. Select “Create New Tag from…” in the drop down menu.

Adding a tag within Tower

In GitHub, tags are referred to as releases. So, if you’d prefer to do it from their site, you can click on the Releases tab, then Draft a new release.

Release inside GitHub
Draft a New Release inside GitHub

Updating your plugin

When you get ready to update the plugin, simply download the latest release from the developers’ site, then replace all of the code in your local repository with theirs.

Commit it, tag it, and push it to your remote repository.


F-I-N-A-L-L-Y

Let’s download all these plugins and actually install them on WordPress.

Within the root of your project folder, inside the Terminal, run composer install.

Run composer install from Terminal

It might take a while, but when it’s done, you can go to the Plugin screen of WordPress and activate all your plugins.


Troubleshooting

If you get an error within the Terminal about not having the right privileges to download the plugins, it’s probably related to your SSH keys.

I actually wrote a blog post about Setting up a Site with SSH. I can’t tell you how many times I actually reference that post myself! The post refers to SpringLoops, but the same applies here. Scroll down to where it says, “First, you’ll need to check for existing SSH keys.” Once you copy the keys to your clipboard, you can go to your service of choice, find the section that says SSH keys, and paste them there.

SSH Keys within GitHub
SSH Keys within BitBucket


Update January 26, 2015

I just moved all my Composer plugins off of GitHub to BitBucket. I had some problems. I kept getting an error everytime I ran composer update:

composer_update_error

I was finally able to get it to work, but I had to change the version number within my main composer.json file to dev-master. In context:


"require": {
     "ahhacreative/ahha_plugin_gravityforms" : "dev-master",
     "ahhacreative/ahha_plugin_wpdbmigratepro" : "dev-master"
},

Then, within each individual plugin’s composer.json, I had to add a version and dist parameter:


{
  "name": "ahhacreative/ahha_plugin_wpdbmigratepro",
  "version": "master",
  "type": "wordpress-plugin",
  "require": {
    "composer/installers": "v1.0.6"
  },
  "dist": {
        "url": "git@bitbucket.org:ahhacreative/ahha_plugin_wpdbmigratepro.git",
        "type": "git"
    }
}

Update February 18, 2015

I just ran into an issue when I was trying to deploy my site via capistrano: No submodule mapping found in .gitmodules for path.

No Submodule Mapping Found

Fortunately, this article pointed me in the right direction. Within my root directory, there’s a file called .gitmodules, I opened it up and all that was listed was the WordPress submodule:

[submodule "wp"]
	path = wp
	url = git://github.com/WordPress/WordPress.git

I added the following lines:

[submodule "ahha_plugin_acf"]
 	path = wp-content/plugins/ahha_plugin_acf
 	url = git@bitbucket.org:ahhacreative/ahha_plugin_acf.git
[submodule "ahha_plugin_gravityforms"]
 	path = wp-content/plugins/ahha_plugin_gravityforms
 	url = git@bitbucket.org:ahhacreative/ahha_plugin_gravityforms.git
[submodule "ahha_plugin_wpdbmigratepro"]
 	path = wp-content/plugins/ahha_plugin_wpdbmigratepro
 	url = git@bitbucket.org:ahhacreative/ahha_plugin_wpdbmigratepro.git

Problem solved.


composer.lock

You’ll also notice that now, in addition to your composer.json file, there should be a composer.lock file. This file locks things down. It records the exact version of the file being installed.

If you want to update your site, simply go to the composer.json file, update the version numbers and then go to your project folder, inside the Terminal, and run composer update. Yep! That simple.


This seems awfully complicated…

Like a lot of things in the dev world, it can be a lot up front. That’s the learning curve talking. But, once that’s mastered, things go a whole lot faster. So, here’s my process now:

  1. Create a WordPress project using Yeoman.
  2. Within the root folder, create a composer.json file, copying and pasting my own GitHub boilerplate gist.
  3. Go to my project in the Terminal and type cu (I have Oh My Zsh! installed with the composer plugin activated.)

That’s it! 3 steps!



Posted 07.13.2010

My Blogging Workflow

As I’m continuing to challenge myself with the direction of my blog, I’ve tried to do a better job on the planning side. Unfortunately, you don’t get a chance to see that side of things. So, I thought I’d share what works for me.


Scheduling


I keep a Numbers grid (Excel for Mac) that I update at least once a week that tells me what I need to post everyday. It has 8 columns: the date, the day of the week, and a column for each category on my blog. Once I’ve published a post, I’ll change the background color of the cell to yellow so I can keep track of what I’ve accomplished.

For a while, I tried planning a month out, but the problem? I’d find things that I’d rather write about sooner. Or, things I planned to write about at the end of the month were already obsolete. Remember, it’s just a plan.


Content Audit


I’ve talked about this before. In Kristina Halvorson’s book, Content Strategy for the Web, she talks about developing a content audit: going through your site and keeping track of all the content that you’ve posted. It’s been great for several reasons

  • Big picture for what’s on my site
  • Reference when I’m linking between my blog posts
  • Knowing what content needs to be updated

This grid is huge! I have 11 columns. Then, there’s a row for every page (right now I’m at 160).

  1. ID Every page has an ID
  2. Date The date that the post was published
  3. Title The title of the post
  4. Link The page URL
  5. Summary This is to help me remember the content that’s on each page
  6. Category These are the categories (i.e. My Life, Programming, Photography, Design, Finder’s Keepers, Web 101 — obviously your cateogries will look different) associated wtih a given post
  7. Type Your grid may or may not need this column. I have all my posts organized by the type of post (i.e. link, post, movie, picture, post, or quote)
  8. Notes These are reminders to me of what I need to go back and update. For example, I have a whole series on jQuery. I want to go back and create a series page and link all those pages together. My reminder lives here.
  9. Tags This is a list of tags for each post
  10. Meta Keywords This is for SEO (Search Engine Optimization). If you were at Google, this is a list of all the keywords that I think you might use to find my post
  11. Meta Description When you’re at Google and the summary of site appears next to my link, this is where it’s pulling that from

It’s a lot of work to keep this updated. Honestly, I still have a lot of gaps that I need to go back and fill in. It might be contrary to what Kristina Halvorson suggests, but I update this once a week when I do my scheduling (I think she recommends updating it everytime you write a post).


Brainstorming for Future Posts


I use a free Mac program called MindNode. There’s also a web site (MindMeister) that achieves does the same thing, for all you PC people.

MindNode allows me to create a mind map with all my post ideas. I’ll add to this throughout the week as I think of things. (Usually ideas will come while I’m writing or while I’m reading other blogs.)

When I get ready to schedule, I’ll pull out my mind map.


Writing blog posts in Markdown

Markdown is an abbreviated coding language. Hopefully I didn’t scare anyone, because the people I probably scared are the people that would love Markdown the most.

John Gruber of Daring Fireball created Markdown.  He explains it as

a text to HTML conversion for web writers

It’s probably easier that I **show** you, instead of just **telling** you.

Normally, if I wanted a link and I were coding it in HTML, I would type:

<a href="http://www.amyhaywood.com">Visit my site</a>

but, with Markdown, I just type this instead:

[Visit my site](http://www.amyhaywood.com) 

I like to code as much as the next person, but Markdown is so much easier to read! Haven’t sold you yet? Here’s the HTML for an ordered list:

<ul>
	<li>Item one</li>
	<li>Item two</li>
	<li>Item three</li>
</ul>

But, Markdown is simply:

* Item one
* Item two
* Item three

If this interests you, you can look at John Gruber’s site for a complete list of Markdown syntax or if you’re interested in learning more about HTML, I’ve written a post, A Crash Course in HTML…in English.


Writing blog posts in Notational Velocity


I generally write my blog posts in Notational Velocity. It’s a VERY generic text editor, similar to Notepad if you’re a Windows user or an even more dumbed down version of TextEdit if you’re a mac user. I love it for a couple of reasons.:

  • I can search (bar at the top)
  • It syncs. I have my personal laptop and work laptop syncing through Dropbox. I also have my personal computer (only) syncing with my iPhone and iPad through SimpleNote. This means, no matter where I’m at, I can work on a blog post draft. If I’m going through my RSS feeds at lunch and find a link and think “That would be great for today’s five post,” I pop open Notational Velocity, quick copy and paste. When I get home, everything syncs automatically, I can pick up right where I left off.

As soon as I’ve finished writing, I’ll copy and paste the post into TextMate. Then, go to *Bundles > Markdown > Convert Document to HTML. * It will do exactly what it sounds like it will do, converts everything to HTML, adding in all my tags. Then, I copy and paste everything into Expression Engine. This might be too cumbersome for some, but it works for me. —that’s the important part. Find something that works for you.

If you’re interested in this setup, here are a few links that can help:

NOTE I have a special build of Notational Velocity. Steven Frank forked the code to create a third pane for MarkDown.

NOTE If you’re syncing your computers with Dropbox, you can only have one of your computers sync with SimpleNote, otherwise you’ll create an infinite loop and you’ll end up with duplicate posts.