One common act of Terran desperation during an attack is to send buildings elsewhere. They lift off and float away, and ground-only invaders (like Zerglings) are unable to cause any more damage.

As a developer, I hate having to move any application from one environment to another. The rationale for doing so is almost always because I am forced, either by rapid user growth, or inadequacies with an existing technology stack.

PHPFog

GoSoapBox recently had to migrate away from PHPFog, a PHP-specific host. In November, we received noticethat the creators of PHPFog were shutting down the service to focus on another offering called AppFog. We were given two months to plan and complete our move. In exchange for the major inconvenience, they offered a $100 service credit.

Like many application hosts, PHPFog is an abstraction layer on Amazon Web Services that includes some value-adds like Varnish, but more importantly makes it easy to deploy an application.  Though there are noteworthy competitors, AWS is the redoubtable leader in cloud computing; when they go down, so does half the internet.

Cloud Hosting

Cloud hosting’s true advantage is scalability. In our early days, we kept GoSoapBox on a lone dedicated PAIR Networks server. Though this server handled traffic quite satisfactorily, our concern is that it would not perform as well when the number of visitors increased. Cloud hosting makes it easy to handle that load by adding instances of your application to a server pool.

Application hosts vary in in how they approach scaling. PHPFog required us to manually move a slider and click update; AppFog acts the same. Another service, called Orchestra, purports to offer automated scaling when they detect increased load, resources are moved into place without you having to do anything. Xeround, a MySQL provider, also claims to do the same.

Here’s the rub: These small hosting startups abstracting through AWS or other server farms have pathetic support response. If something ever goes wrong with GoSoapBox’s connectivity, dozens of teachers will be complaining within minutes, and I will be sweating bullets while waiting for my application host to respond. Support level is a deal breaker.

Migrating

Orchestra was the first application host I tested. Deploying was a cinch, SSL was running, and I thought everything was going to be just dandy until I applied some load. Using loader.io, I successfully crashed a development instance of GoSoapBox. When I do this, the defeated server typically comes back to life after the load drops off. With Orchestra, it wasn’t coming back at all. So I emailed their support, and waited. And waited.

Granted, this occurred on December 22nd, just a few days before Christmas, but no one got back to me until mid-day on December 26th. And it wasn’t even a resolution, just a “we’re escalating this” email. Altogether, the time from problem report to initial response was 90 hours.

Nearly four days later, I had already decided to move on. I tried my hand with AppFog but discovered they have serious undocumented problems with requests per second. Their instances topped out around 30/s, by far the most pathetic benchmark number I have seen when testing GoSoapBox. AppFog’s support response time was much better than Orchestra, but left much to be desired, particularly when the questions were simple items that should have been written somewhere in their documentation.

(Also: How the hell is it okay to advertise Redis when your version of it only supports six concurrent connections? That’s like a restaurant saying they are open on Sunday, but only between 3:00-3:30 PM).

Eventually, we gave up on third-party services and deployed directly on AWS via Elastic Beanstalk. AWS support has a noted one-hour response time, which amazingly we haven’t had to use yet, and for more money you can get a 15-minute SLA. We also moved our database away from the autoscaling mess that is Xeround and onto Amazon RDS.

For the Love of Customer Service

What I have discovered during this journey is a deep love for services and products with rapid support response, which is why, if I can figure out their cloud services, I would eventually like to move GoSoapBox to Liquid Web. You can email them and they get back to you within minutes; or you can CALL them and a real person will answer.

I didn’t realize it, but I apply a similar philosophy when responding to support requests with GoSoapBox. When someone sends in a problem report, I move heaven and earth to reply straight away. They’ve taken the time to use my service and write to me. I am certainly going to try returning the favor.

Server Administration

While you’re reading this, I may come off as someone competent in the area of server administration. Don’t be fooled – I have little clue what I’m doing. But I do understand, conceptually, how everything works, and this has allowed me to have fruitful conversations with engineers about scaling GoSoapBox.

Though there are blogs and books and forums for tech-minded folks to discuss scalability, one thing missing from the market is a service that helps small startups get server administration right. I’m great with code, but before having to learn about caching and sharding and all the good stuff, I knew diddly about building an application to scale.

I would gladly have paid for advice and direction from a third-party company that would have taken the time to listen and understand my needs. Had an application host been able to do this, I likely would have become a loyal and lifelong customer. But, painstakingly, I had to learn it on my own, and instead of praising services like Orchestra, I am now deriding them.

Despite the actuarial reality, digital entrepreneurs are coming out of the woodwork. They are driven by two things: The ease of coding something up in a weekend, and the tales of hundred-million-dollar exits.

“If we build it, people will come.” If only it were that easy.

Designers and developers don’t appreciate marketing. I know I sure didn’t when we started GoSoapBox. Over a few months, we built an outstanding audience response system that allows teachers to constructively leverage the devices students already bring to class. And then we had to get people to use it.

If we could do it all over, I would take a different approach. Building something is not even half the battle. I would start by seeking partnerships.

Investors

Angel investors and venture capitalists are handy partners because they have a direct interest in seeing their investments mature. In addition to financial support, investors tend to be well connected and can give you direct access to the people and places you need to be to succeed.

A great example of an investment partner is the television show Shark Tank, where small business owners pitch their products to sharks (veteran business folks) with deep pockets and unlimited connections. The entrepreneurs give up 5% of their company and 2% of their gross sales just to pitch, and if they strike a deal with a shark they are typically giving up an additional 20-50%. That’s how valuable the partnership is with one of these individuals.

Funding isn’t for everyone, and not all investors will be able to guarantee success like those in Shark Tank. But for many entrepreneurs, investment partners are a step in the right direction.

Development Partners

Your first customers are enthusiastic about your product. (If they’re not enthusiastic, you might want to re-think who you’re selling to.) Rather than build something blindly, you can form a symbiotic relationship with your first customers by asking them to be development partners. Development partners get access to your daily builds, and while acknowledging the bugs and limitations, provide steady feedback. They get something that solves a problem, and you get information that would otherwise cost tens of thousands of dollars in usability research fees.

Distribution

Sales can be time-consuming. With Conferences I/O, the award-winning audience response system for events and conferences, we typically do one-on-one demonstrations with prospective customers. Each demonstration takes about one hour; that’s hard to scale without having a dedicated sales staff.

Distribution partners can put your product in the hands of customers without requiring you to do anything. In exchange, the partner receives a cut of the sale. For example, with Conferences I/O, we offer event planners a percentage of our revenue when they sell our product to their clients. Everyone wins: The event planner’s client gets a great product, the event planner receives a bonus, and we gain a customer without having to lift a finger.

One great distribution partner can guarantee a company’s success.

Marketing

In the same vein as distribution partners, a marketing partner will help connect you to potential customers. Typically this relationship will include referral fees, and you will still be responsible for the bulk of the sales process.

Creating Barriers to Entry

As I mentioned at the outset, designers and developers are attracted to digital entrepreneurship because it is easy to hack something up in a weekend. But that very advantage is also a danger. What’s to stop someone from copying your idea and stealing customers?

Partners can support your company’s position by creating barriers to entry for competitors. If you’re building software for tech-savvy lawyers to use and you get the biggest legal blog to sign on as a marketing partner, it’s going to be an uphill battle for a competitor to upstage you.

Conclusion

I love building beautiful digital products that solve meaningful problems. I’m product-focused. When I come up with an idea, I want to run out and build it.

But we forget that successful companies don’t operate in silos. They have relationships with investors, advisors, marketing partners, and distribution partners.

Product is provocative, but partnerships are powerful.

High-fidelity interfaces, by their very nature, are bulky. Bulky design has no place in a future that will soon see mobile web outpace desktop web. Though improving, mobile web speeds aren’t broadband, and mobile device displays are nowhere near the pixel perfection offered by cinema monitors.

So how’s that heavyweight homepage working out for you? The audience running broadband on their oft-updated, recently-purchased rig probably loves your site. But for everyone else, maybe it loads slow. Maybe it doesn’t load at all.

Despite my warning, the web has continued full-throttle toward heavyweight design.

Performance Matters

Website performance is essential to creating a positive user experience; nothing annihilates a visitor’s experience quite like slow-loading pages. Folks who don’t really care about your site will bounce faster than you can, well, say ‘bounce’.  But if they have to use your website to accomplish some task, all that time wasted waiting for page to load will be converted into a serious grudge. Users will eventually despise you and your website.

Hefty websites continue to be churned out by professional design shops, which fail at performance because they use a PSD-driven workflow. Website design at most firms is literally pixel pushing and getting client sign-off before anything is built. When the look and feel is an exact quantity, the developer has to produce code that aligns seamlessly, regardless of the performance cost.

Responsive/adaptive design gives this conversation greater importance. When we design one site for many devices, there’s a risk that mobile users will be fed a hefty meal that takes minutes to download. If there was a 45-minute wait in line to get fast food at McDonald’s, would you stick around or just go to Burger King next door?

Designing for Performance

Designing for performance means changing your workflow. Get rid of layered PSDs and build an HTML/CSS functional prototype. Start with the overall look and feel, critical points of interaction, and then dive into detailed design work. Add JavaScript libraries only when you need to. As much as possible, merge your visual design and frontend development.

Throwing away the PSD is the most significant change that we need to make. As website designers steadily acknowledge the emerging responsive design ethos, it makes increasingly less sense to whip up PSDs for every possible device and resolution.

Over the last few years, my design workflow has evolved to this: Discussion, sketching, and prototyping. Clients tell me what they want to get out of a site, I generate ideas through sketching, and then settle on a consensus by building out a prototype. This process allows me to rapidly construct exceptional, UX-oriented design. Outstanding performance comes naturally with this workflow, because a functional prototype will not pass muster if it does not perform.

Improving Website Performance (A Technical View)

Website performance is a combination of two factors: Network latency and server latency. Network latency is the time a request takes to get to and from your server. Server latency is the time that request requires once it hits your server.

Strategies for Improving Network Latency

Reduce Number of Requests

Websites with fewer assets requests take less time to load.

Imagine that you’ve just returned home and your car’s trunk is full of groceries ready to be taken inside. Your groceries are in bags, and even though you’re strong, you don’t have the capacity to carry all the bags in at once, so you make multiple trips.

Your web browser behaves similarly. When talking to the server, several asset requests will occur simultaneously to reduce the number of trips that need to be made. But for a page with dozens of separate assets, there will be more back-and-forth time.

Use a Highly-Available DNS Service

When you load a website for the first time, your browser has to figure out that website’s IP address. The process looks like this:

1. Talk to root name servers to determine the name servers for your TLD.
2. Talk to your TLD’s name servers to get the authoritative name servers for your website.
3. Talk to the authoritative name servers to get the IP address.

A highly-available DNS service reduces initial IP lookup time by pushing your DNS records to a series of DNS servers around the world. Instead of having to talk to a single authoritative DNS server in the United States to get your server’s IP address, a user in Europe will get this information faster because of the presence of a local authoritative DNS server.

Content Delivery Network (CDN)

CDNs like AWS CloudFront take your static assets and push them to edge servers positioned around the world. Because static assets account for the bulk of initial HTTP requests, this is advantageous as it considerably reduces the distance between the assets and a visitor’s computer. All serious websites and web applications use a CDN.

Strategies for Improving Server Latency

Once a request arrives, your server needs to send a response. Sometimes it’s easy and just means delivering a static asset like a CSS file or a flat HTML file. Other times, it means hitting an application which needs to perform expensive logic before eventually returning a response.

Because the sources of server latency vary wildly, I will not discuss apache vs nginx, database optimization, in-memory caching, or anything of that nature.

Output Compression

Output compression (typically gzip) deflates a response, resulting in generally improved load time. Think of this as crumpling a piece of paper into a ball before throwing it.

Local Caching

Most CMS and frameworks have options for page caching. Enabling local caching means that the application will write the response to disk and deliver this, up until the cache expires or is manually removed. Even though a request still hits your server, the response is faster because the database won’t be involved.

HTTP Caching

HTTP Caching (typically Varnish) is often used to front high-traffic websites and web applications. When your server responds to a request, it also sends an expiration header. For example, I might say that a particular page expires in 3600 seconds (60 minutes). Varnish listens to this header and caches the response, then delivers the cached response for subsequent identical requests up until the cache expires.

Performance gains through HTTP caching can mean going from 50-100 server requests per second to 25,000 Varnish requests per second without breaking a sweat. Though a CDN is still better for pure static assets, Varnish is quite powerful for application-driven responses that don’t change often.

Conclusion

Website and web application performance is an important topic that can be addressed from many angles. All projects will benefit from the adoption of a prototype-oriented workflow that allows designers and developers to observe performance as a concept is being produced. From a technical perspective, developers can employ a number of strategies to improve network and server latency, thereby reducing load times and keeping visitors happy.

Here’s a real quote from a fellow user experience designer:

Every day I read another story about a startup getting millions of dollars of funding with no defined target audience and no defined problem they’re trying to solve.

These startups only exist to add something new to the world without any intention of taking anything away from it — obstacles, frustration, pain. They create massive amounts of digital garbage and conveniences for no one but themselves. And their VCs give them near-unlimited access to resources to do so.

This line is alarmingly similar to political stump speeches that rail against the National Endowment for the Arts, a taxpayer-funded organization that funds artists’ projects. Every election cycle we hear, “Society should not support this filth!”, followed by boisterous applause from a partisan crowd.

I don’t vote for those candidates. I don’t vote for them because I believe exploration and discovery are essential for cultural growth. We need our scientists to investigate the unknown. We need NASA searching the space beyond our atmosphere. We need the NEA supporting weird shit that we don’t like. And yes, we need venture capitalists funding some products with no defined target audience and no defined problem. Startups are as much an engine of exploration as the Mars Curiosity Rover.

(Brief aside: I also disagree that these undefined-audience-problem startups are receiving enormous sums of capital. $1M+ rounds of funding go to companies with traction, and traction can only be established when people actually use a product.)

Of course, there is still cause for concern: Entrepreneurs could be doing more for the good of society, and investors could be doing more to encourage positive behavior. Without blinking, we sign NDAs and operating agreements; we need to be more serious about our social contract to make the world a better place for ourselves and our children.

Two final notes on this topic:

First, there are communities of entrepreneurs and invstors trying to do social good. Imagine K12 is an education-focused incubator aiming to improve educational technology for youth worldwide. Kickstarter allows individuals to vote for ideas they want to see through donations. There’s a lot of good and a lot of good people out there in the startup space.

Second, a fool and his money are soon parted. User experience matters, and  success will favor venture capitalists who get it.

Education is more than about how to navigate an interface. We also need to show our users what features exist, when they would use them, and where to find help. I often refer to this as designing the onboarding experience. That name isn’t very catchy, though, and if you are interested in the topic you should check out the slides from Daniel Burka’s presentation after reading this post.

What we have found with GoSoapBox is that educators who participate in a live demonstration of the product very quickly grasp the concepts behind it. That is, when we have their attention, they absorb our mental model with ease, and are much more likely  to continue using the product. Teachers who onboard without such a demonstration are less likely to continue using it.

Live demonstrations require a lot of extra time. Because we prefer to keep these sessions one-on-one, there are a limited number of teachers we can onboard in a given week. So for those we cannot reach directly, we offer a thorough knowledge base, videos, and a quick-response support system.

Unfortunately, the resources we have created aren’t always used. We’ve been searching for a new approach to hands-off onboarding. I’m going to mention a few here:

Desk.com

Desk.com, a popular support/help system, incentivizes product discovery by giving users bonus flex hours by doing new things. This approach works because Desk.com is a broad application with a lot going on. They believe their product is valuable, and to get users to see that value they want them to sink their teeth in deep during the trial period.

Incentivizing comes easier to Desk.com because they have something to give away, these flex hours (they charge by support agent, and flex hours allow someone to be a part-time agent). For a product like GoSoapBox, the users we want to discover features are not paying anything anyway. To gamify feature discovery, we would have to ger very inventive about what to give away. Maybe a t-shirt.

Kera.io

From the screenshot, you are probably having a hard time guessing what Kera does. When you click their ‘demo’ button, a video playback box appears and you hear the voice of the product’s founder, Max Cameron. What happens next looks like a standard video, but is actually an automated tutorial. A piece of recorded JavaScript takes over during this audio recording and begins interacting with the page, guiding visitors through the homepage intro slides before inviting them to sign up for the beta.

The potential of Kera is that it can allow a visitor to engage with the tutorial. For example, we could create Kera tutorials for each GoSoapBox feature … a brief discussion of polling and then inviting the teacher to create their first poll without having to switch between a help page and our product.

For the time being, though, Kera is in a limited beta and not available for widespread consumption. Definitely something to keep an eye on.

Tutorialize.me

Tutorialize is a bit more simplistic, but also provides an interactive approach to a product tutorial. After clicking “See an example”, a little yellow box appears on the screen. Clicking ‘Next” within that box opens another dialog elsewhere on the page, and the screen scrolls to that location.

This could be very useful for introducing a complex user interface.

Pulse App (iOS)

Pulse is a RSS feed reader for iOS devices. The screenshot above is for Pulse’s iPad version. The first time you load the app, a semi-transparent screen appears above the normal display with instructions and arrows. They point to a few important tools and use the rest of the space to set expectations for use. “This is how you’ll use Pulse”.

Successfully setting expectations is the greatest outcome of a product tutorial. When you transfer your product’s conceptual model to a user, they will understand how to fit it within their existing workflows, leading to much greater retention than if they’re not sure what you’re about.

Conclusion

In this article, I have highlighted several approaches to hands-off onboarding. While not perfect, they are interesting alternatives to status-quo knowledge bases and videos.

When a website has some primary desired action, UXers will recommend that the action be strongly emphasized. There’s no need to be shy about it, especially if it’s what a user wants to do anyway.

However, there are usually supporting actions that still lead to the desired behavior and perhaps even reinforce the value in doing so. For example, a tour page can be very useful for explaining a product in greater detail and ensuring that visitors take the next step. Some folks have found that inserting a tour page into their signup funnel will increase overall conversion numbers.  Others have tried inserting the primary action form (like a free trial signup) directly into the landing page.

The Challenge for UXers

For UXers, the challenge is finding the right balance. Every business lives within its own context. Sometimes we need to be pushy to get things done, other times we need to back off and create a gentle slope. There is no universal answer.

At GoSoapBox, we have been struggling with how to position our product tour and free trial signup.Presently we have a funnel that looks like this:

[Landing Page] => [Product Tour] => [Sign Up]

This conscious choice is intended to get prospective educators excited and education about our product such that when they sign up they already have a decent concept of how to use it, leading to improved rates of activation and retention. At least, that’s the theory.

While we want to give visitors a roadmap to getting started, there is a nagging feeling that we lose some folks who get to the product tour and miss our trial signup links.

So what’s the answer for our context? We can start by re-examining the placement of secondary actions.

Perhaps we could so something like Wufoo.

Not bad. A primary “Sign Up” action, followed by supporting actions with acceptable contrast from the desired behavior.

For years, most websites have followed this model. But it has never felt quite right, because the placement of the secondary actions compete for attention with the primary action.

Small tech startups, more recently, have led the charge in dropping secondary calls to action entirely from this space, and increasing the size of the primary action several fold.

But what about the secondary actions? Is there really no room for those in the same same space as a primary call to action? Are secondary actions doomed to live a life in the de-emphasized void of our websites?

Conjoined Calls to Action

Today, there are a few examples of a new style of call to action which I have labeled conjoined calls to action.

Conjoined calls to action have the following attributes:

• Occupy a single visual unit to keep the page from looking cluttered.
• Place the primary action on the left.
• Use effective contrast between actions so that visitors are aware of the difference.

The examples included above also use the text “or” to distinguish between the actions. Stylistically, the “or” improves contrast, but psychologically it also helps because it creates a simple decision tree in a visitor’s head.

“Okay, I can do this one thing which seems to be what I ought to do, or if I’m still not sure what this is I can learn more.”

So what’s keeping conjoined calls to action from proliferating on the web?

First, someone needs to write a blog article about them (we can check that off now). Second, someone needs to objectively test them and show how they improve conversions on a website. And third, Bootstrap and jQuery need to make it easy to implement conjoined calls to action. When these steps are complete, there will be an explosion in conjoined calls to action adoption.

Last year, I wrote and spoke about the necessity of context when making mobile design decisions. However, context is almost always opaque, and it is impractical for an organization to select a diverse set of development strategies. With these constraints in mind, I reasoned that responsive design would play a major role in the future.

Well, the future got here a lot faster than I imagined. An ethos is taking shape, and it looks something like this:

Responsive design will become the default web development pattern. Content-first and mobile-first mindsets will be the primary drivers of great websites and web apps. Device-specific and channel-specific apps will only be necessary when context demands them.

In other words, we’re going to have content-oriented design optimized for mobile viewports, and we will use adaptive techniques like media queries and Modernizr to add layers of progressive enhancement.

The only piece missing is inclusive design, which always looks great on paper but never seems to make the cut as a core value. That’s a shame, but at least some libraries (like jQuery Mobile) are trying to make basic accessibility compliance built-in.

Distribution Channels are an Obstacle

Native platform marketplaces are the only significant obstacle blocking the new ethos. These marketplaces serve as major distribution channels, and only native apps are allowed to play. Considering that Apple and Android take a 30% cut on sales, there’s little incentive to open their marketplaces to the outside.

Therefore, the Friendly Web ethos will be derailed if content creators cannot establish traction without going through an app marketplace.

Let’s assume that doesn’t end up being a problem. What’s going to happen to all those mobile sites already out there?

Mobile sites that only exist for viewport-optimization will fade away because responsive design and a mobile-first mindset make separate versions obsolete. But some mobile sites are different, offering focused functionality specific to the needs of an audience subset. What should we do with these?

Well, when a mobile site is not meant to be the viewport-optimized equivalent of a traditional site, context may demand that it continues on as a separately-branded service. Most mobile sites in higher ed are like this. Whereas the traditional homepage serves up an external focus, the mobile homepage provides easy access to resources for internal audiences like students and staff. As long as there’s a need for an internal-focused service, there’s nothing wrong with it existing independent of the university’s responsive homepage. The same will be true elsewhere.

Upheaval

There’s going to be some upheaval in the mobile space as organizations change tack. I’m sure that red-faced executives are going to angrily ask why they have to invest even more money into mobile when they just launched something a few months ago. Or maybe they’re still on the mobile crusade and will wonder who pulled the rug out from underneath. Regardless, a lot of people are going to be annoyed before they realize that they just need to accept it and move on.

Are we done with this for a while? Maybe. There’s still mobile emerging as a mass media, and the forthcoming one-to-many zombie apocalypse. But if you want to roll out a responsive website and take an extended break, you probably won’t miss much.