Legends of the Sun Pig

May 14, 2011November 5, 2011

Big Bag o’ Mobile (aka White Van Mobile Phone Man)

Mobilism business ideas #1:

Big bag o'mobile Suppose I were to offer a service where you could book me to show up at your office with a suitcase full of mobile devices. A large spectrum of phones (& tablets), ranging from old to new, smartphones to feature phones, different software levels. iPhones, Androids, Nokias, Blackberries, etc. Let’s say about 30 different models, just to give it a number. They’d all be fully charged (spare chargers in my other suitcase), and loaded with SIM cards with data plans. You could then proceed to spend a few hours or a day loading up your app or web site on the ones you are interested in, and running through test scripts.

The benefit of this approach over remote testing, or testing with emulators, or testing with devices connected to local networks, is that you would get to feel the devices in your hand, and experience actual network speeds and latencies. (One of the biggest take-way points from the Mobilism conference was that you really have to use actual devices to understand how your web site will behave in real life.)

Another benefit is that you wouldn’t have to buy a suitcase load of phones yourself, and tie yourself to the subscriptions that go with them. You could also use the time to invite along subjects so you could run usability tests. Lots of possibilities!

Questions, then:

Would you (or your company, or your clients) use such a service?
How often, or how frequently do you think you would want to use the service?
How much would you (or your company, or your clients) be willing to pay for this? (Per hour, or per day.)

May 10, 2011March 30, 2012

The spectrum of commonly disabled browser features

Images enabled?	CSS enabled?	JS enabled?	Use case
Y	Y	Y	The full web. The happy path. The zen garden. 95% of people will see some form of this. However, progressive enhancement, natural browser variations, and adaptive/responsive design means that you can’t (and shouldn’t) treat this 95% as a monolithic block of pixel-perfection. It’s a sub-spectrum of features.
Y	Y	N	JavaScript is disabled. Common reasons for this: You are in a corporate environment that does not allow untrusted scripts to run You have got sick of dynamic web pages, and want a more peaceful web environment Your bandwidth is metered, or your connection speed is slow, and you don’t want to download lots of scripts that probably aren’t designed to enhance your reading experience. A script has crashed somewhere on the page, taking everything else down along with it. There are plenty of other reasons, but a lack of JavaScript does not imply that the user is working with a screen reader, or some other form of assistive technology. Screen readers do actually handle JavaScript these days. This is definitely a use case you should care about. As Mark Pilgrim points out, “If your web application fails in browsers with scripting disabled, Jakob Nielsen’s dog will come to your house and shit on your carpet.”
Y	N	Y	CSS is disabled, but JavaScript is enabled. You’re a web developer.
Y	N	N	CSS and JavaScript are both disabled, but you can still see images. You’re a web developer trying to figure out why your print stylesheet doesn’t work.
N	Y	Y	Images are disabled. This is actually more common and more useful than you might think, especially in low-bandwidth or expensive bandwidth situations. Most modern web pages still work just fine without images, they’re just a little less visually interesting. You should try it some time. Opera is the only browser that has consistently made it easy to toggle image downloading from a menu or keyboard shortcut. Other browsers allow you to do this, but you have to dive into their options or preferences screen, or install an add-on.
N	Y	N	Images and JavaScript are disabled, but CSS is still turned on. You’re trying to save ink while printing a web page.
N	N	Y	Images and CSS are disabled, but JavaScript still works. You are a client-side unit testing framework.
N	N	N	Free-range organic HTML, rendered as nature intended it. You’re an awesome time-travelling hard-core Unix geek from the Dark Days before Mosaic (aka 1992), or, more disappointingly, a bot. Hello, bot. Nice bot. Have a cookie.

May 6, 2011January 12, 2012

Using a VPN from the guest OS in Parallels

Problem statement: I am running OS X 10.6 (Snow Leopard), and have a Windows 7 virtual machine running under Parallels 5. I want to have both of them connected to a remote VPN at the same time. Getting the host Mac to connect to the VPN was not a problem. But connecting to the VPN from the Windows 7 guest would not work. It would just sit there at the “Verifying user name and password…” message.”

Solution:

Set the virtual machine instance to use Bridged Networking (Default Adapter) instead of Shared Networking.
Make sure that the advanced options for the VPN in the host OS X are not set to send all traffic over the VPN connection. (This is actually the default setting, but if you’ve just spent an hour fucking around with your network configuration trying to make it work, you may very well have changed this.)

This now allows me to connect the VPN on the host and the guest completely independently. (Either one or the other, or both at the same time.) I have no idea if this is a universal solution; if it doesn’t work for you, asking me why really isn’t going to help.

May 4, 2011May 12, 2011

The mobile web is an illusion

Here’s an old joke: there’s a man crawling around on the ground just under a streetlight, searching for his keys. A friendly passer-by offers to help him out. When they still haven’t found anything after a few minutes, the passer-by says, “are you sure this is where you dropped the keys?” “No,” the man says, “but this is the only place I can see well enough to look.”

This reminds me of the technique of leading a target, which means to shoot ahead of a moving target, so that the target and projectile will eventually collide. Basically, you don’t aim where the duck is, you aim for where the duck will be.

And this, in turn, reminds me of the current situation in web development right now. The mobile web is moving so fast that you can’t base your next year’s development plan on current browser statistics. You have to be planning for the future.

The growth of mobile internet usage has taken a lot of companies by surprise, and mobile web skills are so hot right now you risk serious burn injuries by just adding them to your LinkedIn profile. So now we are going to see wave upon wave of “mobile versions” of existing web sites, optimized for 320px-wide screens running webkit.

But that’s where the duck was; it isn’t there any more. Adaptive or responsive techniques allow you to build web sites that adapt to the capabilities (primarily screen resolution) of whatever device is viewing them. This is not a new idea, but it has taken the rise of mobile devices (face it: the iPhone) to convince stakeholders that the same web site cannot look exactly the same on every browser…and that that’s okay.

This is why I think “the mobile web” is an illusion, or at least just a passing phase. Remember when Ajax was the new hotness? How we were going to build fast, rich apps, and how we all started calling ourselves “web application developers”? Well, Ajax isn’t a separate thing any more. It’s just how we build the web.

Remember how “social” was going to transform everything? How deep integration with Twitter and Facebook would lead to new modes of customer involvement, and more meaningful experiences? Well, ditto. In 2011, that’s just how we build the web.

You know how “mobile” is going to revolutionise customer behaviour? How “mobile web developers” chortle at the idea of separate sites for desktops and small-screen devices (take two web sites into the shower?), and sit around earnestly discussing “mobile strategy”? Yep, same deal. Two years from now, we will have web devices with so many different sizes and capabilities to render the distinction between “mobile” and “desktop” web completely meaningless. The device does not imply the context. It’s just how we build the web.

A shotgun approach to mobile development (iPhone app! Android app! Blackberry app! Mobile site!) is not enough. Adaptive design for a web site is not enough. Just flipping stylesheets depending on screen resolution is pretty, but it doesn’t in itself lead to better web sites, as measured by ongoing customer satisfaction and engagement. The reality of the web is that as a site owner, your control of how someone consumes your content is limited. Companies that learn how to deal with this limitation, and turn it to their advantage, will be the big success stories of the next few years.

IE6 does not natively understand many significant features of CSS2.1, such as the child (>), adjacent sibling (+), and attribute ([attr]) selectors. Because of this, many web developers (myself included) often ignore them, and work with a more highly-compatible subset of CSS. But if you have the luxury of ignoring IE6–and unfortunately it is still a luxury–then all of these cool features (and more!) suddenly come into play, and they can make your code a lot cleaner.

My favourite illustration of CSS2.1 hotness is nested modules. Here’s some typical HTML:

<div class="mod mod-blog">
  <div class="hd">My awesome blog</div>
    <div class="bd">
    ...
      <div class="mod mod-blogentry">
      <div class="hd">My awesome breakfast</div>
      <div class="bd">
        ...
      </div>
      <div class="ft"></div>
    </div>
  ...
  </div>
  <div class="ft"></div>
</div>

If you use a descendant selector to style the .hd of the outer module, you have to be careful to override any styles for the .hd of the inner module, otherwise the outer styles will apply to it, too:

.mod-blog .hd {
  font-size:167%;
  font-weight:bold;
}

.mod-blogentry .hd {
  font-size:100%;
  font-weight:normal;
}

Alternatively, you end up decorating the .hd element with additional classnames so that you can target the elements more specifically in your CSS (e.g. <div class=".hd .hd-blog">).

By using child a child selector, you can be much more specific in which elements you target. In this example, you can ensure that the “big and bold” style only gets applied to the header of the outer module by using the child selector:

.mod-blog > .hd {
  font-size:167%;
  font-weight:bold;
}

And boom, your code is a lot cleaner, and your modules can be coded in a much more modular style–without having to worry quite so much about nesting issues and inherited rules.

Of course, even if you do have to support IE6, there is nothing to stop you from using these selectors anyway. You can use a polyfill like Selectivizr to implement the missing support in IE, or you can provide IE6-specific overrides in a separate stylesheet, like so:

.ie6 .mod-blogentry .hd {
  font-size:100%;
  font-weight:normal;
}

I don’t recommend doing this, though, because IE6 is already the slowest mainstream browser on the block. Adding additional cruft is just going to make it even slower, and give your site’s visitors an even worse experience than they already have.

But seriously: if you’ve been drooling over rounded corners and gradients without background images, you owe it to yourself to remind yourself of these older features as well. You’ll be very pleasantly surprised by what you can do with them.