Local Dev Environments For Newbies Part 1: AMP on Mac OSX

There are many cases where having a local development environment is helpful and it is a relatively straightforward thing to do, even if you are new to development.  However, the blessing and the curse is that there are many, many tutorials out there attempting to show you how.  This series of posts will aim to walk through some basic steps with detail, as well as pass on some tips and tricks for setting up your own local dev box.

First, what do I mean by a local development environment?  This is a setup on your computer which allows you to code and tweak and test in a safe environment.  It’s a great way to hammer on a new application with relatively low stakes.  I am currently installing dev environments for two purposes: to test some data model changes I want to make on an existing Drupal site and to learn a new language so I can contribute to an application.  For the purposes of this series, we’re going to focus on the AMP stack – Apache, MySQL and PHP – and how to install and configure those systems for use in web application development.

Apache is the web server which will serve the pages of your website or application to a browser.  You may hear Apache in conjunction with lots of other things – Apache Tomcat, Apache Solr – but generally when someone references just Apache, it’s the web server.  The full name of the project is the Apache HTTP Server Project.

PHP is a scripting language widely used in web development.  MySQL is a database application also frequently used in web development.  “Stack” refers to the combination of several components needed to run a web application.  The AMP stack is the base for many web applications and content management systems, including Drupal and WordPress.

You may have also seen the AMP acronym preceded by an L, M or W.  This merely stands for the operating system of choice – Linux, Mac or Windows.  This can also refer to installer packages that purport to do the whole installation for you, like WAMP or MAMP.  Employing the installer packages can be useful, depending on your situation and operating system.  The XAMPP stack, distributed by Apache Friends, is another example of an installer package designed to set up the whole stack for you.  For this tutorial though, we’ll step through each element of the stack, instead of using a stack installer.

So, why do it yourself if there are installers?  To me, it takes out the mystery of how all the pieces play together and is a good way to learn about what’s going on behind the scenes.  When working on Windows, I will occasionally use a .msi installer for an individual component to make sure I don’t miss something.  But installing and configuring each component individually is actually helpful.

Tips

Before we begin, let’s look at some tips:

  • You will need administrative rights to the computer on which you’re installing.
  • Don’t be afraid of the command line.  There are lots of tutorials around the web on how to use the basic commands – for both Mac (based on UNIX) and Windows.  But, you don’t need to be an expert to set up a dev environment.  Most tutorials give the exact commands you need.
  • Try, if possible, to block off a chunk of time to do this.  Going through all the steps may take awhile, from an hour to an afternoon, especially if you hit a snag.  Several times during my own process, I had to step away from it because of a crisis or because it was the end of the day.  When I was able to come back later, I had some trouble remembering where I left off or the configuration options I had chosen.  If you do have to walk away, write down the last thing you did.
  • When you’re looking for a tutorial, Google away.  Search for the elements of your stack plus your OS, like “Apache MySQL PHP Mac OSX”.  You’ll find lots, and probably end up referencing more than one.  Use your librarian skills: is the tutorial recent?  Does it appear to be from a reputable source?  If it’s a blog, are there comments on the accuracy of the tutorial?  Does it agree with the others you’ve seen?
  • Once you’ve selected one or two to follow, read through the whole tutorial one time without doing anything.  Full disclosure: I never do this and it always bites me.

Let’s get going with Recipe 1 – Install the AMP Stack on Mac OS X

Install the XCode Developer Tools

First, we install the developer tools for XCode.  If you have Mac 10.7 and above, you can download the XCode application from the App Store.  To enable the developer tools, open XCode, go to the XCode menu > Preferences > Downloads tab, and then click on “Install” next to the developer tools.  This tutorial on installing Ruby by Moncef Belyamani has good screenshots of the XCode process.

If you have Snow Leopard (10.6) or below, you’ll need to track down the tools on the Apple Developer Downloads Page.  You will need to register as a developer, but it’s free.  Note:  you can get pretty far in this process without using the XCode command line tools, but down the road as you build more complicated stacks, you’ll want to have them.

Configure Apache and PHP

Next we need to configure Apache and PHP.  Note that I said “configure”, not “install”.  Apache and PHP both come with OS X, we just need to configure them to work together.

Here’s where we open the Terminal to access the command line by going to Applications > Utilities > Terminal.

Open Terminal

Once Terminal is open, a prompt appears where you can type in commands.  The ” ~ ” character indicates that you are at the “home” directory for your user.  This is where you’ll do a lot of your work.  The “$” character delineates the end of the prompt and the beginning of your command.

terminalprompt

Type in the following command:

cd /etc/apache2

“cd” stands for “change directory”.  This is the equivalent of double-clicking on etc, then apache2, if you were in the Finder (but etc is a hidden folder in the Finder).  From here, we want to open the necessary file in an editor.  Enter the following command:

sudo nano httpd.conf

“sudo” elevates your permission to administrator, so that you can edit the config file for Apache, which is httpd.conf.  You will need to type in your administrator password.  The “nano” command opens a text editor in the Terminal window.  (If you’re familiar with vi or emacs, you can use those instead.)

nano

The bottom of your window will show the available commands.  The “^” stands for the Control key.  So, we want to search for the part to change, we press Control + W.  Enter php and press Enter.  We are looking for this line:

#LoadModule php5_module        libexec/apache2/libphp5.so

The “#” at the beginning of this line is a comment, so Apache ignores the line.  We want Apache to see the line, and load the php module.  So, change the text by removing the #:

LoadModule php5_module        libexec/apache2/libphp5.so

Save the file by press Control + O (nano calls this “WriteOut”) and press Enter next to the file name.  The number of lines written displays at the bottom of the window.  Press Control + X to exit nano.

Next, we need to start the Apache server.  Type in the following command:

sudo apachectl start

Now, go to your browser and type in http://localhost.  You should see “It Works!”Apache Browser Test

Apache, as mentioned before, serves web files from a location we designate.  By default, this is /Library/Webserver/Documents.  If you have Snow Leopard (10.6) or below, Apache also automatically looks to username/sites, which is a convenient place to store and work with files.  If you have OS 10.7 or above, creating the Sites folder takes a few steps.  On 10.7, go to System Preferences > Sharing and click on Web Sharing.  If there’s a button that says “Create Personal Web folder”, it has not been created, go ahead and click that button.  If it says, “Open Personal Website folder”, you’re good to go.

On 10.8, the process is a little more involved.  First, go to the Finder, click on your user name and create your sites folder.

sites

Next, we need to open the command line again and create a .conf file for that directory, so that Apache knows where to find it.  Type in these commands:

cd /etc/apache2/users
ls

The ls at the end will list the directory contents.  If you see a file that’s yourusername.conf (ie, mfrazer.conf) in this directory, you’re good to go.  If you don’t, it’s easy to create one.  Type the following command:

sudo nano yourusername.conf

So, mine would be sudo nano mfrazer.conf.  This will create the file and take you into a text editor.  Copy and past the following, making sure to change YOURUSERNAME to your user name.

<Directory "/Users/YOURUSERNAME/Sites/">
  Options Indexes MultiViews
  AllowOverride None
  Deny from all
  Allow from localhost
</Directory>

The first directive, Options, can have lots of different…well, options.  The ones we have here are Indexes and MultiViews.  Indexes means that if a browser requests a directory and there’s no index.html or index.php file, it will serve a directory listing.  Multi-Views means that browsers can request the content in a different format if it exists in the directory (ie, in a different language).  AllowOverride determines if an .htaccess file elsewhere can to override the configuration settings.  For now, None will indicate that no part can be overridden.  For Drupal or other content management systems, it’s possible we’ll want to change these directives, but we’ll cover that later.

The last two lines indicate that traffic can only reach this directory from the local machine, by typing http://localhost/~username in the browser.  For more on Apache security, see the Apache documentation.  If you would like to set it so that other computers on your network can also access this directory, change those last two lines to:

Order allow,deny
Allow from all

Either way, press Control + O to save the file and Control + X to exit.  Restart Apache for the changes to take effect using this command:

sudo apachectl restart

You may also be prompted at some point by OS X to accept incoming network connections for httpd (Apache); I would deny these as I only want access to my directory from my machine, but it’s up to you depending on your setup.

We’ll test this setup with php in the next step.

Test PHP

If you want to check php, you can create a new text document using your favorite text editor.  Type in:

<?php phpinfo(); ?>

Save the file as phpinfo.php in your username/sites directory (so for me, this is mfrazer > Sites)

Then, point your browser to http://localhost/~yourUserName/phpinfo.php  You should see a page of information regarding PHP and the web server, with a header that looks like this:

PHP Info Header

 

 

MySQL

Now, let’s install MySQL.  There’s two ways to do this.  We could go to the MySQL downloads page and use the installers.  The fantastic tutorials at Coolest Guy on the Planet both recommend this, and it’s a fine way to go.

But we can also use Homebrew, mentioned previously on this blog, which is a really convenient way to do things as long as we’re already using the command line.

First, we need to install homebrew.  Enter this at the command prompt:

ruby -e "$(curl -fsSL https://raw.github.com/mxcl/homebrew/go)"

Next, type in

brew doctor

If you receive the message: “Your system is raring to brew.” You’re ready to go.  If you get Warnings, don’t lose heart.  Most of them tell you exactly what you need to do to move forward.  Correct the errors and type in brew doctor again until you’re raring to go.  Then, type in the following command:

brew install mysql

That one’s pretty self-explanatory, no?  Homebrew will download and install MySQL, as of this writing version 5.6.10, but pay attention to the download to see the version – it’s in the URL.  After the installation succeeds, Homebrew will give some instructions on finishing the setup, including the commands we discuss below.

I’m going to pause for a second here and talk a little about permissions and directories.  If you get a “permission denied” error, trying running the command again using “sudo” at the beginning.  Remember, this elevates your permission to the administrator level.  Also, if you get a “directory does not exist” error, you can easily create the directory using “mkdir”.  Before we move on, let’s try to check for a directory you’re going to need coming up.  Enter:

cd /usr/local/var

If you are successfully able to change to that directory, great. If not, type in

sudo mkdir /usr/local/var

to create it. Then, let’s go back to our home directory by typing in

cd ~

Now, let’s continue with our procedure. First, we want to set up the databases to run with our user account.  So, we type in the following two commands:

unset TMPDIR
mysql_install_db --verbose --user=`whoami` --basedir="$(brew --prefix mysql)" --datadir=/usr/local/var/mysql --tmpdir=/tmp

The second command here installs the system databases; ‘whoami’ will automatically replace with your user name, so the above command should work verbatim.  But it also works to use your user name, with no quotes, (ie –user=mfrazer).

Next, we want to run the “secure installation” script. This helps you set root passwords without leaving the password in plain text in your editor. First we start the mysql server, then we run the installation scripts and follow the prompts to set your root password, etc:

mysql.server start
sudo /usr/local/Cellar/mysql/5.6.10/bin/mysql_secure_installation

After the script is complete, stop the mysql server.

mysql.server stop

Next, we want to set up MySQL so it starts at login. For that, we run the following two commands:

ln -sfv /usr/local/opt/mysql/*.plist ~/Library/LaunchAgents
launchctl load ~/Library/LaunchAgents/homebrew.mxcl.mysql.plist

The ln command, in this case, places a symbolic link to any .plist files in the mysql directory into the LaunchAgents directory.  Then, we load the plist using launchctl to start the server.

One last thing – we need to create one more link to the mysql.sock file.

cd /var/mysql/
sudo ln -s /tmp/mysql.sock

This creates a link to the mysql.sock file, which MySQL uses to communicate, but which resides by default in a tmp directory.  The first command places us in the directory where we want the link (remember, if it doesn’t exist, you can use “sudo mkdir /var/mysql/” to create it) and the second creates the link.

MySQL is ready to go!  And, so is your AMP stack.

But wait, there’s more…

One optional tool to install is phpMyAdmin.  This tool allows you to interact with your database through your browser so you don’t have to continue to use the command line.  I also think it’s a good way to test if everything is working correctly.

First, let’s download the necessary files from the phpMyAdmin website.  These will have a .tar.gz extension.  Place the file in your Sites directory, and double-click to unzip the file.

Rename the folder to remove the version number and everything after it.  I’m going to place the next steps below, but the Coolest Guy on the Planet tutorial referenced earlier does a good job of this step for OS 10.8 (just scroll down to phpMyAdmin) if you need screenshots.

Go to the command line and navigate to your phpMyAdmin directory.  Make a directory called config and change the permissions so that the installer can access the file.  This should looks something like:

cd ~/username/sites/phpMyAdmin
mkdir config
chmod o+w config

Let’s take a look at that last command: chmod changes the permissions on a file.  The o+w sets it so users who are not the directory’s owner can write to the file.

Now, in your browser, go to http://localhost/~username/sites/phpmyadmin/setup and follow these steps:

  1. Click on New Server (button on bottom)
  2. Click on Authentication tab, and enter the root password in the password field.
  3. Click on Save.
  4. Click on Save again on the main page.

Once the setup is finished, go to the Finder and move the config.inc.php file from the config directory into the main phpmyadmin directory and delete the config directory.  So in the end, it looks like this:

phpmyadminlast

Now, go to http://localhost/~username/sites/phpmyadmin in your browser and login with the root account.

You are ready to go!  In future parts of this series, we’ll look at building the AMP stack on Windows and adding Drupal or WordPress on top of the stack.  We will also look at maintaining your environment, as the AMP stack components will need updating occasionally.  Any other recipes you’d like to see?  Do you have questions? Let us know in the comments.

The following tutorials and pages were incredibly useful in writing this post.  While none of these tutorials are exactly the same as what we did here, they all contain useful pieces and may be helpful if you want to skip the explanation and just get to the commands:


How to Git

We have written about version control before at Tech Connect, most notably John Fink’s excellent overview of modern version control. But getting started with VC (I have to abbreviate it because the phrase comes up entirely too much in this post) is intimidating. If you are generally afraid of anything that reminds you of the DOS Prompt, you’re not alone and you’re also totally capable of learning Git.

DOS prompt madness

By the end of this post, we will still not understand what’s going on here.

But why should you learn git?

Because Version Control Isn’t Just for Nerds

OK, never mind, it is, it totally is. But VC is for all kinds of nerds, not just l33t programmers lurking in windowless offices.

Are you into digital preservation and/or personal archiving? Then VC is your wildest dream. It records your changes in meaningful chunks, documenting not just the final product but all the steps it took you to get there. VC repositories show who did what, too. If you care about nerdy things like provenance, then you care about VC. If co-authors would always use VC for their writing, we’d know all the answers to the truly pressing questions, like whether Gilles Deleuze or Félix Guattari wrote the passage “A concept is a brick. It can be used to build a courthouse of reason. Or it can be thrown through the window.”

Are you a web developer? Then knowing Git can get you on GitHub, and GitHub is an immense warehouse of awesomeness. Sure, you can always just download .zip files of other people’s projects, but GitHub also provides more valuable opportunities: you can showcase your awesome tools, your brilliant tweaks to other people’s projects, and you can give back to the community at whatever level you’re comfortable with, from filing bug reports to submitting actual code fixes.

Are you an instruction librarian? Have you ever shared lesson plans, or edited other people’s lesson plans, or inherited poorly documented lesson plans? Basically, have you been an instruction librarian in the past century? Well, I have good news for you: Git can track any text file, so your lessons can easily be versioned and collaborated upon just like software programs are. Did you forget that fun intro activity you used two years ago? Look through your repository’s previous commits to find it. Want to maintain several similar but slightly different lesson plans for different professors teaching the same class? You’ve just described branching, something that Git happens to be great at. The folks over at ProfHacker have written a series of articles on using Git and GitHub for collaborative writing and syllabus design.

Are you a cataloger? Versioning bibliographic records makes a lot of sense. A presentation at last year’s Code4Lib conference talked not only about versioning metadata but data in general, concluding that the approach had both strengths and weaknesses. It’s been proposed that putting bibliographic records under VC solves some of the issues with multiple libraries creating and reusing them.

As an added bonus, having a record’s history can enable interesting analyses of how metadata changes over time. There are powerful tools that take a Git repository’s history and create animated visualizations; to see this in action, take a look at the visualization of Penn State’s ScholarSphere application. Files are represented as nodes in a network map while small orbs which represent individual developers fly around shooting lasers at them. If we want to be a small orb that shoots lasers at nodes, and we definitely do, we need to learn Git.

Alright, so now we know Git is great, but how do we learn it?

It’s As Easy As git rebase -i 97c9d7d

Actually, it’s a lot easier. The author doesn’t even know what git rebase does, and yet here he is lecturing to you about Git.

First off, we need to install Git like any other piece of software. Head over to the official Git website’s downloads page and grab the version for your operating system. The process is pretty straight-forward but if you get stuck, there’s also a nice “Getting Started – Installing Git” chapter of the excellent Pro Git book which is hosted on the official site.

Alright, now that you’ve got Git installed it’s time to start VCing the heck out of some text files. It’s worth noting that there are software packages that put a graphical interface on top of Git, such as Tower and GitHub’s apps for Windows and Mac. There’s a very comprehensive list of graphical Git software on the official Git website. But the most cross-platform and surefire way to understand Git and be able to access all of its features is with the command line so that’s what we’ll be using.

So enough rambling, let’s pop open a terminal (Mac and Linux both have apps simply called “Terminal” and Windows users can try the Git Bash terminal that comes with the Git installer) and make it happen.

$ git clone https://github.com/LibraryCodeYearIG/Codeyear-IG-Github-Project.git
Cloning into 'Codeyear-IG-Github-Project'...
remote: Counting objects: 115, done.
remote: Compressing objects: 100% (73/73), done.
remote: Total 115 (delta 49), reused 108 (delta 42)
Receiving objects: 100% (115/115), 34.38 KiB, done.
Resolving deltas: 100% (49/49), done.
$ cd Codeyear-IG-Github-Project/

 

The $ above is meant to indicate our command prompt, so anything beginning with a $ is something we’re typing. Here we “cloned” a project from a Git repository existing on the web (line 1), which caused Git to give us a little information in return. All Git commands begin with git and most provide useful info about their usage or results. In line 2, we’ve moved inside the project’s folder with a “change directory” command.

We now have a Git repository on our computer, if you peek inside the folder you’ll see some text (specifically Markdown) files and an image or two. But what’s more: we have the project’s entire history too, pretty much every state that any file has been in since the beginning of time.

OK, since the beginning of the project, but still, is that not awesome? Oh, you’re not convinced? Let’s look at the project’s history.

$ git log
commit b006c1afb9acf78b90452b284a111aed4daee4ca
Author: Eric Phetteplace <phette23@gmail.com>
Date:   Fri Mar 1 15:27:47 2013 -0500

    a couple more links, write Getting Setup section

commit 83d92e4a1be0fdca571012cb39f84d86b21121c6
Author: Eric Phetteplace <phette23@gmail.com>
Date:   Fri Feb 22 01:04:24 2013 -0500

    link up the YouTube video

 

We can hit Q to exit the log. In the log, we see the author, date, and a brief description of each change. The terrifying random gibberish which follows the word “commit” is a hash, which is computer science speak for terrifying random gibberish. Think of it as a unique ID for each change in the project’s history.

OK, so we can see previous changes (“commits” in VC-speak, which is like Newspeak but less user friendly), we can even revert back to previous states, but we won’t do that for now. Instead, let’s add a new change to the project’s history. First, we open up the “List of People.mdown” file in the Getting Started folder and add our name to the list. Now the magic sauce.

$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   Getting Started/List of People.mdown
#
no changes added to commit (use "git add" and/or "git commit -a")
$ git add "Getting Started/List of People.mdown"
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   Getting Started/List of People.mdown
#
$ git commit -m "adding my name"
$ git status
# On branch master
nothing to commit, working directory clean
$ git log
commit wTf1984doES8th1s3v3Nm34NWtf2666bAaAaAaAa
Author: Awesome Sauce <awesome@sau.ce>
Date:   Wed Mar 13 12:30:35 2013 -0500

    adding my name

commit b006c1afb9acf78b90452b284a111aed4daee4ca
Author: Eric Phetteplace <phette23@gmail.com>
Date:   Fri Mar 1 15:27:47 2013 -0500

    a couple more links, write Getting Setup section

 

Our change is in the project’s history! Isn’t it better than seeing your name on Hollywood Walk of Fame? Here’s precisely what we did:

First we asked for the status of the repository, which is an easy way of seeing what changes you’re working on and how far along they are to being added to the history. We’ll run status throughout this procedure to watch how it changes. Then we added our changes; this tells Git “hey, these are a deliberate set of changes and we’re ready to put them in the project’s history.” It may seem like an unnecessary step but adding select sets of files can help you segment your changes into meaningful, isolated chunks that make sense when viewing the log later. Finally, we commit our change and add a short description inside quotes. This finalizes the change, which we can see in the log command’s results.

I’m Lonely, So Lonely

Playing around with Git on our local computer can be fun, but it sure gets lonely. Yeah, we can roll back to previous versions or use branches to keep similar but separate versions of our files, but really we’re missing the best part of VC: collaboration. VC as a class of software was specifically designed to help multiple programmers work on the same project. The power and brilliance of Git shines best when we can selectively “merge” changes from multiple people into one master project.

Fortunately, we will cover this in a future post. For now, we can visit the LITA/ALCTS Library Code Year‘s GitHub Project—it’s the very same Git project we cloned earlier, so we already have a copy on our computer!—to learn more about collaboration and GitHub. GitHub is a website where people can share and cooperate on Git repositories. It’s been described as “the Facebook of code” because of its popularity and slick user interface. If that doesn’t convince you that GitHub is worth checking out, the site also has a sweet mascot that’s a cross between an octopus and a cat (an octocat). And that’s really all you need to know.

Gangam Octocat

This is an Octocat. It is Awesome.


Good Design: Pleasing to the Eyes “and” Functional

Many librarians work with technology even if their job titles are not directly related to technology. Design is somewhat similar to technology in that aspect. The primary function of a librarian is to serve the needs of library patrons, and we often do this by creating instructional or promotional materials such as a handout and a poster. Sometimes this design work goes to librarians in public services such as circulation or reference. Other times it is assigned to librarians who work with technology because it involves some design software.

The problem is that knowing how to use a piece of design software does not entail the ability to create a great work of design. One may be a whiz at Photoshop but can still produce an ugly piece of design. Most of us, librarians, are quite unfamiliar with the concept of design. ACRL TechConnect covered the topic design previously in Design 101 – Part 1 and Design 101 – Part 2. So be sure to check them out. In this post, I will share my experience of creating a poster for my library in the context of libraries and design.

1. Background

My workplace recently launched the new Kindle e-book leader lending program sponsored by the National Network of Libraries of Medicine/Southeast Atlantic Region Express Mobile Technology Project. This project is to be completed in a few months, and we have successfully rolled out 10 Kindles with 30 medical e-book titles for circulation early this year. One of the tasks left for me to do as the project manager is to create a poster to further promote this e-book reader program. No matter how great the Kindle e-book lending program is, if patrons don’t know about it, it won’t get much use. A good poster can attract a lot of attention from library patrons. I can just put a small sign with “Kindles available!” written on it somewhere in the library. But the impact would be quite different.

2. Trying to design a poster

When I planned the grant budget, I included an budget item for large posters. But the item only covers the printing costs, not the design costs. So I started designing a poster myself.  Here are a few of my first attempts. Even to my untrained eyes, these look unprofessional and amateurish, however. The first one looked more like a handout than a poster. So I decided to make the background black.  That makes the QR code and the library logo invisible however. To fix this, I added a white background behind them. Slightly better maybe? Not really.

Kindle0

My first try doesn’t look so good!

Kindle1

My second attempt is only marginally better!

 

 

 

 

 

 

 

 

 

 

 

One thing I know about design is that an image can save or kill your work. A stunning image alone can make a piece of design awesome. So I did some Google search and found out this nice image of Kindle. Now it looks like that I need to flip the poster to make it wide.

Kindle2

The power of a nice image! Too bad it is copyrighted…

But there is a catch. The image I found is copyrighted. This was just an example to show how much power a nice image or photograph can have to the overall quality of a work of design. I also looked for Kindle images/photographs in Flick Creative Commons but failed to locate one that allows making derivatives. This is a very common problem for libraries, which tend to have little access to quality images/photographs. If you are lucky you may find a good image from Pixabay which offer very nice photographs and images that are in public domain.

Kindle3

Changed the poster setup to to make it wide.

3. What went wrong

You probably already have some ideas about what went wrong with my failed attempts so far. The font doesn’t look right. The poster looks more like a handout. The image looks amateurish in the first two examples. But the whole thing is functional for sure, some may say. It does the job of conveying the message that the library now has Kindle E-book readers to offer. Others may object. No, not really, the wording is vague, far from clear. You can go on forever. A lot of times, these issues are solved by adding more words, more instructions, and more links, which can be also problematic.

But one thing is clear. These are not pretty. And what that means is that if I print this and hang up on the wall around the library, our new Kindle e-book lending program would fail to convey certain sentiments that I had in mind to our library patrons. I want the poster to present this program as a new and exciting new service. I would like the patron to see the poster and get interested, curious, and feel that the library is trying something innovative. Conveying those sentiments and creating a certain impression about the library ‘is’ the function of the poster as much as informing library patrons about the existence of the new Kindle e-book reader lending program. Now the posters above won’t do a good job at performing that function. So in those aspects, they are not really functional. Sometimes beauty is a necessity. For promotional materials, which libraries make a lot but tend to neglect the design aspect of them, ‘pleasing to the eyes’ is part of their essential function.

4. Fixing it

What I should have done is to search for examples first that advertise a similar program at other libraries. I was very lucky in this case. In the search results, I ran into this quite nice circulation desk signage created by Saint Mary’s College of Maryland Library. This was made as a circulation desk sign, but it gave me an inspiration that I can use for my poster.

An example can give you much needed inspiration!

Once you have some examples and inspiration, creating your own becomes much easier. Here, I pretty much followed the same color scheme and the layout from the one above. I changed the font and the wording and replaced the kindle image with a different one, which is close to what my library circulates. The image is from Amazon itself, and Amazon will not object people using their own product image to promote the product itself. So the copyright front is clear. You can see my final poster below. If I did not run into this example, however, I would have probably searched for Kindle advertisements, posters, and similar items for other e-book readers for inspiration.

One thing to remember is the purpose of the design. In  my case, the poster is planned to be printed on a large glossy paper  (36′ x 24′). So I had to make sure that the image will appear clear and crisp and not blurry when printed on the large-size paper. If your design is going to be used only online or printed on a small-size item, this is less of an issue.

Final result!

5. Good design isn’t just about being pretty

Hopefully, this example shows why good design is not just a matter of being pretty. Many of us have an attitude that being pretty is the last thing to be considered. This is not always false. When it is difficult enough to make things work as intended, making them pretty can seem like a luxury. But for promoting library services and programs at least, just conveying information is not sufficient. Winning the heart of library patrons is not just about letting people know what the library does but also about how the library does things. For this reason, the way in which the library lets people know about its services and programs also matters. Making things beautiful is one way to improve on this “how” aspect as far as promotional materials are concerned. Making individual interactions personally pleasant and the transactions on the library website user-friendly would be another way to achieve the same goal. Design is a broad concept that can be applied not only to visual work but also to a thought process, a tool, a service, etc., and it can be combined with other concept such as usability.

Resources

While I was doing this, I also discovered a great resource, Librarian Design Share. This is a great place to look for an inspiration or to submit your own work, so that it can inspire other librarians. Here are a few more resources that may be useful to those who work at a library and want to learn a bit more about visual design. Please share your experience and useful resources for the library design work in the comments!

 


The Mobile App Design Process: A Tube Map Infographic

Last June I had a great experience team-teaching a week-long seminar on designing mobile apps at the Digital Humanities Summer Institute (DHSI). Along with my colleagues from WSU Vancouver’s Creative Media and Digital Culture (CMDC) program, I’ll be returning this June to the beautiful University of Victoria in British Columbia to teach the course again1. As part of the course, I created a visual overview of the process we use for app making. I hope you’ll find it a useful perspective on the work involved in crafting mobile apps and an aid to the process of creating your own.

topological map of the mobile app design process

A visual guide to the process of designing and building mobile apps. Start with Requirements Analysis in the upper-left and follow the tracks to Public Release. (Click for full-sized image.)

Creating the Tube Map:

I’m fond of the tube-map infographic style, also know as the topological map2, because of its ability to highlight relationships between systems and especially because of how it distinguishes between linear (do once) and recursive (do over and over) processes. The linear nature of text in a book or images in slide-deck presentations can artificially impose a linearity that does not mirror the creative process we want to impart. In this example, the design and prototyping loops on the tube-map help communicate that a prototype model is an aid to modeling the design process and not a separate step completed only when the design has been finalized.

These maps are also fun and help spur the creative process. There are other tools for process mapping such as using flowcharts or mind-maps, but in this case I found the topological map has a couple of advantages. First and foremost, I associate the other two with our strategic planning process, so the tube map immediately seems more open, fun, and creative. This is, of course, rooted in my own experience and your experiences will vary but if you are looking for a new perspective on process mapping or a new way to display interconnected systems that is vibrant, fun, and shakes things up a bit the tube map may be just the thing.

I created the map using the open source vector-graphics program Inkscape[3. http://inkscape.org/] which can be compared to Adobe Illustrator and Corel Draw. Inkscape is free (both gratis and libre) and is powerful, but there is a bit of a learning curve. Being unfamiliar with vector graphics or the software tools to create them, I worked with an excellent tutorial provided by Wikipedia on creating vector graphic topological maps3. It took me a few days of struggling and slowly becoming familiar with the toolset before I felt comfortable creating with Inkscape. I count this as time well spent, as many graphics used in mobile app and icon sets required by app stores can be made with vector graphic editors. The Inkscape skills I picked up while making the map have come in very handy on multiple occasions since then.

Reading the Mobile App Map:

Our process through the map begins with a requirements analysis or needs assessment. We ask: what does the client want the app to do? What do we know about our end users? How do the affordances of the device affect this? Performing case studies helps us learn about our users before we start designing to meet their needs. In the design stage we want people to make intentional choices about the conceptual and aesthetic aspects of  their app design. Prototype models like wireframe mock-ups, storyboards, or Keynotopia4 prototypes help us visualize these choices, eventually resulting in a working prototype of our app. Stakeholders can test and request modifications to the prototype, avoiding potentially expensive and labor intensive code revisions later in the process.

Once both the designers and clients are satisfied with the prototype and we’ve seen how potential users interact with it, we’re ready to commit our vision to code. Our favored code platform uses HTML 5, CSS 3, jQuery Mobile5, and PhoneGap6 to make hybrid web apps. Hybrid apps are written as web apps–HTML/JavaScript web sites that look and performlike apps–then use a tool like PhoneGap to translate this code into the native format for a device. PhoneGap translates a web app into a format that works with the device’s native programming environment. This provides more direct and thus faster access to device hardware and also enables us to place our app in official app stores. Hybrid apps are not the only available choice and aren’t perfect for every use case. They can be slower than native apps and may have some issues accessing device hardware, but the familiar coding language, multi-device compatibility, and ease of making updates across multiple platforms make them an ideal first step for mobile app design. LITA has an upcoming webinar on creating web apps that employs this system7.

Once the prototype has been coded into a hybrid app, we have another opportunity for evaluation and usability testing. We teach a pervasive approach that includes evaluation and testing all throughout the process, but this stage is very important as it is a last chance to make changes before sending the code to an app marketplace. After the app has been submitted, opportunities to make updates, fix bugs, and add features can be limited, sometimes significantly, by the app store’s administrative processes.

After you have spent some time following the lines of the tube map and reading this very brief description, I hope you can see this infographic as an aid to designing mobile web apps. I find it particularly helpful for identifying the source of a particular problem I’m having and also suggesting tools and techniques that can help resolve it. As a personal example, I am often tempted to start writing code before I’ve completely made up my mind what I want the code to do, which leads to frustration. I use the map to remind me to look at my wireframe and use that to guide the structure of my code. I hope you all find it useful as well.