Kevin Thompson | Blog

iPhone & iPad Browser Testing Using the iOS Simulator

2011-07-25T02:31:39+00:00

On more than one occasion I’ve had clients, as well as fellow designers and developers, ask me to assist them in building a mobile (or iPhone specific) version of their website, following their request immediately with something like, “You do have an iPhone, right?”

I do happen to have an iPhone (although no iPad), but I rarely need to pick it up when developing and testing websites for iOS devices. Instead, I use the iOS Simulator.

Why Should You Use iOS Simulator?

Beyond simply being able to test websites on Mobile Safari without having a physical device, iOS Simulator has a few other advantages.

Local Development Sites – Using the iOS simulator, you can easily access development sites on your local machine that might otherwise be difficult to do so.
Physical Keyboard – Instead of pecking away at on onscreen keyboard, you can save yourself a bit of time using the real thing.
Multiple Environments – Easily test iPhones and iPads of varying screen resolutions in both possible orientations.

Getting Started

Getting up and running with the iOS Simulator is extremely simple and really takes just two quick steps:

Install Xcode from the Mac App Store (Free)
Launch iOS Simulator

Once Xcode is in stalled, The iOS Simulator can be found at /Developer/Platforms/iPhoneSimulator.platform/Developer/Applications/iPhone Simulator.app

The iOS Simulator can also be found and launched through Spotlight, ⌘ + space, but it may take time for Spotlight to index the new files. If you’re using an application launcher such Alfred, you might need to add /Developer to the applications scope.

After opening the iOS Simulator, simply launch Mobile Safari and direct the browser to your website of choice.

Tips

Using the ⌘ + ← and ⌘ + → hotkeys you can quickly change the orientation of the iOS device.
You can assign hotkeys to various iOS devices using the Keyboard Shortcuts panel of the Keyboard Preferences pane in System Preferences (see http://support.apple.com/kb/ht2490#l4)
Script debugging can be enabled for Mobile Safari through the iOS Settings app under the Safari tab.

Hiding JavaScript-Dependent Content

2011-07-16T00:22:11+00:00

When implementing various JavaScript-dependent solutions such as image sliders and accordions, its easy to start throwing around display:none; attributes in your CSS to avoid seeing a flash of content before it’s removed by your JavaScript, but there’s another way to achieve the same result without alienating users that may have JavaScript disabled.

In order to ensure that your content remains visible when users happen to encounter it with JavaScript disabled, avoid hiding elements with CSS alone. Instead, apply a simple class to your tag early during page rendering, then prefix JavaScript-dependent CSS with that class.

Example

HTML

Available on Github »

CSS

Available on Github »

By using this method, you’ve first verified that JavaScript is enabled before hiding content that your user may otherwise be deprived of.

Placeholder Image Services

2011-03-10T20:07:49+00:00

From time to time, I find myself needing to create a quick HTML document to exemplify a concept, or to explore and alternative layouts in an existing project. When these quick and dirty prototypes need to include some form of imagery, I turn to one of my favorite placeholder image services.

Depending on the type of page I’m creating (wireframe, mockup, whimsical tomfoolery), I typically choose from one of three services.

Placehold.it

Placehold.it is a simple, yet versatile, solution that I often use when creating wireframes. When wireframing, I typically do not want to portray any particular visual aesthetic, so the bare, monochromatic images from Placehold.it are ideal.

These images can be passed as little as the image width, or as much as the width, height, format, color, and text:

FlickHoldr.com

When I need images with a bit more substance, such as when I’m mocking up a new layout for an existing site, I’ll often use FlickHoldr.com, which can pull images based on a set of tags from Flickr, to find images that suit the project.

FlickHoldr.com requires you send at least the width an height parameters of your image, but unlike Placehold.it, you can also specify tags, whether or not an image is black and white, and also an offset, which allows you to pull different images for the same size and tags:

Placekitten.com

Of the three, Placekitten.com tends to get the least use, but there’s still that rare occasion where you just need pictures of kittens. Placekitten.com doesn’t accept many parameters, in fact all they accept is width, height, and an option for black and white images:

All three of these are great services that can help expedite your workflow, and while I’ve given you a few examples here, I’d recommend clicking through to each of them and reviewing their options. Figure out what works for you and have fun. If you know of any other placeholder image services, let me know in comments below!

Securing Your Staging Environment

2011-03-09T21:02:59+00:00

While working as a part of a team or with a remote client, it’s often beneficial to have a staging environment accessible outside of your local office or VPN for quality assurance, editorial review, or client approval. However, when configuring your staging environment, there are several precautions you should take in order to guarantee the security and privacy of your work.

Restrict Search Engine Access

In order to stop users from finding your staging environment in search engines, and also to avoid any duplicate content issues that could negatively impact the rankings of your production site, you’ll want add a restriction to the robots.txt file at the public root of our sites:

User-agent: *
Disallow: /

These two lines alone, when added to our robots.txt file, will tell search engines to ignore all content on the site beginning at the root URL.

Note: Be sure to remove these rules from the robots.txt file on your production site, otherwise it will not be indexed by search engines.

Require User Login

While adding a rule to your robots.txt file will stop search engines from indexing your staging environment, it will still be possible for users to access it unless you implement some form of user authentication. If you’re using an editorial platform or content management system such as Wordpress or ExpressionEngine, there is typically an option available in the site’s configuration, or a plugin that can be installed that will disable access to all unauthorized users.

For example, in ExpressionEngine, this option can be found in Admin > General Configuration > Is system on?. Once this option is changed to “no”, only member groups who’ve been allowed to view the site in offline mode will be able to access it.

HTTP Authentication

If you’re not using a platform that’s already capable of restricting user access, or you’ve yet to build user authentication into your site and you’re hosting the project on Apache, you can use basic HTTP authentication to limit access.

To create your HTTP authentication files, first create a file named .htpasswd and place it in your site root (take note of the full server path to this file as you’ll need it in the next step). Next, use the htaccesstools.com htpassword generator to create username and password pairs that will be added to your .htpasswd file. After adding each username and password pair to your .htpasswd file, use the htaccess authentication generator to create the authentication rules that will be added to your website’s .htaccess file.

Once these steps have been completed, when accessing a secure area of your site, you should be prompted to enter your username and password.

What steps do you take to secure your staging or beta environments? Share your tips in the comments below!

Discovering Version Control & Deployment Systems

2011-03-06T16:44:08+00:00

For the last few years, I’ve managed and deployed my code using archaic, time consuming methods. Version control meant duplicating and renaming folders, and deployment was simply dragging and dropping files into an ftp client.

While I had worked with version control systems in the past, I had yet to reach a point where I felt particularly comfortable working with them and, at the time, they seemed to be more of an inconvenience than anything. I did however recognize the potential benefits of using a VCS, so I continued to follow the growth of systems such SVN and Git.

Enter Github

Although Github has been around for several years, it was only recently that I found myself using the site on an almost daily basis, following links from various open source projects or for addons and applications being developed by my friends and colleagues. Once I realized how much I had come to enjoy following and exploring repositories on Github, I knew I needed to make a greater effort in adopting some sort of version control system myself.

I began researching SVN, Git, and Mercurial in greater detail, but ultimately articles such as “How I use Git” and “A successful Git branching model”, along with my new found affinity for Github, lead me to use Git over the alternatives. I breezed through a few quick tutorials on Git and before long I had created a number of repositories on Github and was thoroughly enjoying every branch, commit, and merge. For whatever reason, where previous version control systems had been difficult to adopt, Git just clicked.

While this new found workflow made development a breeze, I was still fumbling my way through deployment. Since it was easy enough to clone a repository with Git, I decided to clone a repository on the production server, then shell into the server and issue a git pull when I needed to deploy. While this was simpler than manually transferring files via FTP, it still required a few too many steps to make deploying my code the casual process I wanted it to be. To further simplify things, I wrote a shell script and setup a dedicated user for deployment on each server so that I could easily issue a command on my local machine and off the code would go. This, again, was another degree simpler, but the maintenance and management of these scripts and users still stole time away from development.

Enter Beanstalk

While researching Git, Beanstalk was also mentioned fairly frequently in more recent articles. Beanstalk is a service that, for a small fee, will quickly deploy code from a Git or SVN repository over FTP with little to no effort. I decided to give Beanstalk a shot and signed up for their trial account. If you’re already familiar with Git or SVN, Beanstalk makes deployment a breeze. Once you’ve started your account, you’ll need to define your servers and configure deployment for each.

In my case, I typically have a staging environment and a production environment (with development being done on my local machine). I configure Beanstalk to automatically deploy my staging branch to my staging server on each push, and my master branch to my production server manually from the Beanstalk interface, or when I append [deploy:production] to a commit message in my master branch (or on a commit message merged into the master branch). With this configuration, it’s become trivial to deploy my code to either environment.

The addition of Git and Beanstalk to my workflow has not only simplified the management and deployment of code, but it’s also allowed me to spend more time doing what I truly enjoy, developing web applications.

Completely remove index.php from ExpressionEngine URLs

2011-03-04T13:30:42+00:00

While there are a number of known solutions for removing index.php from ExpressionEngine URLs, few developers realize that although URLs now resolve without index.php, the previous URLs including index.php also still exist.

The Example

At the time of this writing, if you were to visit http://expressionengine.com/index.php/overview/ or http://expressionengine.com/overview/, you’d be presented with the exact same page. Having the same content resolve at two distinct URLs can potentially harm your search engine rankings and disrupt your analytics.

The Rules

Available on Github »

The Story

A few weeks ago, while optimizing an ExpressionEngine installation, I was working to ensure that all invalid URLs either redirected to the appropriate URL, or returned a 404 error as necessary. During this process, I realized that URLs beginning with index.php still resolved, even though I thought I had removed index.php completely from URLs. I struggled for a few hours with various mod_rewrite rules in my .htaccess file but they all lead me into redirect loops. I ultimately settled on adding a tag to all pages and added a rule to my robots.txt file that would stop spiders from crawling the additional URLs.

Although duplicate content was no longer a concern, as search engines should no longer see the index.php URLs, the fact that they existed, and that a user could potentially find the duplicate URL, still bothered me. I could have redirected users using PHP, but in this instance it seemed like a bit of a hack, and I couldn’t shake the feeling that there had to be a way to solve this with a mod_rewrite rule. I happened to be working through this issue on a thursday evening, so I decided to pop into the weekly ExpressionEngine Help Chat to see if anyone else had come across it.

I asked my question and received a number of responses confirming the issue, but not offering much in the way of a solution. I left the chat open and continued tinkering with my .htaccess file. After a while I decided to check back in on the EE Help Chat, and to my surprise, Erick Reagan and Nevin Lyne had worked out a potential solution:

RewriteCond %{THE_REQUEST} ^[^/]*/index\.php [NC]
RewriteRule ^index\.php(.+) $1 [R=301,L]

I quickly modified my .htaccess file and sure enough, this new rule was able to catch URL requests beginning with index.php and issue a 301 redirect to the correct URL. The trick to circumventing the redirect loops I was encountering was using %{THE_REQUEST} to match the request string as opposed to the actual URL.

Thanks to Erik and Nevin my OCD has been suppressed, for now.

The Update

In the comments, Manuel pointed out the fact that the rules suggested by Erik and Nevin would break any POST request sent to an index.php URL. To resolve this, he suggested adding the following condition to the rewrite (which has already been included in the example above) that would restrict it to only GET requests:

RewriteCond %{THE_REQUEST} ^GET

Init();

2011-03-01T16:51:19+00:00

I’ve oft longed to begin writing in some capacity; likely documenting or dissecting code and disseminating the odd amounts of web development knowledge I’ve accumulated over the years. Unfortunately, past attempts have failed as I find myself fumbling around in PhotoShop, manipulating pixels to no end in hopes of finding the “perfect” design for my phantom content.

Time for a change

Over the last few weeks, I’ve pieced together a relatively simple design and configured the barest of ExpressionEngine installations. The site now allows me to post simple blog posts and project entries, and for you, the reader, to navigate them in some capacity. I’ve set a goal for myself to produce at least one post per week, and at least one substantial post per month.

I hope to avoid posting trivial links, photos, or comments to this blog (but you’re welcome to follow me on twitter if you’re into that sort of thing), and I hope that over time it will serve as a valuable resource my peers and for fledgling designers and developers

I’m excited to finally begin producing content for a community that has fostered my growth as a developer for the past five years, and I hope that you’ll enjoy what I have to offer.