Web Platform Posts
Will WebRTC disrupt or be disrupted?
WebRTC promises to deliver computer to computer communications with minimal reliance on central servers to manage the conversation. Peer-to-peer systems promise smoother exchanges without the tremendous scale challenges of running video, for example, through central points.
The WebRTC Conference and Expo was unlike any other web conference I’ve attended. Though technologies in development are common at tech conferences, I can’t remember attending a show that was focused on a technology whose future had these levels of promise and uncertainty. Also, despite the name, WebRTC doesn’t resemble much of the Web despite being built into some browsers (more hopefully coming soon) and supporting HTTP(S) proxying.
The power of a technology now taken for granted
A friend wanted to show me a great new thing in 1993, this crazy HTML browser called Cello. He knew I was working on hypertext and this seemed like just the thing for it! Sadly, my time in HyperCard and an unfortunate encounter with the HyTime specifications meant that I bounced off of it, because markup couldn’t possibly work.
I was, of course, very very wrong.
Markup with some brilliantly minimal hypertext options was about to launch the World Wide Web. The toolset was approachable, easy to apply to many kinds of information, and laid the foundation for greater things to come.
Flexible dreams for a responsive world
Last week’s Artifact Conference focused on the challenges of designing for multiple devices simultaneously. One frequent suggestions on stage and off was rough sketching, on screen or on paper, but it’s tricky to get there. The problem is easiest to see for designers on the Web, but it applies to a wide range of digital projects.
What does a sketch of a page look like when that page morphs itself to fit differently in different containers? What does a sketch of a site look like when that site may present different content (and different types of content) to different users based on their past encounters with the site? What does a sketch of a program look like when it handles many different kinds of input in many different kinds of circumstances?
One answer – the classic answer for those of us walking around with notebooks full of dot grid paper – is multiple sketches. Breakpoints become critical as “it looks like this when…” becomes a mantra.
At the same time, though, I rarely feel comfortable creating site (or code) details on paper when I know the result will be electronic. I spent way too much time explaining how paper and screens are different to saddened designers to want to inflict that pain on my own projects. My notebooks are largely filled with words, with occasional pictures.
A truly accessible website is both accessible and usable
Every time I give a talk about making accessible websites, I get the following question:
“What checklist do you use to make sure a site is accessible?”
My response always surprises them:
“I don’t use a list.”
Why not? There are so many lists out there that I could be using! Practically every US government agency has a checklist published on their site, and several non-government sites offer checklists of their own. With so many free resources, why do I ignore checklists?
Can version control manage content?
Web designers? Git? Github? Aren’t those for programmers? At Artifact, Christopher Schmitt showed designers how much their peers are already doing with Github, and what more they can do. Github (and the underlying Git toolset) changes the way that all kinds of people work together.
Sharing with Git
As amazing as Linux may be, I keep thinking that Git may prove to be Linus Torvalds’ most important contribution to computing. Most people think of it, if they think of it at all, as a tool for managing source code. It can do far more, though, providing a drastically different (and I think better) set of tools for managing distributed projects, especially those that use text.
Git tackles an unwieldy problem, managing the loosely structured documents that humans produce. Text files are incredibly flexible, letting us store everything from random notes to code of all kinds to tightly structured data. As awesome as text files are—readable, searchable, relatively easy to process—they tend to become a mess when there’s a big pile of them.
The standard for mathematical content in publishing work flows, technical writing, and math software
20 years into the web, math and science are still second class citizens on the web. While MathML is part of HTML 5, its adoption has seen ups and downs but if you look closely you can see there is more light than shadow and a great opportunity to revolutionize educational, scientific and technical communication.
Somebody once compared the first 20 years of the web to the first 100 years of the printing press. It has become my favorite perspective when thinking about web standards, the web platform and in particular browser development. 100 years after Gutenberg the novel had yet to be invented, typesetting quality was crude at best and the main products were illegally copied pamphlets. Still, the printing press had revolutionized communication and enabled social change on a massive scale.
In the near future, all our current web technology will look like Gutenberg’s original press sitting next to an offset digital printing machine.
With faster and faster release cycles it is sometimes hard to keep in mind what is important in the long run—enabling and revolutionizing human communication.
Since I joined the MathJax team in 2012, I have gained many new perspectives on MathML, the web standard for display of mathematical content, and its role in making scientific content a first class citizen on the web. But it is rather useless to talk about MathML’s potential without knowing about the state of MathML on the web. So let’s tackle that in this post.
Can explanation contribute to technology creation?
“If you’re explaining, you’re losing.”
That gem of political wisdom has always been hard for me to take, as, after all, I make my living at explaining technology. I don’t feel like I’m losing. And yet…
It rings true. It’s not that programs and devices shouldn’t need documentation, but rather that documentation is an opportunity to find out just how complex a tool is. The problem is less that documentation writers are losing when they’re explaining, and more that creators of software and devices are losing when they have to settle for “fix in documentation.”
I was delighted last week to hear from Doug Schepers of webplatform.org that they want to “tighten the feedback loop between specification and documentation to make the specifications better.” Documentation means that someone has read and attempted to explain the specification to a broader audience, and the broader audience can then try things out and add their own comments. Writing documentation with that as an explicit goal is a much happier approach than the usual perils of documentation writers, trapped explaining unfixable tools whose creators apparently never gave much thought to explaining them.
It’s not just WebPlatform.org. I’ve praised the Elixir community for similar willingness to listen when people writing documentation (internal or external) report difficulties. When something is hard to explain, there’s usually some elegance missing. Developers writing their own documentation sometimes find it, but it can be easier to see the seams when you aren’t the one creating them.
The W3C sells out users without seeming to get anything in return
I had a hard time finding anything to like in Tim Berners-Lee’s meager excuse for the W3C’s new focus on digital rights management (DRM). However, the piece that keeps me shaking my head and wondering is a question he asks but doesn’t answer:
If we, the programmers who design and build Web systems, are going to consider something which could be very onerous in many ways, what can we ask in return?
Yes. What should we ask in return? And what should we expect to get? The W3C appears to have surrendered (or given?) its imprimatur to this work without asking for, well, anything in return. “Considerations to be discussed later” is rarely a powerful diplomatic pose.
Intriguing reviewers and attendees
Audience: Who are they? What do they want?
My first suggestion to anyone proposing a talk (or a book, or even a blog post) is to focus on audience. Who is going to be interested in what you want to discuss? Will they be at that event? What should they know before they get there? How can you convince them that it’s worth their time to join your conversation? Even for lectures and books, thinking of it as a conversation helps to focus planning.
Testing, Python 3, and Dealing with Technical Debt
Nathan Yergler (@nyergler), Principal Engineer at Eventbrite, and I had a chance to talk Django at OSCON 2013. We talk about why Django is the go-to choice for Pythonistas and about the growing technical debt that each programmer has to deal with on Python projects and beyond.
Key highlights include:
- Django is mature and feature complete amidst many Python frameworks [Discussed at 0:15]
- Testing in Django leads to straightforward code that the next programmer can read as well as you can [Discussed at 1:02]
- Dare we discuss Django’s weaknesses like: Is Django too monolithic? [Discussed at 2:43]
- Django at long last supports Python 3! Check out Django 1.5 [Discussed at 4:06]
- Dealing with technical debt while programming [Discussed at 5:36]
You can view the full interview here: