Cover photo
Verified name
Nathan Smith
Works at projekt202
Attended Washington State University
Lives in Dallas, TX
3,822 followers|77,356 views


The following is from an email I sent to coworkers at projekt202, sharing my thoughts on the new Atom text editor by GitHub.

TL;DR — Atom looks promising, but Sublime Text is currently better. Atom will have a lot of catching-up to do.


My initial impression of Atom is that it feels a lot like Sublime Text (a good thing).

Here are some things I've noticed, both good and bad…


[1] BAD

It shows hidden files and directories in the sidebar of a project.

With the exception of .htaccess, that's rarely the behavior I want.

For instance, the ".sass-cache" directory is pointless for humans to look at.


[2] GOOD

It has a lot of syntax highlighters built in that you would normally need to install a Sublime plugin for (CoffeeScript, Go, LESS, Sass).​

​Note: Not an endorsement of CoffeeScript or LESS.​



​[3] BAD

​It has that weird "max line length" guide set at 80 characters by default. Realistically, who actually cares about that anymore?

It only ever existed ​because that was the exact width of a terminal monitor/window. And before that, punch-cards…

You can set this to a higher value in the settings.

But as of yet I don't see a way to just disable it altogether.



​I find myself missing the "mini map" that Sublime Text has on the right side of the editor.

(Generated CSS, don't hate.)

I don't think Atom has that. Or at least, it's not enabled by default.​



​I also miss the ability to "peel off" a tab, like you can in: Sublime Text, Chrome, Opera, Firefox, Safari, etc.​

​Atom doesn't seem to allow for that. Though, you can drag to rearrange tabs that are already open side-by-side.​


​[6] BAD

​There doesn't seem to be the concept of "projects" as with TextMate and Sublime Text.

You can File →​ Open a directory, but I don't see a way to say "Associate this collection of files and directories at a project."

​With TextMate and Sublime, you could make a project file (saved outside of your repo) and then drag that to your dock.

That way, reopening a project is as easy as clicking an icon. I'm not sure if Atom has this, but I haven't figured it out yet.​



​There's no vertical selection. Meaning, you can't hold down Option and drag your mouse to select text like this…

(Screenshot from Sublime Text.)​



No JSLint / JSHint.

I'm sure this will come later, via a plugin. But currently, there's no JS validation​.

To be fair, this functionality is via a plugin for Sublime Text as well, not built-in.

A missing ":" shows several resulting errors on Sublime ("!" icons in the gutter, and partial underlines of code)…

The same file with the same error, in Atom (no visual indicator of any error)…

​(Missing ":" after "go" on line 23.)



​Clicking a file in the sidebar opens the file in a tab. This drives me crazy.

In Sublime Text, it will show the contents, but won't keep the tab open if no edits were made (Saving a file without edits also keeps it open).

One might argue that Atom does it right (I think TextMate worked this way) but I prefer it to be a "glance" not an "open."​


[10] BAD

​No "current line" indicator. Sublime, TextMate, and just about every other IDE has a way to highlight the line that your cursor is on.​

​Perhaps this is in Atom, but the default skin doesn't make use of it. Either way, it's​ harder to tell where you're at when using Atom.

To be fair, Atom does highlight the line number in the gutter, but I prefer the indicator to be more obvious.
Kevin Lloyd's profile photoChris Williams's profile photoNeHeMueL García's profile photoMatt Farina's profile photo
Hey, I didn't get this email. :-(

Also, if you have an invite…
Add a comment...

Nathan Smith

Shared publicly  - 
Nice digestible infographic about CISPA.
Brent O'Connor's profile photo
Thanks for sharing! I shared this as well.
Add a comment...

Nathan Smith

Shared publicly  - 
I just emailed this to my coworkers. I figured it'd be worth sharing.



This was such a great point, from Nicholas Zakas, a (former) lead JavaScript engineer at Yahoo…

> "It's a little bit difficult for us as [front-end developers]… We're kind of unique in our field. That's because the sort of stuff that we do, is not taught in college. ​ That's huge, for the number of people we have doing this…​ So, everybody learned on their own."

I think that's why we (and everyone else) have such a tough time finding good front-end developers, as opposed to good designers or "classically trained" computer science grads ("server side" developers).

aka: Why recruiters are terrible at vetting FED candidates.


Design is self-evident. With (or without) a design degree, good/bad design is obvious.

Formal training in computer science is more measurable: CS degree, certifications, code compilation.

Anyway, that "learned on their own" aspect is also why I feel a (healthy?) sense of inadequacy with every project.

I never quite feel like I know what I'm doing. However, I take comfort in the fact that nobody else does, either.


— Nathan
Qawelesizwe Mlilo's profile photoNathan Smith's profile photo
Agreed. It's good to have that separation.
Add a comment...

Nathan Smith

Shared publicly  - 
Web Designers ...
Alan Musselman's profile photo
Ha nice one!
Add a comment...
In his circles
1,015 people
Have him in circles
3,822 people

Nathan Smith

Shared publicly  - 
Interesting article on how Google is changing their hiring practices, based on insights gleaned from big data

"Another reason is that I think academic environments are artificial environments. People who succeed there are sort of finely trained, they’re conditioned to succeed in that environment. One of my own frustrations when I was in college and grad school is that you knew the professor was looking for a specific answer. You could figure that out, but it’s much more interesting to solve problems where there isn’t an obvious answer. You want people who like figuring out stuff where there is no obvious answer."

I didn't particularly apply myself in college. I was too busy making video game levels for the Sith and Quake 3 engines (Jedi Knight 1 & 2). That led me to want to have a website, so that I could send links to friends, to download my levels.

And here I am today, doing web (and mobile) development as a career. Completely unrelated to my bachelor's or master's degree.


In case anyone cares, here's an old video game level I made…
Danilo Visco's profile photoArif Kashmiree's profile photo
Add a comment...

Nathan Smith

Shared publicly  - 
So, there's an intersection near where I live.

It's at El Dorado Parkway and Hillcrest Road, for those who are familiar with the area.,-96.785442

It seems like drivers either:

1. Don't realize that two lanes merge down to one, or…

2. Don't care, and just use the left turn lane as a passing lane, meaning that they're going around people in the right lane, in the intersection.

I'm pretty sure that what I experienced today was the latter.

It seemed like this driver was just waiting for a chance to cut into the flow of the traffic in the right lane.

I just happened to be in the wrong place, at the wrong time. Or, perhaps it was the right time, because I was able to snap a few photos.

The vehicle in question was a white Ford SUV, with Texas license plate number 8CM-5097.

I'm documenting this here, in hopes that:

1. Perhaps the driver of the SUV will Google for their own license plate number, and realize their actions have consequences (not likely), or…

2. The Frisco Police Department will see this, realize that it's happening with increasing regularity, and post a police car there during rush hour.

I'm not holding my breath, but here's to hoping.
Add a comment...

Nathan Smith

Shared publicly  - 
Jack Hoffman is a 7-year-old brain cancer patient.

Yesterday, Nebraska football made his dream a reality.
tinny w's profile photoAdam Cmiel's profile photo
tinny w
oh gosh...
Add a comment...

Nathan Smith

Shared publicly  - 
I though of a metaphor tonight, of why I don't really care much to argue about CSS stuff. (Soundboard, versus playing jazz.)

The following is an email I sent to a guy whose coworker was arguing with him (and I by proxy, me) over whether fluid grid systems should have percentage based, or fixed-width, gutters.

I was trying to explain why I don't really care one way or the other, and had also (in a previous email) explained that gutters in are configurable via a single Sass variable ($gutter-half).



One of the reasons I don't really like to argue about CSS (anymore) is that a lot of my job, the majority of the coding anyway, is writing JavaScript.

(Either for web-based stuff, or in Titanium – that compiles down to Android/iOS for "native" apps.)

I feel like "I have bigger fish to fry," when it comes to where I spend my time.

By way of example…

The unsemantic-grid-responsive-tablet.css file (the biggest one, with IE7 support and a tablet breakpoint) is 2137 lines long.

That's generated dynamically. Because, when it comes down to it, I'm really not a big fan of writing CSS, so I try to automate the repetitive aspects.

A project I just finished this past Friday — an iPad-centric website that works offline, and in "app" mode — ended up with 1849 lines of JavaScript, just in the tablet-specific JS file.

Needless to say, that wasn't auto-generated because it's more nuanced programming, beyond just having the Compass compiler spit out CSS from a Sass loop.

That's the part of web development that I truly enjoy. Allow me to over-simplify, using screenshots from Sublime Text's mini-map sidebar.

Code that looks like this (Unsemantic's CSS) doesn't excite me, and (probably) isn't worth arguing about…

Because really, once you grasp that class="grid-X" equals width:X% — it's as boring as it is repetitive.

Whereas, code that solves a unique problem, where there's actual functionality being built — such as the tablet JS from the aforementioned project — is way more interesting to me…

It feels like the difference between tapping out a consistent "boom, boom, boom" on a drum — that could just be recorded once and played back via soundboard — versus playing jazz, live.

I think as you "evolve" in your career as a developer, debates like "Should this be pixels or percentages?" and/or "Why did you name your class with 'grid-' in it?" will become less important.


— Nathan
Jeffree Hilton's profile photoHonest S Brown's profile photoRyan Long's profile photo
Just got a new book idea, "CSS - The Good Parts". Ok, done. Now I'm looking for a publisher.
Add a comment...

Nathan Smith

Shared publicly  - 
The following is an email I sent to coworkers at projekt202, about how designers/developers can (should?) work well together. I figured it's worth sharing.

(Subject: “How [Having Less Time] Made Me a Better Programmer”)



I thought this was an interesting (brief), blog post worth sharing.

The actual title of this post is…

"How Getting Married and Having Kids Made Me a Better Programmer"

…But, whether someone is married (or has kids) or not isn't really the point.

Basically, he talks about how his brain dissects problems (unconsciously), even when he's not actively working on solving them. Having a family simply means he has less time to spend at a computer, so he has to noodle on things passively.

I can attest to this. Sometimes I'll be working at home in the evening, stuck on a code problem that I just want to "power through."

Getting up from my desk and doing something mindless (like watching Parks and Recreation) actually helps untie that "mental muscle" knot. Or, I'll be brushing my teeth, and I'll tell my wife:

"I think I just hit my brain stem, because I have an idea!"

So, getting to the point of my email…

Lately I've been trying to figure out a way to articulate why I think it's important for UI developers to be involved further upstream in projects, even if that just means being "a fly on the wall" when designers are talking to clients.

This blog post was an "aha moment" for me.

It's not so much that all visuals need to be 100% vetted (from a technical standpoint). But the scenario of not having enough lead time — not having all the pieces to a UX problem to unconsciously chew on — makes for a more haphazard UI coding experience.

I'm sure that server-side developers (aka real "developers," sans front-end/UI job prefix) can probably also attest to this as well.

Seeing more/all permutations of front-end templates they'll be expected to "wire up" affords a certain peace of mind. When the phase of a project is reached where it's time actually do the UI/data integration work, they've had ample time to be thinking about it already.


This past week (at the risk of seeming rude), I basically invited myself to a meeting at which +Mike Townson was the key p202 attendee. Mike is the designer on the project, redesigning functionality of a client's desktop app for the iPad.

Once I realized that meeting was to take place, and since I was already at the client's office, I wanted to make sure I sat in. Seeing how their "legacy" system worked ahead of time will inevitably help me better understand the rationale behind Mike's forthcoming designs (that I'll eventually be coding).

Anyway, I'd love to see p202 have a more collaborative workflow, and for us to strike "throw it over the wall" from our collective vocabulary.


I leave you with this slide from a talk I gave several years ago, depicting stereotypical perceptions of designers/developers…

I think when there's more communication/visibility on a project, designers and developers are less likely to stereotype one another.


— Nathan
Joshua Turmel's profile photoJohn Saddington's profile photoChang Ioannidis's profile photo
brilliant stuff here.
Add a comment...

Nathan Smith

Shared publicly  - 
The following is an email I recently sent to coworkers (on a client project), entitled "Thoughts on HTML Email."

I'm sharing this in hopes that maybe it'll help other unsuspecting designers/devs realize what they're signing up for, when volunteering to handle HTML email for a client.



Short version = HTML email is a huge time-sink.


Long version…

If we need to build an HTML email template for {client}, the sooner we know that the better.

Reason being, to account for the "lowest common denominator" of email app support, we have to make sure everything works correctly in Outlook for Windows.

Unfortunately, Outlook for Windows uses the HTML/CSS rendering engine from Microsoft Word. Which is to say, Outlook (on Windows) is the worst possible email client to build for. It used to render with the underlying engine from Internet Explorer (not great, but sufferable).

There was a viral campaign awhile back, to try to get Microsoft to change their mind…

Sadly, that failed. Microsoft realized they'd screwed up, but not before already shipping Outlook as we know it now. By way of example, here's the same email rendered in the previous version of Outlook (on the left) and the current version (on the right)…

Additionally, once you get a solid HTML template done, that works across all email apps — You can't just send it from within Outlook on Windows, or it will add its own weird formatting before it goes out, thereby breaking in all email apps.

So — because Outlook on Windows can display HTML emails (built with enough forethought to support it), but cannot send them — that requires using a third-party service to send the email, such as or (HTML email is an entire industry).

We'll need to train the client on how to create/edit HTML email (they'll need to know enough to be "dangerous"), and how to manage their email campaigns. This person will also need to know how to do a manual "build process" of converting a development version of the HTML email (with external styles) into a "production" HTML email, using this tool…

For the developers on this thread, view-source and compare these two…

1. Development versionloads slow, as PHP adds CSS to <head>.

2. Production versioninline CSS tool converts everything to style="…"

That's the process/tool I used to make our p202 HTML email template. Creating the initial template took me about a week and a half to get everything solid. It's like coding in 1997 with very few modern layout techniques available to you – nested tables, etc.

Each time we prep to send a p202 HTML email, it takes me about 1 or 2 hours of back-and-forth with {coworker} (in the Dallas p202 office). There usually last-minute copy edits, me fixing unforeseen bugs, her getting the email campaign squared away in MailChimp, sending a test email, and then sending the real thing.

So, anyway, if that's what we need for {client}, it will add a not-insignificant amount of scope.



What's ironic is that Outlook on Mac uses WebKit, a state-of-the-art rendering engine that is the underpinnings of both Chrome and Safari.

— Nathan
Jared Taylor's profile photoNathan Smith's profile photoColin Mitchell's profile photoEric Eggert's profile photo
Thanks for sharing this +Nathan Smith. Reading through it made me cringe thinking of client requests that come in last minute not thinking the add is a 'big deal'. I may have to reference this sometime in the future. (Hopefully not, but...)
Add a comment...
In his circles
1,015 people
Have him in circles
3,822 people
Principal UI Architect
  • projekt202
  • Pure Charity
  • Hewlett-Packard
  • Fellowship Technologies
  • Viewzi
  • EMC
  • Albertsons
  • Asbury Theological Seminary
  • Washington State University
  • YMCA
Map of the places this user has livedMap of the places this user has livedMap of the places this user has lived
Dallas, TX
Honolulu, Hawaii - Houston, Texas - Yuba City, California - Atwater, California - Papillion, Nebraska - Derby, Kansas - Great Falls, Montana - Spokane, Washington - Montgomery, Alabama - Springfield, Virginia - Minot, North Dakota - Pullman, Washington - Wilmore, Kentucky - Boise, Idaho

Third person narrative…

Nathan Smith is an IA, Designer, Front-end developer.

He began building sites late last century and enjoys hand coding HTML, CSS, and JavaScript. He also dabbles in design and information architecture.

He created the 960 Grid System, a design and CSS framework for sketching, designing, and coding page layouts.

As web development shifted more towards a responsive (not fixed-width) approach, he made Unsemantic, a fluid grid system that scales to fit mobile, tablet, and desktop screens.

He also created Formalize, a JavaScript and CSS framework that endeavors to bring sanity to form styling.


He has co-written two books:

jQuery Cookbook (ISBN: 0596159773)
Textpattern Solutions (ISBN: 1590598326)

He has tech-edited two books:


He has written for online and paper publications:


He has spoken at various venues:

  • Washington State University
  • Asbury Theological Seminary
Basic Information