So, you’ve got a great design idea for a new website, and you’re ready to take it to a developer. Or so you think. The developer looks at your mockups, and he’s got a few questions. Will it use jQuery for animations? How will drop-down menus behave? What will be your links’ hover states and rollover styles?

If your answer to these questions is, “uhhh…” (or anything similar), listen up. If you’re designing for the web, it doesn’t matter whether you’re doing the actual coding. Knowing at least a little about the world of web development is now officially part of your job.

Your design files should allow a developer to easily pick your design apart, build it, and take it live. To do this, you need to speak developers’ language—so you can explain exactly what you want them to do.

Why’s this so important? Because if you aren’t clear about how you want things to look, certain features won’t be built into the live site. (I learned this one the hard way.) But knowing the basics of web development means you can communicate clearly. And that will make your life—and the developer’s life—a whole lot easier.

At a minimum, here’s what you need to know.

• Get some basic CSS3 know-how. Gradients, buttons, drop shadows, and even basic shapes and rounded corners can be built with CSS. And using CSS instead of images cuts down on the size of a site—meaning faster loading time. Design visual elements that can be reproduced in CSS (rather than creating clunky image files), and developers will thank you for it.

• Use standard fonts. Choose fonts from Typekit, Google Web Fonts, or another major font directory. Again, if you choose a font that isn’t common on most browsers, your type will have to be displayed as an image, meaning slower loading times—and frustrated developers.

• Go easy on the backgrounds. The same goes for webpage backgrounds. Go for a solid color—or a small image or texture that can be easily repeated. This will also help cut loading times.

• Be careful with images. If you’re a designer, Photoshop is probably your thing. Here’s a tip for sharing images with web developers: Use the Pen Tool to cut out all images that will need a transparent background, instead of using blend modes. If the developer goes to save the image and you used a blend mode, it’ll show up on the live site with one of those ugly, patchy backgrounds. Don’t let this happen to you.

• Keep responsive features in mind. As some screens get bigger, while others get tinier, you need to make sure your design can easily adjust to different browser sizes—or appear in a totally different configuration based on the device it’s viewed on. So make sure design elements can be resized easily or simplified for faster viewing on mobile platforms. But don’t forget a high-res photo for full-width banner images—that way, it won’t get pixelated if viewed on a huge screen.

And where can a designer learn development basics—fast? You can’t learn to code overnight, but sites like Codecademy and Smashing Magazine are a great place to start. Another cool trick I’ve learned: find a site you like, and peek at its code using the Inspect tool in Chrome or Firefox. Just right-click on an element, click “Inspect,” and voila—learn any site’s coding secrets!

Soon, you’ll be throwing around terms like “cell padding” and “pseudo-class selectors” with ease. And you’ll be happy seeing your design creations come to life—just the way you imagined them.

Want to see what our designers are capable of? Contact Atomic, and we’ll give you all we’ve got.

 

Clients often tell me that they think their sites scroll too much. “People are too lazy to scroll,” they say. “We want all of our most important content visible at once.”

I hear what they’re saying. Designing “above the fold” used to be huge in web layouts. But unless you’re still living in the early 2000s, this way of thinking just isn’t relevant anymore.

Designing above the fold means content has to fit in a space the size of your computer screen. That seriously limits design options—and can make your site look crowded as everything gets tinier and tinier to fit. Exactly how much space do you have to work with? That’s hard to judge, too, considering the countless screen sizes, resolution levels, and devices someone might want to view your site on.

I’m not saying you should load down your sites with never-ending blocks of text. The new generation of scrolling sites uses movement to tell a story. They’re perfect for introducing a new company or product: you can walk users through what your product does and how it works, then lead them right where they need to go to learn more—or better yet, buy. These sites are animated—but they require viewer interaction in order to come to life. Check out these examples to see what I mean:

http://www.zensorium.com/tinke/

http://www.milwaukeepolicenews.com/

http://a-class.mercedes-benz.com/com/en/index.html

Sites like these seem like they’d be complicated to build, but they’re really not: most of the effects you see can be created using just jQuery and CSS (get started with a framework like Blueprint or Foundation). Like any new trend, scrolling sites have their kinks: some techniques are only supported in current modern browsers, and adjustments have to be made for mobile displays.

But personally, I’m excited about what scrolling sites have to offer. I could click around sites like these all day and never get bored—they’ve got the power to hook even the laziest of web surfers. And I keep going back to show other people how awesome they are. As a developer myself, I know that’s music to a site creator’s (and client’s) ears.

Is your site trapped in a scroll-less rut? Contact Atomic, and we’ll help you set your site free.

A few years back, I was working as special projects manager for the City of Dayton. The city needed a firm to take on a unique assignment: creating a website for the Ohio Aerospace Hub. Dayton earned the Hub title in 2009, an initiative to draw aerospace-related jobs, education, and economic development (read: cash money) to the region.

Researchers partnering with the Ohio Aerospace Hub are up to all kinds of crazy stuff: advanced sensing, drone technology, cybersecurity, you name it. The Hub needed a website to show off its research to the world.

But the website had to do more than just inform. The Ohio Aerospace Hub will require significant investment over time—not to mention an A-team of scientists and engineers to get things done. Now, we locals already know how cool Dayton is. But the city wanted to raise its profile by attracting a new segment of people: techies, creative types, entrepreneurs, and businesses keen on Dayton’s new aerospace economy. That’s a tall order for one little website—but Atomic was up to the task.

In the search for the perfect firm for the job, Atomic really set themselves apart. (It also led to my job here—but that’s a different story.) Throughout the development process, there was great collaboration between the guys at Atomic, the director of the Hub, and all of the partners involved. The result: an awesome site—that got people talking as soon as it launched.

And it’s not just Daytonians taking notice. International publication fDi Magazine held its first annual Digital Marketing Awards in 2012, sizing up economic development sites worldwide on design, innovation, and social media strategy. More than 50 organizations entered the contest. The Ohio Aerospace Hub won 12th among websites overall, and third among Economic Zones, a category for initiatives within a city, state, or country.

I’m proud of what our team has accomplished. Now, Atomic is ready to help the Ohio Aerospace Hub move forward as its research products take flight. (Plus, maybe they’ll finally let us give their latest gadgets a try. Fingers crossed.)

We can’t wait to see what the Hub does next.

We’ve talked a lot lately about responsive web design—and if you’ve been paying attention, you know it’s an innovation we’re pretty excited about. As Atomic’s new web development manager, I’ve noticed something else: responsive design has changed the designer-developer relationship.

It used to be that a graphic designer would create a finished Photoshop document depicting his or her vision for a site. The developer’s job was to make the site match the doc, pixel for pixel. In design school, you’d lose points for wrongly-sized columns or incorrect text. And if you were a professional developer, the consequences weren’t any friendlier.

Now, things are different. As Web platforms, screen sizes, and resolution types multiply like rabbits, a layout that looks great on one screen might not look so good on another. This means that designers and developers alike have had to learn to compromise.

Designers have to accept the fact that their designs aren’t going to be exactly the same form one viewport to the next. And developers have to realize that they can’t build a unique site for every device—coding time and costs would be way too high.

Another downer for developers: with the number of screen sizes out there, we have to give up on pixel perfection. Why? Responsive designs use percentages, rather than fixed widths, to tell browsers how to display websites. For ensuring a consistent look from one screen to the next, this is great. The problem is that when percentages aren’t expressed as whole numbers, browsers get confused. The number ends up getting rounded either up or down, meaning that sites don’t always display the way we plan. But fortunately, most of these rounding errors are usually only obvious to other keen-eyed developers.

So yes, responsive design has created some bumps in the road. But ultimately, I think it’s led to a more collaborative relationship between style-minded designers and code-bound developers. Designers still bring the initial creative force with a site mockup. But developers don’t have to follow it blindly: they’ll create a beta site, and we’ll test it on different devices to make sure all of the responsive elements work. The designer comments; the developer tweaks. We’ll go through as many iterations as we need until both sides (and of course, the customer) are happy.

And when my team’s happy, I’m happy.

Need a site that looks great on every screen? Call up Atomic and we’ll make it happen—no matter how many trials it takes.

When Apple rolled out the Retina display-equipped MacBook Pro earlier this year, the world oohed and aahed at its eye-popping renderings of nature photographs and smiling stock photo models. Meanwhile, web developers everywhere did a collective facepalm.

‘Retina’ quality devices are said to have such high pixel quality that at a normal viewing distance, the human eye can’t detect pixelation. Less pixelation means, crisper, cleaner, more beautiful-looking websites. Newer iPhone and iPad models already use Retina displays, and with the release of the new MacBook Pro, these devices are gaining market share.

That’s great. But for web designers, Retina displays pose a few problems. Plenty of consumers have scrambled for the new MacBook Pro (despite the hefty price tag)—but plenty haven’t. When Retina-display users view a site designed for an ordinary low-res screen, all that pricey pixel potential just gets wasted. But completely revamping web graphics and typography in Retina quality means larger image sizes and longer page-loading times—even for users without Retina display. It’s a lose-lose.

So how’s a designer to create a great cross-platform web experience and stay cutting-edge? The answer is responsive web design (RWD). Just as media queries can be applied to CSS to tell a site how to behave on different devices, they can also be used to change what users see depending on whether they’re viewing in a high-res or low-res environment. It means non-blurry, fast-loading pages for everybody—and less headache for developers.

Dealing with a new set of compatibility standards isn’t always easy. But at Atomic, we’ve made RWD part of our standard development processes, so we can respond and adapt with ease. As it happens, so-called retina-quality devices don’t even come close to the pixel-perceiving quality of the actual human eye (they’re based on 20/20 vision—but plenty of people can see even better).

Retina 2.0 may not be far off—and we’ll be ready.

Do you know how your site looks in Retina-vision? Contact Atomic and we’ll get your page up to snuff.

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.