Some Terminology

• Keyword: The search terms used to locate content on a search engine.
• Organic Search: A “normal” Google search in which the user clicks on non-paid search results relevant to his or her keywords.
• Paid Search: A Google search in which a user clicks on a keyword-targeted ad which is paid for by a Google AdWords campaign.
• Analytics: Google Analytics (GA), website statistics and metrics.
• AdWords: Google AdWords (AW), pay-per-click advertising.

“Not Provided”

This phrase will show up in GA results if Google is “hiding” the keywords used in an organic search. This happens when a user is logged into his or her Google account while performing a search. Google claims to hide the keywords for the privacy of the user.

Example: If I’m logged into my Google account and search “atomic object spin” to locate and visit Atomic’s blog, none of these organic search keywords will be passed to our GA account. My visit will show up with the “Not Provided” keyword.

If a visit comes not from organic search, but paid search, then the keyword will be displayed, even if the user is logged into his or her Google account.

Example: If I’m logged into my Google account, search for “atomic object spin,” and click on an AdWords ad (not an organic search result) created as part of an AdWords campaign, my visit will show up in GA with the actual keywords “atomic object spin.”

“Not Set”

This phrase will show up for three different reasons:

1. If the visit is a case of “direct traffic”: the user clicks on no links, and just types in (or copies and pastes) a URL.

   Example: I just type in “spin.atomicobject.com” in my browser’s address bar.

2. If the visit is a case of “referral traffic”: the user clicks on a link on another site (such as a blog, forum, or aggregator), but not from a search engine.

   Example: I click on a link to a “spin.atomicobject.com” post on Twitter.

3. If the visit is a case of paid traffic for a Google AdWords account that is not linked to the current GA account.

   Example: I search for “atomic object spin” on Google, and click on an AdWords ad. However, my current GA account is not linked to the Google AdWords account which manages the ad’s campaign.

   This situation happens most often when an organization has multiple AdWords accounts that all create campaigns for the same website. A GA account can only be associated with a single Google AdWords account. If a campaign that generates the visit belongs to an AdWords account which isn’t linked to the given GA account, the visit will show up with the keyword “not set”.

   Example: An organization has one GA account (“corporate”), and two Google AdWords accounts (“corporate” and “branch”). The “corporate” Analytics and AdWords accounts are linked, but the “branch” AdWords account is not. However, both “corporate” and “branch” AdWords accounts are used to create ads for the website. If an ad belonging to a campaign from the “branch” AdWords account is clicked from a search, the visit will show up in the “corporate” Analytics account as “not set”.

“Content Targeting”

This keyword will show up for visits generated by ads that are not related to a user search, but which appear on Google’s Display Network. These are the ads which you will often see when visiting other websites, on your mobile phone, or in online videos. They are associated with the Google AdWords account that owns the campaign, but do not rely on any specific user search.

Example: If I visit Facebook, and click on one of the numerous “linux hosting” ads which show up on the right-side of my screen, my visit to that particular website would list a keyword of “content targeting” in their GA account.

So when do real keywords show up?

With all of these meta-keywords, it’s helpful to review under what conditions real keywords do show up:

1. Organic search visits when a user is not logged into his or her Google account.
2. Organic search visits from other search engines.
3. Visits from paid search when the AdWords campaign owning the clicked ad is linked to the Analytics account being used.

The post Understanding “Not Set,” “Not Provided,” and “Content Targeting” in Google Analytics appeared first on Atomic Spin.

“Nothing extraordinary is ever achieved through ordinary means.” -Scott Belsky

My experience this year at 99U has left me holding on tight to something extraordinary. I can only describe these two days as a perfect dream, a place I want to hold onto and remember as if it were yesterday. As a designer, my senses are fine-tuned to pick up all the details, and from 99U I only expected… perfection. Okay, I knew my sights were set high — but I didn’t anticipate the extent to which they would be surpassed.

Setting the Scene

The venue set the tone for an inspiring and profound event. Alice Tully Hall, located in Lincoln Center, is near the southwest corner of Central Park. This location provided me a perfect walk through Central Park both days of the event (not to mention the magnificent weather we had). The event ended Friday evening at the MoMA — my favorite art museum. Both the park and museum served as a perfect platform to reflect upon and unfold the events of the day.

No expense was spared. Not only was there forethought in rich content curation, but every detail felt planned with such careful precision. The Behance team really outdid themselves by laying out the red carpet for attendees to meet and converse in an inviting pool of smart, creative enthusiasts.

Insights from Scott Belsky

While there were many key insights that had a profound impact on me, I’d like to cover just a few that Scott Belsky touched on in his masterclass, “Making Ideas Happen: Key Insights to Creative Execution.”

For those of you who don’t know Scott, well… he is a leading exemplar, not just to designers, but emerging entreprenuers, makers and creatives alike. He co-founded Behance, serves as VP of Community at Adobe, and is most prominently known as the author of “Making Ideas Happen.” I have read the book (which was insightful, in and of itself). Then I went to 99U, which is a product of Behance, and observed a leader who was an exact testimony to all of the things he talks about in his book. In front of a room of 1,000 professionals, all the senses came together as Scott’s calm demeanor set the tone in an already acoustically-sound venue.

“The tragedy of talent is when no one knows who they are looking at.”

In his masterclass at 99U, two things that Scott talked about particularly stayed with me: how leadership fosters a culture where ideas can be shared liberally, and how to maximize creative potential in your team. He suggests using sketch assignments as a way to learn more about your team’s hidden talents and discover new ways to implement your ideas.

“Leaders fail to buy engagement by talking first.”

Scott uses the example of a team standup meeting to illustrate how a leader who is silent can draw out more ideas and creativity from the team. So silence the visionary! Foster a culture of “get and give” idea sharing to discover talent in all corners of your business.

“Incentivize innovation by tolerating failure.”

And finally, Scott talks about creating an allowance for failure within a culture. If you institute a “try without being docked” mentality, you can give your team even more opportunities to learn new things.

Learning to Reach Out

After the class, I took an opportunity to approach Scott in person with something project-specific in mind. The conversation was succinct, but it offered me an opportunity to overcome a personal fear and approach the curator himself. I also got some very topical project advice, which lifted confidence in my team’s approach to some interesting design challenges.

I was surprised that an event like this could present so many layers of interaction and variety in medium. There was a sense of cohesion in the room, and casualness to approach and kickstart conversations with other attendees. The intricacies of curating such a well-crafted social framework piqued a new curiosity in me.

“We believe that ‘networking’ is sharing.”

In closing, I want to touch on this statement and thank Scott for sharing it. It has resolved a stigma for me when it comes to attending “networking” events. In turn, I have a renewed interest and hunger to continue overcoming self-doubt, exposing myself as a designer and sharing ideas more often.

More from 99U

• Insights from A.J. Jacobs, Joe Gebbia, Charlie Todd
• Insights from Ramit Sethi, Leah Busque, Jeff Sheng
• Insights from Hosain Rahman, Josh Reich, Heather Payne

I also published this post on Medium, “A place to read and write things that matter.”

The post A First Experience at 99U: Through the Lens of a Designer appeared first on Atomic Spin.

I’ve implemented a few web applications using this feature and have always found the biggest issue to be the connection —handling the setup of the Google doc and managing the CSV format that it provides as the interface.

Thankfully I was not alone. Tabletop takes a Google Drive spreadsheet and converts it into a JavaScript object. I’ve found Tabletop integration into Backbone.js to be quite simple. With a few lines of custom code you can even hook up the Backbone.js sync method to use Tabletop as a data source.

So if you followed my other post or are just interested in using a Google Drive document in JavaScript I recommend checking out Tabletop.
 

The post Convert Google Drive Data to JavaScript with Tabletop appeared first on Atomic Spin.

Smashing Magazine
http://www.smashingmagazine.com/
Smashing Magazine has been in my reading list for almost a decade. Their articles are always highly researched and well-crafted, and they cover a wide range of topics related to designing and creating for the web. If you don’t read Smashing Magazine, you should. Smashing Magazine has been one of the best design blogs out there for a long time.

ZURBlog
http://zurb.com/blog/
I’ve enjoyed using Zurb’s Foundation framework for the first time on my current project, and I’m enjoying their blog even more. As a software product design company, Zurb is somewhat of a kindred spirit to Atomic Object, so I appreciate reading what’s going on in their neck of the woods and learning about new approaches that they are working on.

Sidebar
http://sidebar.io/
Sidebar is a relatively new site. It’s a daily, curated list of 5 links to high-quality web- and software-design related articles from around the net. I appreciate the breadth and depth of the articles featured.

HBR Blog Network
http://blogs.hbr.org/
You might not expect to see a business website on a list of the best design blogs, but as a software designer, my job isn’t just about designing pretty interfaces — it’s about helping my clients find solutions to their business problems. HBR Blog Network is great for helping me to “zoom out” and learn more about the business ecosystems surrounding the products I help create. As you would expect from HBR, the articles are well-written, well-researched, and cover a variety of interesting topics.

Cameron Moll
http://cameronmoll.tumblr.com/
Cameron Moll is an industry veteran, and his site is another one that I’ve kept an eye on ever since I was a high schooler designing websites in my parents’ basement. Cameron’s tumblr blog is a reliable smorgasboard of interesting thoughts and links related to design, the web, and the world around us.

Jen Myers
http://jenmyers.net/writing/
Jen Myers is great. I respect her as a fellow user interface designer, and I deeply appreciate and the work she does related to increasing diversity in the tech industry. Her writing is thought-provoking. Also check out her tumblr.

Little Big Details
http://littlebigdetails.com/
Little Big Details is perfect for a quick brain-break in the middle of the day. As the name implies, they showcase the little details that make a big difference in interface design. Great for inspiration when you’re trying to come up with that signature interaction to really set an app apart.

Wells Riley
http://blog.wells.ee/
I’ve only recently become aware of Wells Riley’s blog, but I’ve found it to be a good source of thoughtful commentary on our industry. One recent post I enjoyed is Less Aesthetic, More Design.

Design Observer Observatory
http://observatory.designobserver.com/
A site about “Design and Visual Culture,” Observatory is one of the places I go for increasing the breadth of my knowledge about design. Recent articles at Observatory have covered topics as diverse as architecture, typography, and playgrounds.

Design Festival
http://designfestival.com/
There’s a whole genre of web design blogs dedicated to step-by-step tutorials and gallery posts. Design Festival belongs to this genre, and I’ve found it to be one of the higher-quality ones. If I want to learn some new Illustrator-fu or see a gallery of minimalist websites, Design Festival is my go-to.

Did I skip over your favorite site? Please let me know in the comments! I’m always interested in finding more sources of great information!
 

The post 10 of My Favorite Industry-Related Blogs & Websites appeared first on Atomic Spin.

At Atomic Object, we’re very dedicated to test-driven development. The project I’m currently working on has 113 files of tests for a project with 154 files of logical code. Most code files are verified by a corresponding test file, so it’s important to update the appropriate tests before making changes to the code. Coming from a project that put more emphasis on full-stack integration tests rather than file-by-file unit tests, it was easy to forget to update the unit tests before diving into the code. Correcting this tendency required a bit of habit hacking.

Charles Duhigg’s excellent book The Power of Habit lays out a three-step framework for forming a habit. First, you need a trigger, something that cues you to carry out a routine. When you finish the routine, you need to receive a reward. Once you know the trigger, the routine, and the reward, the habit will start to form.

When working with the project’s code, I already had the trigger. Any time I opened a code file to make changes, I needed to open the unit tests as well. In fact, opening the unit tests was the necessary routine. Only the reward was missing. In place of a reward, I had a sigh, a tiny moment of dread. Sighs discourage habit formation — they’re the anti-reward — so first I had to figure out what I dreaded. A little introspection suggested that the chore of finding the right test file among 113 files sparked a flicker of dread. It was a simple task, but magnified into a sigh by my unfamiliarity with the codebase.

To undermine the sigh, I threw together a script to find the right test file and open it. The script took about six seconds to run — a delay that would spark more sighs — so I rewrote it to be faster. In the end, the script found the right test files in less than a tenth of a second. I was quite proud of the script’s speed once I finished. In fact, I was so proud that I inadvertantly discovered the reward to make my habit program complete. Every time I hit my keyboard shortcut to open the right test file, I beamed a little at how fast and how well my script worked — a tiny reward, but enough to make me look forward to updating the unit tests when I opened a code file. Looking forward to updating the tests kept me from forgetting that single most important step of TDD. Habit formed. Human programmed.

Habit formation is a powerful way to automate human behavior, and building habits is available to anyone. I wrote a script to automate away an annoyance, and the reward offered by running the script trained me to carry out an important routine. You too have tools available that you can use to build new, helpful habits, and if you have any stories about building habits, I invite you to share.
 

The post How to Automate Your Human – Forming Good Development Habits appeared first on Atomic Spin.

• Breaking things down by value, not by task
• Thinking in terms of “size” (not time)
• Making estimates

I did this because, even though we’re all a bunch of Agile know-it-alls by now, and estimation is a remedial topic from 10 years ago, there are still plenty of people who haven’t been introducted to size-based estimation. Besides, making the switch from time-based estimation to size-based isn’t as easy as some of the books and blogs out there make it sound.

(Nevertheless, I didn’t design the talk to actually teach the skills needed to fully implement size-based estimation and planning. For a better-articulated discussion on how complexity-based estimates actually work and on why and how to start using them, see Carl’s talk on Making Better Estimates.)

As a tail on the conversation, I prepared some common high-level concerns and roadblocks to discuss, but the audience in the room provided plenty of same-level questions. A good example was, “How does all this data-driven re-estimation help me when I’ve got a fixed timeline that cannot change?” Answer: “This is one of the best tools to know if you’re going to get done on time; your manager will thank you for sharing that information early.”

I also had a brief tangent where I had to admit that Atomic does, in fact, use time-based “Aggressive-but-possible/Highly-probable” estimates during the sales process, when sketching high-level time-and-money estimates, since it assists with bidding and budget setting. But these estimates are then decomposed further using size-based tools for tracking and management.

Some common questions I didn’t get to in the talk:

• When is a story “done”? (When the customer says so, or when you’re able to demonstrate the value has been added.)
• Should estimate and track points for bugs? (Depends on what your customer is planning around; bugs aren’t scope, but they take time. Best to tackle them regularly and let them affect overall velocity.)
• Will customers accept estimates given in points? (Maybe eventually, but don’t force anyone to understand or accept your point scale. Instead, derive an estimated duration and be ready to explain how size and velocity create that information.)

I actually hope to continue the discussion. Size-based estimation — far from being old-hat or a close topic — is still the kernel of any great software project management process, and it still takes care and effort to keep the furnace stoked with good input.

Here are the slides from the presentation:

 

The post Time-Based Estimates Are for Suckers! (Size-based Is the Way to Go) appeared first on Atomic Spin.

The Build is an essential cog of any software project, but it is most often maintained by identified “experts.” This needs to stop. Agile depends on shared code ownership and understanding of the system — all parts of the system.

Consequences of Ignoring the Build

Most sufficiently-sized projects use a continuous integration system and some amount of configuration and/or code to make them work. If only a subset of individuals understands and maintains this system, it will likely not be kept up to snuff to meet the growing demands of the project.

I have experienced the effects of an insufficiently-maintained build system on numerous projects in the past. The risk of the build system getting in the way is especially high in the case of static languages (like C/C++). These compiled language project frequently require a lot of non-standard setup and complex build and/or packaging requirements (including compilers, linkers, tests, simulation, and static analysis tools).

Continuous integration systems, which use The Build, are invaluable for regression testing. Although, if the understanding of how the system works is compartmentalized, the overall health of the project will most likely suffer.

Where Things Go Wrong

The most disheartening aspect of this problem is that The Build is indeed code, just like the real code that developers write every day. While the code that makes it into the product being developed usually has mandates on its quality, structure, maintainability, and testing, code in the build system is too often not held to this high standard.

As a result, the build system suffers, tech-debt grows and eventually comes back around to bite you. And thanks to Murphy’s Law, it usually rears its ugly head at the worst possible time.

Not maintaining the code and/or services that comprise the build environment is a recipe for disaster. Instabilities in the build and the need to continuously tend to specific areas of the build environment are red flags that technical debt exists and is not being dealt with properly.

Spreading the understanding and ownership of The Build will have very beneficial effects on any project — most notably, sanity of the developers and all involved in delivering the product. Treat it with the same respect and the rest of your code base. You will not regret it!

Does your team tend to the build environment over the course of a project? Or does your team and/or management wait for the system to fall apart before addressing the resultant issues?
 

The post Not Tending to “The Build” – A Common Anti-Pattern appeared first on Atomic Spin.

In a previous post, I explored the question: Is your chair your enemy?, based in part on the many recent articles, research reports, and infographics claiming that the simple act of sitting is killing you.

But I recently read David Zax’s FastCompany article, In Defense of Sitting, a humorous counter argument (“Sitting may kill you. But at least you’ll die doing something you love.”) to the widely-published judgement that standing while at task is surely the key to eternal life.

What the summer of 1975 did for sharks, what the fall of 2001 did for anthrax, the last few years have been doing for that seemingly innocuous object: the chair.

Seeking inspiration of the “Great Standing Writers” like Ernest Hemingway and Philip Roth, Zax decided to try working while standing, but things didn’t go well:

The first thing I noticed about my standing desk was that it wasn’t particularly comfortable. It was also the second thing I noticed, and the third thing I noticed.

Zax also talked to some furniture designers and learned that it is not necessarily sitting that’s bad for us, but sitting still. Herman Miller has researched the health benefits of dynamic sitting. One of their seating research papers, Sitting Can Be Good for the Circulatory System, identifies the need for chairs that help users move:

One approach to promoting movement in a work chair would be to design one with a dynamic seat and backrest. Doing so would require a surface that automatically conforms to a sitter’s micro-movements and distributes weight evenly. This would allow the seat to take on the greater burden of supporting more weight while providing stability. It would also reduce seated pressure and increase blood circulation to improve oxygen flow and decrease heart rate.

While the jury is still out on whether or not sitting will actually kill us, we’ll continue to benefit from a variety of postures and overall movement as we work. And David Zax reminded me that a good sense of humor helps too.

The post Is There a Case to Be Made for Sitting? appeared first on Atomic Spin.

My team recently needed a date picker in our web app. We wrote tests and implemented a simple text field first as scaffolding. Call it YAGNI if you want — we really just weren’t excited about choosing from the long list of time-forgotten, unlovable JavaScript date picker widgets out there.

Surprises from Chrome

The next day while we were pairing, we opened up Chrome, hit our app, and noticed that our new “date” field had magically turned into a fully-functional date picker!

We were puzzled. We started looking at commit logs, wondering if another teammate had snuck in a little treat without us noticing. Then I tried the app in Firefox… and the date picker disappeared.

As it turns out, Chrome automatically adds a date picker to input elements with a type attribute of “date.” It’s been in there for a while, but we’d never noticed. It’s one of a longer list of new input types in HTML5 that Chrome has implemented, while Firefox has not.

Why Ember?

My team chose Ember.js to help us build a web app on top of a REST-based JSON+HAL API. Our next task then was to figure out how to integrate this gift horse into our app.

I like Ember.js for two reasons: I trust their team, and I like the decoupled, testable style of their architecture. It’s still a small enough framework that our team can solve most problems by looking through the source code or by running simple examples (or, sometimes, by asking fellow Atoms who’ve been using Ember longer than we have).

As it happens, our app expects a typical (for us weirdos in the US anyway) MM/DD/YYYY date format. We are using moment.js to convert a user’s entry into a preferred ISO8601 format for storage in CouchDB, so we started with a simple Ember view and a template helper to make our date picker and date display easy. The View was kickstarted with the results of this thread on the Ember Discourse page. We used Modernizr to help detect browser support and adjust the expected input format accordingly, so if you’re in Firefox, you’re just going to get a text field. If you’re in Chrome, you can haz a date picker.

The resulting model property is a bonafide Moment object, which in our case converts cleanly when JSON.stringify is called on the way to our API.

Here’s the resulting view class (in CoffeeScript of course.) Good luck with your Ember app!

# Usage:
# {{App.DateField dateBinding="date"}} # Where "date" points to a Moment.js object
App.DateField = Ember.TextField.extend
  type: 'date'
  hasFocus: false
  placeholderBinding: 'dateFormat'
  dateFormat:(->
    if Modernizr.inputtypes.date then 'YYYY-MM-DD' else 'MM/DD/YYYY'
  ).property()
  init: ->
    @_super()
    @updateValue()
  updateDate: (->
    ms = moment.utc(@get('value'), @get('dateFormat'))
    @set('date', ms) if ms and ms.isValid()
  ).observes('value')
  updateValue: (->
    return if @get('hasFocus')
    date = @get('date')
    if date
      @set('value', if moment.isMoment(date) then date.utc().format(@get('dateFormat')) else moment.utc(date))
  ).observes('date')
  focusIn: ->
    @set('hasFocus', true)
  focusOut: ->
    @set('hasFocus', false)
    @updateValue()

The post HTML5 Date Inputs and Ember.js appeared first on Atomic Spin.

Old Habits (Letting my email manage me)

I get about 2,000 work-related emails every month (I’ve nearly given up on my personal email account), and my historical approach to keeping an empty inbox was to be always checking and responding to my email.

I’d frequently check email:

• first thing upon waking up
• right before commuting to work
• first thing upon getting to work
• in between meetings or scheduled sessions
• during any free moments or waiting periods
• right before I left work
• while eating lunch or dinner with others
• as a car passenger during family errands
• right before I went to sleep
• in the middle of the night if I woke up

My empty Mailbox inbox. I wish life could always be this good.

It’s a little embarrassing to admit, but there were times I’d check email on my phone and feel a sense of loneliness or anxiety if no new messages had come in. I was so addicted to email that I didn’t realize its corrosive effect on my productivity and energy levels.

A Forced Experiment

About a month ago, I took a trip to Mammoth Cave National Park and found that I had no cell reception. The Mammoth Cave Hotel had limited WiFi access only available in the lobby.

The limited internet connection forced me to batch my email interaction to 1-2 concentrated sessions per day. I was struck by the mental impact of batching email up instead checking it throughout the day. I was more present with others and focused during the day because I was not preoccupied with potential distractions in my inbox. When I did check email, I felt I had more energy to power through the entire batch more effectively and efficiently.

During the same trip, I read Harvard Business Review’s Guide to Getting the Right Work Done and discovered two great sections on email:

1. Simplify Your E-mail by Gina Trapini
2. Eight E-mail Overload Experiments by Alexandra Samuel

New Habits (Managing email on my terms)

Back at work, I’m now trying to establish the following email habits:

• Ruthlessly set filters for any newsletters or lists I don’t actively read (I have 67 new delete filters after ~1 month).
• Process email in batches (I usually check before lunch, before going home, and in the evening).
• When processing batches, quickly follow up or put the response task on my todo list in priority with my other tasks.
• Steer clear of lengthy conversations with “reply all” chains. If something is important enough for a group discussion, we should schedule an in-person group discussion.
• Stop replying to every email I get.
• Be more conscious of the email I send and reduce the amount of email I generate.
• Communicate more by phone. It’s amazing how much more you can convey quickly on the phone, even if it’s through a voicemail.
• Do the most important tasks of my day in the morning and don’t check email before my allocated priority time block is done. I’ve realized that if someone needs me urgently, they can call or text me.
• I don’t keep my email open in a browser tab, and I’ve turned off my email notifier.

My new email habits have me feeling happier and more productive. I seem to be getting more work done at work — and in less time. I’m spending less time at night or on the weekends getting my priority work done.

Are you addicted to email? Do you believe email has a negative impact on your productivity? Please share your stories or solutions.
 

The post Kick Your Bad Email Habits appeared first on Atomic Spin.