web development

The Web is not Poor Man’s Native

Posted on by cwilso

I read PPK’s “Web vs. native: let’s concede defeat” article with great interest.

I agree quite strongly that the web does not need to emulate native to provide a powerful, vibrant app ecosystem. If your goal is to build awesome experiences for the web, you will be very poorly served by attempting to just emulate native. The web has its own set of strengths – its ephemeral nature and lack of friction, for example, and its incremental security model.

However, I believe it’s fundamentally flawed to draw lines around the experiences you can build with the web, and “concede defeat” to native apps. PPK himself previously identified that “Web vs native [is] the wrong question”. The “web has to capitalise on its own strengths, primarily its reach”. To my mind, those strengths don’t end when the user wants a home screen icon to integrate that experience better in their experience.

The web has incredibly low friction

The average mobile user visits far more sites per month than individual apps – I’d postulate because installing an app has a somewhat high cost; you have to knowingly wait for the app to install, possibly agree to a EULA-like list of permissions that you may not understand (or more likely, haven’t bothered to read), and then you’ll be reminded of this relationship forever after by that icon in your home screen (if not notifications popping up).

PPK referred to a article by Scott Jenson to support that home screen location was the dividing line between web and native; but Scott DIDN’T make the point that home screen icons are the problem, he made the point that having to curate a set of apps was a problem. In fact, Scott’s point was largely around the importance of just-in-time interaction vs having to curate a set of apps. The necessity of this curation comes from space, device impact (aka “stuff running in the background that can drain my battery and/or annoy me with notifications), and permissions, more than home screen icon space IMO. This is certainly a pain point for users, though; I’ve changed mobile devices multiple times in the past year, and Android helpfully re-installs apps for me – reminding me just how much junk I’ve installed.

The web, by comparison to native platforms, is very low friction. Commerce is heavily web-based, even on mobile devices – watch the excellent talk just given by Alex Komoroske and Elisabeth Morant at Google IO for more.

Everyone wants to be on the home screen

PPK’s presumption is that engagement – RE-engagement, in particular – is just not done for web apps. That’s no longer true. We’ve had add to homescreen for quite a while – of course, it’s been somewhat hidden; but now, with re-engagement features like push notifications and add-to-homescreen apps that work offline thanks to Service Workers, putting web apps on the home screen is no longer putting lipstick on a pig; for example, I didn’t bother installing the Google I/O native app – I just added the Google I/O web app to my home screen, and it popped up notifications when it was time to go to a session and everything. With the addition of web app install banners, we’ve made this both much more natural and more effective.

I believe no content developer – say, a news site – would agree that they don’t want to be on the home screen. They DESPERATELY want that re-engagement with the user. The user, however, may not be completely ready to sign up to that just yet; they want to date for a while before living together. But adding an icon to the home screen is like putting someone in your speed dial; it doesn’t mean you’re handing them the keys to your house.

The web, by contrast, excels at just-in-time interaction, as it IS hassle-free. But it’s a natural progression to enable users to move that onto their home screen, and let them get notifications and other engagement features if they so desire. This is still the web, though – I don’t need to have the NYT app open just to read the article at a link I followed. There are also app-like behaviors you may want occasionally too, e.g. a “what’s near me?” app. There’s an assumption that app-like behaviors demand native, and that the web is for documents.

The cruft of the current Web

Of course, the web development model also has its own set of challenges. In particular, there is a huge over-indulgence in trackers today, and this can wildly impact responsiveness. If you run a plugin like Ghostery for a while, you’ll quickly learn just HOW prevalent add-ins like this are. In a quick tour around common news sites, for example, I found the AVERAGE number of external tracking libraries being loaded to be more than twenty.

Would I include more than twenty external code libraries into my native app, for dubious user benefit? Probably not. As Jeremy put it, that cruft was put there by us; and Marco Arment agrees: “The entire culture dominant among web developers today is bizarrely framework-heavy, with seemingly no thought given to minimizing dependencies and page weight.” I think it’s also true that web developers tend to rely heavily on frameworks, sometimes without understanding the cost/benefit tradeoffs in order to use them judiciously. Particularly in the case of stale frameworks, or ones that don’t adhere to a RAIL-like philosophy, this can dramatically impact your usability. I’m not saying “never use trackers”, but take a look in dev tools; maybe you don’t need a couple of dozen trackers on every page. Focus on providing an incredible user experience; the little things add up.

Rethink the web

Properly designed web apps in the modern world – particularly, utilizing Service Workers in order to manage your performance and offline experience – can be incredibly responsive, and with re-engagement features like push notifications being added daily, the web is now a viable platform for engaging user experiences.

There will always be reasons to build native applications. It’s quicker to innovate platform APIs when you don’t have to go through standardization and browser implementation. Exposing new “bedrock” APIs can be done more quickly. As Jeremy aptly summed up, “The price we pay for that incredible cross-platform reach is that features on the web will always be lagging behind.”

On the other hand, reach is incredibly beneficial. Low-friction initial engagement (and scalable re-engagement) are an amazing on-ramp for users.

7
photography

Outdoor shooting

Posted on by cwilso

One of the things I’m bad at is sharing advice in a broader public forum. I love sharing advice, but sometimes I respond just to one person at a time. I’m going to try to start sharing bits a bit more broadly.

This morning, someone on a photography list I’m on asked:

“I’ve been asked to do an outdoor shoot for a friend…what equipment do I need for something like this, and what do I need to keep in mind?”

My advice back was:
First, an outdoor shoot of what? Portraits, cars, landscapes?

Secondly, just like indoor shoots, the key to outdoor shoots is lighting, and controlling the light. The hard part, of course, is that can’t have direct control over the brightest light source – the sun. General guidelines are that shooting in bright sun at high noon is pretty tough, and the golden hours can be great for this; but shooting in late morning or early afternoon is doable, but equipment-wise, you may want to make use of sunshades and sun reflectors (and/or strobes) for fill lighting. I found even a small reflector can help tremendously at changing around the light on the subject; strobes in sun, for me, require a lot of trial and error, and I found a reflector was easier to visualize.

Obviously, too – don’t shoot into the sun; that will wildly exacerbate the dynamic-range problem (subjects will be in shadow, background will be very bright, and you’ll lose detail in both). Polarizers, on the other hand, can help control glare immensely, and when I’m shooting outside in sun, my polarizer almost never comes off my lens.

In general, I’d grab a reflector, a reflector caddy (aka a friend who can bounce the light for you), and a polarizer, a strobe if you have it, try to set it up for late afternoon/early evening, and give it a shot.

(As with all photography “rules” – your mileage may vary, and it is possible to get some incredible, innovative shots while blithely ignoring all the above suggestions. 🙂

waterfall
1
web development

Chromium’s Blink announcement

Posted on by cwilso

In case you haven’t seen the news yet, the Chromium project is building and releasing a new open source web rendering engine based on Webkit, called Blink.

This is all goodness, in my opinion.  It will make Chromium faster and more stable, it increases the diversity in the rendering engine space, and best of all, the Chromium team has already put in place strong guidelines for new features that will help mandate standards focus, openness and interoperability.

Along with many others, I was sorry to see the browser engine space diminish with the loss of Opera’s engine, Presto, and I believe Blink will help improve that engine diversity – while maintaining a strong focus on continuing to improve interoperability.

As someone who saw first hand how a web platform monoculture – even the well-intentioned aspects of it – affected the web platform the first time (or two :), I’m excited by the strong investments in getting this right from my colleagues in the Chromium project.

To learn more about Blink visit our project page. As always, feel free to engage me personally, here, on Twitter, on G+, or in email.

-Chris

0
CSS, professional, Trolling

Content Protection, fonts, and trolling

Posted on by cwilso

(Updated: eek!  @marypcbuk pointed out that I had an unfinished sentence at the end of paragraph 3.  Fixed.  I blame the still-lingering SXSWScurvy.)

Jeremy Keith posted some thoughts on SXSW, including the always-incredibly-fun browser wars panel I got to participate in again (yay!) with some good friends.

Jeremy, a couple of corrections – 1) I think it was probably at least three years ago that I was “defending” the EOT format – and 2) my point was not “hey, that’s just the way things go.”  In fact, that’s the core of the problem with video right now – the cost/benefit here is not “that’s just the way things go”, so I want to expand my argument from the font controversy.

I most certainly did NOT say “Without some form of DRM [on fonts], … we couldn’t have fonts on the web.”  I said, at the time, that font foundries needed to be happy with the arrangement, because the TTF/OTF files on your computer have at best convoluted and hard-to-track-down licenses and provenance.

At the time, the competing “standard” for embedding fonts from Opera was simply direct linking to TTF/OTF files; my point was that really, only a select set of freeware fonts had licenses that allow you to reshare the font like this.  (Many of freeware fonts, for example, require you not to mess with their .zip file package when you re-host, and for their license.txt file to remain intact – which you can’t really do when resharing for use in direct linking.) In general, any non-freeware (i.e. licensed) fonts would not allow you (“allow” in terms of what their EULA allows to do, based on their copyright of the file) to just put their TTF file up on a web server.  In general, it’s quite a challenge to look up what the permission rights for a font on my computer is;  it’s basically a detective investigation to figure out where the file came from, and what the EULA says about redistribution of that file.  In short, I did not think this was a particularly good design.  Having originally implemented EOT in IE (in IE4, I believe), I wasn’t under any particular delusions of its brilliant design as a web embedding technology either, but I’d been pragmatic then.  I think you must have been reading my insistence that direct linking wasn’t good enough as an argument for hardcore DRM (which, BTW, EOT isn’t really anyway, but I could see even at the time how it triggered the DRM hotbutton for people).  The issue was not, though, that there was a demand for DRM – it was there was demand for something other than just raw TTF/OTF files.  There was a demand for a wrapper that was, in the end, satisfied by… a wrapper.

WOFF was not yet a thing – in fact, it partly grew out of the conversations we’d been having with font foundries based on EOT.  I was attempting to get exposure for the idea that something other than just a raw TTF file was going to be necessary – I believe I said, “if the font foundries are happy, I’m happy.  I don’t care.”  That happened; everyone pretty much implements WOFF now; font foundries are really happy, because designers have some idea fonts are IP, but designers are happy because it’s not “DRM” and it’s not very restrictive at all.  Thus, I am happy.

So, in short – I was trolling you.  Gotcha.  🙂

-C

PS – in followup; I believe IE only ships VBScript turned on for intranet, but maybe I’m confused.

PPS – I haven’t said much about content protection and video here; nor do I really intend to.  It’s pragmatic; the rights owners (aka the studios) get to control whether episodes of Big Bang Theory (or whatever) get released in a particular format, and they believe DRM is important and useful.  Don’t ask me to defend this; go talk to them.  Or decide that you still want iTunes/Flash/Silverlight whatever totally-proprietary platform to maintain its critical position, and you’re limited to content studios don’t think is as important (or comes from studios willing to take that risk).  That’s where we are today.  We can hold that course, and I can continue to have to buy a copy of BBT for Android devices, one for my iOS devices, and still not get to watch on the web.  Go have this argument with the studios (again) – or, better yet, participate in the TV and Web IG at the W3C, because the studios are.  I personally am absolutely not asking anyone to just accept this because “hey, that’s the way it goes.”  I do think it’s probably the most pragmatic thing to do, and I am a pragmatist.  But my head is sore from banging on this rock, and it’s not even my rock.  🙂

PPPS: I don’t really watch BBT.  But I got insulted last time I admitted to being a How I Met Your Mother fan.  (SERIOUSLY?!?  WHO CAN RESIST THE BRILLIANCE OF NPH?)

PPPPS: I would have stopped SOPA at the “Something must be done!” stage – no, I don’t think it does.

PPPPPS: Is there a legal restriction on the number of Ps?

3
Uncategorized

Holga Lens for Canon EF Mount

Posted on by cwilso

For those of you not in the know, a Holga is a “toy camera” – it’s a plastic camera body, with a plastic lens, that retails for around $25.  It uses 120 film – taking a 6cm x 6cm image.  The pictures taken with it tend to be very unpredictable, with lots of blurriness (it’s hard to focus precisely, and nothing is every REALLY sharp), light leaks (the clips that hold the back on don’t really provide a totally light-proof seal all the time), and in general, a real lo-fi look.  The Holga (and similar cameras) really are partly responsible for spawning photo manipulation applications like Instagram, and they have a huge following (there are over 7,000 Flickr groups with “Holga” in the name).

I bought a Holga a few years ago, and played with it for a while – but of course, getting 120 film developed is a pain (and expensive), and my Lensbaby 2.0 (and more recently, my Lensbaby Composer, with a nearly full set of optics) have taken up my lo-fi attention.  There have been some mods to take Holga lenses and mount them on SLRs, but I’ve never taken the plunge – but I recently ran across the official Holga Lens for Canon SLRs, and decided it was worth $25 to try it out.

So, how does it compare?  Well, I’ve got a few photos from my actual film Holga in my Flickr feed, like this one:

You can clearly see the vignetting in this image, as well as the warping, focus issues, and chromatic aberration.  But it’s still pretty.  🙂

Although I’ve taken tons of pictures with my Lensbabies over the years, I was looking forward to playing with a new toy.  All in all, I’m pleased; although I thought it was a little weird when I opened up the lens and saw this:

Now, logically, the original Holga lens was designed for a 6x6cm film “sensor” – so it was going to look a lot different when cropped down, even on my full-frame Canon 5D mk ii.  For reference, here’s that same Holga image, but with 35mm crop frame (orange) and APS-C crop frame (yellow):

So the odd little aperture arrangement was apparently Holga’s attempt to replicate the vignetting and soft focus of their medium-format lens onto a smaller frame.  (Not surprisingly, this is reminiscent of the Lensbaby Soft Focus Optic aperture discs.)  Somewhat ingenious – Holga can still claim “the original Holga lens!” while still actually getting the vignetting, etc on a smaller frame.  The unfortunate part? They really designed the aperture for APS-C crop cameras (e.g. the Canon 60D or 7D, not really my full-frame 5D mk ii.  A full-frame camera gets much of the outer frame completely vignetted out, and a weird 8-overlapping-circles bokeh pattern to boot:

Of course, it works okay on full-frame when the background is dark anyway:

But can look a little weird at other times – which brings me to my one of my main points: this SLR lens was really designed for cropped-sensor cameras, like the 60D or 7D.

The real tragedy, however, is that in adding this funky aperture, the lens goes from the original approximately f/13 aperture to being somewhere between f/32 and f/40 (from an evaluative-metering on full-frame test, I measured it at about f/45; but I think that’s unfairly penalizing for the heavy vignetting on full-frame.  So, trying to use this in anything but lots of light – good luck.  You’ll need a REALLY slow shutter speed – and you will find it nearly impossible to aim, since the viewfinder will be very dark.  Even in bright sunlight, you’ll want to bump up the ISO – for example, this photo of my daughter in bright sunlight was ISO 400, 1/40sec exposure:

Incidentally, I did discover that funky little aperture disc is removable – it’s glued in to the lens, but only with cheap sticky stuff.  Once you pull it out, though, as you’d expect from the crop example above, there’s basically no vignette at all, even on full frame.  I put it back in, but I think I’m going to try creating an aperture disc to stick in there that is larger than the current one, to get less vignette on full-frame, but still some.  That’ll be a future project, though.

So, pluses to the Holga-for-Canon lens:  easy to use, great serendipity potential.  Downsides: WICKEDLY slow lens (f32-f45-ish on full frame), and has a very strange vignetting pattern in full frame.  Overall, though, absolutely worth the (little) money for a new creative tool.

All the photos I’ve taken with the Holga lens on my SLR so far can be found on my Google+ account in the “Holga Lens” set.

2
Uncategorized

Promoting the Open Web, and Platform Competition

Posted on by cwilso

Robert O’Callahan wrote a post last week about Mozilla’s historical promotion of the open Web over proprietary platforms.  There were some things in there that I agreed with strongly, although some not as much.

Robert, as I read your view, the competition has changed from WPF, Silverlight and Flash to iOS and Android, and “accordingly, the features the Web needs to catch up on are mobile focused.”  Although I absolutely agree that the web needs to be “knocking down barriers that make mobile app developers write native apps instead of Web apps,” I think it is a mistake to think that the web should narrow its competitive focus to mobile.  Mobile is just a placeholder for computers that are embedded in your daily life, and don’t cost $1000+, and aren’t chained to a desk.  It’s not about making phone calls.  It’s about being highly interactive, with lots of integration with the real world via sensors and outputs.  (There’s a whole 5-minute diatribe here about why the iPhone became popular – skipped for brevity’s sake.  Let me know in comments if you want me to expand.)  This isn’t a different Web; it’s just a more integrated one.  The Web platform is supposed to be good at scalability, so scaling to these needs should be a strength – and I DO think we need to expose APIs to those device capabilities.

The Web platform’s competition here *IS* all proprietary stacks – WPF, Silverlight, Flash, iOS, Windows Phone, Windows, Metro, MacOS, and yes, Android.  That doesn’t mean I hate all those stacks, or that I think they’re ebil – I just want the Web to be a viable competitor to them.  When some developer somewhere starts building the NEXT Angry Birds, I hope it can be in the Web platform to begin with, and won’t need to be ported to those other platforms.

(As an aside, Robert, I was curious to see you give kudos for Microsoft for moving towards a standards-based platform in the same post as lambasting Google for the Chrome Store.  You understand although you can write Hello World for Metro completely using standards, more complex apps are likely going to be heavily dependent on the Windows Metro Runtime APIs, right?)

I was somewhat amused to see you say “We also need to send a clear message that browser-specific app stores run counter to the open Web,” when Mozilla itself has one of the earliest (and wildly successful!) browser-specific app stores – https://addons.mozilla.org/en-US/firefox/.  You can say “that’s just addons,” but looking at apps like XulTris, it’s hard to agree with that argument.  I get (and agree with you) that the point should be to not silo web platform applications inside a single-browser tower, though.

To be clear – I’d like to see the Angry Birds web app work across all browsers, including being offline-accessible.  I’d like to see offline GMail and Google Calendar work across all browsers, too.  On the flip side, I think it’s pretty natural that there are going to be vendor-specific app stores – if for no other reason that users can get varying levels of confidence (or different assurance, or just different brand identification) from downloading an app package from Google, or Mozilla, or Amazon, or whoever.  And yes, that “package” may be a link, not a JAR file, but there has been store-specific level of vetting of the application that users will find useful.  I think the real question is “Could you use the Google app store from Firefox?” – personally, I’d like to say yes (modulo the browser add-ons, of course).  We’ve got a ways to go there, certainly.

Robert, I’m not sure where you got “Google is explicitly telling its developers to target Chrome-only at first and support other browsers as an afterthought” – the link pointed to the Dash (Dart) “memo”, which says “Developers who can focus solely on Chrome can expect…”  in essence saying “we can get this stuff into Chrome; we can’t push it to other browsers, but we can support a cross-compiler to JS.”  I don’t read that as a whole lot different than any other new feature that turns up in one browser first, and goes through a lot of work before it might (or might not) be adopted by others.  I think either Dart (nee Dash) will be successful as an attempt to build a wildly more productive runtime, and it will turn into a real open standards part of the web platform, and other browsers will build their own implementations of whatever it becomes as it is tossed into the open development pot – or it will inform the current efforts on Harmony, et al to goad more aggressive improvements into the current efforts.  (Or it will be a complete flop, and sink without a trace.  I doubt that, but I wanted to feed the trolls.)  Personally, I would bet more on the informing-current-efforts-and-goading-further-improvements path, but that’s based on my history.  (WPF was, after all, an attempt to learn from the Web platform and do it better.)

I’m concerned that you seem to think only Mozilla, and maybe Opera, have no vested interest in the success of a non-open-Web platform – mostly because the convolutions and double negative of that statement imply that others (Google in particular) have no vested interest in the success of the Open Web platform.  I have to disagree, if that’s the implication.  Yes, Google has Android; I would be a happy, happy person if the success of the open web platform placed Android into obscurity.  If anyone at Google wants to fire me for that, I’ll be happy to go.  And in fact, I would say Google has a very vested interest in the success of the shared open web platform, with a more solid business model behind that interest than most.  If I didn’t feel that way, I wouldn’t have come to work here.

Today, in the short term, there are certainly features that are browser-specific, that enable cool applications.  I hope those features will become part of the shared open web platform – and that’s what I plan to do here.  If certain features don’t merit becoming part of that shared platform, for the most part I’d expect them to die on the vine*.

But to get back to the core point – if someone at Google is telling web developers across the board to target Chrome only and only support other browsers as an afterthought, I’d like to know who, so I can go kick them in the (figurative) nuts.  Unless that message is actually being said by someone, I’d like to keep the focus where it needs to be – on figuring out what we need collectively to push the common Open Web platform to be competitive with all the other platforms out there, and on evangelizing building (cross-browser) web applications built on that Open Web platform.

-C

PS: *Remind me to post something on vendor prefixes.  This was already getting long.

PPS: Which also reminds me – if there’s something any of you WANT me to post about, let me know.  I’m free, in case you didn’t hear. 🙂

2
personal, professional

Tick.

Posted on by cwilso

Tick. The clock just ticked past 5:00PM PT September 21st, 2011, marking exactly one year since I walked out the doors of Microsoft as a former employee.

The reason I care, of course, is that means both my non-compete clause and my non-solicitation clause have expired. I am now free to go work on whatever I want, (and I’m also free to talk to my former co-workers about working for Google – y’know, if you want ;).

So yes, you can expect that I will now be finding my way back to working on the core Open Web Platform, since that is where my passion lies. And you can also expect I will be less…restrained… about discussing the web platform in the future. Off to celebrate…

4