"Web Tools" entries
Do one thing…
I don't want barely distinguishable tools that are mediocre at everything; I want tools that do one thing and do it well.
I’ve been lamenting the demise of the Unix philosophy: tools should do one thing, and do it well. The ability to connect many small tools is better than having a single tool that does everything poorly.
That philosophy was great, but hasn’t survived into the Web age. Unfortunately, nothing better has come along to replace it. Instead, we have “convergence”: a lot of tools converging on doing all the same things poorly.
The poster child for this blight is Evernote. I started using Evernote because it did an excellent job of solving one problem. I’d take notes at a conference or a meeting, or add someone to my phone list, and have to distribute those files by hand from my laptop to my desktop, to my tablets, to my phone, and to any and all other machines that I might use.
But as time has progressed, Evernote has added many other features. Some I might have a use for, but they’re implemented poorly; others I’d rather not have, thank you. I’ve tried sharing Evernote notes with other users: they did a good job of convincing me not to use them. Photos in documents? I really don’t care. When I’m taking notes at a conference, the last thing I’m thinking about is selfies with the speakers. Discussions? No, please no. There are TOO MANY poorly implemented chat services out there. We can discuss my shared note in email. Though, given that it’s a note, not a document, I probably don’t want to share anyway. If I wanted a document, even a simple one, I’d use a tool that was really good at preparing documents. Taking notes and writing aren’t the same, even though they may seem similar. Nor do I want to save my email in Evernote; I’ve never seen, and never expect to see, an email client that didn’t do a perfectly fine job of saving email. Clippings? Maybe. I’ve never particularly wanted to do that; Pinboard, which has stuck to the “do one thing well” philosophy, does a better job of saving links. Read more…
Proposing CSS input modality
:focus'ing on users.
Editor’s note: The author would like to acknowledge her co-author, Brian Kardell, who contributed many insights to the ideas presented here, along with a substantial number of the words.
Web developers and web standards authors alike strive to live up to the promise of “universality” — the idea that the web should be available to all. This concept drives many innovations in web technology, as well as being fundamentally built in to the philosophy of the open standards on which the web is based.
In order to achieve this, we frequently find that having some carefully chosen information about how the user intends to view the content (a concept we’ll refer to in this article as “user context”) allows web developers to create more flexible and useful user experiences. In this post, we’ll lay out a case that it’s time to expand our view of user context to include the concept of modality (how the user is interacting with the page), but before we flesh that out, let’s take a look at “user context”.
JavaScript shares its ubiquity
WebAssembly changes the rules of the JavaScript game.
I’ve never seen a technology lay down its primary advantage and prepare to hand over its ubiquity. I’m proud of JavaScript for doing this, and I’m sure that in the long run this will be good for the Web, but in the meantime I’m wondering where WebAssembly will take us.
Brendan Eich’s announcement of the effort makes clear that this builds on the earlier asm.js (and Google’s similar PNaCl), a highly efficient JavaScript subset that compilers of other languages could target. Eich enjoyed using Unreal Engine for demos of the speed asm.js could provide, but compiling to JavaScript, even weird JavaScript, still needed to go through a JavaScript parser. (Other approaches compiled to more comprehensible but less optimized JavaScript.)
WebAssembly – wasm – skips that final step, producing a binary format, technically a compressed AST encoding. Unless you’re going to be building compilers, you can compare wasm to a bytecode system. There is a text format for debugging, but the binary emphasis yields substantial extra speed as it skips parsing and minimizes decompression.
Read more…
Add depth to your project with practical web audio
Enhance the user experience with the thoughtful use of sound.
There is little debate that Web Audio is cool. Take for example Stepkit by Brent Jackson (embedded below).
It’s definitely a fun toy to play with, but most of us probably couldn’t think of how this might be relevant to our jobs. When I presented 8-bit game music with the Web Audio API at last year’s Fluent Conference, I readily admitted that it was intended to be purely fun rather than practical.
Recently I explored the idea of adding audio to web apps, but I think the big problem isn’t that web developers were unsure how to add audio to their app, but that they don’t think they should add audio to web apps. In this article, I’d like to make the case that you should be considering audio when designing your web application user interface.
Signals from the O’Reilly Fluent Conference 2015
From user-centric performance to cognitive resources, here are key insights from the O’Reilly Fluent Conference.
Experts from across the Web development world came together in San Francisco this week for the O’Reilly Fluent Conference 2015. Below we’ve assembled notable keynotes, interviews, and insights from the event.
User-centric performance metrics
Paul Irish, PM at Google Chrome, says it’s important to look at performance the right way. Rather than ask “what is slow,” instead focus on “what does the user feel?” Irish outlines four phases of interaction and what users expect to experience. “Focus on the user,” he says, “and all else will follow.”
The magic design sauce: curiosity and serendipity
Khoi Vinh on "How They Got There," the cards interaction model, and designers as founders.
I recently sat down with Khoi Vinh, vice president of user experience at Wildcard and co-founder of Kidpost. Previously, Vinh was co-founder and CEO of Mixel (acquired by Etsy, Inc.), design director of The New York Times Online, and co-founder of the design studio Behavior, LLC. Our conversation included a discussion of career paths; the much talked about new interaction model, cards; and advice for design entrepreneurs.
Curiosity serves designers well
Vinh and I discussed the ever-evolving role of designers. He recently self-published How They Got There, a book of interviews with interaction designers who describe their career paths and offer advice and insight. Vinh explained:
“How They Got There is kind of like the book I wish I could have read when I was just starting out in my career. The central thesis is that very few careers are truly planned out, A to B, to C, to Z, and it’s usually a lot of stuff that just happens by circumstance or blind luck, or through someone who knows someone.
“As I became more and more aware of that in my career, I started to find those stories really interesting, really revealing, because they say so much about the character of people who achieve notoriety in their careers; the circumstances that led them to where they are can be fascinating. In a lot of instances, the things that get these people onto these paths are very, very minor events or minor coincidences. … There’s a serendipity, but I think, one thing that comes out when you read these stories is what serves these designers really well is curiosity, a willingness to be available to opportunities, so to speak. They go with the flow. They let one thing turn into another through their ability to acclimate themselves to various situations.
“What’s that old saying from Branch Rickey — “luck is the residue of design”? These careers are somewhat serendipitous, but they are really the result of folks who are very conscientious about making the most of whatever situation they had and working really hard and applying themselves, and looking at the world around them with great curiosity and being really willing to study what it takes to get to the next level.”
Pandora’s box model
An experiment in containing stylesheet complexity.
This post is part of my personal notes about the benefits currently specified in Shadow DOM, but contentious and held up in committee. We’ll work it out in standards, I’m sure — but given the number of things Shadow DOM was addressing, it may still be several years until we have solutions widely implemented and deployed that solve all of them. This has me doing a lot of thought exercises about what can be done in the meantime. The following reflects one such exercise: specifically, what would it mean to solve just the styling end of this on its own. Warning: it may be mildly crazy.
The Pandora Box
CSS works really well if you can follow good patterns and have nice rich markup. It lets you define broad rules and inherit and override selectively, and if used well it cleanly decouples a separation of concerns — it’s pretty elegant actually.
On the other hand, in the real world, things are often not that simple: until pretty recently, HTML wasn’t especially expressive natively, so we worked around it — many times on our own by adding classes like “article.” But, there wasn’t a standard. Likewise, our ideas about the patterns we should follow or best practices continues to change as we gain new powers or spend more time with the technology. Of course, there are a vast number of cases where you’ll just go and upgrade your philosophy and be the better for it, but there are a number of times when this just isn’t an option. This is sometimes referred to in standards circles, less colorfully, as “the composition problem.”
When it comes to these sorts of cases, quality and philosophy are inevitably mixed and not entirely in the control of any one team. In these sorts of cases, CSS selectors are kind of like live hand grenades, it’s just way too easy to do damage you didn’t intend to do because it requires a level of coordination of approach which is, for business reasons, highly impractical. And so you try really hard to analyze the problem, get the right select/cascade/descend/inherit/specificity, pull the pin, lob it into the pages and… hope. Frequently, all hell breaks loose. The more you mix it up, the harder it gets to reason about and the more our stylesheets explode in complexity. You’ve opened the proverbial Pandora’s Box.
When can you learn JavaScript?
Khan Academy explores how far learners can get at different ages.
I picked up a brief guide to programming in 6th grade. There, on page 1, was A = A + 1. I knew that wasn’t possible, so I put it down, and came back to programming in 7th grade.
Khan Academy is having better luck with young students, but learning to program is kind of like learning to drive: the prerequisites aren’t obvious, but they’re helpful and often come later. At Fluent 2014, Pamela Fox explored the data Khan Academy has collected on learner age, and what it might mean for curricula going forward.
In her keynote, Fox explored:
- What the world might look like if JavaScript were part of the curriculum as early as possible. (1:42)
- Developing a sense of how kids respond to fairly easy challenges with Khan Academy’s participant data. (3:24)
- What in the first programming challenge might keep people from succeeding? (4:37)
- How different is the data for a logic challenge? At what age does completion level off? (6:16)
- What might JavaScript skills enable in a high school curriculum? (8:24)
4 things that happened in PHP while you weren’t looking
PHP gains some modern features as it heads to a 7.0 release.
I think most programmers have come into contact with PHP at some point, editing a WordPress plugin or getting PHPMyAdmin running on a server. We think we know what PHP is, but the language has been very quietly growing up over the last few years, so here’s some headlines that you might have missed.
Upgrading is easy
PHP has always had frequent patch releases, but now its minor releases are approximately annual. This means that the differences between the versions, and therefore the painful experiences of an upgrade, are much reduced. It also means that there’s probably a relatively new version available at the time when a distro is rolling its new release.
PHP has also developed much greater consideration for its users when upgrading. From PHP 5.3 there is an error_reporting level, E_DEPRECATED, which will log any features you are using which will be removed in the next version of PHP. Nothing gets removed in a minor version that wasn’t already planned to be removed before the release of the previous minor version — so fewer surprises for those of us in userland.
Power of the platforms
Uncertainty is a feature, not a bug.
After decades of work on programming, we finally got a development environment with massive reach and tremendous power. Somehow, though, the web isn’t centered on a comprehensive programming environment. The web succeeded with a (severely) lowest-common denominator, specification-driven approach that let it grow with time, technology, and multiple communities, across multiple platforms.
Almost two decades ago, I was all excited about Java. Write applets once, run anywhere, with libraries to make sure it all came out the same wherever anywhere might be. Java is still a powerhouse, but it all worked out differently than I expected. Even in Java’s early years, before the Java news was filled with security bulletins, applets felt like a strange mix with their surrounding web pages. Creating an applet demanded programmers to build every detail. Even with Java’s ever-improving libraries, creating a Java applet that did much was an intense experience focused on programming.
Java wasn’t the only comprehensive way to build web apps, of course. Flash demanded programming, but its values always incorporated design, action, and well, flash, in ways that meshed well with the way people built sites. Flash kept growing and growing before its ecosystem took a fatal hit from the iPhone as HTML5 offered replacements for some of its key strengths. I mostly notice Flash these days because it asks me to update it regularly and because pages tell me when it’s crashed.
Compared to either of those rich environments, web technology is a tangled mess. The early web was functional but unstyled, with no behavior beyond navigating among pages. That? That would dominate client-side computing? Read more…