Archive: December, 2015

71

sparkline
                    5th                     10th                     15th                     20th                     25th                     30th     
12am    
4am
8am                      
12pm                      
4pm                      
8pm          

Monday, December 28th, 2015

The App-ocalypse: Can Web standards make mobile apps obsolete? | Ars Technica

I really, really want to like this article—it’s chock full of confirmation bias for me. But it’s so badly-written …I mean like, just the worst.

Here’s an actual sentence:

So with a capable, HTML-based platform and a well-designed program that makes good use of CSS, one site could support phones, tablets, PCs, and just about anything else with one site.

So, yeah, I’m still linking to it, but instead of it being for the content, it’s because I want to lament the dreadful state of technology writing.

Saturday, December 19th, 2015

Friday, December 18th, 2015

Thursday, December 17th, 2015

Write What You Know (Now) · An A List Apart Column

Well, this is rather lovely!

I nodded along with host Jen Simmons and guest Jeremy Keith saying some very smart things about the web and its roots as the El train cut across Philadelphia. But at the 48-minute mark things got weird, because Jen and Jeremy basically started writing my column for me while I listened.

Read on for some great advice on conquering your inner critic.

Wednesday, December 16th, 2015

More Responsive Tapping on iOS | WebKit

This solution to the mobile tap delay by the WebKit team sounds like what I was hoping for:

Putting touch-action: manipulation; on a clickable element makes WebKit consider touches that begin on the element only for the purposes of panning and pinching to zoom. This means WebKit does not consider double-tap gestures on the element, so single taps are dispatched immediately.

It would be nice to know whether this has been discussed with other browser makers or if it’s another proprietary addition.

Interactive Storytelling | Codrops

I think this might be the most tasteful, least intrusive use of scroll events to enhance a Snowfallesque story. It’s executed superbly.

You can read all about the code. Interestingly, it’s using canvas to render the maps even though the maps themselves are being stored as SVG.

(There’s a caveat saying: “This is a highly experimental project and it might not work in all browsers. Currently there is no IE support.” I don’t think that’s true: the story works just in IE …that browser just doesn’t get the mapping enhancements.)

Tuesday, December 15th, 2015

What Progressive Web Apps Mean for the Web - Telerik Developer Network

A hands-on look at building a progressive web app with Service Workers, manifest files, HTTPS, and all that good stuff. This is nice and balanced, extolling the virtues but also warning about the potential difficulties in implementing this stuff.

One nitpick though: there’s talk of graceful degradation, and while I get that that’s the outcome, I think it’s better to think in terms of progressive enhancement, which is the approach.

Monday, December 14th, 2015

My latest Twitter bot: @5point9billion (14 Dec., 2015, at Interconnected)

I always loved Matt’s light cone project—it was a big influence on the Radio Free Earth hack that I made with Chloe. Now it has been reborn as a Twitter bot. Here’s Matt’s documentation for his future self:

I haven’t made a habit of project write-ups before, but I’m taking an increasingly “long now” approach to the tech I make and use. How will I remember what I made in a decade? By reading this post.

The web accessibility basics – Marco’s Accessibility Blog

Marco gives a run-down of the basics of getting accessibility right on the web. Nothing here is particularly onerous but you’d surprised how often developers get this wrong (or simply aren’t aware of it).

He finishes with a plea to avoid unnecessary complexity:

If there’s one wish I have for Christmas from the web developer community at large, it is this: Be good citizens of the web, and learn proper HTML before you even so much as touch any JavaScript framework. Those frameworks are great and offer a lot of features, no doubt. But before you use hundreds of kilobytes of JavaScript to make something clickable, you may want to try if a simple button element doesn’t do the trick just as fine!

Sunday, December 13th, 2015

Untangling the Tale of Ada Lovelace—Stephen Wolfram Blog

A detailed history of Babbage and Lovelace through the lens of Wolfram’s work today:

Ada seems to have understood with some clarity the traditional view of programming: that we engineer programs to do things we know how to do. But she also notes that in actually putting “the truths and the formulae of analysis” into a form amenable to the engine, “the nature of many subjects in that science are necessarily thrown into new lights, and more profoundly investigated.” In other words—as I often point out—actually programming something inevitably lets one do more exploration of it.

If this piques your interest, I highly recommend the Babbage biography The Cogwheel Brain by Doron Swade.

HIKE - Introduction to accessibility concepts for the Web

It really isn’t hard to get the basics of accessibility right on the web …and yet those basics are often neglected.

Here’s a handy shortlist to run through, HIKE:

  • H stands for headings and semantic markup.
  • I stands for images and labels.
  • K stands for keyboard navigation.
  • E asks for you to ACT with a little extra love for custom components and more.

(ACT = ARIA, Colour Contrast, Text Size)

Smaller, Faster Websites - - Bocoup

The transcript of a great talk by Wilto, focusing on responsive images, inlining critical CSS, and webfont loading.

When we present users with a slow website, a loading spinner, laggy webfonts—or tell them outright that they‘re not using a website the right way—we’re breaking the fourth wall. We’ve gone so far as to invent an arbitary line between “webapp” and “website” so we could justify these decisions to ourselves: “well, but, this is a web app. It… it has… JSON. The people that can’t use the thing I built? They don’t get a say.”

We, as an industry, have nearly decided that we’re doing a great job as long as we don’t count the cases where we’re doing a terrible job.

Friday, December 11th, 2015

IonicaBizau/gridly

Grid frameworks don’t get much more minimal than this—eleven lines of CSS:

.row { display: flex; }
.col { flex: 1; }
@media (max-width: 48em) {
    .row { flex-direction: column; }
    .col { flex: 0 0 100%; }
}
.col-tenth { flex: 0 0 10%; }
.col-fifth { flex: 0 0 20%; }
.col-quarter { flex: 0 0 25%; }
.col-third { flex: 0 0 33.3333334%; }
.col-half { flex: 0 0 50%; }

Should’ve been a gist really.

An Event’s Lifecycle: The Highs, The Lows, The Silence // beyond tellerrand

I can certainly relate to everything Marc describes here. You spend all your time devoted to putting on an event; it’s in the future, coming towards you; you’re excited and nervous …and then the event happens, it’s over before you know it, and the next day there’s nothing—this thing that was dominating your horizon is now behind you. Now what?

I think if you’ve ever put something out there into the world, this is going to resonate with you.

Thursday, December 10th, 2015

Wednesday, December 9th, 2015

Progressive Enhancement—Ain’t Nobody Got Time for that | GlückPress

Two sides of a debate on progressive enhancement…

Andrey “Rarst” Savchenko wrote Progressive enhancement — JS sites that work:

If your content website breaks down from JavaScript issue — it is broken.

Joe Hoyle disagrees:

Unlike Rarst, I don’t value progressive enhancement very highly and don’t agree it’s a fundamental principle of the web that should be universally employed. Quite frankly, I don’t care about not supporting JavaScript, and neither does virtually anyone else. It’s not that it doesn’t have any value, or utility - but in a world where we don’t have unlimited resources and time, one has to prioritise what we’ll support and not support.

Caspar acknowledges this:

I don’t have any problem buying into pragmatism as the main and often pressing reason for not investing into a no-JS fallback. The idealistic nature of a design directive like progressive enhancement is very clear to me, and so are typical restrictions in client projects (budgets, deadlines, processes of decision making).

But concludes that by itself that’s not enough reason to ditch such a fundamental technique for building a universal, accessible web:

Ain’t nobody got time for progressive enhancement always, maybe. But entirely ditching principle as a compass for resilient decision making won’t do.

See also: Mike Little’s thoughts on progressive enhancement and accessibility.

Tuesday, December 8th, 2015

The web will always be a moving target : Eclectic Dreams

Caution:

It would be convenient to think that because we live in a world where people’s browsers are regularly updating, that we live in a world where the web is in a reliable state.

Reminder:

The web is a continually moving target. It probably changed in the time it took me to write this. If you work with web stuff you need to embrace this fact. It will be the only constant in your career.

Do not panic:

On the web progressive enhancement is and will always be, the methodology of choice. It makes your site robust to the shifting sands of the web front end.

Cutting the Mustard Revisited — sixtwothree.org

Jason revisits some cutting-the-mustard techniques, as started by the BBC and refined by Jake. This kind of feature-testing is indispensable for progressive enhancement.

Personally though, I’m still uncomfortable with the assumptions baked into equating particular features with particular browsers …maybe I’ve known PPK too long.

I much prefer to cut the mustard on a case-by-case basis by feature testing the actual APIs I’m about to use in a script. I realise that might be harder to scale, and it’s more verbose, but it’s the only way to be absolutely sure.

Monday, December 7th, 2015

Sunday, December 6th, 2015

The Moral Character of Cryptographic Work by Phillip Rogaway (PDF)

It’s a PDF and it’s an academic paper, but this rousing call to arms is a remarkably clear and engrossing read.

With few exceptions, the atomic scientists who worked on disarmament were not the same individuals as those who built the bomb. Their colleagues—fellow physicists—did that. Cryptographers didn’t turn the Internet into an instrument of total surveillance, but our colleagues—fellow computer scientists and engineers—did that.

It concludes with a series of design principles for the cryptographic community:

  • Attend to problems’ social value. Do anti-surveillance research.
  • Be introspective about why you are working on the problems you are.
  • Apply practice-oriented provable security to anti-surveillance problems.
  • Think twice, and then again, about accepting military funding.
  • Regard ordinary people as those whose needs you ultimately aim to satisfy.
  • Be open to diverse models. Regard all models as suspect and dialectical.
  • Get a systems-level view. Attend to that which surrounds our field.
  • Learn some privacy tools. Use them. Improve them.
  • Stop with the cutesy pictures. Take adversaries seriously.
  • Design and build a broadly useful cryptographic commons.
  • Choose language well. Communication is integral to having an impact.

We need to erect a much expanded commons on the Internet. We need to realize popular services in a secure, distributed, and decentralized way, powered by free software and free/open hardware. We need to build systems beyond the reach of super-sized companies and spy agencies. Such services must be based on strong cryptography. Emphasizing that prerequisite, we need to expand our cryptographic commons.

Taking Let’s Encrypt for a Spin - TimKadlec.com

Tim outlines the process for getting up and running with HTTPS using Let’s Encrypt. Looks like it’s pretty straightforward, which is very, very good news.

I’m using the Salter Cane site as a test ground for this. I was able to get everything installed fairly easily. The tricky thing will be having some kind of renewal reminder—the certificates expire after three months.

Still, all the signs are good that HTTPS is about to get a lot less painful.

Saturday, December 5th, 2015

Universal React ◆ 24 ways

I have no hands-on experience with React, but this tutorial by Jack Franklin looks like a great place to start. Before the tutorial begins he succinctly and clearly outlines the perfect architecture for building on the web today:

  • The user visits www.yoursite.com and the server executes your JavaScript to generate the HTML it needs to render the page.
  • In the background, the client-side JavaScript is executed and takes over the duty of rendering the page.
  • The next time a user clicks, rather than being sent to the server, the client-side app is in control.
  • If the user doesn’t have JavaScript enabled, each click on a link goes to the server and they get the server-rendered content again.

YES!!!

Y’know, I had a chance to chat briefly with Jack at the Edge conference in London and I congratulated him on the launch of a Go Cardless site that used exactly this technique. He told me that the decision to flip the switch and make it act as a single page app came right at the end of the project. I think that points to a crucial mindset that’s reiterated here:

Now we’ll build the React application entirely on the server, before adding the client-side JavaScript right at the end.

Native or Not? The Untapped Power of Web Apps | Viget

Following on from that last link, here’s an in-depth run-down of what you can do in mobile browsers today. I think a lot of people internalised “what you can’t do on the web” a while back—it’s well worth periodically revisiting the feature landscape to revise that ever-shrinking list.

Perhaps the biggest advantage the web has over native apps is how quickly users are able to engage. All that’s between the user and your content is one click.

Progressive enhancement needs better advocacy • Zetafleet

A rousing call to arms for progressive enhancement. I agree with the sentiment, but I’m less comfortable making assumptions about the reasons why developers don’t use progressive enhancement:

However, what’s actually happening is that “universal access to content” is being subversively replaced with “universal access for a limited subset of users that I care about”.

Honestly, I think that plenty of developers just aren’t thinking about it—especially if they’re relying on a particular tool or framework to save them time and effort (which is not a crime). So that’s why I agree with the title of this piece: let’s talk about this more; let’s make sure developers understand what they’re doing when they make JavaScript a requirement for basic functionality.

I particularly like the point in here about content blockers like NoScript:

In fact, it’s probably more likely that a user will try browsing the Web today without scripting than at any other time since the 1990s.

Thursday, December 3rd, 2015

WTF is Solid?- Solid

The new style guide and pattern library for Buzzfeed.

It all looks pretty reasonable on the surface but if you poke around in the CSS, you’ll find 1157 uses of !important. Yikes!

The whole point of having an agreed-upon codebase in a pattern library is so that developers need never reach for nuclear options like !important, so I’m afraid, for me, this is a demonstration of what not to do (in terms of CSS—the output of the HTML in the styleguide looks perfectly fine).

Solid uses immutable, atomic CSS classes…

CSS is “mutable”. By design. I don’t think we should be working against that.

Wednesday, December 2nd, 2015

Performance Calendar » Reducing Single Point of Failure using Service Workers

This is a nifty use of Service Workers—using a cache to mitigate unresponsive Content Delivery Networks.

The stuff in here about Promise.race is particularly useful for “lie-fi” scenarios: instead of thinking about the network connection in a binary way (either it’s available or it isn’t), considering the scenario of a crappy network connection seems more realistic.

The System of the World Wide Web

A fascinating ten-year old essay looking at the early days of the web and how it conquered FTP and Gopher.

And though glitz, politics, hard work, and competitors’ mistakes all played a role in the success of the web, there are also aspects of the architecture that ensured the web would catch on. I think the web won because of the URI.

URIs are everywhere, and what’s vaguely funny now is the idea that they’re something special. But they’re very special: URI management is the fundamental consideration behind the design of web sites, web applications, and web services. Tim Berners-Lee originally intended URIs to be invisible, but they’re too useful for that.

Strange Horizons Fiction: Let Us Now Praise Awesome Dinosaurs, by Leonard Richardson

A riotously great short story…

“It always comes down to that, doesn’t it?” said the voice in disgust, now circling around Tark. “Whether a successful Internet filmmaker can also be insane. Given that his quote-unquote insanity is also the fuel for his objectively measurable success as an entrepreneur. And whether it makes sense to judge him by the standards of talking dinosaurs from Mars.”

Tuesday, December 1st, 2015

Why Implementing Swipe Gestures Causes A Mobile Accessibility Issue

Jennison Asuncion outlines the problem with relying on a swipe gesture for interactions.

I would say that this could be expanded to just about any interaction: it’s always dangerous to rely on one specific gesture. It’s always better to either provide multiple ways of accomplishing a task, or to simply take a declarative approach, get out of the way, and let the user agent handle it.

Translating Gender: Ancillary Justice in Five Languages Alex Dally MacFarlane | Interfictions Online

A fascinating look into the challenges encountered translating Anne Leckie’s excellent Radchaai novels into Bulgarian, German, Hebrew, Japanese, and Hungarian.

What is clear in all of these responses is that by examining the notions of ‘neutral’ and ‘feminine’ in grammar and gender through the lens of translation, we reveal their complexity – and some of their possible futures in languages, in both literature and speech.