funk rock http://ross.posterous.com Most recent posts at funk rock posterous.com Sun, 01 Mar 2009 19:51:00 -0800 Limitations of the WAI-ARIA http://ross.posterous.com/2009/03/01/limitations-of-the-wai-aria http://ross.posterous.com/2009/03/01/limitations-of-the-wai-aria

As a follow up to my previous post, I wanted to learn more about the WAI-ARIA spec, so I went ahead and read it. I won't claim to be an expert, or to have anything more than a basic understanding of the spec at this point, but I was not impressed with what I saw. Unfortunately, the spec doesn't seem particularly forward thinking. There are two main issues I have with the spec: first is that it's a very limited extension of the DOM and of what we already have on the web; second is that there is no programmatic interface to the accessibility system. The most obvious downside of assuming that the DOM will be the basic building block of future web applications is that it presumes all web apps will always be structured with DOM trees. But this already isn't true today. Look at Mozilla's Bespin editor, which renders text inside a canvas element, or SUN's Lively Kernel, which implements an entire widget set in SVG. Because there is no underlying DOM structure, these two programs can not be made accessible under the WAI-ARIA spec without substantial hacks. What about elements that aren't part of the visual structure at all? For example, in Cappuccino, every application has a CPApplication object. This object contains information that would undoubtedly be useful to the accessibility system, but because it's an abstract object and isn't part of the render tree in any way, it will never be visible to WAI-ARIA compliant browsers. This leads us to the second problem, not having programmatic access to the accessibility system. This spec is designed to target web applications, but it has taken the same document based approach as HTML. Applications are defined by requiring a programming language, which in the case of the browser is usually JavaScript. It seems short sighted to develop a standard for applications that uses a fundamentally different technology than the application does. Even beyond the fact that elements in your program that don't exist in the DOM tree can't become part of the accessibility system, not having a programmatic interface means that you can't dynamically compute accessibility values. Imagine some user interface element that changes frequently, or perhaps is a composite of several other objects. Under the current WAI-ARIA spec, every change to this user interface element needs to be immediately reflected in the DOM. This means a potentially substantial performance hit that is unnecessary for the vast majority of users, and even for people requiring the accessibility feature if they aren't focused on that element. Lack of an actual API also limits the potential uses of ARIA. I can't, for example, implement my own accessibility tool within the browser. It also causes issues with the event system, and doesn't add any enhanced functionality for simulating events using accessibility APIs, which could have enabled a lot of advanced automated testing. These thoughts are a result of my very brief research into ARIA so far, and if anything is technically incorrect, I'd appreciate that feedback. At this point, I'm not sure where to go with ARIA and accessibility. As far as Cappuccino implementation is concerned, there is enough in ARIA that we can significantly enhance the accessibility of Cappuccino, if not 100%. I suspect the performance implications will be minimal for most UI elements (though I am concerned about text fields), but it's impossible to say until we actually have ARIA implemented. I'm interested to hear other opinions on ARIA, especially from those who are developing modern web applications. It would be interesting to know if anyone shares my concerns, and if there is any way to actually address some of them within the current framework of ARIA or perhaps another active project I'm not aware of. I don't claim to have any answers, just a lot of questions, so please share your thoughts.

Permalink | Leave a comment  »

]]> http://files.posterous.com/user_profile_pics/225705/Photo_1021.jpg http://posterous.com/users/T7SMgz Ross Boucher boucher Ross Boucher Thu, 26 Feb 2009 09:59:47 -0800 Accessibility & Degradation in Cappuccino http://ross.posterous.com/2009/02/26/accessibility-degradation-in-cappuccino http://ross.posterous.com/2009/02/26/accessibility-degradation-in-cappuccino On Tuesday, we announced Atlas, our new visual layout tool for Cappuccino. I'm incredibly excited about where Atlas is headed, and I'm also glad to hear all the feedback we've been getting just from our demo video. One of the things in particular that I've read several discussion on is accessibility and Cappuccino, and I wanted to share some thoughts on the topic. Drew McLellan wrote an interesting piece outlining his concerns about the subject, but I think certain things need to be clarified. First, there's a difference between accessibility and the availability of JavaScript. Accessibility is about enabling assistive technologies like screen readers to relay information to users with disabilities like vision impairment. JavaScript availability, on the other hand, is about whether or not a user's browser has JavaScript enabled (or supports JavaScript at all). JavaScript availability is what people are talking about when they talk about graceful degradation. Both of these issues are important, but they need to be addressed separately. Let me state the obvious: JavaScript availability is a requirement for writing an application in the browser. The reason is simple, writing a program requires a programming language, which HTML and CSS are not. To be more precise, I'm talking about an application that doesn't rely on the server for all its logic, a truly browser based application, not a website with a dynamic back end. Not all programs should be or need to be written this way, that is something we readily acknowledge. But, some applications only make sense written like this: a presentation editor can't hit the server on every single move or update or reposition of a slide element; a word processor can't hit the server every time you need to type a character. I don't believe this is a controversial statement, it's a fundamental reality of the web. And it's something you see not just in Cappuccino, but in any complex web application, from Google's to Apple's and countless others. The second issue is accessibility, and I do believe its important. First, to put on my contrarian hat, you have to consider that not all applications can be made accessible. Although I could be wrong, I don't think there's a reasonable way to make Photoshop accessible to someone who can't see; fundamentally it's a visual tool. 280 Slides, for the most part, is the same (and to a large extent, Atlas may be as well). They are largely visual tools, heavily relying on visual design, drag and drop, and other mouse based metaphors. Since Cappuccino development up to this point has been driven mostly by our own needs, that may help explain why this hasn't been a top priority for us. All that aside, we absolutely want Cappuccino to be an accessible platform. Until pretty recently, this just wasn't a possibility. Browser vendors and assistive technology vendors provided absolutely no facilities for interacting with the accessibility system. We've been working on Cappuccino for some time now, and I think it would be a travesty if none of the things we've accomplished had been done simply because there wasn't yet a way to make them accessible. Cappuccino is pushing the edges of web development right now, and understandably some things take time to catch up. Vendors need to take their share of responsibility for the problem. More recently, efforts like WAI ARIA are starting to be taken seriously enough to consider as a potential avenue for Cappuccino. Like the rest of our APIs, we have a strong foundation to build upon -- Mac OS X has great support for accessibility in custom UI. I am extremely excited about integrating some of these technologies into Cappuccino. At the same time, 280 North is a three person company, developing our own products to support our business, and developing Cappuccino in the open to benefit everyone. We can't program every feature needed in Cappuccino all at once, but that's part of why we're embracing open source. If people feel strongly about WAI ARIA, I encourage them to get in touch with us about helping to add support to Cappuccino. It isn't an area we have a great deal of expertise in, but we're happy to learn new things, and this is absolutely a problem we want to work on. As for Atlas, I'm looking forward to sharing more about development status, and what it can do. We've got a lot of ideas, but we really love hearing what fellow developers feel is important. This is just one good example of the feedback we've been getting, and hopefully I'll be able to share more in the coming months.

Permalink | Leave a comment  »

]]> http://files.posterous.com/user_profile_pics/225705/Photo_1021.jpg http://posterous.com/users/T7SMgz Ross Boucher boucher Ross Boucher Sun, 15 Feb 2009 18:47:01 -0800 iReddit - the official reddit iPhone App http://ross.posterous.com/2009/02/15/ireddit-the-official-reddit-iphone-app http://ross.posterous.com/2009/02/15/ireddit-the-official-reddit-iphone-app An iPhone application I wrote just got posted to the app store yesterday. iReddit (cleverly named huh?) is the official reddit client for the iPhone. I may have built the iPhone app, but they built reddit, which is the really hard part, and for that we're all thankful.
Media_httprossboucher_mcmlj
Actually, I've been interested in trying out the iPhone dev environment for some time. I got to talking with Alexis and thought this would be a great opportunity to build something useful, and help out our startup at the same time. All in all it was a good experience, but at times the iPhone dev process may make you want to kill yourself (and not because of the programming part). Don't say I didn't warn you. The app itself is pretty great. You can browse the combined front page, or look at individual subreddits, and even get your own customized reddit list on the phone by logging in. Commenting, voting, and saving are all there, plus "serendipity" mode, which displays a random upcoming reddit story every time you shake the iPhone. The best part of the app is probably the reddit alien getting pissed off at slow loading pages. The effect is great. So, if you haven't already, go buy the app! I'll try and write more about the dev process in future posts, and in particular about my take on the app store and some of the things people have been complaining about. Alexis has a bit of a crazy side to him, and it called him to make this commercial for the app. Hand modeling by yours truly. Still waiting to hear what Wil Wheaton actually thinks of it.

Permalink | Leave a comment  »

]]> http://files.posterous.com/user_profile_pics/225705/Photo_1021.jpg http://posterous.com/users/T7SMgz Ross Boucher boucher Ross Boucher Wed, 10 Dec 2008 01:30:54 -0800 JavaScript IS a High Level Language! http://ross.posterous.com/2008/12/09/javascript-is-a-high-level-language http://ross.posterous.com/2008/12/09/javascript-is-a-high-level-language In response to some extended discussion via JResig, Ajaxian, and Francisco, Charles Jolley said the following:
JavaScript, on the other hand, is a high level language. It has garbage collection, lambda functions, dynamic typing, object messages, and nearly every other feature you would expect in a modern high-level language. When you wrap JavaScript in another high-level language, you don’t free yourself from managing low-level details; you just exchange one abstraction for another.  You pay the cost of two high-level languages without gaining any benefits for your final product.
The implication here is that JavaScript is the highest level language currently imaginable; in a word, it's perfect. Actually, the next line, which I won't quote, warns us not to interpret that as claiming JavaScript is perfect. It then goes on to reverse course and say the only way to abstract JS further is with a UI builder. But is this really the case? There's a simple test: Can I create a language on top of JavaScript that has at least one feature not present in JavaScript? Of course, the answer is yes, and the proof is Objective-J. If there is one feature that proves this point best, it's @import. Importing is a feature that almost every high level language offers, and yet it isn't present in JavaScript. This begs the question: couldn't I just implement this as a feature in a native library? Yes, and no. This is a complex topic, and I don't want to get into the specifics, but to get the asynchronous/look-ahead code importing built into Objective-J, you need to preprocess code (aka, extend the language). Objective-J doesn't just add one feature, it adds many. These include dynamic message sending (which enables features like method_missing from ruby, and which is completely different from what JavaScript does have -- function calls; I'm not sure why Charles called them "object messages"), importing, and classical inheritance. Many of these features use a runtime component, called the Objective-J runtime. Most of the new syntax in Objective-J is shorthand for accessing this runtime (which is built, of course, in JavaScript). You could say that the language frees yourself from managing low-level details of the runtime that you shouldn't need to worry about. And since Objective-J is a strict superset of JavaScript, you don't pay any cost for utilizing it. You can drop down to "pure" JavaScript at any time. You don't even need a compiler or a special build tool to use Objective-J, since the language is written in JS and preprocesses dynamically in the browser.

Permalink | Leave a comment  »

]]> http://files.posterous.com/user_profile_pics/225705/Photo_1021.jpg http://posterous.com/users/T7SMgz Ross Boucher boucher Ross Boucher Thu, 20 Nov 2008 19:37:01 -0800 Google, iPhone, and Thinking Like a Programmer http://ross.posterous.com/2008/11/20/google-iphone-and-thinking-like-a-programmer http://ross.posterous.com/2008/11/20/google-iphone-and-thinking-like-a-programmer Yesterday, John Gruber declared that Google Mobile uses private iPhone APIs. Since he wrote it, it must be true, which is why TechCrunch picked up on the article this morning. Nevermind the fact that the only evidence offered by Gruber was that "there is no public API in the iPhone SDK for using the proximity sensor in this way." The critical mistake Gruber makes is assuming that because there's no documented method for trivially utilizing the proximity sensor, there must be no possible way to do it. This is a severe lack of imagination. Programming is an exercise in creative thinking, especially when working within the context of specific platform. There are always things you, the developer, want to do but don't seem to be able to. This has always been and will always be true. It's the reason why plenty of desktop Mac apps use private Apple APIs, and it's the reason why plenty of iPhone apps on the store are using undocumented APIs. The essential question, then, is can what Google is doing be done without using undocumented APIs on the phone? I think it can. I spent an hour this morning trying to prove it, and came up with this iPhone app. To be fair, this doesn't work as well as Google's version, or exactly the same way. For one, I didn't bother to program in the proximity requirement for the trigger. This is well documented, so anyone could easily add it to this project. The other way in which my method underperforms Google's is that the phone actually has to touch your ear before it will trigger. Google's just needs to come close to your ear. But, the code does use the proximity sensor, and it only uses the available API method for that sensor, which gives you the ability to turn it on and off. The code uses no undocumented APIs. How does it work? As I mentioned, it requires you actually touch the phone to your ear. Once you do, the application receives a touchBegan event, and turns on the proximity sensor. It also makes a note that the app is in the middle of a touch sequence, and finally it fires off a timer which makes this trick work. Once the proximity sensor is turned on, it is immediately engaged because the phone is so close to your face. When the proximity sensor is engaged Cocoa turns off the touch sensor, but it doesn't send a touchEnded message to the application. Thanks to that timer we fired, we can poll for the current number of touches on the screen. If it drops to zero, but we never saw the touchEnded message, we know we've triggered the proximity sensor. The project I've included will turn the screen yellow and play a little sound, just like the Google application. Here's all the relevant code:
- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event
{
    [self setBackgroundColor:[UIColor redColor]];
    [UIApplication sharedApplication].proximitySensingEnabled = YES;

         _inLiveTouch = YES;

         [self performSelector:@selector(checkTouches:) withObject:event afterDelay:0];
}

- (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event
{
    [self setBackgroundColor:[UIColor greenColor]];

         _inLiveTouch = NO;
    [UIApplication sharedApplication].proximitySensingEnabled = NO;
}

- (void)checkTouches:(UIEvent *)event
{   
    if (_inLiveTouch && [[event allTouches] count] == 0)
    {
        [self setBackgroundColor:[UIColor yellowColor]];
        AudioServicesPlaySystemSound(_sound);
        return;
    }

    if (_inLiveTouch)
        [self performSelector:@selector(checkTouches:) withObject:event afterDelay:0.5];
}

An hour of programming, and three methods get us something relatively close to what Google is doing. I'm far from an expert in the iPhone SDK, but it only took a little bit of imagination to come up with this idea. Google has perhaps a dozen or more employees working full time on the iPhone. It's not much of a leap to believe they figured out an even smarter trick than mine to accomplish what they wanted to do. Gruber did mention later that at least one other app is doing something similar without using the proximity sensor, but was quick to point out how inferior it was to the proximity based approach. Now, as it turns out, Google probably is using private APIs to do what they're doing. Erica Sadun, over at Ars Technica, made a more convincing case. The ultimate question then, is does it matter? The reality of the situation is that there are a lot of apps doing this that have already shipped. It isn't just Google, and it isn't just big companies, it's everybody. Either Apple knows this and isn't doing anything about it, or they don't know. Either way points to indifference. If they know, it's obvious how not taking action is indifferent towards things, but what about if they don't know. In that case, it means the review process they've built is not designed to catch these cases. To be sure, the dynamic nature of Objective-C would make it difficult to catch all instances of runtime tomfoolery, but it's not impossible to do so, nor would it be particularly burdensome to catch most of the cases. As it currently works, I believe they are only checking to see which frameworks you link against statically, and denying anyone who includes private frameworks in that list. Even if Apple was deeply concerned that people were using undocumented APIs, would it be a big deal if Google was granted an exception? Gruber thinks so:
Third-party iPhone development is purportedly a level playing field. If regular developers are forced to play by the rules, but Google is allowed to use private APIs just because they’re Google, the system is rigged.
Rigged? Who said the iPhone SDK was a level playing field in the first place? Apple has never been a company that stands up for level playing fields, nor should they have to be. Every business makes business deals, partnerships, exclusive rights agreements -- this is common business practice, at Apple, Google, and everywhere else in the business world. Why should the iPhone be any different? If you had billions of dollars in the bank, Apple would talk to you too. This isn't only realistic, it's also reasonable. One of the reasons to prevent people from using undocumented APIs is not wanting applications to break between upgrades. If Apple knows every single application that will break, because it has an arrangement with the developer, it can make sure to correct the problem in advance. This obviously doesn't scale to every developer, but it makes perfect sense to do so on a limited case by case basis. In fact, this is how Apple already behaves in the desktop world. Wil Shipley gets his bugs fixed faster than Joe the Indy Developer. Why? Because his app is popular, and because he has connections at Apple. TechCrunch claimed in their article this morning that "Apple wouldn’t allow Google to use an unsupported call. It’s not in their DNA." If anything, Apple is more likely to help Google than any other company. After all, Google provided Apple with a special version of maps for the iPhone application, and now the company refuses to license Google Maps to any other iPhone developer, even the ones willing to pay the outrageous sums of money a license costs. Google gave Apple a virtual maps monopoly for the iPhone, the least Apple can do is let them use an undocumented method here and there.

Permalink | Leave a comment  »

]]> http://files.posterous.com/user_profile_pics/225705/Photo_1021.jpg http://posterous.com/users/T7SMgz Ross Boucher boucher Ross Boucher Tue, 19 Aug 2008 18:44:40 -0700 iPhone Touch Events in JavaScript http://ross.posterous.com/2008/08/19/iphone-touch-events-in-javascript http://ross.posterous.com/2008/08/19/iphone-touch-events-in-javascript Yesterday I gave a presentation at the San Francisco JavaScript Meetup about the new JavaScript touch events API in iPhone 2.0. I thought I'd share the slides, in case people were interested in viewing them after the fact. I owe a great deal of thanks to Neil Roberts from SitePen, who's post on the topic was my main source of information. My co-founder Tom Robinson was also helpful, thanks to his iPhone light-table. One of the interesting things I was able to talk about was reusing existing mouse based libraries with the iPhone by using touch events to simulate mouse events. The basic idea behind it was to address the fact that mouse events don't work particularly well on the phone. It's unpredictable when you'll get them, if at all (you won't if you attach only to document, for example). Mousemove in particular doesn't work in any meaningful way. In contrast, the touch events are completely predictable and reliable (excepting the existing bugs). We can use these events to simulate the existing mouse events with a fair amount of accuracy. In particular, when one finger is down on the screen, touchstart, touchend, and touchmove correspond nicely with mousedown, mouseup, and mousemove. There's some difference in the way mousemove works, since we can't get mousemove events when the finger is not touching the screen, but this is an acceptable trade off. It doesn't make sense on the iPhone anyway because there's no persistent cursor. I took this jQuery based drag and drop example to see if I could get it working on the iPhone without modification. Here's the working iPhone demo. The only existing code that I modified was some CSS to make the page fit nicely on the iPhone screen, and a viewport meta tag. The added code to get drag and drop working is really simple:
function touchHandler(event)
{
    var touches = event.changedTouches,
        first = touches[0],
        type = "";

         switch(event.type)
    {
        case "touchstart": type = "mousedown"; break;
        case "touchmove":  type="mousemove"; break;        
        case "touchend":   type="mouseup"; break;
        default: return;
    }

             //initMouseEvent(type, canBubble, cancelable, view, clickCount,
    //           screenX, screenY, clientX, clientY, ctrlKey,
    //           altKey, shiftKey, metaKey, button, relatedTarget);
    
    var simulatedEvent = document.createEvent("MouseEvent");
    simulatedEvent.initMouseEvent(type, true, true, window, 1,
                              first.screenX, first.screenY,
                              first.clientX, first.clientY, false,
                              false, false, false, 0/*left*/, null);

                                                                                 first.target.dispatchEvent(simulatedEvent);
    event.preventDefault();
}

function init()
{
    document.addEventListener("touchstart", touchHandler, true);
    document.addEventListener("touchmove", touchHandler, true);
    document.addEventListener("touchend", touchHandler, true);
    document.addEventListener("touchcancel", touchHandler, true);    
}

I've captured the touch events and then manually fired my own mouse events to match. Although the code isn't particularly general purpose as is, it should be trivial to adapt to most existing drag and drop libraries, and probably most existing mouse event code. Hopefully this idea will come in handy to people developing web applications for the iPhone. Update: In posting this, I noticed that calling preventDefault on all touch events will prevent links from working properly. The main reason to call preventDefault at all is to stop the phone from scrolling, and you can do that by calling it only on the touchmove callback. The only downside to doing it this way is that the iPhone will sometimes display its hover popup over the drag origin. If I discover a way to prevent that, I'll update this post. Second Update: I've found the CSS property to turn off the callout, "-webkit-touch-callout". You can read about it in Apple's documentation.

Permalink | Leave a comment  »

]]> http://files.posterous.com/user_profile_pics/225705/Photo_1021.jpg http://posterous.com/users/T7SMgz Ross Boucher boucher Ross Boucher Tue, 29 Jul 2008 00:06:30 -0700 Resizing TextAreas http://ross.posterous.com/2008/07/28/resizing-textareas http://ross.posterous.com/2008/07/28/resizing-textareas Yesterday I was working on making a textarea element automatically resize itself to fit its content without a scroll bar. I've seen this done before, so it isn't something strictly new, but I did notice that a lot of people are doing hacks with rows/columns, so I thought I'd share my own approach. In my case, I wanted a fixed minimum height, and then I wanted the box to grow as the user typed additional text. Assuming you have a reference to your textarea, and a MIN_HEIGHT variable defined somewhere, the javascript is actually very simple:
textArea.style.height = MIN_HEIGHT + "px";
textArea.style.height = Math.max(MIN_HEIGHT, textArea.scrollHeight) + "px";
 We need to do the first set because otherwise Firefox and Safari will not shrink if the user deletes text. I should note that the textarea was styled with a fixed width in pixels, which shouldn't be strictly necessary. The real reason I wanted this auto-expanding and contracting view was actually because I wanted to use it in my own custom scroller. For the scroller to work properly, it needs to know the size of whatever its scrolling inside of it. The other problem with putting a textarea into my custom scroller was knowing where to scroll too. Since textarea's have their own caret, and since most browsers will scroll the textarea to follow the caret no matter what you set overflow to, I needed a way to know where exactly the caret was in the textarea. Both Firefox and Safari have the selectionStart and selectionEnd properties on textarea elements. When there's no selection, these two numbers are the same; they tell you the character index of the caret. Strictly speaking, knowing the index of the caret isn't enough; I need to know the vertical offset. There's no easy way to do this, so I reused one of the hack's I've been playing around with lately. What I did was create a duplicate of the textarea's text content inside another element (a div in our case). We make sure to style the textarea and div the same so that the rendered text would look exactly the same, except one would be editable and the other wouldn't. The trick is, in our new element, I surround each character with it's own span. Then, I can use the caret index we got before as an index into the childNode array of our div element to get a reference to the specific character we're dealing with. Here's a relatively simple implementation of what I'm talking about:
var start = textArea.selectionStart,
    end = textArea.selectionEnd,
    imposter = document.createElement('div'),
    referenceSpan = document.createElement('span'),
    stringValue = textArea.value;

//You may need to copy more than just these two styles
imposter.style.height = textArea.style.height;
imposter.style.width  = getComputedStyle(textArea, "").getPropertyValue('width');

for(var i=0; i {
    referenceSpan.innerHTML = stringValue.charAt(i).replace("\n", "
");
    imposter.appendChild(referenceSpan.cloneNode(true));
}

document.body.appendChild(imposter);

var caretOffsetTop = imposter.childNodes[start - 1].offsetTop - imposter.offsetTop,
    caretHeight = imposter.childNodes[start-1].offsetHeight;

document.body.removeChild(imposter);

 At the end of that block we have the vertical position of the caret in the textarea (or at least an incredibly good approximation). There are a few things I've glossed over; the most obvious is that if you call this on every keypress you've turned an O(1) operation into an O(n) operation. The enterprising individual will want to cache and and keep track of the state of the textarea rather than build from scratch, but I can tell you from personal experience that it's a real pain, and may not be worth the effort. For most uses, and in pretty much any version of Firefox or Safari, the above code will work well enough. The other thing to watch out for is that many browsers won't report the size/position of whitespace characters, so you'll need to scan for the nearest non-whitespace character. Right now this doesn't work in Internet Explorer. IE uses a different mechanism -- document.selection.createTextRange() -- to return information about the position of the caret. Unfortunately, the character index is not one of the properties of the TextRange object. The object does have an offsetTop property, but it seems to return the offset into the whole window, and I'm having difficulty keeping that in sync with the scrolling textarea. If anybody has any feedback on that front, or on the hack in general, I'd like to hear it.

Permalink | Leave a comment  »

]]> http://files.posterous.com/user_profile_pics/225705/Photo_1021.jpg http://posterous.com/users/T7SMgz Ross Boucher boucher Ross Boucher Thu, 19 Jun 2008 23:49:48 -0700 Aftermath of 280 Slides http://ross.posterous.com/2008/06/19/aftermath-of-280-slides http://ross.posterous.com/2008/06/19/aftermath-of-280-slides We launched 280 Slides two weeks ago, and it's been a great experience. After putting five months of non stop work into it, it's a good feeling to be able to point to it and say "That's what I've been doing." It's also fantastic to be getting all kinds of feedback from people who like (and dislike) the application. It really does help you focus on what matters to people. We've had some great press mentions too (both Slides and Cappuccino): TechCrunch Ajaxian TUAW Guardian.co.uk And quite a few blogs. (and twitter) There's also been a fair amount of confusion regarding MobileMe and SproutCore. Just to clarify, MobileMe is not based on Objective-J or Cappuccino, and 280 Slides is not based on SproutCore. 280 Slides isn't part of MobileMe, and we have no affiliation to Apple. Oh, and there are three of us, not two.

Permalink | Leave a comment  »

]]> http://files.posterous.com/user_profile_pics/225705/Photo_1021.jpg http://posterous.com/users/T7SMgz Ross Boucher boucher Ross Boucher Mon, 21 Apr 2008 21:12:42 -0700 Safari's Web Inspector http://ross.posterous.com/2008/04/21/safari-web-inspector http://ross.posterous.com/2008/04/21/safari-web-inspector The WebKit team announced the list of participants they'll be working with on this year's Google Summer of Code today. Of particular interest to me was this applicant. Anyone who does serious web work can attest to the difficulty of debugging anything in Safari, meaning that most web developers have pretty much given up and develop in Firefox full time. This is such a shame, since Safari is almost universally a better browser -- it's faster, it supports more of the things I care about, and for all the reasons Gruber listed (and more), it's the browser I use personally. The thing is, the WebKit team has known for some time that they have serious issues with debugging. In fact, I've been told better debugging support is the number one requested feature. We saw some attention paid to the issue with Drosera, but it turned out to be nothing more than lip service. Our code brings Drosera to a halt in seconds, as do most of the complicated sites we've tried it on. Safari desperately needs a profiler, stack traces, and someday step through debugging. Even beyond advanced tools like what Drosera promised and what Firebug has, WebKit fails on some of the most basic levels. This bug is damning. It should be a P1. Any callback function (read: any AJAX request, event handler, etc.) fails to report the error it encounters. Almost every error in our code base is reported as "undefined" by Safari. Keishi, you've got an important job ahead of you. You've been tasked with doing what might be the most important thing the WebKit project has done in a long time. Safari has been kicking ass in pretty much every other area, but it's ignored by web developers precisely because it's so cruel towards them. I wish you the best of luck in doing this project, and if you're looking for feature requests, I've got at least a million. At the top of my list? Solve the most important limitation of Firebug -- not properly recognizing anonymous (eval'd) code. I have high hopes for what this could be by the end of summer, and I'll definitely be following the progress.

Permalink | Leave a comment  »

]]> http://files.posterous.com/user_profile_pics/225705/Photo_1021.jpg http://posterous.com/users/T7SMgz Ross Boucher boucher Ross Boucher Mon, 24 Mar 2008 01:45:08 -0700 Lions in a Cage http://ross.posterous.com/2008/03/23/lions-in-a-cage http://ross.posterous.com/2008/03/23/lions-in-a-cage Paul Graham wrote an essay last week where he compared employees of big companies to lions in a cage at the zoo. Sort of.
I was in Africa last year and saw a lot of animals in the wild that I'd only seen in zoos before. It was remarkable how different they seemed. Particularly lions. Lions in the wild seem about ten times more alive. They're like different animals. And seeing those guys on their scavenger hunt was like seeing lions in a zoo after spending several years watching them in the wild.
Technically, Paul is comparing the startling impact of seeing lions in a cage after seeing them in the wild to his experience seeing these employees ('those guys on their scavenger hunt") after spending the last three years watching founders at Y Combinator. Nevertheless, the article (and this quote in particular) caused quite the controversy around the Internet (or at least around the tiny subset of the Internet that reads Paul's essays, myself included). It's not hard to read that last sentence and interpret it as a claim that working for a big company is like being an animal in a cage. I don't think it was Paul's intention to say exactly that, but even if it were, I think the point is immaterial to the essay as a whole. It is, at its worst, an exaggeration to prove a point, something I think we can all admit to doing from time to time (indeed it's something that great writers have always done). The central thesis of the essay is that being an employee is harmful to individual programmers, and that being a startup founder is a better way to live. In fact, he states this explicitly:
Watching employees get transformed into founders makes it clear that the difference between the two is due mostly to environment—and in particular that the environment in big companies is toxic to programmers.
It seems to me that Jeff Atwood's (and others) primary argument is that some employees have actually enjoyed working for big companies, himself included, and Paul is thus making a generalization that is not true. But Paul makes no claim about employees being unhappy. Though he doesn't address the topic directly, he sets up the entire essay by saying that he isn't talking about some special property of founders, he believes there is something missing from the life of an employee. The absence of something you don't even know you're missing is hardly likely to make you unhappy on its own. When I left Apple, it was not because I was unhappy. I was working with phenomenal individuals on an interesting set of problems. I left because I was excited about the potential of our company. And despite having worked in a great environment, at an amazing company (Apple was my dream job), I feel that all the things Paul said about founders at Y Combinator ring true. I am definitely "more worried and happier at the same time." So is John Gruber. When I had lunch with my old team on Friday, at least one person mentioned noticing the change as well. I think Paul's food analogy was a much better one to illustrate the point. There is plenty of science to back up the claim that most of the food we eat is unhealthy (and I'm just as guilty as anyone else), however the position is still controversial. People who avoid highly processed foods, high fructose corn syrup, refined sugar, white flour, and lots of red meat are generally healthier. These people will tell you that they are happier, and more active, and that it's directly related to what they eat. Yet these people are also ridiculed by the majority as fringe environmentalists, lunatics, or hippies. Most people will live their entire life eating what everyone else does and will be perfectly happy doing so, but until you've actually gone out and changed your lifestyle and started eating "like a hippy," you can't possibly know whether or not you would feel better than you already do. Eating like a hippy isn't for everyone and neither is starting a startup, but a lot more people would thrive in a startup environment than you think, just as a lot more people really would feel better eating like a hippy. Not everyone will be convinced by Paul's essay, and that's okay. There are parts I disagree with as well, in particular with respect to getting some experience at a company before starting your own. As a whole, though, the essay is consistent with what I've experienced at Y Combinator, and other founders I've talked to agree.

Permalink | Leave a comment  »

]]> http://files.posterous.com/user_profile_pics/225705/Photo_1021.jpg http://posterous.com/users/T7SMgz Ross Boucher boucher Ross Boucher Fri, 22 Feb 2008 18:16:47 -0800 Optimus Maximus http://ross.posterous.com/2008/02/22/optimus-maximus http://ross.posterous.com/2008/02/22/optimus-maximus Those of you who read Engadget, or follow tech blogs, or are otherwise incredibly geeky, have surely heard of the Optimus Maximus. Vaporware for years, Engadget has finally got their hands on one. The verdict?
Typing on it, well, sucks.
This is a shining example of people building tech products that appeal to geeks, but overlooking the most basic, important functions. Sure, it's nice to look at, and it sounds really cool to hot swap your keys. But, if it can't type, then what good is it to anyone? What, I'm supposed to have two keyboards at my desk? One for typing, and one for ... having little pictures? There's a reason the iPhone is also a great phone. At $1500 it might not matter, because only crazy people are going to buy one anyway.

Permalink | Leave a comment  »

]]> http://files.posterous.com/user_profile_pics/225705/Photo_1021.jpg http://posterous.com/users/T7SMgz Ross Boucher boucher Ross Boucher Wed, 20 Feb 2008 22:36:15 -0800 Why I Love Vimeo http://ross.posterous.com/2008/02/20/why-i-love-vimeo http://ross.posterous.com/2008/02/20/why-i-love-vimeo My good friend Brian sent me a link to his demo reel yesterday, which he uploaded to Vimeo. I'd never heard of it before, but I was impressed with the site. The most obvious reason to fall in love with Vimeo is the quality of the videos they are serving up. Default quality looks leaps and bounds better than YouTube's video, but the really great part is that they offer HD video in full 720p. The quality is really amazing. For Brian, this was a no brainer -- after all, who wants their demo reel to be viewed in a super compressed low quality format? Brian used Vimeo to make himself look better, and I decided we should too. We already had YouTube search integration in our upcoming product, so I decided to take a look at Vimeo's API and integrate some results from their site too. It only took about an hour to get everything hooked up and working, using the same system we had already built for YouTube, and the higher quality video really does make our app look better. Since we were going for quality, we wanted to highlight the search results that came from an HD source. Unfortunately, there was no way to determine whether or not a video was HD with the current API. I decided to send an e-mail to the contact listed on the developer pages, Ted Roden. Within minutes, Ted had responded saying that he thought having an HD flag in the response was a great idea, and first thing the next morning, I had a message in my inbox explaining how the new information worked. But the story doesn't end there. A few hours later, after realizing how long our searches were taking, I fired off another e-mail to Ted asking for a few tips to speed things up. You see, the design of their API was such that search results only contained a video id, and a separate call was needed to get the full information for each video object. On top of that, yet another call was needed for thumbnails, and since we use two, that was 3 calls per search result. Needless to say, the overhead from all those requests added up pretty quickly, so I wanted to know if there was another way to get the same job done. Ted responded and asked what information I needed in the search results to do what I was doing, and I let him know. An hour later, he posted this to the Vimeo forums, and sent me a message letting me know that the search results could now return all the information about every video object in one call. The average time for one of our searches was sped up by an order of magnitude! And so I just want to highlight the excellent support I received from Vimeo, and Ted. Sometimes startups can be really amazing to work with.

Permalink | Leave a comment  »

]]> http://files.posterous.com/user_profile_pics/225705/Photo_1021.jpg http://posterous.com/users/T7SMgz Ross Boucher boucher Ross Boucher Fri, 15 Feb 2008 20:11:49 -0800 Cold Brewed Coffee http://ross.posterous.com/2008/02/15/cold-brewed-coffee http://ross.posterous.com/2008/02/15/cold-brewed-coffee A while ago, the New York Times had an article about cold brewed coffee that peaked my interest. I'm not much of a coffee drinker, but iced coffee is, on occasion, a pretty exceptional summer time drink, so I filed the article in the back of my mind for future reference. Some time later, Francisco, aware of my irrational love for Dunkin' Donuts (or, more accurately, my rational hatred for Krispy Kreme), brought back a few bags of Dunkin' Donuts coffee for me from his trip to New York. Not having a coffee maker, or any desire to drink it really, it sat in the cabinet for a few months, until yesterday. The weather is already pretty nice again here in Cupertino, and combined with the discovery of this article, I had no excuse not to give cold brewed coffee a chance. Substitute taco bell cups (gross) for a couple red cups, recalculate the ingredients proportionally, and I was ready to go. 24 hours later, I'm enjoying a great cup of iced coffee that was practically free (compared with $2.80 at that other coffee place)! A picture's worth a thousand words, so here's 5k (courtesy of iPhone).
Media_httpblogrossbou_waeek
Media_httpblogrossbou_smalc
Media_httpblogrossbou_eirpr
Media_httpblogrossbou_nthcb
Media_httpblogrossbou_audwp

Permalink | Leave a comment  »

]]> http://files.posterous.com/user_profile_pics/225705/Photo_1021.jpg http://posterous.com/users/T7SMgz Ross Boucher boucher Ross Boucher Tue, 12 Feb 2008 00:41:27 -0800 On Browser Share http://ross.posterous.com/2008/02/11/on-browser-share http://ross.posterous.com/2008/02/11/on-browser-share A lot of people working on web applications these days seem to be oblivious to the rest of the world beyond their own team. Naturally, most of these people are using Firefox to do their browsing, and subsequently to do their development and testing as well. This makes sense, given, well, just about everything about Internet Explorer (and the fact that only about 5% of us own macs). Unfortunately, the browsing public at large is nothing like these people. Depending on who you ask, Firefox's share of the browser market hovers somewhere between 15 and 20%, while Internet Explorer dominates with 70% or more (and Safari is slowly building ground at around 6%). Given this, I have to ask, why on earth do developers think its okay to write Firefox only software? If asked, most of them will tell you, "Oh, I'm just a startup, I don't have time to invest in IE," or "the market I'm going after all uses Firefox." I'm not buying. Except for the most demanding of projects, making something work in IE is hardly the burden people make it out to be. Sure you have to spend extra time to workaround the missing pieces, or the flawed implementations, but if you wait until after you've launched a product, you're going to have to spend weeks or months in "compatibility" development, where you write zero new features. Meanwhile, you're turning away 80% of the potential users of your product, and many of them will never come back. At the other end of the spectrum, it's highly doubtful you're really targeting people who only use Firefox. Even if you had done market research, which you almost certainly haven't at this stage in the game, at the very least you're likely talking about a group of people who use Firefox and Safari, in which case you really should have put in the extra effort to at least make Safari work. The differences between Firefox and Safari, at this point, are miniscule -- in most cases it is trivial to make something that works in Firefox work in Safari. And if you buy the argument that Safari users are very similar on average to Firefox users, you are still excluding as much as a quarter of your potential market not working in Safari. But, like I said, this probably doesn't even apply to you, because it's highly unlikely you can know for sure what percentage of potential users are using Internet Explorer. Of course, there may be exceptions. Legitimately complex applications, or incredibly focused markets, for example, might validate focusing on Firefox alone (or preferably with Safari). A good example of this is recently launched Heroku. This team has tackled a hard problem on the client side (an in browser text editor) that could be difficult to reproduce faithfully in Internet Explorer. Furthermore, by targeting Ruby on Rails developers specifically, they probably are talking about a smaller market that is likely to use Firefox more than Internet Explorer. But even Heroku, who's goal is to bring Rails to the kind of people who don't want to go through the hassles of deployment on their own, is probably shutting out at least some potential users who would honestly try it out, if it worked in the browser they were using. It is difficult to say how many, but analyzing their own traffic, they may be able to get a good idea. (Aside: since the rails community seems particularly Mac friendly, this might make an even stronger case for having Safari support, though, in some of my own research, it has seemed that some of the Firefox features they rely on for text selection may legitimately not have duplicates in Safari). Ironically enough, many of the same people who would advocate Firefox only support, would outright refuse to use a service that was Internet Explorer only. Yet somehow, they cannot manage to imagine a user who would not be immediately willing to go download a new browser, and fundamentally change their online behavior, just at the opportunity to try out the "next big thing" on the web.

Permalink | Leave a comment  »

]]> http://files.posterous.com/user_profile_pics/225705/Photo_1021.jpg http://posterous.com/users/T7SMgz Ross Boucher boucher Ross Boucher Mon, 11 Feb 2008 09:57:10 -0800 What's Old is New http://ross.posterous.com/whats-old-is-new-17 http://ross.posterous.com/whats-old-is-new-17 I don't have anything to say today, except the fact that I've gotten rid of some cruft from the site, in the beginnings of bringing it back. I even linked it up to rossboucher.com instead of having it relegated to blog.rossboucher.com. Thus, in theory at least, I will force myself to use it. Major changes: a new header image (taken at the conservatory in Golden Gate Park), no more silly navigation to a bunch of useless empty pages, and a solid color background. All in all, not much, but its enough of a refresh to satisfy my desire to redo the whole thing for a while, which allows me to focus on the more important things going on right now (which we'll discuss later). That's all for now.

Permalink | Leave a comment  »

]]> http://files.posterous.com/user_profile_pics/225705/Photo_1021.jpg http://posterous.com/users/T7SMgz Ross Boucher boucher Ross Boucher