Imagine this: you start conducting as if you were in front of a great orchestra, and music fades in out of thin air, matching your tempo and time signature. Your nuanced gestures can indicate changes in intensity, and of course affect the speed of the piece. You'd first need to learn some basic conducting patterns, like these:
I wrote a short book about the Web Audio API. The book is meant as an introduction to the web audio API, as well as some audio basics for web developers with little audio experience. It is available for free on Chimera, a web-based book viewer, which presents a nicely laid out page and lets you leave per-paragraph comments. The online version also includes inline samples from webaudioapi.com. If you don't like reading on the web, you can also buy a physical copy or an ebook from O'Reilly.
↪
I've been thinking about this for a while, but the recent sunset announcement of Google Reader made me revisit this topic. Google Reader isn't the only thing that's dead. RSS (aka. Really Simple Syndication) has long been proclaimed dead as well. In fact most people never even knew what RSS was. That said, it was a very useful tool for me and many others that like to stay up-to-date in their areas of interest. Increasingly, I've been getting my dose of news through social networks. However, social networks contain a lot of noise that I care little for. I want to rebuild the RSS spirit using modern social networks. This post describes one possible approach, which I refer to as Really Simple Social Syndication (RSSS).
↪
Largely because of the plummeting price and thickness of touch screens, these devices are increasingly ubiquitous. One of the latest trends is touch screen laptops, spearheaded by Surface devices and the recently announced Chromebook Pixel. In this post I'll dive into some experiements around this new form factor. The main goal is to try to convince myself that this form factor makes sense for reasons other than economic ones.
In exploring the interaction design angle of these new devices, I came across a couple of what I think are a couple of interesting ideas that I'd like to share with you: responsive input and simultaneous interactions using both mouse/trackpad and touchscreen. I wrote some demos that illustrate these ideas. A touchscreen laptop is required for these demos to work properly.
↪
All good things must come to an end. VPS hosting paid for by my former university is no exception! Ever since the University of Madeira-provided credit card paying for the account expired, I began wondering whether it's worth paying for a VPS that I hardly use. Combined with two consecutive 10-minute stretches of downtime last week, I had my answer.
I run this blog, my mother's site and a handful of mini-sites, all of which are inherentily static content. Today, I moved them all away from my VPS completely. I migrated the relatively complex sites to the lightning engine, and updated the engine with a couple of nice features: fixed content links in list pages and feeds, and support for publishing to S3.
↪
Many new devices come with unexpected connectivity - often a WiFi connection that enables them to connect to a hotspot and the larger internet. Nest, a smart thermostat, was one of the first commercial products to do this. Many more indie projects are following suit, with an explosion of kickstarters like this teleoperated light, connected scale or this general purpose connected sensor. The idea of an Internet of Things, in which every appliance and object is somehow connected, has long been popular in academic circles, and this time around it feels like we're actually close.
If we think of these physical devices/appliances as web services with APIs, we can mash them up just like we did in the early days of the web, creating applications that are more useful than the sum of their parts. In this post I argue for using the web as the medium to tie everything together, describe a simple architecture for building networked physical devices and build a web lamp controlled by an arduino.
↪
These days, I write a lot more code, and my projects have increased in complexity. Often, a single application brings many kinds of data sources and bleeding edge web features together. On the other hand, most of what I build are prototypes, which need to be churned out quickly, work reliably in demos, and look/feel good.
MVC frameworks help write UI code much more quickly, but there are drawbacks too: there are too many to choose from, they don't interoperate with one another, and if you want to release parts of your code to the open source community, only those developers that use the same framework will benefit. The solution is to create a clear separation between core application logic and MVC UI code. This way you can reuse a lot of code and reduce switching costs.
↪
When developing in a particular environment, say Android or Cocoa, we are subconsciously aware that the APIs are essentially fixed and beyond our control. There is no effective mechanism to go and tell Apple that some method is poorly named, or tell the Android team how much you wish the Audio APIs were nicer to use.
The web, however, is built by many different companies and individuals, giving consumers of the platform (web developers) a unique chance to also become contributors to its evolution. Rather than griping about how broken something on the web is, remember that you can play a part in fixing it!
↪
My article on high DPI images went up on HTML5Rocks this morning. In it, I outline techniques for delivering the best quality images as quickly and efficiently as possible. I'm most excited about the new platform features that help developers reach this goal:
image-set is already available in WebKit. Read the
spec to learn more.<img> attribute srcset isn't implemented anywhere yet, but
is available via polyfill. Read the spec
to learn more.These new features are very similar to one another, but have subtly
different syntax. See this thread to www-style and whatwg
for an deep dive into these differences and an attempt to fix some
problems in the spec.
I gave a talk on building fast UIs for the cross-device web at Google I/O. In addition to discussing some problems and best practices to work around them, I mentioned device.js, pointer.js and other projects I've written about. The video and slides are available.