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
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
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:
The CSS function image-set is already available in WebKit. Read the
spec to learn more.
The new <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.