While working on Gilt Mobile Web, these are our development tools of choice to get the job done:

Browsers & Emulators

Android emulator: http://developer.android.com/sdk/index.html

XCode iOS Simulator: https://developer.apple.com/devcenter/ios/index.action

Chrome Canary + mobile settings: https://www.google.com/intl/en/chrome/browser/canary.html

Page Speeds

HTTP proxy/monitor and bandwidth throttler: http://www.charlesproxy.com/

PageSpeed Insights: https://developers.google.com/speed/docs/insights/using_chrome

Device Testing

User agent strings: http://youruseragent.info/commonua.en.htm

Feature compatibility checks: http://caniuse.com/

Android debug bridge for inspecting your Android device: http://developer.android.com/tools/help/adb.html

Adobe inspect for inspecting Android Browser: http://html.adobe.com/edge/inspect/

iOS 4.2.1 to 6.1 iPods and iPhones

Android 2.1 to 4.2 phones and tablets

Usability Testing

Reflector: http://www.reflectorapp.com/

So, what tools do you use?

When you develop a front end experience for the full screen, the feedback loop between code and test is relatively fast. You code. You refresh your browser. Repeat. When you develop a front end experience for mobile devices, this can become a little cumbersome because the feedback loop can sometimes feel much slower. There are emulators for your machine and browser sizing/user-agent strategies that you can employ to make your development process more efficient. But in the end, you’re going to want to test on your devices.

In this post, I’ll explain how you can proxy your local development (localhost) to both your Android and iOS devices. When you do this, you’ll be able to code, refresh, repeat a lot faster and more efficiently.

Charles Proxy

To get started, you need a strategy to manage your HTTP proxy. I use and recommend using Charles Proxy (http://www.charlesproxy.com/) but there are certainly other alternatives. Charles Proxy is very powerful but I won’t be going into much detail about it here. Instead, we want to set up a port that we can HTTP proxy to.

If you click on PROXY, then PROXY SETTINGS, you’ll see a menu where you can enter in a port that you would like to proxy to. I’ve chosen 8888.

Charles Proxy is going to look for incoming connections on this port. When you connect iOS or Android to this port, you will see that Charles Proxy will ask you to allow or deny this connection attempt:

Now, let’s connect our devices.

iOS

In iOS, navigate to your WiFi menu and then tap into your connected WiFi. At the bottom of this screen, tap on MANUAL under HTTP Proxy. Where you see computer_ip_address_here, enter your computer’s ip address and where you see 8888, enter the port that you set up on Charles Proxy.

That’s about it. On your device, open localhost:1234 or whatever in a browser and then Charles Proxy will ask you to allow or deny. You can now start coding on your machine and refreshing on your iOS device. You’re done.

Android

On Android, tap SETTINGS and then Wi-Fi. Next, tap and hold on the WiFi network that you are currently connected to. On the following menu, tap on MODIFY NETWORK CONFIG.

You next see a menu to manage your network config. Scroll to the bottom of this modal and tap on SHOW ADVANCED OPTIONS.

In the menu options that appear, you will see configuration settings similar to those found in iOS. Where you see computer_ip_address_here, enter your computer’s ip address. Where you see 8888, select the port you set up with Charles Proxy.

And, that’s about it. On your device, open localhost:1234 or whatever in a browser and then Charles Proxy will ask you to allow or deny. You can now start coding on your machine and refreshing on your iOS device. You’re done.

This hasn’t been very well documented on the internet just yet so I thought I’d share how you need to connect your Samsung S4 device to a Mac. When you connect this device to your Mac, it (most likely at the time of this writing) will not be recognized.

To have your Mac detect your Samsung S4, you have to do some magic on your device. Click on into SETTINGS and then click on ABOUT DEVICE. If you scroll to the bottom, you will see a line entitled BUILD NUMBER.

Tap on the build number 7 times. I’m not kidding.

When you are now “a developer,” you’ll see a new menu option in SETTINGS -> MORE entitled DEVELOPER OPTIONS. In this option, you need to check USB DEBUGGING.

Then when you next connect your device to your computer, you’ll see your device:

Over the last three months, we overhauled the front end (jsp, html, handlebars, less/css, javascript, zepto) for Gilt’s mobile web experience (http://m.gilt.com). The redesign was inspired by learnings acquired from our iPhone App and the design is meant to replicate a lot of those features.

Here are 10 side by side comparisons with notes inline and at the bottom. Let us know what you think!

In the previous design, there was an assumption that the Gilt shopper uses the mobile experience quickly and wants to see as many sales as possible in a short amount of space and time. But according to our iPhone App results, our users want to see larger pictures. Having two sales on the first view compared to four has resulted in increased sales, largely due to our amazing imagery.

We dropped the black background on the product details because most of our imagery adopted a white background.

A nice feature of the redesign is that the add to cart button is visible on the bottom while scrolling on the product detail page. If you are shopping on m.gilt.com and want to purchase an item, you should have the add to cart accessible at all times. But, this doesn’t always work on all devices.

We created a more streamlined view for our sign in and registration pages by simplifying the experience.

Our cart page features a similar button to what existed on the product detail page. Again, we are trying to make it as easy as possible to shop on a mobile device.

The checkout experience mimics the iPhone App experience while trying to keep a style that is more generic so that it looks great on Android as well.

While scrolling to the bottom of the checkout page, the submit order button stays fixed. In our older version, the user had to scroll to the button to checkout.

We are reusing elements in our account page that we used in the checkout flow.

Our footer introduces more spacing as well as elements that were previously found in the checkout and account flow.

We have an amazing customer service team.

Here are 5 learnings from redesigning the Gilt Mobile Web experience.

1. Visual Components: Abstract away visual components that can be reused throughout the mobile experience. For example, the buttons in the footer are also used in the account page as well as in checkout. We only need to supply text and an optional image to create one.

2. Cross-Browser Compatibility: Handle browser-specific issues like fixed-positioning on a per-device basis. The fixed “submit button” appears at the bottom of the screen on the product detail page, cart, and checkout page for modern browsers. But for early versions of Android, for example, the buttons appear inline.

3. Iterating: Gilt Mobile Web is a complete experience in that it includes everything from the sales listing page through account and checkout. When trying to roll releases out to production, we searched for places where the old and new designs could coexist for a limited period of time. With this strategy, we didn’t have to redesign everything at once.

4. Cross-Device Compatibility: We tested m.gilt.com against several android and apple devices (as well as ie6 and ie7) to make sure it looked good on many different screen sizes. In many instances, DOM element sizes are determined as a percentage of the viewable screen. But since the majority of our users are accessing us from Safari on iPhone, development starts on the iOS Simulator.

5. If it doesn’t work, roll it back: I deployed our second phase to production and immediately upon doing so realized that “sold out” hover states were not… hovering. It was something that we missed and instead of making a quick fix, we rolled it back and spent a little more time testing. We pushed to production again a few days later with bug fixes in place and confidence that the experience was stable. Sometimes, we can’t catch it all on staging environments.

Last week, Gilt Tech presented ‘MongoDB at Gilt’ at MongoDB Austin. Thank you 10Gen for hosting the event.