Finally! No more tedious zooming, pinching, squinting or scrolling to see who owns a domain name, browse Whois history, or search domains to buy in the new DomainTools Marketplace. Starting today, anyone who visits DomainTools.com from their Android or iOS device (plus a few others) will see a mobile-optimized layout that provides nearly all the functionality and content of the standard DomainTools site. Nearly 10% of our visits are from users with mobile devices, so this is a very significant launch for us, especially at our traffic volumes.
Building a mobile version of a big, complicated site like ours is not a trivial effort. Indeed, the biggest question is whether to build a “mobile site” at all. Why not build one site, and let it “adapt” or “respond” to whatever device happens to be accessing it? You get the benefit of a device-agnostic approach that more readily accommodates the direction web use seems to be headed. Essentially, if your code is saying something like “if device==iPhone” you’re doing something wrong.
That’s the concept behind a set of web design principles known as “Responsive Design”: build your site from the ground up to gracefully compress, re-flow, and even hide content when the site is viewed on a narrower screen. Users get essentially the same experience when they move from their desktop to their tablet to their phone, and developers only need to build and maintain one set of code. If you can avoid coding for specific resolutions, your site will continue to look awesome when Apple comes out with its new ultra-resolution iWhatever next month.
Like most good design, though, the concept works best when it’s part of your plans from the very beginning. Retrofitting an existing site can be quite tricky, especially if your site is more data-centric than content-centric, and if it has lots of interactive elements and conversion flows. It’s one thing to have text fill the full width of the screen, but does that really make sense for a button? Perhaps so on a mobile device, but certainly not on a big desktop screen.
Still, there are techniques from the responsive design paradigm that can be applied effectively to a site like ours, and in the end, that’s the approach we chose. We still built custom mobile style sheets for many of our products, but we usually steered clear of any changes to the HTML code itself. We tried not to code for specific device or screen sizes (although we did exclude tablets from the list of “mobile” devices), and we didn’t launch a separate mobile site on its own domain name.
That helped us quickly bring a mobile experience to the entire site without undertaking a long and painful re-design of every product.
We think mobile visitors to our site will prefer these optimizations to the standard site, but in case we’re wrong, we’ve provided a way out. There are few things more annoying to me than to visit a website on my iPhone only to be re-directed to a crippled, barely-functional mobile site. I can usually find a link to get back to the main site, but too often it just sends me back to their broken mobile site. I knew we could do better, so our engineers added a reliable “View Standard Site” link to the top of every mobile page. If you don’t like how a product functions on your device, use that to get back to the main site and we’ll remember your preference on future visits.
This represents the first step of a broader mobile product initiative we’re advancing in 2012. We’re working on a much-needed update to our iPhone app, and we’re building a new Android app. We will also continue to iterate on the mobile site, including a mobile-optimized Whois lookup designed for touch-based, small-screen interactions that puts the most relevant data at the top of the screen.
We welcome you to try jump in and try our new mobile experience!
As always, we want to hear your feedback.
What do you like? What would you improve on?
Send your feedback to email@example.com
Category: Domain Tools Updates