Archive for category Web Ninja Interview

Web Ninja Interview: Marcin Wichary — Creator of Google Pacman Logo, HTML5 Slide Deck, and More

You know what time it is.... it's time for another Web Ninja Interview! Huzzah! The Web Ninja Interview series focuses on people doing amazing and interesting work using JavaScript, CSS, HTML, SVG, WebGL, and more.

One of the goals behind the Web Ninja Interview series is to talk with the web gurus behind many amazing web sites and products that don't directly blog or speak at conferences as much.

Today we talk with Marcin Wichary. I'm a huge fan of Marcin's work. He was behind the animated and playable Google Pac-Man logo; created the initial HTML5 fancy (shmancy) slide deck that is now an open source project; and helped with Google Instant. He also has a geek love of computer history; just as artists study the masters who came before them computer scientists should know their history. Let's begin.

Brad Neuberg: Tell us a bit about yourself, where you're from, your background, interests, and some projects you have worked on (don't be humble!)

Marcin Wichary: I grew up in Poland. I have a master’s in computer science, and a doctorate in human-computer interaction. I created my first HTML tag in… 1995? It was probably a <P>, but that’s just a guess.

I am proud of GUIdebook, which is (was) an online gallery of graphical user interfaces. Alas, I have not had time to update it since 2006.

At Google, which I joined in 2005 as a user experience designer, I helped with various internal tools and a number of search-related initiatives, including search options, real-time search, and most recently Google Instant.

Brad Neuberg: You built the HTML5 Pac-Man Google Doodle. What's the story behind that? Any technical things you ran into that surprised you?

Marcin Wichary: One of the Google illustrators and a good friend of mine Ryan Germick had an idea to create a first playable doodle for Pac-Man’s birthday. Since I’ve been exposed to arcade games a lot in my childhood, he reached out to me; I built a very early prototype the same night.

The biggest surprise was how much thought went into Pac-Man’s details. You’d think it’s a very simple game, but there’s so much nuance and polish in every aspect. I had to recreate all of it from scratch, and since I personally believe that it’s the details that make or break the experience, it was inspiring to see someone thinking about all that already 30 years ago.

Technically, I was sad to witness HTML5 audio not being quite ready to be used in games. (There’s actually very little HTML5 in the Pac-Man doodle.) And the infamous background caching bug in IE6 bit me so bad that no known solutions worked; I had to introduce a separate code path that didn’t use CSS backgrounds, just regular images cropped by parent divs.

Brad Neuberg: You created the amazing HTML5/CSS3 Slide Deck over on API Rocks. What prompted you to create this initially? What are some of the technical things you used to create this?

Marcin Wichary: A colleague suggested I give a talk to my team about HTML5. I agreed, thinking “I’ll just find a nice list of what’s there in HTML5 and make a presentation out of it.” Turned out, there was no such list, so I had to poke around and construct one myself. It was actually an interesting process. I called it “archeology of the future” – I was looking at Web technologies that’ll ultimately span years 2000 to 2020, trying to figure out how they all fit together right now, in 2010.

In terms of choosing a medium, I’ve been making my slide decks in HTML for about a decade now. Before Keynote, it was the only way for presentations to look exactly the way I wanted (have to give credit to IE6 here for its gorgeous full-screen mode), so I felt fairly comfortable following that – but utilizing newer technologies this time around. I’ve also always enjoyed teaching by example, hence the addition of sliders that allowed direct manipulation of CSS.

I am a very hands-on, low-level kind of guy. I created my first website in FrontPage, but since then I’ve been coding everything by hand. These days it means TextMate and Safari’s excellent Web inspector. I also make a point not to reuse much of what I do, but write the same things over and over again. This allows me to learn and adapt to changing technologies. (For example, I wrote two new presentation engines since the said HTML5 presentation.)

Brad Neuberg: What is a clever hack, trick, or elegant turn of code you've discovered or created while working with JavaScript, HTML, CSS, etc. that you are particularly proud of? Give good details, and don't be afraid to be technical :)

Marcin Wichary: Get an iframe, make it tiny using CSS3 translate/scale, cover with a transparent div to intercept events, and voilà – you have a nice site thumbnail without having to create an image, upload it and worry about them getting out of sync. Of course, it also comes with terrible latency, so there you go.

color: transparent and text-shadow with 0px offset means blurry text. How is that not awesome? (Not that I can think of a use for it.)

Not sure if those are particularly clever or useful – I have an attention span of a <marquee> tag and if I do anything innovative I’m usually the first to miss it – but it’s exciting to discover new uses for things that, in and of themselves, are so brand new.

Brad Neuberg: What are some of the things you are hacking on these days (that you can talk about)?

Marcin Wichary: My main project for the past several months was Google Instant, and we just launched it, so right now I’m looking around and learning about projects. I’ll be doing some internal HTML5 advocacy, teaching and workshops – hopefully some of that will surface on HTML5rocks.com.

Brad Neuberg: Tell us about a hobby, interest, or something in your background that most people wouldn't expect or know about.

Marcin Wichary: One thing that I feel keeps me in balance is collecting (and slowly going through) books about computing history. I probably have some 800 of them by now. My apartment filled with obsolete technology talking about another obsolete technology is a good counterpoint to living in the future at work. And, as always, the best technology stories are those about people – this keeps me focused on our users in the present as well.

Brad Neuberg: Where do you see HTML5, CSS3, SVG, etc. (i.e. the new stuff on the web) going in the next year? How about the next 3 years?

Marcin Wichary: They say nothing ages faster than today’s idea of tomorrow, and I’ve never been a good futurist. :) So I’ll give you my wish list instead.

I would love to see more attention paid to nuances of typography. Computers took most of them away and sure, we reclaimed some back, but not yet very many. And lord, please, layout! We’ve all been using JavaScript crutches to do that for so long that it’s not even funny anymore – indeed, in a lot of my projects the first listener I add is “onresize.”

There’s also a number of avenues in JavaScript to build pretty crappy UIs. alert() and its brethren is the only way to reliably catch the user’s attention. Oftentimes it’s like pillow talk using a bullhorn. :hover allows only for the most rudimentary and unforgiving mouseover actions. We need better defaults for stuff like that.

Brad Neuberg: For folks that want to do the kinds of cutting edge things you've been doing and have done, what advice or resources would you give them?

Marcin Wichary: One of the first popular home video game consoles was 1977’s Atari VCS 2600. It was an incredibly simple piece of hardware. It didn’t even have video memory – you literally had to construct pixels just moments before they were handed to the electron gun. It was designed for very specific, trivial games: two players, some bullets and a very sparse background. All the launch games looked like that.

But within five years, companies figured out how to make games like Pitfall, which were much, much cooler and more sophisticated. Here’s the kicker: if you were to take those games, go back in time, and show them even to the *creators* of VCS, I bet they would tell you “Naah, it’s impossible to do that. The hardware we just put together won’t ever be able to handle this.” Likewise, if you were to take Google Maps or iPhone Web apps, take your deLorean to 1991 and show them to Tim Berners-Lee, he’d be all like “get the hell out of here.”

What I’m trying to say is: Assume nothing is impossible. It’s actually easier this way. So many times people asked me if something is doable in HTML, and my initial instinct was to say “no.” But you look around, ask around, *think* around, and there’s always a way.

Something else that took me a while to internalize: you have to accept that with Web development, anything that’s worth anything will be a hack. Not just prototyping; production code as well. That’s hard to swallow when you’re used to proper, clean, sterile programming. I’d go as far as to say if you’re working on something and you never think “what I did here is terrible; hopefully one day there will be a nicer, better way to do it,” you’ve already fallen behind.

And eventually that battery of hacks in your sleeve might make you stand above. My crude and jaded metaphor of Web development is button mashing when playing video games. Everyone hates button mashers, but working with cutting-edge Web really is flying blind a lot of the time – you’re trying out all sorts of things that sometimes don’t logically make a lot of sense. But they somehow work. If you get used to that mentality and you get familiar with those hacks, you will train your instincts to know which buttons to mash first, and give yourself more buttons as well.

Lastly, if you ask a “what if?” question and leave it unanswered, you should be ashamed. :)

Brad Neuberg: Thanks Marcin!

What kinds of questions do you have for Marcin? Ask them below!

Web Ninja Interview: Mr. Doob

As part of our Doob-a-thon today, we have a Web Ninja Interview with Mr. Doob. The Web Ninja Interview series focuses on people doing amazing and interesting work using JavaScript, CSS, HTML, SVG, WebGL, and more.

Mr. Doob has delighted us with many awesome visualization and demos, including the recent Wilderness Downtown project. He is one of a crop of JS wizards that are taking advantage of new tools like Canvas, CSS3, SVG, and WebGL. Let's get started.

Brad Neuberg: First things first, the most important question is where the name Mr. Doob comes from?

Mr. Doob: I've always been very dependent on wearing headphones in order to get some level of concentration. Because of that I started using combinations like do_ob, dõ_õb, dò_ób, dê_êb, d=_=b, ... as IM nicknames. One day a friend greeted me as Mr.doob and the name somehow stuck. It was also easier for my coworkers to pronounce than my real name.

Brad Neuberg: Now that we have that out of the way, tell us a bit about yourself, where you're from, your background, interests, and some projects you have worked on (don't be humble!)

Mr. Doob: I'm originally from Barcelona (Spain). After primary school I studied Electronics and later Arts. From the early days I was very involved in this thing called Demoscene. Always attracted to anything computer graphics but, although I tried to learn code my mind wasn't ready yet and focused on design and editing. Because I felt I was learning way more from doing demos than attending college I stopped my education and looked for a job where I could develop my interests and ended up working as a HTML developer. Since then I've been alternating the coder and designer roles in every company.

Most of the projects I've worked on have been about creating the ID or online presence for small companies. It wasn't until I joined Hi-ReS! that I worked for bigger brands such as Sony, Nokia, Sprint, Jägermeister, Chanel, Dolce&Gabanna, ...

By that time I started experimenting with Actionscript and uploading the results to my site. Unexpectedly the site started to attract production companies and studios that were looking for some experimental effects and/or interactions.

Brad Neuberg: You recently worked with Google on The Wilderness Downtown. Tell us a bit about the project and what you did, including some technical details on how you built things.

Mr. Doob: Probably the project in which I've been able to apply most of what I've learned until now. There are some pieces of code reused in the project like three.js, the Sequencer code or the Harmony base code but my main tasks were working in the Street View shots and the birds. The Street View being by far the most challenging for performance reasons. We intended to directly use the Google StreetView Javascript Embed but it performed very slowly. A custom Street View Data viewer had to be done by drawing sinusoidally distorted columns of crops from the panorama texture. The effect isn't 100% how it should be but it's very similar and fast. After that there was the challenge of finding out where in the panorama was the user’s home so we could use the right point of view for some shots. I couldn't find much documentation about that, but just when I had a desperate email ready for the Google Maps guys I came up with idea of getting the vector from the lat/lng of the house and the lat/lng of the panorama data. It's now obvious but there was so much data around to assimilate and the deadline was approaching fast.

Brad Neuberg: Tell us about a hobby, interest, or something in your background that most people wouldn't expect or know about.

Mr. Doob: Hmm... not that it’s too interesting but... I used to be fairly good at football. At some point I had to decide whether to join a football team or joining a comic school. Some times I regret I didn't do the former. Something tells me I'll go back to that eventually...

Brad Neuberg: What is a clever hack, trick, or elegant turn of code you've discovered or created while working with JavaScript, HTML, CSS, etc. Give good details, and don't be afraid to be technical :)

Mr. Doob: It's not much of a trick or a hack, but I've always found very beneficial to avoid using libraries such as jQuery. I guess such libraries are helpful for cases where IE6+ support is required, but otherwise I think that, ironically, it over complicates things. The more control you have over your code the better.

Also, I’m still learning JavaScript and I don’t know the reason behind some objects. As an example, I recently stopped using new Image() and started using document.createElement( ‘img’ ) for consistency reasons.

Brad Neuberg: Where do you see HTML5, CSS3, SVG, (i.e. the new stuff on the web) going in the next year? How about the next 3 years?

Mr. Doob: They’ll continue evolving at a nice pace. And browsers will have to keep up to date or they’ll lose their user base.

In 3 years I think it’s all going to be WebGL though. I think it’s easy to imagine videogames moving from native applications to web applications. Windows/MacOS/Linux compatibility comes for free, the downloading/installing process won’t be needed and, if done right, the experience starts instantly. At this point Windows/MacOS/Linux as OS becomes irrelevant for most of the people.

It scares me that people browse the internet more and more from devices that can’t be used for authoring but, on the bright side, I like the fact that with Javascript nothing gets compiled and kids will be able to right click any page and see directly the code.

Brad Neuberg: What excites you the most about what is happening on the web today? What still frustrates you?

Mr. Doob: The competition between browser vendors. That competition is making the platform improve at a rate I wish the Flash platform would have been while I was into that.

This new trend of serving results in realtime and realtime interactions is also exciting. The internet is evolving very quickly.

What still frustrates me are usually stupid politics-based decisions like Safari and Internet Explorer not supporting Vorbis in <audio>, Safari only playing iTunes rendered h264 .mp4, ... And other than that I just can’t understand why ‘darker’ is being removed from context.globalCompositeOperation in the WHATWG specs.

Brad Neuberg: For folks that want to do the kinds of cutting edge things you've been doing, what advice or resources would you give or point them to?

Mr. Doob: Just look at the past. I’m not doing much else than combining old Amiga/DOS techniques with what the web has to offer. Thanks to the recent JS1k contest we now have lots of code to learn from and experiment.

Thanks Mr. Doob! What questions do you have for Mr. Doob? Ask them below!

We end with a presentation Mr. Doob gave recently at ARTtech 2010 on Laziness, Creativity, and Code:

ARTtech 2010: Laziness, Creativity and Code from AssemblyTV on Vimeo.

Web Ninja Interview: Erik Arvidsson

Today kicks off a new series focused on interviewing people doing amazing work on the web using JavaScript, CSS, HTML, SVG, WebGL, or any of the other new-fangled Three-Letter Acronyms coming out. We call these people Web Ninjas.

Our kickoff blog post for the Web Ninja Interviews is Erik Arvidsson, one of the original Obi Wan Kenobi's karate chopping JavaScript whether it's called DHTML, Ajax, or HTML5. He is one of the original JavaScript bad-asses. Let's begin.

Brad Neuberg: Tell us a bit about yourself, where you're from, your background, interests, and some projects you have worked on (don't be humble!)

Erik Arvidsson: I'm a Frontend Engineer at Google and I've been there for 5 years.

I'm currently working on Chrome. A lot of Chrome's UI is done using HTML+CSS+JS. For example I created the New Tab Page and the new Bookmark Manager. Working on Chrome is a breath of fresh air. I no longer have to care about cross browser issues and I can use all the goodies from HTML5 and CSS3 that we have in Chrome. Another big difference working on Chrome UI compared to working on web apps is that we only have to work with ToT (tip of tree) and when I find bugs in Chrome/WebKit I try to fix them instead of finding work arounds. As soon as the bug gets fixed I know that 100% of the users will have the bug fix.

Before Chrome I worked on Gears and then later moved over to the Gmail team to ship Offline Gmail. Working on Gmail and Offline was very exciting. Gmail is the largest web app I've worked with and it taught me a lot about the issues with large scale projects using JS. For example, the large memory working set caused us to have to do major low level refactoring to not get dog slow in IE6 since JScript had an extremely inefficient GC.

When I got to Google the state of JavaScript was a mess. Me and Dan Pupius took it upon ourselves to fix this and Closure (library) was born. A lot of the best practices from creating large scale web apps such as Gmail went into Closure and we worked closely with the Closure Compiler people making sure we would get the most efficient JavaScript possible.

I am also a member of the ECMA TC39 [working group]. The group that is responsible for the standardization of JavaScript. JavaSript as a language has a lot of warts but I love the flexibility that it gives us developers. Yes, it is too easy to do the wrong things in JS and I think JS needs some soft boundaries to encourage the programmer to do the right thing. Today, writing programs that are efficient and easy to maintain requires too much boiler plate code. I also think it is important to continue to keep JavaScript dynamic and flexible. I am afraid of initiatives to make everything static and locked down. There are plenty of good static languages and there are lots of projects that compile from <insert language here> to JavaScript.

Before Google I worked on a small company where I created a GUI toolkit called Bindows. It was a big change going from a 1 engineer company to Google and working on a code base with hundreds of different engineers.

Earlier than that I created WebFX with Emil. This was one of the earlier DHTML web sites and it got quite a lot of creds back in those days.

In 2000 I worked on something called WebOS (yes, that was the name) and we built a complete desktop environment and GUI toolkit for IE5 and later rearchitectured that to work with Netscape 4 and IE4 (yuk).

I got into DHTML around 98. I had a web page at my university where I used a lot of CSS for IE3 and I was into the whole beta scene. I was pretty excited what early alphas of Windows98 where doing with Windows Explorer where a lot of the UI was done in HTML and I absorbed every little method and property as the IE4 developer previews came out. It was like Christmas every time a new beta came out. One thing that made me so excited about DHTML was that I could with, very little code and no compilation, do things that would take hundreds of lines of code to write in Java, C++ or any of the other languages/toolkits they were teaching at the university.

Brad Neuberg: You were one of the first to jump into DHTML, watched the transition and rebrand with 'Ajax', and have watched as HTML5 has come on the scene. What are some of the things that excite you the most about what is happening on the web today? Are there any old tricks in particular you are looking forward to not needing to do as more modern browsers arrive on the scene?

Erik Arvidsson: I think one of the most exciting thing about the web is the richness and usability of modern web apps. The speed improvements that Chrome pushed so hard for have paid off and all the browsers today are a lot faster. The other reason applications have become better is the tireless work of people like Steve Souders who keep reminding people that latency is important.

I find a lot of the new CSS3 features available in WebKit allows me to do more with less. I really like being able to use a canvas as my background image and CSS transitions (although I often find them too limited) are really amazing. I also like the direction aware CSS properties (padding-start, margin-end, text-align: end etc) which allow me to remove a lot of CSS that is used to display the page correctly in RTL. I understand that most people do not have to care about RTL but for Chrome all the UI has to work in RTL.

With IE9, event abstractions is a thing of the past and good riddance. Just implement your own EventTarget interface and your JS objects works exactly like the DOM objects.

I'm also happy that Explorer Canvas will not be needed much longer. It was a fun project but VML in general was never well implemented and it has caused me a lot of head aches.

Brad Neuberg: What are some of the things you are hacking on these days (that you can talk about)?

We're finishing up another iteration of the New Tab Page for Chrome as well as moving all the settings UI to HTML. Besides from that I'm getting more into WebKit. It is such a mind blowing change to be able to actually fix the browser when something is not working as it should.

Brad Neuberg: Where do you see HTML5, CSS3, SVG, etc. (i.e. the new stuff on the web) going in the next year? How about the next 3 years?

Erik Arvidsson: I'm really excited about IE9. I feel like all the browsers today are finally supporting a big chunk of CSS, JS, DOM and HTML. If you are willing to use Chrome Frame for your old IE users all your users will have access to modern web APIs. This has never happened before and I expect a lot of applications to be rewritten with this in mind, leading to faster, more interactive and more usable applications.

Another big thing is that I believe that the innovation in the web browser and the standardization communities have been focused on providing missing capabilities like drag and drop of files, offline, rich graphics etc. However, the usability of these APIs have been lacking. Everything feels more disconnected now than it ever did before. I think and hope that we will see a lot of work making things fit better together in the future. I have a few pet peeves that I would like to see fixed:

How come NodeList is not an instance of JS arrays? Why can't I do document.querySelectorAll('.foo').forEach? Why can't I splice that collection? Yes, there are issues with some of these collections being read only etc but nothing that cannot be solved. Why is it that DOM and JS never seem to fit together? Why can't I do "new HTMLButton"? Why can't I create custom HTML element in JS? How come all JS libraries wrap elements with a JS object and they all build their own component models that never work together.

I think some of this comes down to be able to make the platform self hosting. I'm not saying that we should build the input[type=range] element in user code. I'm just saying that I think it should be possible to do so. Same goes for CSS which is far from extensible today.

Brad Neuberg: What is a clever hack, trick, or elegant turn of code you've discovered or created while working with JavaScript, HTML, CSS, etc. that you are particularly proud of? Give good details, and don't be afraid to be technical :)

Erik Arvidsson: This is a trick that I settled on while working on the Bookmark Manager for Chrome. It allows you to sub class HTML elements which in turn allows you skip the common JS wrapper that all JS toolkits use.

JAVASCRIPT:
var myButton = new MyButton;
myButton.innerHTL = 'Hello &lt;b&gt;World&lt;/b&gt;';
document.body.appendChild(myButton);
 

The trick here is to use a SpiderMonkey extension that all JS engines except JScript supports. The extension allows you to change the [[Prototype]] of an object using the __proto__ property.

JAVASCRIPT:
function MyButton() {
  var element = document.createElement('button');
  MyButton.decorate(element);
  return element;
}

MyButton.decorate = function(element) {
  element.__proto__ = MyButton.prototype;
  element.decorate();
};

MyButton.prototype = {
  __proto__: HTMLButtonElement.prototype,
  decorate: function() {
    ...
  },

  get myProperty() {
    ...
  }
  ...
);
 

In the code above the constructor creates an element but it changes the prototype chain of the element to add our custom object before the built in prototype, effectively allowing us to inject our own behavior, and then returns that element. Now you can effectively work with the element instead of having to keep track of whether you got the element or the element wrapper. Things like document.querySelector('.foo').myProperty just works.

Brad Neuberg: For folks that want to do the kinds of cutting edge things you've been doing and have done, what advice or resources would you give them?

The way I learned it was to read the API docs of MSDN (the whole thing). With every new release I scoured for changes in the DOM (using for in loops) but today you can do the same with Web Inspector or Firebug. Just keep playing with the new stuff, you don't have to build anything useful, just get a feeling for what the API can do for you. One thing that I found fun and educational was to build small games. Just take one of your favorite games from the 8-bit era and reimplement it. It has never been as easy to do this as today since we now have canvas (WebGL) and fast JS engines.

And of course, read Ajaxian and other blogs to see what crazy shit people are coming up with these days.

Brad Neuberg: Thanks Erik!