Dylan Schiemann

I am currently contributing code and effort to the Dojo Toolkit project. The site was updated today to reveal a little about what we’re doing.

Numerous sites capture the onload event handler to move focus to a specific form field, usually for logging in (for example, My Yahoo!). Other sites will even clear the current text in the field in addition to providing focus (for example, American Express). However, they both exhibit a really annoying behavior: when the page is slow to load, the user will usually click in the field and start typing in their login information, only to be interrupted with a change in focus when the page finally loads. A significant improvement to usability would be to first check to see what the current focus is, and only set the focus if it is not already set to a form element. This change is really quite simple, and I am surprised that so many major sites do not consider this when providing onload focusing.

The press has been speculating since the google ipo that there will now be a mass exodus of talent due to the new found wealth of google’s employees. So the press, in wanting to prove their point, believe they have their first data point with the departure of Evan Williams. However, anyone who can actually read should check out Evan’s blog entry and realize that this is not necessarily an indicator of things to come for google.

Quirksmode.org has a great article on how to create the illusion of a styled input type=”file” element. This is a problem I tried to solve years ago, before the options presented here were really viable. This trick will probably put Michael McGrady on the map if he wasn’t already.

In 1954, this computer of the future (source) was predicted for 2004. One of my friends deadpanned: “I always wanted a steering wheel for my computer”

My thoughts on how to save SVG.

Update: I have been persuaded by the community to point out that SVG is not dead, is gaining strong support in the cell phone market, and will finally be enabled by default in mozilla 1.8. SVG itself is a great and very promising technology… I am simply frustrated by the current lack of widespread browser support. And maybe Adobe is considering open sourcing their SVG implementation based on the slashdot story today about Adobe forming an open source strategy.

Scalable Vector Graphics (SVG) is a promising recommendation, providing a rich XML syntax and language specific DOM bindings for the drawing of graphics. However, this standard has stagnated for the past several years for at least the following reasons:

• Lack of native support in mainstream browsers (mozilla is working on partial support, with widespread release rumored for late 2004 or early 2005)
• Fragmentation and apathy in the plug-in vendor market (Adobe has not publically released a signficant new version of non pre-alpha code since 2001, Corel has discontinued development, etc.)
• The fear of Microsoft's XAML (and WVG) has prevented development effort (one of the leading SVG JavaScript developers, Kevin Lindsey, has shifted his efforts to XAML/WVG, and of course Microsoft is not supporting the SVG recommendation)
• Major open source browser vendors have not embraced the recommendation, complaining that the specification is flawed and too complicated (while they may be correct, they have done too little to fix the spec.; it can be argued that the SVG Working Group is one of the few remaining W3C groups that actually tries to tackle the hard and interesting problems). A more modular approach the recommendation than what they today would be useful if browser vendors were involved in this process.
• Adobe, a company that made the strongest initial push for SVG adoption, has not devoted resources to the project that are needed for it to succeed. In fact, their organizational direction for SVG is at best unknown, and at worst abandoned.
• Apple prefers to ignore SVG, and instead implement their own vector specifications for vector graphics in Keynote, and client-side drawing with the proposed canvas element, that provides parametric drawing capabilities within a box element.

The current situation of SVG support is very disappointing, as I personally know a couple of the people that worked on the team to promote SVG. I have no insider information about their current plans. To me, it appears that Adobe has effectively abandoned the market with an incomplete implementation of an SVG viewer, one that remains the best and most widely used on the market, thus preventing other companies from investing resources into similar projects for fear of Adobe restarting development efforts. Community support is waning as champions of SVG such as Michael Bierman and Niklas have not updated their SVG blogs this year, probably because there is no current progress to report. SVG Open 2004 happened this past week, yet the descriptions of the talks seem terribly out of touch with the market (i.e. "since SVG is widely used on the WWW"). Most uses of SVG are currently limited to intranet applications, server applications with Batik, demo sites, or rare instances where sites offer a compelling enough benefit that requires the end user to install an SVG viewer.

So is it possible to revive this once promising recommendation? Maybe. A unique solution in my mind would be for Adobe to donate their codebase to mozilla, with the stipulation that they continue to support a plug-in solution as well as a native solution. The plug-in could be done through the Gecko Runtime Environment. This would offer many benefits to Adobe and the world:

• Adobe's codebase will not be lost to the world, and Adobe can still profit off of Illustrator sales.
• mozilla would be asked to manage the codebase as both a stand-alone plugin for any browser, and as a module to add native support to browsers such as mozilla, safari, and opera. And they could offer the plugin as a backport for older versions of mozilla.
• Adobe would develop goodwill with the open source community, and gain the other benefits of open source such as reduced maintenance cost for maintaining the SVG code base through third party development, and driving the direction of the product.
• Adobe would no thave to deal with the normal headaches of setting up community support for an open source project.

This of course would depend on the Adobe codebase being something that mozilla could actually use, which I am in no position to evaluate, even if I had a copy of their source code, which I do not. However, it seems like a dramatic solution such as this one is the only way to save SVG in the browser.

How do you measure success in the world of blogging? Well, in the case of Athletics Nation, you can say you’re a success when you land something really unique… in this case, an exclusive interview with Billy Beane, the well-known GM of the Oakland A’s.

Recap of the BayChi Rich Internet Applications Discussion on August 10 at PARC.

Reading the technology tea-leaves: Is a Rich Internet Application in your future?
David Temkin, Laszlo Systems
Mike Sundermeyer, Macromedia
Jim Hobart, Classic Systems Solutions
Ethan Diamond and Iain Lamb, Oddpost
PARC

This seminar began with an opening set of slides with way too much text and way too little time to read them. Several quotes were provided from previous BayChi seminars as far back as 1995 discussing the limitations of web based applications and technologies in delivering a smooth, fluid end-user experience. The question 'Does the navigation metaphor apply?' was asked, meaning does the traditional web-based hierarchical navigation structure apply to a web application, or does something more like a sliding windows metaphor make more sense, where information is revealed and concealed in response to user interactivity, without having to make additional server requests to display views. My response to this question is that it of course depends on the type and purpose of the application and its users.

The first panel speaker was Jim Hobart with a presentation titled: "Rich Internet Applications, Will they Enable or Disable us?' His company, Classic Systems Solutions, provides a corporate usability portal, training, consulting, usability lab, and other services related to usability of web applications.

Jim describes a Rich Internet Application as one that is complex, with a whole new level of interactivity. In 1999, when he was first involved with a large organization to build a web application, he told the client that there were two options: sucks, or sucks less. He described the natural progression of software applications as a function of usability such that web applications and web sites were a step back in terms of usability when compared to traditional client/server applications, with their main advantage being wide availability. He expects that the next wave of internet applications will have the flexibility and interface usability comparable or better than traditional software applications.

He describes the ultimate goal of applications being that of user synchronicity. By this he means getting users in the zone, achieving true productivity, working in the present, leveraging human potential. He describes a situation when everything just works, rather than the current web-based experience of click, wait, click, wait, click, wait.

The most powerful portion of this talk was the videos showing the testing of people in their usability lab. Three tests were shown: applications for selecting a camera, add a contact to a PIM, and choosing a paint scheme for a kitchen. They showed that the taskflow metaphor, i.e. trying to make the experience mimic the real world isn't necessarily a good thing, especially when it comes to replicating the information overload found by most shopping experiences. The paint selection app reminded me of the IKEA app for putting together a room of office furniture. Unfortunately, I felt that the usability testing wasn&3039;t as useful as it could have been because much of the commentary was focused on clearly broken interface features. Maybe those issues were not obvious before the testing, but I would have rather heard more information about the actual user experience rather than the issues with a slider that did not have sufficient precision.

Conclusions from this talk:

• study task flows
• be careful with metaphors
• keep it simple
• basics still apply

The next speaker was Mike Sundermeyer from Macromedia, giving a talk titled: "The Rich Internet Application Experience". Macromedia has designed ~50 applications, using the results of these designs to influence the design of their development software.

The main thing he said that I strongly agree with is that experience matters… meaning that how you provide the service and how your user feels while they're doing it is as important as the product actually working.

He then showed an Evolution of the web diagram from Forrester (very much like an evolution of man diagram), which implies that the web site is a regression from the client/server experience. The vision of the Rich Internet Application is bringing the greatness of past paradigms (client/server apps) with the reach and flexibility of the web. Of course, I had to wonder to myself the following: if web apps are so important to Macromedia, why are none of their development applications web applications? Mike then went on to make points about user experience:

• Online relationships are replacing in person digital relationships.
• Interface specific to their problem…
• Switching costs are low: so experience matters even more.
• Experience can yield significant ROI when used appropriately. (faster, increased revenue, less support calls, etc.)
• A great experience is useful, usable, and desirable.

He then asked the question: "What are RIAs good for" His answer was multi-step processes, expressing complex relationships, user customization, convergence, searching, filtering, sorting, persistence, offline, emotional appeal, brand, etc.

He also emphasized the separation of look and feel, implying that applications should strive to maintain their uniquely branded look while still trying to provide a familiar response and feedback mechanism for a navigation interface. However, I felt that their demos and examples were really about impressive animations and transitions, and less about building intuitive applications. It seems that they have done a great job with very low end applications, but do not attempt to address anything that is data intensive.

Macromedia is working on defining consistent patterns that solve problems across multiple use cases. My thought at this time was that the main benefit of the Macromedia web applications was adding more tactile feedback in response to user interaction, rather than the dreaded white screen between click and load of very traditional web applications..

Next up was David Temkin with the talk: "What's an RIA?" He began answering this question with the thought that it is a new application distribution technique (browse rather than install), a new development methodology (markup meets object-oriented programming), and a new user experience (best of web, best of GUIs, and more)

Their company delivers a platform for developing and deploying RIAs. Their client allows for flexible and consistent rendering across platforms, zero-install on 96% of browsers, and persistent UI across server roundtrips. They offer a standards-based platform, declarative xml for GUI, xml and xpath for data integration, JavaScript, XInclude, no flash authoring/ActionScript, Flash APIs. Their applications offer direct manipulation, windowing, keyboard control, double click, menus. So yes RIA can duplicate class Windows GUI, but that is not what the world wants. While they do have somewhat of the right idea in offering standards-based input, you are still locked into their technology and delivery mechanism. I do expect that as the market matures, they will have no choice but to expand to offer versions that also deliver XAML and SVG-based applications. If they do this, then they may have a more open, viable platform.

They emphasize the importance of occasional-use applications as this is what the consumer web is about. They make the point that there are different design considerations than normal applications, and that efficiency is not a be-all/end-all. I disagree with this point, as while users enjoy being entertained, it should not be gratuitous, or obviously wasteful of their time. What Laszlo offers that we (meaning DHTML/DOM/SVG developers) don't currently is solid animation and media integration.

David then presented demos of an earthlink start app and a kodak photo story teller, with an emphasis on their tab panel. He demonstrated their efficient use of space, continuous and transient transitions. Key points of their experience included expanding items in place, transiting to the view, and nice use of visual queuing to show how things are related. He then made the point that spatial interfaces are being replaced by querying interface, such as in rich web mail. He then gave some totally bogus information about how much better their web mail app is over DHTML e-mail… he obviously chose to ignore Gmail and Oddpost.

He concluded that RIAs enable a sea-change (more functionality, more flexibility, seamless integration of functionality, content, branding communication). He said that their platform has the goal of enabling engineers to embrace innovative UIs, making it very hard for an engineer to tell a designer that something cannot be done, empowering engineers who are serious about interactive applications, and enabling designers who can break out of the page model. In general, I agree with the message he had, but I just did not see his message matching up with what he showed. In other words, a great sales pitch for a products that does not live up to the message.

The final speaker was Ethan Diamond who co-founded Oddpost about 4 years ago, which was recently acquired by Yahoo! Ethan was by far the most entertaining speaker, though his attempt to demo a blog that ended up having an S&M photo was mortifying for him, and very funny. His talk was focused on Oddpost's features and benefits such as the application always being the latest version, requiring no backups, and having data accessible from everywhere. He asked why real apps are still tied to the desktop, and why most web apps are still slow with bad UI. He began his entry into this field at halfbrain working on a spreadsheet that worked inside a web browser. The demo of Oddpost was good… it loads quickly, with the entire app about 150k, all in DHTML, and then using xmlHttpRequest calls for changes/updates/etc. It looks like a desktop app, performs like a desktop application. Progressive filtering is done on the client. One cool feature: Generate subject… messages are donated by the user base… click a button to get a randomly selected message subject. This was quite possibly the most ideal time for his talk as it was right after the people who said that DHTML applications were too slow, and he showed that this was simply not the case. He also showed a very quick demo of Oddpost finally working in mozilla firefox.

The question and answer session was a bit weak, with most of the speakers avoiding the more difficult questions. We talked with Ethan after the talk for a few minutes. Overall, it was an interesting and informative talk, and shed some insight into both the general market perceptions of these types of applications, and also how various companies are selling the story of sophisticated internet applications.

The day began at Google building 44 with a brief introduction by Mitchell Baker about how well the mozilla foundation is doing. It was also rumored that mozilla is going to leave the software business and enter the t-shirt business after selling an astounding 15,000 shirts at Linux World and OSCON.

The mozilla developer day began at Google building 44 with a brief introduction by Mitchell Baker and Chris Hofmann about how well the mozilla foundation is doing. It was also rumored that mozilla is going to leave the software business and enter the t-shirt business after selling an astounding 15,000 shirts at Linux World and OSCON.

The first real talk was given my Mike Shaver and Brendan Eich (the original author of the JavaScript language). Neither of them had any sleep prior to their talk so it was a very amusing, humorous, and delerious talk about the current plans for mozilla (Shaver was found at lunch time sleeping on the sofa downstairs). Key points made are as follows:

• Some SVG support will ship with a mozilla release around the end of 2004, in either version 1.8 or 1.9
• mozilla 2.0 is targeted for Q4 2005
• They are working on a meta object protocol to share JavaScript across multiple languages (which reminded us of Mark Anderson's JS-DOM for command line JSUnit testing.
• Narcissus – A unified front end for JavaScript
• E4X is coming… not sure I like this (basically it is BEA Systems' syntax for bringing xml concepts to DOM calls to bring brevity to some DOM calls for things like traversals, literals, filtering, and querying. For example, document..someElement uses .. to represent a descendant operator much like an xpath call.
• They're looking to add some of the what-wg extensions to forms such as Web Forms 2 and Web Apps 1, and also XForms Basic.
• As shown with their browser-based presentation, a prototype for the apple:canvas element was developed this week and provides web developers with a quick and dirty way to do drawing and animations from JavaScript as a short term solution until SVG support arrives.

The next speaker was Robert O'Callahan who showed some of the more recent advances with mozilla, including how to create a transparent window with xul apps, and also showing some svg examples. He expects that mozilla 1.8 or 1.9 will contain a version of mozilla with svg enabled that has full integration with DOM and CSS. There was also a demonstration of an implementation for the CSS 3 Multicolumn layout proposal.

Accessibility in web sites and web applications was the subject of the next talk by Aaron Leventhal… check out the mozilla accessibility web site. Basically in order for things to be fully accessible, there needs to be a way to specify the who, what, where, when, and state of every object in the DOM. Demonstrations were provided of mozilla using speech readers. Comments were made that mozilla does not make it easy for JavaScript developers to write accessible applications. I asked a question and received the expected response that mozilla keeps things in DOM order, not in the visual order as manipulated by CSS. As I type this, I wonder what happens when you set display:none on an element… or what about visibility:hidden?

The W3C Dynamic Web Content Task Force has been set up to address some of these issues. mozilla recently added code to make any div or span focusable… simply set the tabIndex attribute to -1 so that it isn’t in the tab order, but is still a focusable element.

We then broke for lunch. We stood around and talked with Brendan Eich for a few minutes. As good as the Google catered lunch looked, Chris Wetherell of Google has other plans for us. He gave us (Alex, David and myself) the tour of Google, showing us around the very hip Google offices, showing us the amazing Google Cafe which shows the world how cafeteria food could be done. It reminded me of a simplfied version of the Marche Movenpick that with a little less decor that I enjoyed so much last year in Toronto and Montreal. Chris is the interface developer for some of the more interesting features found in gmail and blogger. The click-screen NDA that I signed doesn't let me say more than this really.

We were a little late returning from lunch, and then ran into Asa Dotzler and Jesse Ruderman in the hallway and had a great talk about mozilla, web developers, features, and more. For those that don't know, Jesse runs one of the best (if not the best) site for web developer bookmarklets, and Asa is a very persuasive evangelist for mozilla.

So after missing the Nigel McFarlane talk, we made it back into the main room in time for Bob Clary's very interesting talk on cross-browser compatibility. Bob and I talked many times a few years ago about cross-browser issues so it was great to finally meet him in person. Bob has been working on a very intriguing project called mozilla-spiders that allows testing of CSS, JavaScript, and other cool things from a XUL app. One thing that is really neat is that you can automate the testing of event handlers on every object in a document. It was also cool in that we learned how to receive css parsing error messages.

Robert returned to the stage to discuss backwards compatibility issues with mozilla… basically asking for input as to how mozilla should treat deprecation, fixing broken features, supporting other browsers, etc. They currently take what was widely agreed as a sensible, pragmatic approach. The biggest complaints were that there needs to be better communication about changes to the developer community, and that there should be a way in css to specify the version (David Baron explained why this wasn't supported)… earlier in the day I also explained why css does not currently specify a way to logically combine relative and absolute units logically… I basically came to the conclusion that the thing we really need is a way for getComputedStyle to return a value in units that are specified. David Baron told us to check out Ian Hickson's proposal for a new way to do getComputedStyle.

The final talk was given by Myk Melez on forumzilla which is a suprisingly cool way of adding rss aggregation to the mozilla mail applications. Basically each rss entry is treated as a new mail message, giving you the capability of using mozilla mail as a way to sort and read your rss feeds. Perhaps the coolest thing about this is that the feature was added exclusively with xml, css, and JavaScript, meaning that no additional C++ code was needed to add such significant functionality to mozilla.

Several demos were then given, including a xul app that does some pseudo-real-time shopping comparions, a demo by David Baron showing how to use a new mozilla css extension for user style sheets to specify style based on domain (which I asked the humorous question of, wouldn't this be a way of specifying new rules for mozilla 1.8+ since it was enabled for all css documents.

Then we had to take off so I could catch a plane home for the weekend. Overall it was a very interesting day as it gave me a lot of cool anecdotal information about mozilla in a short amount of time. The Foundation put on a great day and I really enjoyed being there. Thanks to Informatica for allowing me to attend this great event.

Well stated, disturbing quote from TiVo vs. the Broadcast Flag Wavers:

“The MPAA and the NFL phrase their objections as reasonable attempts to err on the side of caution. ‘We’re asking them to just wait awhile, let’s think it out more thoroughly,’ Attaway said.

“But if a programmer or an engineer with a bright idea has to go to Washington, hat in hand and lawyers in tow, to request permission to sell a better product — and is then told ‘just wait awhile’ — we are on our way to suffocating innovation in this country.”