You could say I’m a newbie when it comes to web development.

My background is in graphic design, but as Atomic’s newest designer, I’ve been doing some web work, too. Learning the programming ropes has been easier than I expected, though, thanks to my secret weapon: Codecademy. One of my fellow Atomic developers showed me the site, and it’s a novice coder’s dream.

Codecademy is an easy (and free!) way to learn jQuery, JavaScript, and the fundamentals of web development. Information is organized into step-by-step lessons, starting with the basics, like entering commands or performing simple math problems. And it’s fun—seriously. Each course wraps up with a project that requires you to put the skills you’ve just learned to work (I’ve built a virtual blackjack game, address book, and cash register on past levels). Codecademy teaches you to problem-solve with code.

In contrast to the Google-one-command-because-you-can’t-remember-how-to-use-it strategy that’s the tendency of many a developer, Codecademy shows you how commands work together. Each coding lesson draws on skills learned previously, making knowledge more likely to stick.

And it’s not just for beginners. Codecademy has tutorials all the way up to high-level programming. Even if you think you know it all, there are always cool shortcuts to learn. (I’ve learned tricks that shorten ten lines of code to just two or three.)

In case coding savvy isn’t enough, the site lets you create an account to track your progress, earn badges for successfully completing projects, and share your achievements with friends. There are also helpful hints and glossaries for each section, and a Q&A forum to share tips with other coders. I’m about halfway through the program, and am amazed by how far I’ve come. Code that used to look like gibberish suddenly makes sense—now I’m writing gibberish of my own.

Who’s callin’ me a newbie?

Want to see our developers’ coding expertise in action? Give Atomic a ring and we’ll show you what we can do.

Ever visit a restaurant that got the dining experience just right? I don’t mean only great food. I’m talking about a place that really understood what they were about. From the impression when you walked in the door, to the look of the menu, to taste of the meals themselves—this place showed that they were something special. You probably recommended the restaurant to friends, and maybe even became a regular customer. You went for the grub, sure, but it was the experience that kept you going back.

The way we interact with websites isn’t so different. While it might be a little easier (for us non-programmers, at least) to pick out the details that set restaurants apart, it doesn’t take a trained eye to tell the Bob’s Diners from the hip eateries of the web world.

As Atomic’s business developer, I get asked all the time what the big difference is between template-based and custom websites. Why shell out for a custom site when you can get an off-the-shelf template for a fraction of the cost? It’s a valid point—but one you may end up paying for later. Here’s why:

Credibility. Your website reflects your business. A custom-made site says, “I know what I’m doing. This look takes work. Let’s get to know each other. Sit down and stay a while.” And a template looks like, well, a template, no matter which “unique” design you pick. As a veritable fast-food chain of websites, it says…not much.

User experience. Good luck incorporating your company’s branding elements into a template site. All templates have virtually the same navigation and site map, leaving little room for customization. Have extra service lines, a unique business model, or want additional functionality? Too bad. Visitors may never find out about them, because if they don’t fit within the template’s preset formula, you’re out of luck.

Custom design, on the other hand, shakes things up. It gets users excited about all the cool things the Web can do. Plus, it allows for all the business-specific gadgetry your enterprising heart desires (like order tracking, purchase histories, and clear calls to action).

Back-end ease of use. Web code has high standards. These standards help developers organize data so that it’s logical for upgrades. They’re also important for sharing information with search engines, like Google. If standards aren’t obeyed, search engines won’t index your site correctly, making any SEO work you’re doing for naught.

But website templates aren’t always built with standards-compliant code. The worst part? You won’t know if a template is compliant or not until after you’ve purchased it. Reputable web companies build custom websites with clean, well-organized code.

The bottom line is, you just can’t accomplish a memorable user experience using a template (did I mention they’re also prone to hacking?). By the time you spend the time and money to deal with the headaches templates cause, you’ll wish you’d invested in a custom website from the start.

Be the place people are talking about. Don’t be the greasy spoon.

Fortunately for you, custom web design is kind of our thing. Contact Atomic for ideas on how to help your site chuck the cookie cutter.

Here’s how collaborative web development used to work: A bunch of developers download code from a website onto their personal computers. As they finish working, they upload it back to the site. Whoever finishes last ‘wins,’ in the sense that any changes he makes overwrite whatever’s there already—whether or not the changes are correct.

Like many developers, I know the obvious shortcomings of this system all too well. As soon as a developer uploads his or her code, the previous poster’s work essentially gets undone. (I once lost about 8 hours of work this way—don’t get me started.)

Fortunately, we’ve wised up, and have figured out how to spare ourselves that headache. I’m now a firm believer in Version Control.

Working out the kinks, one command at a time

With version control, all previous iterations of a string of code are stored in a single repository, accessible from a development server. When users add or change code, they have to commit changes to the code’s main branch. That way, if there are deviations from what another developer has posted, they aren’t automatically overwritten. All developers on a project can see what everyone else has done, and can verify changes are correct and in line with job specifications.

We use versioning systems Apache Subversion (SVN) and GitHub. SVN is an older system, but it’s simple and powerful, and it gets the job done. GitHub is great for larger client projects. It has a nice user interface, and cool collaboration tools like a bug tracker, an editable style page, and time and date tracking, which we can use to make sure everyone’s pulling their weight.

Turning developers into time travelers

To a developer, version control is a lifesaver. It eases communication tremendously within development teams. It also helps us keep our clients happy. Let’s say we revamped a client’s site menu, and a month later, the client wanted it switched back to the way it was before. Before version control, we would have had to write the old code all over again. Now, all we have to do is go back to the version from the date needed (assuming it had been committed) and snatch up the relevant code.

Version control means security for our code (since it’s stored on a server, it’s safe from crashes). It also means we can keep projects moving forward, because developers can jump in without fear of undoing each other’s work. These days, we can do in 30 minutes what used to take five hours.

I can’t say enough about how much version control can streamline your web development process. Of course, it’s only as good as your developers themselves—if you do a sloppy job to begin with, version control may not do you much good. But if used well, you and your team can make coding magic.

Want to make sure no detail of your site design falls through the cracks? Contact Atomic’s development team for help crafting a showstopping website.

Sure, it’s a first-world problem. But it’s more than a little annoying: you want to know, let’s say, the contact number for a nearby restaurant. You load the webpage from your smartphone, only to find that the text shows up in teeny-tiny print.

A minute of touch-screen pinching and squeezing later, you’ve finally got the text to a readable size. But you still can’t find what you’re looking for. Instead, the number is buried on another page, or in a corner you can’t possibly see once you’ve zoomed in.

If memories like these make you want to chuck your phone across the room or use your tablet as a boomerang, take a deep breath. It doesn’t have to be this way.

Changing up design to fit the medium

That’s why there’s Responsive Web Design (RWD), a way of leveraging current web standards to adapt the layout of what you’re displaying, no matter where you look at it. Like mobile web platforms themselves, it’s a new concept. But as more people access the Internet via mobile devices, it’s gaining ground—and making for a much friendlier browsing experience.

There are a few different frameworks you can use to get your site mobile-ready. I like Foundation’s intuitive, easy-to-use interface. Another good one is Bootstrap, from Twitter. And WordPress has also developed some responsive themes for bloggers.

Foundation allows you to lay out pages quickly and logically within a flexible, nestable system. Upload your content into preset grids, and enter rules in CSS to dictate how windows will appear on various devices. Foundation applies ratios to areas of content (rather than absolute pixel sizing), ensuring that fields remain proportional. Plus, Modernizr is built in, ensuring your site looks its best even on older browsers.

Giving users what they need

What’s great about RWD is that you can emphasize what really matters. If your client wants customers to call, give ’em a landing page with a fat, clickable button they can use to dial the number right from the site. If they want users to be able to make reservations with ease, make sure a reservation schedule shows up on top.

If you’re a developer and you’re not using RWD yet, you should be. It’s a huge timesaver because it means only one development cycle, and one set of code applied to all devices. Just add in the media queries, which control which style rule gets applied, to your CSS, and voila—no more writing entirely separate code for a mobile-only site.

Here at Atomic, we try to incorporate RWD into client projects by default. The way we see it, it’s just the way web design should be done. While some prevailing wisdom favors the ‘Mobile First’ approach, we kind of turn that model on its head. We make desktop sites the best they can be, and go from there to create amazing mobile versions, without sacrificing quality.

The world is going mobile. Don’t let your site be the cause of any smartphone-projectile-related misfortunes. You’ve been warned.

Does your website need to clean up its mobile act? Contact Atomic Interactive to learn how to make responsive web design work for you.

Come with me, friend, to a day in the life of a developer.

You’re working on a new website. You’re in the testing phase. Colleagues and clients are starting to interact with the site and give you feedback.

On Monday, your client emails several change requests. On Tuesday, your designer posts a list of tweaks in Google Docs. On Wednesday, your traffic manager tells you about a few requests the client gave her over the phone. And on Thursday, your client sends an update to the email he sent on Monday.

It’s Friday, and you’re ready to start your fixes. Where in the world do you begin?

Enter Mantis Bug Tracker.

Mantis is an open-source tool written in PHP. It’s designed to help developers describe, assign, and resolve bugs. We use Mantis to avoid the situation I described above: multiple change requests, spread across different media, in no order, and with no accountability.

Instead, Mantis gives us:

  • A central web-based repository for all bugs, fixes, and updates
  • Dropdowns that let us organize fixes by category and severity
  • A color-coded status system that lets us mark fixes as new, assigned, resolved, or closed
  • A “closing the loop” feature that notifies the person who reported a bug when it’s resolved
  • A messaging system that captures all conversations related to a particular fix.

 

Organizing our quality control process in this way has had a big impact on development. Communication is smoother. Accountability and productivity are higher. And frustration is a lot lower.

In short, using Mantis has enabled a faster, more thorough, and more organized process of getting a web site or application ready to launch.

For a developer, that’s a lifesaver.

When you’re at home, on your own computer, you can use whatever browser you want. Into Chrome? Cool. Love Firefox? Fabulous.

But when you’re a developer, you don’t have that luxury. You have to ensure that your sites work well on all browsers —even those that aren’t your favorite. Worse … you have to ensure they work even on dated versions of those browsers.

And that gets old really fast.

Enter Modernizr.

Modernizr is an open-source JavaScript library that helps you build HTML5 and CSS3-powered websites without having to worry about browser compatibility. Modernizer does this through a series of “feature detection tests.” These tests detect features that a user’s browser can’t handle and downgrades those features accordingly, in a way that works for you.

This gives us developers much greater flexibility in building sites. We can build with a “high-end” target in mind — an ideal version of the site — while maintaining full control over what the “low end” version will look like. No more dumbing-down sites to ensure compatibility with older or non-preferred browsers.

Adopting this bit of tech can also save time and money. By building sites with the future in mind, there’s no need to redo development when a browser adopts more of the new HTML5 or CSS3 standards. Your site will have already been built to make full use of them.

This saves the client money and developers time, allowing those resources to be used for more important things. Like well-thought-out user interfaces, and more research in emerging web and mobile technologies.

So we can keep dreaming about the day when all users adopt a single, brilliant, modern browser.

But until then, we’ll keep writing for all the browsers out there. And Modernizr will make that task a lot less painful.

You’d think that using a certain app over and over might get boring. That you’d hit the limits of what it can do and where you can push it. Be ready to move on to something else.

This hasn’t happened yet with WordPress.

This amazing app got its start as a humble blogging engine back in 2003. It’s since become one of the most predominant content management systems used to manage modern websites. It’s used by literally millions of folks—from individuals to interactive developers to huge corporations. And the sites that are running this framework are seen by tens of millions of people every day.

In fact, we’ve found that as WordPress has grown in flexibility, it can be used to manage nearly any type of website or application. We’ve used it to manage Facebook apps, to create social networks, to build mobile web apps and ecommerce sites … and more.

In my opinion, there are several elements that make this radical usability possible.

First is WordPress’s extremely flexible theme and plugin systems. This combination allows for a huge range of sites to be managed via WordPress.

On top of this, WordPress allows custom site development to occur separate from the core framework files. This allows us to apply WordPress and plugin updates as they occur—giving the site increased stability and security.

In addition, WordPress is built on PHP and MySQL and is open source under the GPL license. This means that clients fully own and control their site, including the core CMS framework. There are no outside vendors, license fees, or hosting requirements involved, outside of the basic technology required.

It’s also cost-effective. Using WordPress saves clients time and money because we don’t have to write every piece of webware from scratch. Instead, we can utilize the ingenuity of a worldwide network of developers and designers who contribute to WordPress and its many plugins.

I continually find amazing uses for WordPress. And I love the ease with which I can create custom plugins and themes to fit nearly any site or application a customer desires. It’s great being part of the active developer community behind WordPress, and I look forward to finding new and fun uses for the platform well in the future.

I recently started using a new CSS framework called Blueprint. I’ve been excited about the results and wanted to share some of them here.

The cool thing about Blueprint is that it truly saves time in development. It cuts the time needed to take a design from sketch to a skinned website. And because it works so well across browsers, it cuts down the time needed for testing and debugging.

It’s also flexible. It makes flowing a design into a site simple, and it cuts the labor needed to change that design once you’ve started. If you decide to add an image to the right side of the screen, for example, Blueprint allows you to just drop it in, rather than having to rework your layout from scratch.

Here are some of my favorite Blueprint features:

  • It has a CSS reset feature that eliminates differences across browsers. Those minor differences — like setting a margin at 12 pixels rather than 15 — can turn a website from beautiful to bogus real quick. Blueprint standardizes these values across browsers, creating a uniform appearance for your site and reducing the time needed to cross-check it in Firefox, Explorer, Chrome, Safari … you name it.
  • It has an easy-to-use grid that can accommodate simple and complex layouts. Most designers work in a grid, whether it’s 960 or 1020. With Blueprint, you can “snap” your design into CSS almost as easily as putting together Legos. You can also write custom CSS on top of Blueprint to accommodate out-of-the-box designs.
  • Functional form styles. It’s easy to spot a form that hasn’t been styled — it just looks ugly. With this framework, you can write the HTML for your form, and Blueprint will autostyle it. You can customize the styles as needed, but Blueprint it provides a good base to start from.
  • Ready-to-go print styles. Blueprint also includes separate stylesheets just for printing. They’re set up to hide unnecessary content like banner ads and to print web content in a one-column, easy-to-read format.

The best thing about Blueprint might be the fact that it’s an open-source, supported framework. That means there’s a community of worldwide developers constantly working on making it semantic-valid and browser-tested. As new standards emerge and bugs are discovered, Blueprint’s network of users updates the software accordingly.

So the next time I’m working on a new website, don’t be surprised if I tell you that I’m “working from a blueprint.” That’s what all great architects do, right?

A lot of our clients go wiggy when they see a wireframe. Maybe because of how they look: spare, utilitarian … definitely not sexy. But they play a critical role in the web development process. Here are the top four things to know about what wireframes do … and what they don’t.

A wireframe is a blueprint. A wireframe is very simple diagram that lays out the essential elements of your web pages. For example, a wireframe might have placeholders for a header, navigation, body copy, an image, a search bar, a “call to action” box, and “contact us” information. By carefully assessing which elements are needed for each page of your site, we prevent unpleasant “uh-oh, we forgot that piece” moments once we’re into full development.

It’s not a design. People often mistake a wireframe for a design document. They start to panic because they think we’re using Times New Roman for their font, or arranging their content into boring squares and rectangles. To prevent this, when looking at a wireframe, repeat this calmly to yourself: “This is not my design.” Remember, the wireframe does not represent how your page will look. It represents what it will include.

Wireframes are a step in the development process. Wireframes are just one step in a process that takes your website from idea to launch. These steps include creating a sitemap, wireframes, and design for your site, and then undertaking development. Walking through these steps one by one ensures that the basic elements of your site are established before development begins. So there’s much less chance that development will start, stop, and start over from scratch—which can drive up costs and create a clunky product.

Wireframes are not your final product. Once again, when you see a wireframe, close your eyes and take a deep breath. Repeat to yourself: “This is not my website. This is getting me to my website.” Then, open your eyes and take a critical look. Is everything on the page that should be? Are there too many items in the navigation? Too few? Are there images on the right pages? Is the live chat button where you want it? Ignore the aesthetics, think about what your customer will want to see on each page, and make sure it’s there.

Now you’re seeing a wireframe for what it is – a content planning tool that makes sure nothing critical is left out of your site. And you’re using it the way it’s meant to be used: to increase usability while saving time and money.

Designing a website without usability testing is like building a boat without a blueprint. You’ll make something, but whether it floats is a different matter.

Usability testing fascinates me; in fact, I’m enrolled in grad school at DePaul University, studying for an MS in Human-Computer Interaction. And when I heard some debates recently about whether current usability tools were still valid, I took notice. The crux of the issue seemed to be the value of wireframes vs. prototypes, and whether technical specification documents are necessary.

As someone who believes that a focus on usability should be the focus of building a successful web site or application, I definitely had an opinion. I believe that each of these tools has a distinct place in today’s web development cycle. And as a web developer who handles new projects daily, I’ve seen firsthand how these tools expedite development time and directly reduce the number of bugs found and revisions required after development.

Let’s take a look at how each of these tools works.

  • Wireframes – Wireframes are basic layouts for a site or application. The goal of this phase of usability testing is to focus on determining the basic information architecture and interaction design for a site, without the distractions of interactivity or design elements like color, font, and images. By removing these elements, the development team can focus on the best possible placement for the individual elements of the site or application. They can also begin to think about options for interaction design.
  • Prototypes – Prototypes are beta versions of a site or application that allow information flow and interaction testing. The actual functionality of a site isn’t implemented. However, a user can click through interfaces to get an idea how a site will look and feel. By getting feedback from project stakeholders at this stage and making needed changes, you avoid the difficulty and cost of making revisions after development has taken place.
  • Technical Specification Document – This document combines the information flow, interaction design, and functionality decisions reached during the wireframe and prototype phases of development. It’s presented to the site developers along with other tools generated during usability engineering, giving them a complete, accurate understanding of the site’s usability and functionality requirements. This document also enables clear communication between stakeholders (agency, client, users, designers, and developers) regarding what functionality is expected for each interface.

From my perspective, all three of these tools are essential. They enable a reasonably pain-free development process, and significantly cut down on revision and rework. One small change made during usability testing can save literally days of time and struggle — and beau-coup dollars — later in the process.

So for now, I’m sold on these tools. I’ll be ready to learn about better ones as I continue my studies, but for now, they’ll stay in my tool belt.