For the May NoVA UX meetup, Microsoft Dev Evangelist Andrew Duthie gave the group a presentation on the design thinking behind Windows 8. He described three influences–Bauhaus design, Swiss typography, and motion cinematography–and five design principles that guided the team:

• Do more with less
• Pride in craftmanship
• Be fast and fluid
• Be authentically digital
• Win as one

For more details about each, check out Andrew’s presentation.

Next, applied psychologist and human factors engineer Bill Killam talked about how user perception and various kinds of cognitive biases can affect usability testing. Here’s an example from his talk:

“You are shown a picture of a person running for office
and asked if you think they will win. There are far to
many variables for you to make a good prediction, so the
task is too hard for us to work out consciously.
As a result, our unconscious substitutes the hard
question for an easier one – does the person look like a
person who will win? Our unconscious provides an
answer to that new question, but our conscious self
reports it as the answer to the first question without
realizing the substitution.”

Read about other perception problems, biases you never knew you had, and how to apply testing techniques to overcome them in Bill’s presentation.

Next month’s meetup will be the first birthday for NoVA UX. Stay tuned for details about the festivities!

Understandable.

Without analytics, though, you’re shooting in the dark. Here’s what analytics can help you with.

1. Avoid Following Misleading Information

Gut feelings, and personal impressions can be very misleading. Think about it. Your scope, or the perception of your colleague, can be very biased, and implementing a change that affects everyone (such as all the users of your site), can turn out to be a bad situation if you’ve made the wrong decision.

Before jumping to a conclusion, do your due diligence practices and check your analytics to see if the data supports your decision. Good data won’t be biased; it’s the good friend that won’t sugar-coat it for you, and help you avoid some headaches.

2. Take the Shorter Route

Supplementing your trial and error with data is a shorter route to reaching your goals. Analytics can tell you what you’re doing right or wrong, and give you a better indication of what you could do to improve. Maybe it tells you something really isn’t working––like your audience doesn’t care for your content about pies. (But seriously, who doesn’t like pie?)

On the flip side, maybe your strategy is working, and you should be spending more time on it. Maybe your users love your perspective on making pie crusts from scratch, and you should create tons more pie content!

3. Give You a Solid Foundation

What happens when you plant in good, fertile soil? Your seeds will grow and flourish. But what happens when you dig into dry, rocky soil? Your results won’t be as fruitful.

The same thing applies to building your website, even your business, upon analytics. The right data will enrich and fortify your ability to achieve your goals. It’s the only way to know the real lay of the land you need to deal with, and give you good indicators of what steps you should take next. It’ll always be there, as you improve and change, to continue feeding you the information you need to grow. Seriously, it’s your best friend. Take it from us.

4. Empower You

We completely understand the feeling of being overwhelmed with numbers, data, and figuring out what to do with it. It’s tempting to go with an idea without taking the time to look at your data. But with the AddThis Analytics Dashboard, your information is simplified for you.

The information about your site is imported into graphs, lists, and hyperlinks for you––all under your account. We’ll even email you a notification every week on how your site is doing.

Check out this blog post showing you how to set it up, and navigate through the dashboard.

Over 30 projects were submitted, and lots of cool things came about as a result. Here are some highlights of how the day went.

Here’s the Virginia team gathered to kick off the hackathon in AddThis style!

Getting to Work

Teams took off into different rooms to plan and code for their projects. Even offsite colleagues dialed in to be part of the event. Hi Rich!

Bringing Out the Paint Brushes!

Our quiet room project took a lot of coordination, and teamwork. But the process brought several of us from different departments together. It was awesome!

Check out the before, during, and after pictures:

Before:

During:

After:

Doesn’t it look like it’s straight out of a catalogue?

After 24 Hours of Nonstop Work…

We had almost every project presented to the team.

Fin!

It was a great way to end the week! Have you ever been a part of a cool team-building project? Tell us about it in the comments!

Oops. Seems we left our furniture boxes in our colleague’s office. Guess we’ll get to that later.

We analyzed the difference between the types of people who bought Mom a gift a couple of weeks ago, versus people who still haven’t bought anything for her yet. This information’s based on shoppers looking for Mother’s Day gifts online in the past few weeks!

Whether you bought your gifts a week ago or are still shopping, we’ll be celebrating Moms this weekend. So make sure you go out and get her something nice!

Asynchronous Loading

Asynchronous loading allows you to put our bootloader script–addthiswidget.js–on your page without loading the other assets until you’re ready. To use it, just add the #async=1 flag to the addthiswidget.js URL and then call addthis.init() in a JavaScript function when you’re ready. That will load the assets, and render the AddThis tools.

<script src="http://s7.addthis.com/js/300/addthis_widget.js#async=1" type="text/javascript"></script>
<script type="text/javascript">
// Call this function once the rest of the document is loaded
function loadAddThis() {
    addthis.init()
}
</script>

The Domready Option

Our domready option allows you to load the AddThis bootloader script after the rest of the page. This could be useful if you want to put the AddThis buttons in a pop-over div but not include the tools on the page. Here’s an example script.

<script type="text/javascript">
var addthisScript = document.createElement('script');
addthisScript.setAttribute('src', 'http://s7.addthis.com/js/300/addthis_widget.js#domready=1')
document.body.appendChild(addthisScript)
</script>

This will produce the same result as if the addthis_widget.js script was loaded on the page. You don’t have to call any other function to get the AddThis buttons to render.

Rendering Buttons Dynamically

Many people have sites that use dynamic HTML or AJAX to show content. A common example is endless scrolling, which loads content as the user gets to the end of the page so they don’t have to navigate to another page for more content. However, because AddThis code runs at page load, the AddThis buttons on this dynamic content don’t display.

We offer a few functions to render AddThis on dynamic content, once our assets have been loaded. But the most useful one is probably addthis.toolbox(). Here’s how you use it:

First, add the addthis_widget.js to the page and make sure the assets have been loaded using the addthis.init() function or the domready option if you’re loading AddThis dynamically. This will ensure the addthis.toolbox() function is available.

Then, make sure you’ve got the AddThis buttons in the dynamic content. Something like this:

<h1>My Dynamic Content</h1>
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Maecenas ut nibh vitae quam adipiscing tempor et vitae nisl. Sed vulputate sodales dignissim. Quisque sit amet ante at lorem scelerisque malesuada quis vitae odio.</p>
<!-- AddThis Button BEGIN -->
<div class="addthis_toolbox addthis_default_style ">
    <a class="addthis_button_preferred_1"></a>
    <a class="addthis_button_preferred_2"></a>
    <a class="addthis_button_preferred_3"></a>
    <a class="addthis_button_preferred_4"></a>
    <a class="addthis_button_compact"></a>
    <a class="addthis_counter addthis_bubble_style"></a>
</div>
<!-- AddThis Button END -->

Finally, in the JavaScript callback that renders the dynamic content add the addthis.toolbox() function, using a CSS identifier as the first argument.

function loadDynamicContent() {
    // Code that will load the dynamic content

    // Once that's all done, call addthis.toolbox()
    addthis.toolbox('.addthis_toolbox')
}

What does “mobile” actually mean?

On the go?
A small screen?
A touch screen?
Handheld?

Unfortunately, the term “mobile” is used to describe many different things.

So how do we design for something so vague?
How do we know whether or not we should even try?

Rather than jump on a particular “mobile design” bandwagon, it’s more important than ever for us to cast aside the generic cure-all solutions, and instead embrace each product as its own unique design problem. This is precisely what User Experience (UX) professionals do best, and there are many proven UX methods that are ready to help us navigate these new, nuanced problems.

Let’s take it one principle at a time…

1. We aren’t our users, so we need to research.

We could listen to our gut, throw darts at a wall, or just start with the problems that we’d most like to solve, but I recommend UX research. UX research aligns teams, removes fear, and improves chances of success.

Talk to your target audience (either in person or using free surveys). Ask them what they do now. Ask them why. Listen. Ask follow-up questions. Give them something to use. Watch them use it. Review analytics. Take lots of notes. Review your notes. Ignore one-off requests. Focus on underlying patterns.

UX research has always been about studying user contexts and mental models. These design considerations must now include screen sizes, input methods, physical contexts, attention levels, and more. With a little bit of research, you might find that you only need to design for a couple mobile devices––or none at all.

(Bonus: Download this free tracking tool) 

2. We have limited resources, so we need to prioritize.

If you haven’t yet faced the cold hard truth, let’s face it now together: we cannot design for every user in every situation. Time and resources are limited. We can’t solve for every device in every context. We need to choose our battles. Make a list of the most likely use cases. Rank them by scope and impact. Separate the must-haves from the nice-to-haves. Decide if enough users are even trying to use your product on a new device.

By throwing out less common use cases, we open up opportunities to better serve our primary ones. If we have to design an app for a smartphone, this fact is amplified; there’s only so much room on the screen, space on the hard drive, power in the battery, etc.

3. We can’t predict everything, so we need to design for flexibility.

Even when we’ve done our research, there is still a lot we don’t know. People and technology will always surprise us with new contexts. There are thousands of potential ways in which a given product might need to work. Try (within reason) to design products so they still work with unexpected constraints. It doesn’t matter if the 320px window is on a desktop, a smartphone, or some new, unforeseen device; it would be nice if it didn’t break.

The Result?

If we follow tried-and-true UX methods, we should end up with a rather obvious product design strategy for all relevant devices. Whether it’s building an iPhone app with 3 features or a responsive website with 900 pages, the decision should be clear. It’s impossible for a product to work on every device, in every context, but it should work for the vast majority of users.

Here at AddThis, we serve millions of websites. So, we don’t get off too light. Our tools have to work for billions of users all over the world. But, if you find that all of your users still prefer a 1070px monitor, keyboard, and mouse, your job will be a bit easier.

But you might want check again in a few months.

Let’s focus our attention to concurrent data structures in a shared-memory environment where multiple threads are concurrently reading and/or writing. For a thorough background into concurrent data structures, I recommend reading The Art Of Multiprocessor Programming by Herlihy and Shavit (Morgan Kaufmann 2008, revised printing 2012). An assumption for this discussion will be that all concurrent data structures under consideration are linearizable.

First question: How do we construct concurrent data-structures? There are at least three common techniques used today, plus a fourth technique that I’ll briefly go over.

Coarse-Grained Locking

The first method is coarse-grained locking. Take your precious data, and wrap a giant lock around it.

Several large open source projects have relied on course-grained locking. The Linux kernel used a big kernel lock when it first introduced support for simultaneous multithreading in Linux 2.0. Work began in 2008 to remove the big kernel lock, and it was carefully replaced with fine-grained locks until it was removed in Linux 2.6.39. The default Python interpreter (CPython) uses a global interpreter lock to prevent multiple native threads from executing Python bytecode concurrently.

Fine-Grained Locking

The second method is fine-grained locking. Smash that coarse-grained lock into multiple locks! Each fine-grained lock is responsible for protecting a region of the data. Operations on the data are responsible for acquiring one or more of these locks in order to read, modify, and/or write.

Fine-grained locking can improve the overall throughput of a concurrent system. However, one must be careful to avoid the perils of concurrency including deadlock, livelock, starvation, preemption, priority inversion, convoying, etc. You must also have a strategy for releasing shared resources when a thread unexpectedly dies.

Lock-Free Programming

The third method extends the concept of fine-grained locking its logical extreme, which is to have lock-free programming.

Lock‑free programming is programming without locks. Or more formally, a lock‑free implementation of a concurrent data structure is one that guarantees that some thread can complete an operation in a finite number of steps regardless of the execution of the other threads. Lock‑free programming uses atomic operations, such as atomic swap, test-and-set, fetch-and-add, compare-and-swap, load-link/store-conditional, etc., to maintain consistent state. Lock‑free programming can improve system throughput and has desirable liveness properties. It is also tricky to design and implement correctly. The term wait‑free was introduced in (Herlihy, 1991). One of the earliest formal definitions of lock‑free is found in (Massalin and Pu, 1991). Jeff Preshing has a clever introduction to lock‑free programming.

Transactional Memory

The fourth method is to use transactional memory. Transactional memory allows several memory operations to be grouped together, and execute atomically. Either the entire sequence of operations appear to occur atomically, or else the system state is unchanged.

Transactions are a very familiar concept in a database management system. Transactional memory is still somewhat of an exotic concept. It can be implemented either in software or in hardware, or as a hybrid in software with hardware support. The Intel Haswell microarchitecture will have support for transactional synchronization. Scala, Haskell, and Clojure have support for transactional memory semantics (as do other languages). There are active con- and pro- discussions on the benefits of transactional memory.

More is Easy, Less is Hard

What about the secret life of concurrent data structures? Imagine you are building your own concurrent data structure. Let’s imagine this data structure as an abstract blob. There are three basic operations that we will want to support: get(), insert(), and delete(). Make a prediction on the relative effort necessary to design and implement each of the tree operations.

My ballpark estimate is that the relative effort for these operations amounts to 10% get(), 30% insert(), and 60% delete(). Common sense dictates that the modify operations are more complex than the read operation. Common sense might also lead us to think that the insert() and delete() operations are approximately equal in complexity. This is almost never the case!

It is almost always easier to correctly move from a state of less information to a state of more information than it is to move from a state of more information to a state of less information. This is even ignoring the extra complexity of ensuring that you have hygienic access to objects in memory. In other words I’m assuming a runtime which cleans up memory references, and (mostly) eliminates the ABA problem.

The relative difficulty of the delete() operation increases as one moves from coarse-grained locking to fine-grained locking to lock-free programming. To illustrate the delete() complexity phenomenon let’s take a look into lock-free linked lists. If only get() and insert() operations are necessary, then the lock-free linked list is identical in structure to the sequential linked list.

Lock-free Linked Lists

A linked-list is a collection of nodes. Each node is composed of a value, and a possibly null link reference to another node. For simplicity, lets assume that values in the linked list are immutable. The get() operation performs an atomic read on each link reference as it traverses the list in search of the target element. The insert() operation locates the predecessor node where the new node is to be inserted and attempts a compare-and-swap (CAS) operation on the link reference on the predecessor node. If the CAS operation fails then rinse and repeat until successful.

What happens when we add support for the delete() operation? It is illustrative to look at the literature ,and see how the design of the lock-free linked list has evolved over time.

Valois (1995) introduced the first lock-free linked list algorithm. Consistency is maintained by using auxiliary nodes which are defined as nodes that do not store values. Every normal node in the list is required to have an auxiliary node as its predecessor and its successor. With this design, consistency is maintained at the cost of a x2 storage overhead.

Greenwald (1999) constructed a lock-free linked list that does not rely on auxiliary nodes. The design relies on the double compare-and-swap operation (the ability to compare-and-swap two disjoint memory locations) which is not available on modern hardware.

The modern lock-free linked list design was introduced by Harris (2001) and Michael (2002). In this design two CAS operations are used to perform deletion. The first CAS operation marks the node as logically deleted. The second CAS operation physically removes the node. The linearization point is the first CAS operation. This separation of concerns between logical deletion and physical deletion is a powerful technique. It forms the basis of many modern lock-free data structures. The get() and insert() implementations need to be revised in light of this technique. The other operations need to either ignore or eliminate logically deleted nodes.

The secret messiness of deletion is indirectly exposed throughout the literature. The seminal book Purely Functional Data Structures introduces immutable red-black trees that support get() and insert() but not delete() operations.

The recent paper on the design and implementation of Bw-trees includes the following innocent sentence: “[Node] merges are decidedly more complicated than splits, and we need more atomic actions to accomplish them.”

The Bw-tree paper is definitely worth a read. I have seen other papers in the literature on concurrent data structures that simply leave out the delete() operation. Possibly these papers have sufficient research contributions such that they stand on their own merit without this operation, or possibly the data structure is designed for those contexts in which information is never deleted.

Conclusions

When you are designing and/or implementing a concurrent data structure, the final task in your workflow is typically the deletion operation. But this is the most complex of the operations you will be supporting. You must plan ahead in your design with an eye on the deletion problem. Use the technique of separation of concerns to distinguish between logical deletion and physical deletion. To my knowledge, this is the most common approach used today in supporting lock-free deletions.

Caveat emptor

My personal experience with concurrent data structures has been primarily with ordered data structures. I have a hunch that the relative complexity of deletion for unordered concurrent data structures may not be as high. But I don’t have the evidence to back up that claim. A good place to start reading up on concurrent hash tables is “Hopscotch Hashing.”

Here’s what we saw happen.

Twitter was used 38% more than Facebook when it came to sharing the news.

Twitter users went to the social network to catch live updates, and share them with their network in an incredibly fast pace. It was the go-to network when the news broke, and people highly engaged with each other to spread the word. We also saw the Boston Police Department primarily using Twitter to get the word out about the suspects, polite scoldings, safety alerts, and details of the manhunt.

Email, Reddit, and Facebook were primarily used to have conversations.

This isn’t to say breaking news weren’t shared on these channels, but people came to these channels to talk about the events more than to find facts. Email and Reddit were second and third, respectively, most used channels for conversation about the events, with Facebook coming in after that.

Good and bad information amplified. Big time.

Social media is a voice amplifier (and a fast one, too). Everyone was on high alert watching for any information that could be unveiled at any second. Even though at times misinformation spread quickly, social media was a primary force of sending support and help to these communities soon after the news broke. In fact, check out how the Internet sent its support to Jeff Bauman, one of the survivors of the bombing. And grab a tissue box before you do.

Interestingly enough––though not totally unexpected nowadays––we saw a tremendous amount of crowdsourcing from authorities and news outlets on social.

What’s the takeaway here?

There’s one big lesson to learn here: the tools facilitate and amplify, but it’s the user that gives it a voice.

Akka is a library for building concurrent scalable applications using the Actor Model. Its fault-tolerance model is heavily influenced by Erlang. In this post, I will talk about our experience with using Akka (2.0.x) remote actors to build a distributed system, SAM.

SAM is an internal tool for managing the data processing pipeline for billions of records daily. Much of the big data heavy lifting is done with our home-grown Hydra system. SAM functions as the command and control center that submits jobs and runs queries to advance the workflow. It also needs to do intermediary and post-processing of a non-trivial amount of data returned by Hydra.

SAM is designed to be horizontally scalable, such that it can scale out when the underlying Hydra cluster scales out, or when its own workload requires more processing power. It consists of a master and multiple slaves. The master is responsible for task allocation, bookkeeping (DB access), and providing a RESTful API. The slaves are responsible for task execution, such as running hydra queries and aggregating results.

A typical workflow starts when the master receives a user request as illustrated in the sequence diagram below (the participants are Actors, and interactions are message exchanges between them):

• TaskCreator creates a task based on the user request and sends it to the TaskQueue
• TaskQueue enqueues the task as well as the sender–the TaskCreator’s ActorRef
• TaskQueue dequeues a task and sends it to a Slave’s TaskReceiver, which has registered itself as a task consumer. TaskQueue actually doesn’t know or care about the locality of a consumer–it is just an ActorRef
• TaskReceiver receives the task and sends it to the appropriate TaskProcessor, with the original sender as the result receiver
• TaskProcessor executes the task. When processing is done, it sends the result back to the receiver–the TaskCreator that created the task at the beginning. Here again, the locality of the receiver is transparent to TaskProcessor

Remote message passing is enabled by a few lines of configuration:

akka {
...
	actor {
		provider = "akka.remote.RemoteActorRefProvider"
	}
	remote {
		transport = "akka.remote.netty.NettyRemoteTransport"
		netty {
			port = 2552
		}
	}
...
}

Akka makes it easy to send messages to local or remote Actors. The code is exactly the same from the applications perspective. The Akka libraries automatically route the message to the correct actor.

Akka provides a very easy way to lookup remote actors:

val actor = actorSystem.actorFor("akka://actorSystemName@server:2552/user/actorName")

To minimize explicit knowledge of actors’ locality, however, we try to limit the use of such lookup in our code. The only place we use it is in the slaves for finding the MasterService actor defined by the master that allows the slaves to register themselves as TaskReceivers.

To detect cluster node connection/disconnection, we take advantage of Akka remote events.

On the slave side, we created a MasterMonitor actor dedicated to monitoring the master connection status. It tries to reconnect when the master is disconnected. On startup, the actor subscribes to the global RemoteClientLifeCycleEvent, and pings MasterService:

override def preStart = {
	context.system.eventStream.subscribe(self, classOf[RemoteClientLifeCycleEvent])
	reconnect(Duration.Zero)
}

The response of the ping message is not important–as a matter of fact, MasterService doesn’t even handle “ping”–it is a way to trigger the RemoteClientLifeCycleEvent that MasterMonitor is interested in:

def receive = {
	case _: RemoteClientConnected   => updateMasterStatus(newValue = true)
	case _: RemoteClientWriteFailed => updateMasterStatus(newValue = false)
	case _: RemoteClientShutdown    => updateMasterStatus(newValue = false)
}

If the outbound connection is established, the actor will receive RemoteClientConnected, and it sets the master connection status to true. When the master is disconnected for whatever reason, this actor will receive either RemoteClientShutdown or RemoteClientWriteFailed, and it will set the master connection status to false. Based on the master status, other slave actors such as TaskReceiver can change its behavior accordingly.

The MasterService has a similar approach to handling status messages. Slave disconnection triggers a RemoteClientLifeCycleEvent:

case RemoteClientShutdown(_, addr)          => unregisterSlave(addr)

case RemoteClientWriteFailed(_, _, _, addr) => unregisterSlave(addr)

Because the master must maintain statuses of multiple slaves, it uses the remote address value of the event to tell which slave is disconnected. This simple implementation for detecting cluster node status has proven very robust in practice. It works equally well in case of normal shutdown/reconnect as well as abnormal exits (e.g. kill -9).

Even though Akka makes it easy to use remote actors it is still a good practice to understand how that distribution works. Specifically one should be aware that:

• Akka uses Java object serialization by default to serialize remote messages. Make sure the message objects you use can be serialized/deserialized properly (case class is always a good choice for message)

• Default max message size is 1M, so be mindful about data transfer between remote systems via message passing. When the size of a message exceeds the limit, the error is not always obvious. (For example, if Master tried to send too large a message to Slave, a RemoteClientError would be triggered on the slave side, and RemoteClientShutdown on the master side. Had we not subscribed to RemoteClientLifeCycleEvent, it would appear that the message was simply lost.)

As we build out SAM and gain more knowledge about Akka, we realize that a few things are less than ideal in the current design and implementation:

• In most master-slave setups, master tends to become the bottleneck/single point of failure. It’s no different for SAM. Heavy usage of the RESTful API sometimes puts the master under load, and even a short downtime of the master may affect other systems that depend on it
• Master and slave have different code bases; this makes remoting more difficult. For example, we have to take extra care to make sure the classes we are using as messages between the master and slave are available in both. We ended up putting all those in a common module, which adds some complexity to the whole project
• We designed the master to be the sole location for storing data files. When a task requires files to be exchanged between the master and slave, we can’t send the content of the files as messages because they are usually too large. To work around that we make the sender send a url that the receiver can use to download the file. That becomes tedious quickly. Using a distributed file system such as HDFS can be helpful here

Going forward, we’d like to change the master-slave setup to a cluster of identical nodes with dynamic leader election. A major addition in Akka 2.1.x over 2.0.x is cluster support, including a gossip protocol for cluster membership. That can potentially simplify things quite a bit for us. We can’t wait to try it out!

SAM is not the type of high throughput low latency systems that Akka is usually used for, nonetheless we still find Akka an invaluable tool. Its actor model implementation makes building correct concurrent applications easy. In this post, we covered our usage of remote actors, which is only one of many wonderful things Akka has to offer. We look forward to sharing more of our experiences with you.

Did you get this far? Are you interested in the type of scalable work we’re doing at AddThis?  If so, why not check out the engineering openings on our careers page?

Both companies use comprehensive testing strategies, and multiple analytics tools like Google Analytics, Omniture, and Adobe’s Test and Target, to optimize conversions and revenue. CustomInk shared strategies for refining their unique online + offline ordering process, and ThinkGeek described how they do sophisticated testing with a very small team.

One of the popular quotes of the evening was from ThinkGeek’s Matt Chwat: “Our definition of Lean UX is that we’re lean on UX.”

CustomInk described their experiences developing faceted search for t-shirt ordering, and how its efficacy changes with different audiences and contexts. We also explored how both companies wrap customer service and community management feedback into their design and development processes, keeping the focus ultimately on their customers.

Both companies brought along some fun giveaways; six attendees scored gift bags from ThinkGeek, and one lucky attendee won a $200 gift certificate towards a CustomInk t-shirt order.

As always, we had a lively Q&A throughout the evening with an audience of local designers and developers in the Northern Virginia area.

We’ll look forward to seeing everyone next month, when Andrew Duthie will talk about how Microsoft designs for both mobile and desktop products, and Bill Killam will dive into strategies for usability testing.

If you’re interested in attending these events, join us at the NoVA UX meetup group.

Click here to download the sharing tools.

One of the driving factors behind this blog refresh was to make it more responsive and mobile-friendly… so whether you’re viewing it from your preferred browser, tablet or smartphone, it’s now be much easier to read than before.

The photos on the side were taken around the office, so you also get a glimpse of what it’s like here at AddThis. If you refresh it a few times, you’ll see new photos being loaded… and not to worry, we’ll be adding more shortly.

p.s. In case you’re curious, foosball remains king around here, though I still manage to sneak in some Halo 4 action every once in a while.

Can you connect to AddThis?

AddThis buttons are generated using JavaScript and CSS that’s stored on our servers, so if your computer doesn’t have access to these servers, you won’t be able to see the buttons. This can happen for a number of reasons, but is usually related to adware or malware blocking software. Verify you have access by going to these URLs:

• http://www.addthis.com/
• http://s7.addthis.com/js/300/addthis_widget.js
• http://ct1.addthis.com/static/r07/widget110.css

If you experience errors visiting any of those URLs, or see something that doesn’t look like AddThis, you don’t have access to AddThis and therefore the buttons won’t show up. If you can identify which software is blocking AddThis, follow the prompts to unblock us, and the buttons should show up.

Do you have all the code on the page?

If you’ve recently made changes to your site another problem might be that you didn’t put everything back on the page. View the source of your page (by right-clicking or Control-click your page, and select “View Source” or “View Page Source”) and use the find command to make sure you’ve got the following items on the page:

• The AddThis toolbox with buttons in it. (Note that the buttons inside of this might be different depending on which ones you use.)

  <div class="addthis_toolbox addthis_default_style "> <a class="addthis_button_preferred_1"></a> <a class="addthis_button_preferred_2"></a> <a class="addthis_button_preferred_3"></a> <a class="addthis_button_preferred_4"></a> <a class="addthis_button_compact"></a> <a class="addthis_counter addthis_bubble_style"></a> </div> 

• Also, make sure you have our addthis_widget.js on the page. This script loads all the other code that shows our buttons. If it’s not on the page then none of the buttons will show up:

  <script src="http://s7.addthis.com/js/300/addthis_widget.js" type="text/javascript"></script> 

Are you using WordPress?

First, make sure the plugin hasn’t somehow been deactivated. If you recently changed your theme, make sure it uses the the_content() function instead of get_the_content() as the latter doesn’t include the callback that adds the AddThis buttons to your posts.

Finally, if you’ve got a caching plugin like WP Super Cache make sure that you flush these to ensure the buttons get added to your posts.

Still don’t see them?

If you’re still not seeing the buttons after checking the steps above, you may be having another issue. In that case, contact our support team, and we’ll be happy to help!

While many of my co-workers have claimed they’re the best, we haven’t actually ranked people yet. We’ll need to host a tournament sometime soon.

If you’ve got ping pong and engineering skills, you should come by. Check out our careers page–we’re hiring!

URL design discussions for RESTful web services often degrade into debates over pluralization and parameter names. There are a couple of principles I like to use to keep things simple.

1) Using your API should feel like using a filesystem

• Endpoints used to create, list, and search for entities should look like directories, e.g. /users
• Use a plural noun so it feels like a directory of users, not a user controller
• Endpoints used to read, update, and delete individual entities should look like files, e.g. /users/charlie

2) All calls to a given endpoint should return the same type

• Either apples, or oranges, or a list of oranges, don’t mix them up
• File-looking endpoints should return individual entities
• Directory-looking endpoints should return lists of entities

We may be bikeshedding here but I think your API will be more intuitive to newcomers if you model it this way.

• Consistent response type per endpoint simplifies deserialization for clients, no switching needed
• Once you agree on a contract it’s easy to mock up with static files on a server
• Clients can start working with your mockup before your code is finished

To read the rest of this blog post, head over to APIUX.

Unfortunately, this was out of our hands since the problem happened on Facebook’s end. But I thought this would be a good time to explain how counter values work, and where those values are stored.

How counters work

Counter values for all services are stored based on the URL of the page. So, for example, the URLs http://www.example.com/index.html and http://example.com/ will have different counts because the URLs are different, despite the fact that they’ll display the same page.

Take a look at this image:

If there is a difference in anything falling into the green sections, the counts for those URLs will be different.

There are ways around this; for example, you can set a canonical link tag or set the URL to share to be different, but if you do that, the counters will be the same regardless of the page you’re on.

So if you have the Facebook Like button on several pages of your site, and you don’t have any other configuration telling AddThis to use a specific URL you designate, each page of your site will have different count values.

Many people make the common mistake of thinking the Facebook Like button should have the same number of fan Likes on their Facebook Page. This isn’t true. The Facebook Like button doesn’t count Likes for your Facebook Page just like the Tweet button doesn’t count your Twitter followers, and the Google +1 button doesn’t count the number of people who have +1′ed your Google+ Page.

The Like/Tweet/+1 button counters specifically show the number of times the URL (the one you’ve configured to share) has actually been shared to those services.

The Facebook Like button counter also includes activity not tracked by AddThis analytics, such as likes, shares, and comments that happen on Facebook.com. Here’s a screenshot of what you’d see about your Facebook-related activity from your AddThis analytics page:

Counters are also served from cached servers to improve performance. So, for instance, you share something to Twitter, and then immediately refresh your page, the counter won’t be updated until Twitter’s counter server updates its cache.

AddThis counters work a little differently. We cache the values, but we also store the counter value in a cookie on your computer after you share, so users are reassured their share was registered.

Where counter values are stored

Each service — whether that’s Facebook, Twitter, or AddThis — stores its counter values separately. This means that the value you see in Facebook’s Like counter is only stored on Facebook’s servers, not AddThis servers. The same goes for the Tweet, +1, and all of our third-party buttons. So when you see that your counter reset without having made any changes to your URL, it’s almost always something that happens outside of the AddThis tool.

The only counter values AddThis stores are the ones used in our compact menu and our pill-style menu. That is, for:

<a class="addthis_counter addthis_pill_style"></a> 

and:

<a class="addthis_counter addthis_bubble_style"></a> 

Our Individual Share Counters use the services’ APIs to get the counts, so we don’t store those counter values either.

I hope this answers all your questions about counts, counters, and what happens when you see your counter rest. If you have any questions for me, feel free to post them in the comment section below, or look for me over in our support section!

We upgraded our sharing tool last fall, with a slick new interface which boosted sharing performance, and made it easier to use.

The new version of the AddThis boasts a sleek one-column design, enhanced email sharing, and personalization to show the services you use the most. Check out the picture below.

We also introduced our new instant share feature which lets visitors sign in and share your content without leaving your site! (The green dot on the icons in the picture shows that it’s enabled.)

This is just the tip of the iceberg of what we can do! Are you feeling the excitement yet?!

I know, me too.

The best part: you don’t have to do anything because we’ll do it for you.

On May 7th, 2013, we’re automatically upgrading any sites using old versions of our sharing tool to the latest version of AddThis. Check out these instructions to preview how it’ll look like on your site. (Tip: if you’re not sure which version you have, compare your menu to the image above, and if it doesn’t look like the menu on the right-side, you may have an older version.)

If you don’t want to wait until then, you can grab the latest code right off our site. But if you need a little more time with the older versions, we have instructions on how you can keep your current version for an additional 90 days.

“The AddThis A-team adds passion, commitment, and incredible intellect everyday,” says Ramsey McGrory, CEO. “Our core principles focus on data, simplicity, community and adding value and fun in everything we do. I like to think being named as one of the best places to work in the DC area means we’re doing just that. We’re honored to be recognized.”

Many thanks to the Washington Business Journal!

Want to work here? (We’ve got a foosball table!) Check out our careers page for details on openings.

I’ll be behind the scenes on our AddThis social pages, and all the best platforms and forums to communicate with you. My job is to engage in a conversation with you—our amazing users.

I’ve been doing this a while, and the thing I love the most about community management is watching the difference all of our personal connections make every day–in conversations, communities, industries, even in product features. And its all happening so fast! AddThis is listening and understands the power of connections and data. We’re making online experiences more engaging, and more meaningful.

Being your community manager means I’ll be on several social channels (Follow us! Like us!) to connect with you, get to know you and learn from you. I’ll help answer questions, or direct you to the best resources to get you what you need.

I’m really looking forward to adding to the community! Add yourself if you haven’t yet.

Last night AddThis hosted the the March NoVA UX meetup here in our Vienna, VA headquarters. We had two speakers:

First up was Alex Kalinovsky, CEO of CreamTec LLC, who gave a talk about visual UI testing. Alex talked about the importance and challenges of visual interface testing, described current tools and methodologies, and then introduced his company’s solution called Screenster. You can check out his slides on SlideShare.

Steve Wendel, Principal Scientist at HelloWallet, spoke next. He described strategies for designing products and interfaces that promote behavioral change – Action Design. He describes Action Design as building good products that are effective at changing behavior, so people can do things that they want to do but haven’t been able to do before. You can check out his presentation on his company’s blog. Steve also organizes the Action Design DC meetup.

For next month’s meetup I’ll be moderating a panel discussion about e-commerce user experience design with design leaders from local retailers ThinkGeek and CustomInk. If you’re a UX professional in the Northern Virginia or DC Metro area, come join us on April 10th at 7pm here at AddThis HQ.