Concierge UX : Part 1 of 3

Holiday User Experience

During the holidays a good service experience goes a long way. People tend to get visibly agitated and stressed out for the smallest things during these few months. Retail and Service establishments put so much pressure on employees in regards to sales and expected work hours. It can be overwhelming for many employees and for the guests that shop at their brick & mortar establishments. It is inevitable considering the amount of revenue companies typically need to acquire within that short time. Application developers in sales-focused industries feel this pressure in a different way. They don’t have that face-to-face engagement but they get the pressures of last minute features, production server issues, traffic surges, minimizing downtime, and getting quicker checkout experience with less drop off in the early cart entry to name a few.

Most notably good user experience tends to suffer. Research & Development (R&D) rarely hears about the good experiences. Typically it is the uncensored ravenous rantings of dissatisfaction that rolls down to R&D. The face-to-face experience is lost with a mobile or web application. For online reviewing, sales, and support people are not afraid to speak their minds and in some cases be cruel & abrasive. The people who built the application are out of mind and out of sight to the shopper. Reviews and dissatisfied comments are what usually rolls down to the product engineering team. Many are in the realm of  ‘I-will-never-come back-here-again’ threats accompanied with ‘I-will-spread-the-word-of-my-hatred-to-all-I-come-across-forever’.  This vengeful holiday spirit is exponentially true in the large and mid-size companies and their public facing service and e-commerce applications. It is the responsibility of everyone on a product team to make the experience of these applications the best in class. This is especially true for both the User Experience group &  the engineering group since they are usually responsible for defining and implementing the design and vision of the product.

Concierge Service

I think of this holiday pressure often and find myself very critical of my shopping and support experiences. When I think about the best support experiences I’ve had recently I think of the brick & mortar Apple Store Genius Bar.  The reason this sticks out to me is not because I am a Apple fanatic but because it is a personal and concierge experience. I always feel like I have been personally taken care of when I leave the Genius Bar no matter how long I’ve had to wait. The main reason for that is the engaging personal interaction and the rapport. Geniuses, Apple store concierges, establish trust and personal loyalty early on in their engagements. The Geniuses at Apple are trained masters of customer service practices but they also have a very high level of social engineering skills in a ‘White Hat’ sort of way. Other companies seem to be adopting this ‘concierge model’ and making it their own such as the Microsoft brick & mortar stores. It’s a very effective means of gaining customer satisfaction. Wouldn’t it be great to have this experience without ever leaving the comfort of your own home? Let’s take a look at the current Genius experience online. How does the Genius Bar experience scale and translate to a digital format?

A Digital Translation

The IPhone Apple Store App was the first place I viewed the Genius Bar experience in a digital format. One observation I made was that the app does not have a high level navigation element pointing to a Genius contact or even a information page for that matter. In fact, by means of browsing, one needs to first use the store locator, then touch the Genius section to make an appointment and a series of sub pages follow to make an appointment locally at a store. A search in the app yields no indication of where the a Genius type section exists or how you would have that concierge experience online. This IPhone Apple Store App experience left me wondering what the online desktop web application experience would be. My first instinct was to go to Apple’s website and look for Genius information there. I would think that the home page would showcase the Genius bar Experience at some level. The home page had nothing mentioned about the Genius services at all. At the top level navigation, I clicked the link to the main support page for Apple hoping for some better information. Still nothing on the Genius bar. At this point I decided perform a global search using the search box in the top navigation using the key words  ‘Genius Bar’.  The first result is a Genius bar logo accompanied with descriptive text and a link to make an appointment with a retail store. After I click on the link and run through a series of screens I ultimately get online help  in the form of a chat with an online support person about customer service options for Apple. This digital experience is a very different and disconnecting experience in contrast to the physical brick & mortar one I am used to. A few things struck me as odd with this experience.

My 13 Step Journey

User Flow for Genius Bar

Figure A : My 13 Step User Flow to get to a Live Chat with Support on the Apple Website Apple

Exploring this diagram we can see that it took me quite a few steps to get to a real person. Even when I did get a customer support technician, it was a chat (only a two minute wait on Black Friday though). My point is that the experience is not one of warmth and personal touch as you get in the Apple Store. Don’t get me wrong, the technician I chatted with was very attentive, professional, and polite. I know from experience that these are usually well trained customer service people working in a data center somewhere with a script of things to write, and how to word them. This is not a bad thing per se but not the experience I would have expected based on my concierge service at the Reston, Virginia store Genius Bar.

The next part my journey led me to think about the personas that visit the Genius Bar and how they might utilize a digital experience of similar value. I will post my observations in the next few days.

The Persecution of JavaScript

JavaScript’s history is a colored one of misuse and misunderstanding. It has evolved into a platform that, as of today, is arguably the most approachable, portable, and versatile programming language available. A former colleague of mine recently showed me an article claiming 10 reasons why you should not use JavaScript. JavaScript, like every language, has its strengths and weaknesses, but what is interesting about the article shared with me is the naivety behind it. Comparing JavaScript to languages like Ruby, Go, and Java is like comparing a hammer to a power drill. Each tool is very useful but each is better suited to solve certain types of problems. Developers have learned from their own experiences how to approach certain problems with their language of choice. What we forget sometimes is that we must not assume another language approaches this same problem with the same tools, patterns, or paradigms. That said, let’s look at some claims from the article in question.

The Assumptions

JavaScript hurts your mobile visitors

I am assuming this refers to performance and usability based on a comparison of HTML5 web applications to native applications. When running web applications on mobile devices they are restricted by a few factors.The rendering pipeline limitations of the device, the speed of DOM interactions and degree of GPU acceleration all contribute to performance. JavaScript, like many languages, can always be optimized for mobile performance but is by no means even close to being a major performance problem. I can agree that less lines of code per request helps to “lighten the load” but to say the Phone Gap article bashing JQuery Mobile is referring to all JavaScript is just not true. In fact, as the article title suggests, the post specifically refers to JQuery Mobile.

Many projects optimize web applications for progressive enhancement. One example is SouthStreet By Filament Group. They have taken several problems they see in modern web applications, especially in mobile, and have proposed solutions to these. As an example of one SouthStreet component is PictureFill . At a very high level it enables you to download smaller assets for less capable devices instead of the desktop high resolution versions through markup and JavaScript. This is a way JavaScript actually helps with progressive enhancement. Also, I recommend taking a look at Jake Archibald’s article on Progressive Enhancement. Jake explains “Progressive enhancement has never been about users who’ve turned JavaScript off, or least it wasn’t for me.”. He further details approaches to what he feels true progressive enhancement should be.

JavaScript hurts your robustness

The post talks about “a single bug in your JavaScript can break the functionality” . This is why we, as developers, use linters and testing. If you are pushing code that you haven’t tested in your application’s supported browsers then that is not the fault of JavaScript. Additionally the post argues that using JavaScript MVC frameworks couples your application and prevents testing future browser implementations of JavaScript. Projects like Chrome Canary and Firefox Aurora are extremely helpful if you want to test your code now in future implementations of the browser. This is also great because if you find a bug and submit it it will most likely be fixed by the time your users see it.  One problem I do see with developers often is that they don’t test in their application’s least powerful target browser throughout the development time. That means bugs are not found early enough in the process.  Testing early and often in at least the worst browser on the list will save so much pain in the long run. This is not a JavaScript issue.

JavaScript hurts your security (and your privacy)

We have all heard the horror stories of the evil hacker sitting in an abandoned shack somewhere in Portland hacking into our servers and sucking out our souls from across the the nine hells of the internet. Although JavaScript can be minified and obfuscated, a clever hacker will get your code if it’s there in the browser. While I agree that client side JavaScript has vulnerabilities in this area I do not agree that this should be the responsibility of the JavaScript language. Each browser allows JavaScript to access quite a bit of features. Without that authorization, many features of our applications we run in the browser would not be possible.

The fallacy in cyber security is that we are not protected because of JavaScript. It is true that a simple Google search will yield results that detail standard attack vectors using XSS and XSRF. Anyone can find step-by-step instructions and training videos on YouTube these days. Fear not, XSS and XSRF ARE preventable attacks. You can put countermeasures into your application on the backend to prevent this from hurting your users. As a general rule of thumb, don’t expose sensitive data in the browser where JavaScript has access. Server Side JavaScript has many more security options so storing sensitive data there is not an issue. Your backend, which might be JavaScript should always assume the browser can’t be trusted in these cases. On a related note – the real cyber threat is not JavaScript, SQL Injection Attacks, or even code hacks in general; It’s Human Hacking and the art of Social Engineering.

JavaScript hurts your SEO

Front End Developers seem to have a love for clean markup (I know I do). If you code your HTML semantically, separate your concerns, and use accessibility standards you can progressively enhance your page for robust functionality while maintaining SEO. Section 508 has been due for an overhaul but still yields some great practices that can optimize SEO. WAI-Aria attributes and patterns can progressively enhance your page for robust functionality while maintaining SEO standards.The big concern sited in the post was AJAX. Making your site functional without AJAX is sometimes an option but not always. This is not a JavaScript problem either as the language was not designed for SEO purposes nor claims to assist or hinder it.

JavaScript hurts your development time

Browser tools for Internet Explorer have come a long way. has a lot of testing tools for Internet Explorer. The new F12 tools are no Firebug or webkit debugger but they are getting there. Browser tools and even server side tools for Node.js like DTrace and TraceGl are extremely helpful. Using a linter and checking target browsers in the Continuous Integration and in development is extremely important. Unit testing and End To End testing for JavaScript is a necessity when building massive applications. Would you leave out testing in the backend of the application? Development time optimization comes with experience no matter what platform you are on.

JavaScript hurts your testing costs

If I understood this section correctly, “maintenance costs of testing” and relying on HTML implementations of browsers are the issues causing this ‘pain’. Testing is an quality investment, whether it is on the data layer, back end, or the front end. If you are testing the right functionality in your code and you are communicating what is being tested then testing is maintainable. This is a difficult and subjective way of thinking, especially in large teams where everyone has a different style if testing and coding. That said, testing code is a discipline and an irreplaceable tool to ensure better quality software. This is true not just for JavaScript but for all programming languages. As for setup of these frameworks you most likely need a browser matrix that you are targeting for your code so I get it that there is that dependency. Given that you are creating tools and applications with JavaScript that will run on those targets then it is no different than server side testing requiring environment and system dependencies. End-To-End testing is similar to integration testing on the server side. Whether you are writing unit tests or integration tests,  we have bad tests and good ones. JavaScript is not an exception in this case but not at the fault either.

JavaScript hurts your website performance

Nothing hurts more than watching a client scream at an application you built that loads in 6 or more seconds. Premature JavaScript performance modifications are not necessary. If you are wealthy enough ( or have a client that is) to use a tool like New Relic, you may find that the page is waiting on the server from some crazy SQL call or a service end point that’s slow. Just because the browser takes longer to load a page doesn’t mean it’s the JavaScript that is at fault. When it determined a performance issue is on the client side, it’s usually bad coding practices. Restricting the amount of DOM elements, using spriting techniques, concatenating static assets to avoid vast amounts of server call are a few major contributors to better performance on the front end. Tools like JQuery optimize this and abstract out browser specific implementations but overuse of the DOM is not recommended. This is a failing in how the DOM is implemented across browsers, not in JavaScript.

JavaScript hurts your software investment

JavaScript is almost 20 years old now. It is now a proven platform for major application across the world. Applets and Flash require a plugin and are not the same as JavaScript. JavaScript is native to the browser.You cannot compare Applets to JavaScript. “Client-side technology is doomed to fail” is very presumptuous. I am not sure why you would assume JavaScript is doomed to fail since it has been widely adopted by large companies likes Google, Microsoft, Facebook, etc. I can’t even think of a company that has not desired to build a web application without any use of JavaScript.

JavaScript hurts your software architecture

First off I love MooTools but it is a abstraction of JavaScript. Underneath MooTools is plain old vanilla JavaScript. It is a bad idea to assume that backend developers understand how JavaScript works. Respectively, it is bad to assume JavaScript programmers understand how the server-side backend works and its complexities. JavaScript is flexible enough that it can emulate many styles of development. There is not a right or wrong way to code in JavaScript, only style and tradeoffs. If you don’t understand its paradigms and approaches to coding you should research and learn it.

JavaScript is not needed

This one I actually agree with this to a degree in some cases. For accessibility and Mobile First approaches we have a choice to to approach the application MVP with a semantic HTML version that has a minimal script tag to detect capabilities and provide richer experience in richer device targets. The rich functionality we see in applications is from JavaScript (and CSS) these days. Creating GMail without JavaScript is probably a bad idea. There are still things that can only be done on the client side. JavaScript is just another tool in the toolbox and should be used to create great software.

JavaScript is not perfect and it is definitely not the end of the road for application development. It is a flexible tool akin to a swiss army knife. It is powerful, portable, and versatile. and it has many problems it can solve and many ways to do them.