AIAIO: Our Blog

AIAIO: Our Blog

The pulse and reviews of Alexander Interactive

Technical debt in your bug tracker

Special thanks to Dan Pasette for his insights into how an engineering team like 10gen’s manages technical debt in their issue tracker.

If you work on software, you most likely use a bug tracker to track defects, manage development tasks, and plan releases. The collection of tickets, open and closed, is a data set that doubles as a repository of institutional memory about your software: what components have been the most complex (i.e., have spawned the most bugs)? Who worked on what, when? What issues did the developers grapple with over the course of delivering on a requirement or resolving a defect? What compromises did the team decide to make (or, worse, what were they forced to make) to hit a deadline? What’s never been fixed, left to fester in a dark corner?

You may have other documentation sources for your software: end-user docs, developer handoff docs, long and tortuous email chains, wiki pages, and inline documentation in the code base itself. But, if consistently used, a bug tracker can show the underbelly of the development process in remarkable detail. It is here where teams can probe their work history to uncover decisions and issues that we can categorize as technical debt. (Example: Open the longest-active project in your issue tracker, and find the oldest unresolved bug. Behold.)

And once we have classified bugs as technical debt, that can be its own component—a component we should consider as first-class, along with mission-critical and user-facing components. Unlike other components, which must be maintained and improved, technical debt must be managed. It is an emergent component that we should assume will always be present in a system.

This kind of emergent debt is what happens when we gain insight into the longstanding problems in a system, when we start to trace one problem back to a past decision, well-considered or otherwise. We can find the areas where we have built workarounds over the compromise and complexity we originally injected into the system.

And the status of these issues as bugs means that we have already filtered out most non-harmful technical debt (I am squarely in the “not all technical debt is bad” camp): if the team implemented a shortcut that never caused or registered as a problem, it’s not in the bug tracker to begin with.

Just as importantly, in some situations we can choose to split these bugs into actionable sub-tickets, and cast off the rest. If, for instance, an old bug has to do with a component that has architectural flaws, but which is used more and more rarely, we can choose just to address the surface problems, knowing that the underlying debt in this instance will get zeroed out when we finally sunset this component completely (this must be a real plan, of course, such as a replatforming project in the not-too-distant future). So we break out the surface problems into discrete bugs, and then we can close the hairy old bug and pat ourselves on the back.

For example: an e-commerce system has a year-old bug on the books concerning user feedback in the checkout flow. The underlying problem has to do with the poor integration of the payment gateway. You, the tech lead, are fresh from a meeting where the business owners agreed to a payment processor with a much cleaner integration. The transition is a few months away still, but all the bug-spawning cruft of the old integration is now scheduled to disappear. You can now split this bug into some constituent sub-bugs that make cosmetic changes sufficient to address the symptoms of the original bug report. You can also close out the year-old bug with references to the cosmetic bugs and the impending payment system change. Were a new payment system not in the works, this band-aid approach might seem an irresponsible way to manage the technical debt underlying the original bug; in the new reality, though, you’ve decided to acquire short-term debt that has a definite lifespan.

(Side note: this example highlights the breakdown in the strict financial debt analogy. Technical debt can, in some cases, just magically disappear. Don’t try this with your credit card.)

We can also use the bug tracker explicitly to expose and track technical debt as we take it on or discover it in a system. This is especially useful when a developer needs to surface and memorialize decisions, shortcuts, quandaries, and TODOs in order to implement a feature. Being able to enter bugs related to the development process, and to categorize them as debt and not feature bugs, allows the developer to stay focused on the implementation, while making the process more transparent and contributing to institutional memory.

I’ll explain by example. Let’s posit a developer: Cold cup of coffee perched dangerously on the edge of the desk, sitting back in an office chair, wearing overpriced headphones, perhaps sweating a bit, wrestling with the latest in a series of hairy performance problems near the end of a development cycle. The task at hand is to deal with a slow page load. In the process of tracing the execution chain, the developer runs into a run-on sentence of a method that cries out for refactoring. It’s also probable that some of this logic will be useful elsewhere, once it’s extracted from the monolithic method. It’s also clear, however, that this method is not impacting load time—for the purposes of the task at hand, it’s more of an itch to scratch.

Thanks to the GTD methodology, we know how to deal with these itches. The answer is not to lose focus on the task at hand, but rather to record the unrelated task and file it in a place where we can address it later. To do this, we need a simple filing method that allows us to categorize the new task efficiently, so that task creation is not itself a distracting activity.

Clearly, our developer needs to get this into the bug tracker. It takes thirty seconds to create a task called “Refactor Ai_Checkout_Helper::doThings().” The tech lead should provide a single, simple tag (or label, depending on your issue tracker’s terminology) for these debt-repaying tasks: shouldfix, refactor, or technicaldebt will work. The goal is to create a two-step method for recording technical debt-related bugs that developers find in the course of doing other work:

1. Enter minimal notes, including file and line reference.

2. Label as technical debt.

It would be fun to monitor activity logged against this label in the heat of a project (e.g., an RSS feed attached to the label), as you’d have an equivalent of the fantastic “WTFs per minute” quantification of technical debt.

Technology

The Power of Video as a Selling Tool

Video is a powerful tool to help retailers merchandise more effectively. The bottom line is that video, done right, boosts conversion. Let’s look at some quick data and case studies that are out there to back this up:

  • Zappos reported conversion rates from 6% to 30% higher for products featuring video product descriptions (demos).
  • Internet Retailer reports that OnlineGolf.com customers were 85% more likely to buy than customers who didn’t view video.
  • Ice.com found that customers who viewed video on their site converted 400% more than customers that did not.

These numbers are just the tip of the iceberg. Retailers all over the web are finding that video increases customer engagement, leading to increased email opens, more time on site, more viral marketing activity, and ultimately more sales.

Ways Video Aids Retailers

  • Video Promotes Engagement – Customers who watch video spend more time at your site exploring, learning more about your products, and ultimately purchasing. Comscore has reported an average 2-minute longer stay at a site for users who watch video. Users want to engage with video – one study by Implix reports a 96% higher click-through rate for video email vs. text.
  • Video Boosts SEO – Google rewards sites that produce original video, generally boosting overall site rankings. According to Forrester, videos have a 53x higher likelihood of being on the first page of Google results, versus pages. YouTube videos are almost completely indexed. Bottom line – produce video and you are much more likely to be found on Google, and ranked highly.
  • Video is Social – People love watching video, and love sharing video with their friends. Retailers that publish videos to their Facebook pages often find that the number of video likes far outstrips likes for other types of postings.

Using Video to Increase Sales

There are a number of ways retailers can use video to increase sales. Broadly, these fall into the following categories:

  • Product Merchandising – Video product descriptions can be used to call out key product features and benefits, and tout differentiators. Showing the product in use and in context is something that text and photos can’t accomplish nearly as well. Illustrating a novel product use or difficult to explain feature can make the difference in a sale. Don’t have the resources to create your own product video? Link out to YouTube, industry, or manufacturer videos that feature the product in question.
  • Category / Brand Merchandising – Videos for a category of products will tout customer benefits, lifestyle vignettes, and comparative product reviews. If a product is technical in nature, a category video can highlight and compare product features and specifications, and provide useful comparisons. Videos for a brand of products can highlight lifestyle attributes that embody the brand and that the customer will identify with. Showing contexts in which a category of products are in use can give the customer confidence that they have identified the correct solution for their needs.
  • Global Value Proposition – Have free shipping both ways? Do you provide a 110% money back guarantee? Have a trusted industry professional endorsing your company or brand? Providing a video that speaks to the values your site or brand embodies can be a good way of giving consumers confidence that they should purchase from you.
  • Video Reviews – Video reviews and other user-generated content can be a powerful and economical way to capture customer enthusiasm and criticism. They provide a trusted 3rd party perspective to other customers, who generally view these types of reviews as highly credible.
  • How To / Support – If your product has to be set up, configured, cared for, or otherwise maintained, support videos can help both you and the customer. This type of video can help you reduce customer support costs, but can also lead to increased sales as customers are more confident that there is a reputable, caring company standing behind the purchase.

Making Your Video Stand Out

To make sure the video you produce is the best it can be, keep the following tips in mind:

  • Have a Personality – dry, emotionless video is the worst. Keep it interesting, lively, fun, engaging. Or geeky, spacey, and chintzy. Just choose a direction that has some personality, and employ it consistently.
  • Keep it Brand-Consistent – decide what your brand stands for, and keep the presentation consistent. Zappos found that employees, rather than models, worked better, and customers trusted them more. Look at what your brand stands for and shoot video accordingly.
  • Make it Work – Sounds simple enough, but your video should work across channels (desktop / tablet / mobile), load quickly, and allow good controls for playback and sharing.
  • Test It – Before you decide to put out your video, put it away for a few days, then watch it. Show it to a few friends and family. Ask their opinions, ask how they would improve it. Your little gem of an idea may not be all it could be, and it’s better to realize that earlier rather than later.

On Another Note – Video Is a Killer App for T-Commerce

Tablet users are particularly susceptible to video merchandising. A survey by Forrester Research showed that watching video was one of the top daily activities of tablet users. Research shows that tablet users prefer a “lean back” browsing experience where they can watch and learn in the comfort of their living room and bedroom. Video provides an ideal delivery medium in this lean back world – users simply click once and can be fully engaged for several minutes. T-commerce initiatives should always include a nod to video as a preferred method of consuming information, as opposed to reading and parsing dense textual information.  As tablet penetration increases in the coming years, video is going to be a key strategy for all retailers.

To sum up – video works. It has been proven to be a powerful selling tool that boosts conversion rates, engages customers, and promotes viral marketing. You can start right away by looking at what competitors are doing in your space. If no one is doing video, congratulations, you have an instant competitive advantage. If your competitors are using video, time to catch up and do it better.

Ecommerce

Everyone is “the business”

For technologists who spend much of their time eyes-deep in the tools, platforms, and architectural drivers that great solutions require, it can be easy to feel isolated from the surrounding business. The business goals of the project and the financial context that surrounds and constrains it become, through the necessary processes of business analysis and project planning, several layers removed from the technology team’s internal representation of the project. Components to be built, system and application architectures, UML diagrams, task tickets, and burn down lists may be necessary constructs to run a development project, but they retain little to no understanding of the business context.

Just as the syntax of programming languages by and large lacks the ability to communicate the system architecture, the artifacts of project management and development planning lack the crucial ability to communicate the business context.

This is why the business and technology teams so often feel like separate factions, each harboring gripes about how the other lacks the context to understand the decisions that need to be made. (One beautiful and refreshing aspect of Ai’s culture is that it has the opposite character: we are pretty cozy here, despite our spacious office, and our size helps us to manage and minimize these divides.)

And here’s one big reason why “technical debt” has become a hot topic: it’s a concept that can do wonders to bridge the communication gap that often develops between technology and business teams over the course of a project.

This gap is itself a project risk, and as with all risks, we need to find the right tools to understand and mitigate it. Thus the (justified) popularity of “technical debt”.

But just as “technical debt” is a useful term for mitigating this risk, other terms can broaden or enforce the border around an IT team. One, a term more pervasive in larger organizations, is “the business”. This is how IT project managers often refer to that shadowy side of the organization that issues commands from its isolated realm, dictates that the IT group must translate into actions and project plans.

“The business” will place constraints of budget, schedule, platform on the project. (All too often, these get delivered to us via another unfortunate neologism: “the ask”. “Ask” is a verb. It just is. It’s a verb. When someone drops “the ask” on the meeting table, they’re presenting a hard object with no creator: “the ask” has arrived, ineluctable and undebatable.)

“The business” will make midstream decisions seemingly ignorant of implications to the project’s technological commitments. “The business” also, of course, writes the checks, so we feel we have no absolute leverage.

It is in dealing with these constraints from “the business” that we regularly incur technical debt: to meet a deadline, or to facilitate a sudden change in requirements, we commit to compromises in the code or architecture that we know we’ll need to fix someday. (“Someday”: as with financial debt, technical debt is a tool at your disposal; but you have to fix a date to this payment to keep your debt from ballooning.)

The key lesson here is that we can’t conceive of these decisions as technology decisions. As Steve McConnell notes, “At the end of the day, all [technical] decisions made in this context are business decisions.” The business and technology teams are partners in the success of a project. Business decisions must take technology into account, and vice versa.

We can take it a step further, in fact: there is no “the business”. Each one of us is The Business.

Considering ourselves, the technologists, to be The Business means internalizing that each line of code we write, each component we build, each compromise we make affects the business context of the project, and ultimately the success of the wider organization. What’s the business value of documenting this code? What’s the business value of building this test script? There’s no reason why QA engineers and developers should labor in the absence of this notion of business value. Knowing the business context helps us make intelligent decisions, spend our time and energy wisely to focus on value, not problems or minutiae.

If we erase this construct of a separate “business”, we give the project a huge leg up: now, project direction needs to include business and technological context. Now, we are forced to have cross-disciplinary conversation around difficult decisions. Now, when a high-value and very difficult requirement becomes an architectural driver for the technology team, we can understand and plan around this big hurdle in the context of its overall importance.

The interest in recent years in managing technical debt is just this: an increasing interest in fostering common understanding around difficult technical decisions, and in providing institutional memory of debt incurred so that the organization can agree, and remember, to pay down that debt in the future.

Business

Adding more security to your Pound and Varnish configuration

I recently needed a way to add SSL to varnish and decided to give Pound a try. There are some great howtos available on the web, but there is one thing I don’t like about the suggested configurations. The general suggestion is to add this to your pound config

HeadRemove "X-Forwarded-Proto"
AddHeader "X-Forwarded-Proto: https"

and then to check for that header in your application, varnish, or whereever you need to check for SSL. However, by manually sending an “X-Forwarded-Proto: https” header directly to varnish on port 80, you can trick your backend application into thinking you are requesting information over HTTPS when you aren’t. While I don’t think this is exploitable by itself, I certainly don’t want to leave any room for hacker mischief.

My suggestion is to add one additional secret header in your pound config, and then sanitize the headers in varnish if that secret header is missing. For example, in my pound config, I added this:

HeadRemove "X-Forwarded-Proto"
HeadRemove "X-Pound"
AddHeader "X-Forwarded-Proto: https"
AddHeader "X-Pound: PUTARANDOMSTRINGHERE"

And in my varnish vcl_recv:

if (req.http.X-Pound == "PUTARANDOMSTRINGHERE" && req.http.X-Forwarded-Proto == "https") {
    unset req.http.X-Pound;
    #take any extra needed actions for SSL here
} else {
    unset req.http.X-Pound;
    unset req.http.X-Forwarded-Proto;
}

Now when I check for the X-Forwarded-Proto header in my application, I can be sure that the client really is making the request over HTTPS. Notice that I always remove the X-Pound header after I’ve checked for it, even if it is valid. There is no need for the application to ever see that header – no need to risk any potential leakage of my secret header, which could potentially happen if a debug setting is ever left on in the application.

Technology

What’s Next for Ecommerce?

Michael Zeisser of Libery Media delivered an engaging presentation at the 2012 Shop.org conference on the history of the Internet.  He outlined five primary phases of the industry in a concise and informative manner.  His offer that each phase or shift has generally lasted about 3 to 5 years was presented thoughtfully and supported by data.  If the theory is to be believed, we are soon approaching the next fundamental shift.

Briefly, Zeisser’s history lesson follows shifts from the days of the dial-up ISPs to the mobile device expansion of today:

  1. ISP as Content – AOL, Prodigy, Compuserve
  2. Web Portals – Yahoo, Lycos
  3. Search – Google
  4. User Generated – Social, Facebook, Twitter
  5. Mobile – apps, mobile web, we walk around with the Internet in our pockets

Ziesser stopped short of offering a prediction or opinion on what might be the next phase of the industry, but postulated that it is imminently upon us.  My focus is on how the next shift in the industry will impact (or in many cases be directly impact by) the world of digital commerce.  I am similarly avoiding predictions, but have contemplated those technologies that are certain to be at the center of it all.

So what will the next fundamental shift in ecommerce be?

Big Data

Beyond the hype and buzzword, when we finally get around to analyzing and making use of the petabytes of data that we as online merchants collect on our shoppers the experience of finding products will forever be changed.  This concept goes way beyond “you may also like” recommendations.  The data exists and the statistical techniques are already invented that can quite accurately predict exactly what I’m looking for based on a number of things that a website knows about me: my location, the keywords I typed at a search engine, my past shopping history, the time of the day.  Now we have to fully deploy this knowledge in the form of a consumer experience that “just knows.”  It’s a weeknight at 9pm in the summer, I’m likely watching the Yankee game on TV, surfing Amazon on my iPad, and just saw a commercial for a product.  The site should just know.  Play the odds and guess what i’m doing based on everything it knows about me.  It will take a few years to hone the algorithms, but I fully expect we’ll get there.  Scary.

Voice

Checking sports scores on Siri is just the beginning.  Combine Big Data with a semantically aware assistant who really understands what you want and the concept of browsing a website and clicking or smudging around will forever change.  As craftsmen of the visual user experience for online retail, the notion that our beautiful and highly-converting designs may one day join the annals of Internet phases past is terrifying.  But I believe it’s true.  And designing ecommerce experiences around voice will the next frontier.

Alex: Siri, my wife said we need diapers.

Siri: You probably mean the Size 3 Swaddlers for Nina.  Lesters.com can have them to you tomorrow for $20.  Shall I order them?

Alex: Yes, and have them send a gift for my wife.

Siri: They recommend this bracelet to go along with the earrings you bought her last year for your anniversary.  Shall I add them to the order?

Alex: Yes, thanks.

Siri: Forever in your service, Alex.

Same-Day Delivery

The retail industry continues to evolve to one of on-demand fulfillment.  The majority of American populace will soon live close enough to a major distribution center (DC) capable of trucking an item to your front door the same day you order it.  Amazon’s finally getting around to deploying the shiny robots they bought when they acquired Kiva, and it’s estimated that robot automation will increase the items a single warehouse picker can gather from 160 an hour to 600 an hour.  If free 2-day shipping is the norm for 2012, will consumers expect free 2-hour shipping by 2014?  (I know many CFOs that sure hope not.)

3D Printing

For less than $3,000 you can now buy a high quality 3D printer capable of creating intricate products out of plastic.  More materials, larger sizes, and decreasing prices are coming soon.  Forget same-day delivery–you want that new case for your iWhatever?  Order it (by voice) from Apple.com and it will spit out of your 3D printer.  Marketplaces of interested designers have already started to grow and it’s just a matter of time before major consumer brands get into this space.

These are but 4 areas–Data, Voice, Delivery, and Printing–that are sure to play a major role in the future of ecommerce.  Admittedly, it’s awfully shortsighted to not consider the impact of global ecommerce growth on the next fundamental Internet shift.  China should overtake the US online retail market by 2013 or 2014.  And what’s to keep the Chinese manufacturers of most of the products we buy from building their own DCs all over the US and Europe and selling direct to consumers?  (Answer: nothing, they’re going to do it and cut out the American/European middleman some day.)

Wherever it happens, I endorse Zeisser’s model and there’s no question that we’re sitting on the precipice of the next fundamental shift in our industry.

Ecommerce

Redefining the Post-Mortem Meeting

Thinking back to my first time seeing the meeting subject title ‘Post Mortem for (insert project name that went horribly awry)’ pop up in my Inbox …I remember hitting ‘Accept’ somewhat reluctantly. My mind quickly concocted a visual of a mock funeral for said project, the people there didn’t really like the project, but they attended anyway…out of respect. Afterward they talked about a few good qualities, but mostly complained about it before going back to business as usual.

Yes, a little strange maybe, but that odd visual story in my head proved to be accurate for most Post-Mortem meetings attended in the years that followed. Different agencies, different projects, but they all usually played out in the same way. Typically, one of these meetings would be scheduled only after a project that was riddled with issues, blown budgets & missed deadlines. As for projects that went tremendously well? No need for a Post-Mortem, we’re awesome, go team!

Changing the Perception

Unfortunately, these after-the-fact meetings usually have a negative connotation attached to them. People attend with their backs up, ready to defend their role on the project, air grievances, and place blame elsewhere. Luckily, it doesn’t have to be this way. When it comes down to it, team members want the projects they take part in to be successful. Changing the perception of how a Post-Mortem is perceived is crucial to future success on projects with that specific client, and your company’s process as a whole. Enacting this change is done by focusing on the holistic view of how your company evolves its process over time, not just what they should have done in hindsight on that one project.

Below are the tenants that should always be top of mind for anyone planning on conducting a Post-Mortem successfully. If you stay true to these items, your team will start to view these meetings as a beneficial aspect of the project and you will see the improvements in future endeavors.

1) Keep the meeting structure simple

There are quite a few meeting outlines that exist out there, but they all really break down into five main components. At Ai, the following structure for Post-Mortem meetings has proven very successful.

• What has been working?
• What has not been working?
• What was painful but necessary?
• What did you learn about working with this particular client?
• Any recommendations that we should implement into future processes?

This breakdown requires the team to begin with positive aspects of the project, and end with forward-thinking process improvement ideas to help set an optimistic tone and shift the perception away from the negative. It’s tempting to gloss over everything but that pesky second bullet, but it is so important to make sure all aspects – good and bad – are discussed.

2) Ensure the attendees are prepared ahead of time

By nature, Project & Account Managers are organized. Keeping the client happy, the projects successful, and the team working efficiently is par for the course. This includes getting your Post-Mortem meeting outline in order. But these goals are not always the main focus of the team members executing the deliverables. They are focused on their daily tasks at hand, whether it involves getting a Strategy Recommendation out the door, or the third revision of creative done in time to hand off to Technology. Basically, people are busy and this could fall low on their list of things to get done.

To sidestep any probable delay in receiving feedback, send out a list of questions to the staff at least one week before the meeting. Put a reminder on their calendar, asking them to send responses by a specific date. This forces team members to really think about the answers. If you ask people to physically type out their feedback, you will find the content will be more pointed & specific. People will instinctively recognize in their bulleted list what is legitimate, and what is just whiny.

3) Time It!

The recommended time for a Post-Mortem is no longer than 1.5 hours. Sometimes this can be difficult, especially if there are too many missteps to count. The organizer can sidestep this by identifying overlapping problem areas received in the initial feedback and integrating them into one focus point. Each bullet point has a specified time allotted and, once you reach the maximum time for that item, assess whether it is necessary to schedule a follow-up meeting.

4) Introduce the Mini-Mortem

A few months ago, a PM was trying to see what she could do to correct a list of growing issues on a hectic project…then a light bulb went off. Why wait until after a project has come to an end to course correct issues and highlight achievements? By placing a ‘Mini-Mortem’ at the halfway point of the project, the team as a whole was able to identify problem areas and pain points before the project is over. By providing them a means to voice these concerns and call out things they feel are working well, it allows the Account Managers ample time to refocus efforts where needed. Again, it’s important not to ignore the positive aspects, this is a great time to leverage what has been working well and build upon it.

5) Apply Lessons Learned To the Next Project

When Post-Mortem meetings occur after a project, often times whatever learnings are captured tend to be quickly forgotten. The information shared between coworkers during these meetings is on some level remembered, and corrections of previous issues happen organically, but this isn’t enough. At some point people will roll off and new members will transition onto a piece of client business. If tangible steps aren’t taken to capture the valuable information shared during a Post-Mortem, the ever important ‘Next Steps’ will never be implemented. When mistakes aren’t corrected, these meetings tend to be viewed as a time-suck. Why bother meeting if management isn’t going to fix it the next time around?

When a new piece of work gets underway, make sure there is time allotted to review the previous Post-Mortem notes along with the Next Steps from that meeting. Below is an example of one item that showed up on the whiteboard of a Post-Mortem, and it’s Next Step:

Issue:
“ Having multiple work-in-progress meetings scheduled with the client each week was great in that we got buy in on our ideas throughout the process, but towards the end of the project we needed less meetings and more time to focus.”

Next Step:
PM to check in with the creative team each Monday, at this time we will assess what WIP’s are needed that week. We will also shift the 9:00am scheduled time to 5:30pm to allow creative to be ready.

A Happier Team

By implementing the steps above, you will begin to shift the overall attitude around how the Post-Mortem meeting is perceived by your coworkers. So start changing the perception, assign next steps and hold the team accountable. Next time a new piece of work rolls around, reserve a slot of time to refer back to the items that came up in the last Post-Mortem. Make sure to highlight the good and bad, although correcting mistakes is crucial…touching upon what the team excelled at will boost morale and remind everyone that ‘it wasn’t all bad’.

And lastly…can we please change the name of this meeting?

Business

Stop & Stor Goes Mobile!

Earlier this summer and on the tails of a full-site redesign, Ai Emerge launched a mobile site for Stop & Stor.

After the launch of the full-site redesign, mobile accounted for 25% of site traffic and was trending up. This was the perfect opportunity to mobilize!

The new mobile engagement included discovery, user experience, design, and development work. The discovery and user experience phase was crucial in providing a strong baseline to begin the project. Our strategy was to look at the quantitative data to help drive our recommendation, but to also get in mindset of the end-user: busy people searching for storage in a big city. In doing so, we were able to identify the most useful features to include in the mobile site. These features included simple and straightforward search options, easy ways to contact locations, and pay bills on the go.

In the design phase, we aimed to uphold the brand identity while effectively translating it to a mobile platform. We optimized graphics to target not just the iPhone but other popular mobile devices like the Android, as well as tablet. We designed graphics to load quickly and degrade gracefully on older devices.

During the development phase, we leveraged and optimized the existing CMS so the business had a streamlined process to make site updates across both full-site and mobile platforms. This helped to minimize overhead for updating content. We also ensured that the interface behaved just as efficiently for the end-user. We implemented mobile best practices such as using advanced device detection so the site would load properly on any device, while including the option for the user to toggle their interactive experience from desktop to mobile.  In addition, we used mobile-specific fields, forms and interactions to enhance accessibility and usability across devices.

Since the site launched in July 2012, mobile traffic has already improved! Time spent on the site along with usage of the reservation system has increased resulting in a -21% change in bounce rates, a 13% increase in average visit duration, and a 93% increase in utilization of the online reservation system.  Because of the improved mobile user experience, increased usage of site functions and time spent has shown that users are much more engaged than before.

We are so excited about this result and look forward to continuing our partnership with Stop & Stor.

Ai

Getting a “Head” on Selenium headless testing

A headless Selenium testing system is an ideal addition to any development workflow. Selenium reduces testing time, and integrates into CI tools such as Jenkins. The benefits are great, but only *if* you can get your tests to run. One of the most time consuming problems that can arise from a headless system is a failed test. How can you debug, when you can’t see the browser? Ideally, you will test your scripts locally before running them on the headless system, but anyone who has even dabbled in the world of automation knows that a single procedure can yield very different results on different systems and in different environments. You can deal with the differences, but first you have to see them.  After much searching, I could not find a straight answer as to how to export this display to my Windows machine from our Linux server. It is really quite simple, and can be done in a few steps.  In order to display a headless Selenium test on a Windows machine from a Linux server, you must first be able to have an X window (X11) server running on your Windows machine. This is the underlying window display environment common to Unix systems. I used Xming, as it is the easiest to use and involves almost no setup.

You can download Xming from here.

When the installer finishes, run the Xming server. This doesn’t do anything that you can see, but starts the X11 environment on top of Windows.  Now you need PuTTY, the SSH client.

You can download PuTTY here.

Now that you have installed PuTTY, run the executable. In the left hand category listing for the settings, click on the X11 tab and enable X11 forwarding.

Type in the host name or IP of the remote machine and connect. Type “firefox” in the command line of your PuTTY shell (this assumes you have Firefox on your system).  This should pop the Firefox browser!  Now that you can get the remote Firefox instance to show on your Windows machine, you can run Selenium through PuTTY and debug on the fly with the command:

java -jar (PATH-TO)/selenium-server.jar -trustAllSSLCertificates \
        -htmlSuite BROWSER URL  (PATH-TO)/SUITE  (PATH-TO)/LOG
Gadgets

Generating an InlineAdmin Form on the fly in Django

I’m adding drag/drop uploading to the django admin for one of our open source projects called Stager. A blog post about that will follow, it’s not screen-shot ready yet. While doing this I knew we needed a pretty seamless transition after the upload finished, and that we would have to refresh the inline. I didn’t want a full page refresh, so let’s ajax it in.

For these examples just assume that we have a parent CompAdmin which has an model of Comp and an inline called CompSlideInline. We store the instance of the Comp in comp.

from django.template import loader, Context
from django.contrib.admin import helpers
from django.db import transaction
from django.contrib import admin

comp = Comp.objects.get(id=comp_id)
#get the current site
admin_site = admin.site
compAdmin = CompAdmin(Comp, admin_site)

#get all possible inlines for the parent Admin
inline_instances = compAdmin.get_inline_instances(request)
prefixes = {}

for FormSet, inline in zip(compAdmin.get_formsets(request, comp), inline_instances):
    #get the inline of interest and generate it's formset
    if isinstance(inline, CompSlideInline):
        prefix = FormSet.get_default_prefix()
        prefixes[prefix] = prefixes.get(prefix, 0) + 1
        if prefixes[prefix] != 1 or not prefix:
            prefix = "%s-%s" % (prefix, prefixes[prefix])
        formset = FormSet(instance=comp, prefix=prefix, queryset=inline.queryset(request))

#get possible fieldsets, readonly, and prepopulated information for the parent Admin
fieldsets = list(inline.get_fieldsets(request, comp))
readonly = list(inline.get_readonly_fields(request, comp))
prepopulated = dict(inline.get_prepopulated_fields(request, comp))

#generate the inline formset
inline_admin_formset = helpers.InlineAdminFormSet(inline, formset,
            fieldsets, prepopulated, readonly, model_admin=compAdmin)

#render the template
t = loader.get_template('admin/staging/edit_inline/_comp_slide_drag_upload_ajax.html')
c = Context({ 'inline_admin_formset': inline_admin_formset })
rendered = t.render(c)
Technology

Lock your own processes in Magento

Inevitably, when you get into the weeds with a Magento build, you’ll need to run some big, hairy process — perhaps even on a regular basis. Perhaps it involves processing images, or updating data, or creating reports. Perhaps it runs on cron, but you’d also like to run it from the command line. And if it’s destructive — i.e., it alters data — you definitely want to make sure you’re only running one at a time.

Magento has a nice semaphore locking process handler built in to its indexers. In order for a reindexing process to run, the process needs to obtain a lock. The code lives in the Mage_Index_Model_Process class, and has helpful methods such as isLocked(), lockAndBlock(), and unlock(). These look for and manipulate files in your application’s var/locks directory.

The implementation is a tried and true locking mechanism that you could write yourself, but why bloat an already massive code base? We can just repurpose this relatively self-contained functionality whenever we need to lock a process.

Technology