Back in the days when smartphones began to dominate the market, customers started to access information on-the-go — emails, weather, news, sports etc. Many companies — including Walgreens –realized the need to address the specific requirements of the mobile user and typically introduced a mobile version of their primary website. Either it was a completely different mobile website or a transcoded version of the desktop website.

Those choosing to create a different site ended up designing, coding and managing two different websites, which meant increased cost and maintenance. Those organizations that opted for a transcoded version of the desktop website — as  did Walgreens — ended up with reduced functionality, less content, and a less enjoyable user experience.

syed1

Adopt mobile-first strategy

In the past, Walgreens focused on the needs of desktop users, so functionality and capabilities were designed with the desktop experience in mind. This far exceeded the capabilities of the mobile device with its limited bandwidth, processing power and screen size. The Walgreens Digital Engineering and Mobile Solutions team, for which I am the senior technical architect, had to shift gears and change our focus and mindset to a “mobile-first” strategy. This is when our team turned towards Adaptive and Responsive web design.

Responsive web design is a technique that allows the website to adapt to the screen size of the device on which it is viewed on. The site will notice the constraints of the device and automatically reformat the page to provide the user an experience that is best fit for that screen—be it a desktop, tablet or smartphone.

We took this design a step further where we not only used Twitter Bootstrap, CSS3 and HTML5 to enable a responsive web design, we also introduced AngularJS within our architecture to enable us to bind the HTML content with the data which was now exposed through REST API services. For more details on the architecture, please watch this webinar.

This resulted in a consistent and optimal user experience across pages and breakpoints – desktop, tablet and mobile.

syed2

Transformation

Re-architecting a huge web application like walgreens.com is not without challenges and required transformation across the whole digital division, from Product to Dev to QA to Ops, particularly on the monitoring aspect.

Due to the heavy client-side architecture, we had to make sure that we had full visibility from front end to back end. Predominantly, we have always monitored our backend thru APM solutions but we now had to monitor the front end as well.

This is where we picked Dynatrace UEM as it addressed some of our main challenges and concerns like front end visibility, being able to search for a single visit and drill down to find the pain points, support for AngularJS, powerful charting capabilities to slice and dice the data across multiple breakpoint, browsers, geographic location, bandwidth and more.

Single visit search and User Experience Index are two of my most favorite capabilities. The ability to drill down and pin point an issue and the ability to understand the user experience not just on the bases of page load but factor in errors, exception, bandwidth and user’s ability to complete an action is priceless.

Single user search
Single user search
User Experience Index
User Experience Index

Mobile lessons learned

When monitoring the client side, one should be aware of the capabilities and architecture of specific browsers. We learned that IE browsers, especially the older version, couldn’t handle the extra instrumentation of the DOM on top of what AngularJS was already doing. To resolve the issue we had to cut down on the instrumentation, particularly for IE browsers.

We also found that managing the browser cache became a lot more difficult with the new architecture, and ran into issues with “cache poisoning”. Due to the AngularJS framework, much client side binding code will be written in JavaScript files. From a performance stand point we want to cache these JS files on the client side so that the browser doesn’t have to download them every time the page is requested. But from a release integrity standpoint, we need to make sure the browser is not loading an outdated version of the JS file. This is one of the ways cache poisoning could occur.

Assets versioning is a solution to address this problem. During build/deployment time, JS code should be checked for changes. If there are changes, then a random/auto-generated number is appended to the file name, giving it a new file name which will be different than the previous deployed version. This forces the browser to download the new file rather than referring to the old file in the cache.

Refer to this link for more info on assets versioning and how to implement: http://www.theasta.net/talks/2013-05-22/#/