- Cycles of Invention and Commoditisation (Simon Wardley) — Explosions of industrial creativity rarely follow the invention or discovery of a technology but instead its commoditisation i.e. it wasn’t the discovery of electricity but Edison’s introduction of utility services for electricity that produced the creative boom that led to recorded music, modern movies, consumer electronics and even Silicon Valley. However, utility provision of electricity did more than just create a new world, it disrupted existing industries (both directly and through reduced barriers of entry), it also allowed for new practices and methods of working to emerge and even resulted in new economic forms – such as Henry Ford’s Fordism. This isn’t a one off pattern. The cycle of invention/commoditisation repeats throughout our industrial history, following a surprisingly consistent pathway. Understanding this pattern is critical to anticipating the changes emerging in our industry today – whether that’s the web, cloud computing or the future changes that 3D printing will bring. Simon explains the Business of the Internet in one blog post. Simon is king.
- Why Are Software Development Task Estimations Regularly Off By A Factor of 2 or 3? — never a truer word spoken in parable.
- Using the Full-Screen API in Browsers (Mozilla) — useful! The older I get, the more I like full-screen mode. I found myself wishing my email client had it, then someone pointed out that was called “mutt in a shell window”. Fair ’nuff.
pushState to the future: progressive enhancement using HTML5 pushState at Twitter
One speaker at Fluent 2013 whose talk was particularly well received was Todd Kloots of Twitter who spoke about HTML5’s pushState API and demonstrated how it was used in Twitter’s Web-based interface.
Some key parts of Todd’s talk include:
- The opportunity Twitter saw in pushState [at 01:45]
- What you had to do with dynamic URLs before pushState [at 02:46]
- A summary of the pushState API [at 06:10]
- Gotchas and browser support [at 07:58]
- How pushState sped up navigation on Twitter.com without re-architecting [at 12:15]
- What Twitter had to do server-side to make progressive enhancement work [at 19:11]
- Final thoughts [at 31:37]
- Q&A [at 32:15]
Toward Responsive Web Programming
Creating flexible expectations
“Expect the unexpected” has long been a maxim of web development. New browsers and devices arrive, technologies change, and things break. The lore of web development isn’t just the technology: it addresses the many challenges of dealing with customers who want to lock everything down.
Matt Griffin (and a lot of others) reminded me of these difficulties at Artifact, and his Client Relationships and the Multi-Device Web brings it home for designers.
Is there room for programmers to tell a similar story?
I don’t mean agile. Agile development is difficult enough to explain to clients, but applications that adapt to their circumstances are a separate set of complications. Iterating on adaptable behaviors may be more difficult than iterating on adaptable designs, but it opens new possibilities both for applications and for the evolution of the Web.
Responsive Web Design is (slowly) becoming the new baseline, giving designers a set of tools for building pages that (usually) provide the same functionality while adapting to different circumstances. Programmers sometimes provide different functionality to different users, but it’s more often about cases where users have different privileges than about different devices and contexts.
Adjusting how content displays is complex enough, but modifying application behavior to respond to different circumstances is more unusual. The goal of most web development has been to provide a single experience across a variety of devices, filling in gaps whenever possible to support uniformity. The history of “this page best viewed on my preferred browser” is mostly ugly. Polyfills, which I think have a bright future, emerged to create uniformity where browsers didn’t.
Browsers, though, now provide a huge shared context. Variations exist, of course, and cause headaches, but many HTML5 APIs and CSS3 features can work nicely as supplements to a broader site. Yes, you could build a web app around WebRTC and Media Capture and Streams, and it would only run on Firefox and Chrome right now. But you could also use WebRTC to help users talk about content that’s visible across browsers, and only the users on Firefox and Chrome would have the extra video option. The Web Audio API is also a good candidate for this, as might be some graphics features.
This is harder, of course, with things like WebSockets that provide basic functionality. For those cases, polyfills seem like a better option. Something that seems as complicated and foundational as IndexedDB could be made optional, though, by switching whether data is stored locally or remotely (or both).
HTML5 and CSS3 have re-awakened Web development. I’m hoping that we can develop new practices that let us take advantage of these tools without having to wait for them to work everywhere. In the long run, I hope that will create a more active testing and development process to give browser vendors feedback earlier—but getting there will require changing the expectations of our users and customers as well.
OSCON 2013 Speaker Series
Scoping Code to the Data
Every website has its own navigation structure, layout, and audience, but when you strip away these unique attributes of websites, you are left with data– chats, emails, photos– that can be treated uniformly across all websites. Operations on these data like encryption and signing, can be performed with indifference to their context and their contents.
Privly uses data indifference to create the notion of “Injectable Applications,” which are full web applications that are injected into the context of other web application. Since these applications are scoped to data and not layout, their properties are simplified and usable across the web.
In short, if you scope an application to the data, then the cryptography can be viewed in potentially untrusted contexts.
Pre-Distributing Client Code
Privly creates an ecosystem of apps with known properties because it allows us to reason about security uniformly across the web. However, security is only as strong as the weakest attack point, which is why great care must be taken to appropriately distribute these applications. By packaging a set of applications for integration into browser extensions and mobile apps, the code is not re-loaded from a remote source every time the browser loads a new page.
Requiring users to install an extension before they can view content is likely an impediment for any security system looking to gain users. However, since Privly uses hyperlinks to reference the content, it provides opportunity for a hosted fallback application. Depending on the nature of the injectable application, clicking the hyperlink could either present the same application as normally delivered by the extension, or present a prompt to install the appropriate browser extension.
Fault lines make conversation difficult
Stop standardizing HTML
It's time for developers to create their own vocabularies
When HTML first appeared, it offered a coherent if limited vocabulary for sharing content on the newly created World Wide Web. Today, after HTML has handed off most of its actual work to other specifications, it’s time to stop worrying about this central core and let developers choose their own markup vocabularies and processing.
When the W3C first formed, it formed around HTML, the core standard of content on the Web, defining the structure, appearance, and behavior of content. Over the next few years, however, it became clear that HTML was doing too much, and the W3C and other groups refactored appearance, behavior, and many semantics into separate specifications:
Cascading Style Sheets (CSS) took responsibility for presentation and layout.
WAI-ARIA took responsibility for accessibility semantics, ensuring that content remained available to a broad audience even if developers pushed the current boundaries of markup.
Four short links: 1 February 2012
Four short links: 4 October 2011
Singaporean Incubator, Oracle NoSQL, Should Facebook have a Browser?, and GitHub has Competition
- jfdi.asia — Singaporean version of TechStars, with 100-day program (“the bootcamp”) Jan-Apr 2012. Startups from anywhere in the world can apply, and will want to because Singapore is the gateway to Asia. They’ll also have mentors from around the world.
- Oracle NoSQLdb — Oracle want to sell you a distributed key-value store. It’s called “Oracle NoSQL” (as opposed to PostgreSQL, which is SQL No-Oracle). (via Edd Dumbill)
- Facebook Browser — interesting thoughts about why the browser might be a good play for Facebook. I’m not so sure: browsers don’t lend themselves to small teams, and search advertising doesn’t feel like a good fit with Facebook’s existing work. Still, making me grumpy again to see browsers become weapons again.
- Bitbucket — a competitor to Github, from the folks behind the widely-respected Jira and Confluence tools. I’m a little puzzled, to be honest: Github doesn’t seem to have weak spots (the way, for example, that Sourceforge did).
Four short links: 22 September 2011
Feedback, Open Source Marketing, Programming in the Browser, and Twitter's Open Source Realtime Engine
- Implicit and Explicit Feedback — for preferences and recommendations, implicit signals (what people clicked on and actually listened to) turn out to be strongly correlated with what they would say if you asked. (via Greg Linden)
- Pivoting to Monetize Mobile Hyperlocal Social Gamification by Going Viral — Schuyler Erle’s stellar talk at the open source geospatial tools conference. Video, may cause your sides to ache.
- Twitter Storm (GitHub) — distributed realtime computation system, intended for realtime what Hadoop is to batch processing. Interesting because you improve most reporting and control systems when you move them closer to real-time. Eclipse-licensed open source.
If you're a content designer, the web browser will be your canvas
Peter Brantley on designing and thinking browser first.
The Internet Archive's Peter Brantley discusses the influence of web browsers on content design and the challenges of complex media.
Four short links: 22 August 2011
Cooked Brands, HTML Bootstrap, Browser Security Headers, and Swarming Robots
- Cities in Fact and Fiction: An Interview with William Gibson (Scientific American) — Paris, as much as I love Paris, feels to me as though it’s long since been “cooked.” Its brand consists of what it is, and that can be embellished but not changed. A lack of availability of inexpensive shop-rentals is one very easily read warning sign of overcooking. I wish Manhattan condo towers could be required to have street frontage consisting of capsule micro-shops. The affordable retail slots would guarantee the rich folks upstairs interesting things to buy, interesting services, interesting food and drink, and constant market-driven turnover of same, while keeping the streetscape vital and allowing the city to do so many of the things cities do best. London, after the Olympic redo, will have fewer affordable retail slots, I imagine. (via Keith Bolland)
- Bootstrap — HTML toolkit from Twitter, includes base CSS and HTML for typography, forms, buttons, tables, grids, navigation, and more. Open sourced (Apache v2 license).
- Extra Headers for Browser Security — I hadn’t realized there were all these new headers to avoid XSS and other attacks. Can you recommend a good introduction to these new headers? (via Nelson Minar)
- Swarmanoid — award-winning robotics demo of heterogeneous, dynamically connected, small autonomous robots that provide services to each other to accomplish a larger goal. (via Mike Yalden)