I just rewrote portions of the first few sections of the XUL Tutorial (sections 1.1 to 1.4). Hopefully, this will make the chrome system clearer. Some people were having problems understanding how the chrome URL relates to files. In addition, I've added a bit more detail about the difference between chrome and non-chrome content, as well as a bit about XUL documents in general.
10:27 PM Some UI for a Remote XUL whitelist
Some recent remote XUL discussion (here and here) inspired me to create some dialogs for a whitelisting UI for web sites.
When a site wants extra permission:
Clicking the OK button does not allow the application to do privileged operations. Instead, the user must click the Allow button and then click Add in the resulting whitelist dialog, as shown here:
The idea is that the user has to click a series of buttons before the site can do anything, yet isn't particularly tedious. In my opinion, the icons, which are just the site icons, make the dialog look nicer and, in some cases, allows sites to be distinguished better.
1:04 AM Server Push and Server Sockets
Someone was asking about server sockets, so I wrote some info about how to use them in Mozilla. In addition, this document describes how to use the 'multipart/x-mixed-replace' content type with XMLHttpRequest. In case you're wondering, both features may be used as a form of sending data from a server to a browser client.
11:15 PM Web Applications Workshop Minutes
Minutes of the recent W3C Workshop on Web Applications and Compound Documents (Part 1 and Part 2). Interesting read.
3:13 PM What is the WHAT?
I think I've finally understood what the new WHAT group is trying to accomplish. At first, I thought it was intended to be a group for defining ways to create sophisticated applications but using HTML. In effect, what one might do with XUL, or what Macromedia wants to do with Flash, or what many at the recent Web Applications Workshop want to do overall with other languages. That is, build standalone applications separate of browsers that communicate to servers. I was a bit worried that WHAT was essentially trying to do the same thing but use HTML instead, which wouldn't be a good idea. This, I think, is fortunately not the case.
Instead, WHAT is just trying to build a few additional features onto HTML, CSS and the DOM to allow more sophisticated interaction, perhaps what XHTML really should be. Specifically, the goal is to allow better interfaces for web pages and not to build applications like image editors or web browsers. This will certainly be simpler for web developers and is a much better transition. I personally would like to see HTML include much more document oriented features, and even XHTML 2.0 doesn't provide much of this.
The folks in the standalone web applications camp that prefer using XForms and SVG and the like seem to want to build an entire platform. That's fine, but that is rather a lot of work, and may not have a lot of return value considering that there are lots of platforms already. The biggest disadvantage is that they are starting fresh without much of an existing base to build on. Sure, they have XHTML and SVG and the like, but these are fairly new, don't have a lot of implementations to 'harden' them and are hardly the right languages to form the basis of an application. For instance, I don't know many popular Windows or Mac applications (or those of other platforms) that actually have any vector graphics in them. XForms may be sophisticated, but unfortunately a form is only one style of UI, one which doesn't necessarily fit all of the web applications that the advocates want people to create with it. It fits well when the UI is a set of fields to fill out (which is why it's called a form, since it mirrors the paper forms you need to fill out in order to communicate with the government.) Very few applications outside of web pages use this UI paradigm however. For this, an event model is generally more appropriate, since the user interacts with the UI in a fairly random fashion. Click a button here, choose a menu item there, that sort of thing. Which is why I think server side events are a good thing. In fact, I had started an implementation of XUP a while ago; I wrote everything except the part that required SOAP.
I was also wondering how all of this fit into Mozilla's plans described at the recent developer day. In fact, it does. Mozilla as a platform has the advantage that it's not starting fresh -- I doubt they want to go through that again -- it already has a base which implements much of what is necessary. For instance, Mozilla already implements much of the features listed in the requirements section of the WHAT's Web Applications work. As a platform, Mozilla succeeds since it is actually implemented and has much of the needs of a platform already in place. The WHAT's new features will be a benefit to Mozilla as a web browser and as a platform. And, atcually, due to XUL's design and implementation, don't conflict much at all.
One of the interesting aspects about XUL is that there is very little native code in its implementation. All of the box layout code could be considered part of CSS, since these layout types can be used outside of XUL as well. In fact, this flexible box model is already being worked on as part of CSS. The only code of any considerable size specific to XUL is the template builder and the tree widget, as well as some smaller features such as overlays and listbox handling. The template builder and overlays are perhaps application specific while the tree and listbox code could be adapted in a compatible manner to be useful outisde of XUL.
The WHAT is specifically not trying to define any eleborate UI widgets such as toolbars or progress meters and so on. In fact, those would be better defined in libraries of XBL, much as XUL widgets are currently. I think the eventual goal is to make as much as possible be implementable in CSS or XBL such that HTML, XUL and other languages, even XForms, could build upon them. In addition DOM APIs to do drag and drop, server side events and popups would be available to use. With all of these available in the base browsers, it might be possible for someone to implement XUL in another browser such as Opera, simply by porting the XBL to that browser. OK, this isn't really the goal, but it would be a good indicator that the base web application features were of sufficent capability.
11:18 PM Some Web Application thoughts
Here are a number of thoughts on web applications, inspired from reading the recent discussions of the W3C Workshop on Web Applications.
- The people who will be making the user interfaces for web applications in the future will be the same people who currently make the user interfaces for web sites today.
- The people who make the user interfaces for web sites today are not very technical and frequently have non-technical backgrounds. The people who do have technical programmer-type knowledge are confined to writing server-side code.
- Most of the programmers who work on a web site are young (20-35), the younger of which have no experience working on software that isn't for a web site. Usablity and accessibilty are generally poorer on web sites and will continue to be so as less of the required expertise to improve usablity and accessibilty can be transfered to new developers from experienced developers, since such experience doesn't exist.
- The technical department (engineering group as it's often called) working on the server side code tends to prefer to leave the user interface of a web site (the HTML and CSS) to the other group (the web designers) as these tasks do not require programming skill. In the future world of web applications, the 'engineering group' will likely do the same.
- No existing web designer currently nor ever will understand any technology that begins with the letter X. Thus, if the people who will be making web application UI (the web designers) don't understand these technologies, those technologies will have a hard time getting anywhere.
- Technologies that are seeking a market are very likely to fail. Technologies that have a market seeking it are very likely to succeed. The important market is always the end user and never those making the implementations or the tools. New technologies or specifications with few to no implementations are of the former category. The latter tends to have less well-defined specifications, is poorly implemented or is less powerful, yet since there is demand for it, is actually used. Consider HTML, or email, both of which just appeared and then defined in more detail over time.
- Developers have a tendency to believe that an application that requires communication between a client desktop machine and a server is best run within a browser, leading to applications that require a browser on a specific platform to operate, despite that development costs might be lower and the application would have a better user interface if it were written directly using the platform toolkit.
So what will generally happen in the future is that client-server applications will be run in a browser and they will be just as awful to use as they are today.
Perhaps I'll have more thoughts later.
4:03 PM Effective use of text replication tools
11:55 AM I'm tired of updating Mozilla
The Mozilla Foundation has finally managed to release an alpha version of a later release before the previous release. What does this mean to end users? It means confusion as people don't know what to download. What does this mean to people who want to file bugs? It means that unless you've been involved with the project for a while, you have no idea what you should be testing. What does it mean to extension authors? It means that your users will be using 25 different versions of Mozilla. Is there a way to test your extension or theme with all of these? No. Same goes with web sites actually. They've been known to break between versions. I know of one web application that only worked on Netscape Communicator 4.06 and no other version. Of course, if you're an extension author, you could try only building only to the stable API releases. Do you know which the most recent one is? (Hint: The version number begins with 1 and ends with .4) I doubt many people knew that, since this isn't indicated anywhere. But, of course, don't file bugs on it, since it's too old.
In the world of Mozilla, software that was released two months ago is considered old and outdated. For other software, two months is considered new. If your file a bug on a build that is a month old, you get chastised for using an old product and the bug often gets marked invalid. Sure, some bugs are invalid (or duplicates) since they were fixed recently; many others aren't.
I stopped upgrading Mozilla a long time ago, opting instead for an occasional update. I used Mozilla 1.4 up until a month after 1.6 was released. I could have updated to get a few features or security fixes, but I didn't. Why? I'm tired of updating software. And just for the Firefox crowd, I'm also using Firebird 0.7 (still the old name). Why don't I update? I'm tired of updating software. Will I update to 1.7 or 1.8 or Firefox 1.0? I don't know. Perhaps if it's the one or two days a year when I'm not tired of updating software, I will.
I used to get excited when a new version of something arrived. I don't any more, as the new version is more of the same. Ordinary users aren't going to update software either. (People who have at some point posted a message on Mozillazine.org aren't ordinary users in this sense). They're not going to update unless there's a compelling reason to do so. And that reason has to be more than my urge not to update since I'm tired of updating software.
This is also why people don't switch from IE. Popup blocking is the only real advantage that any end user would care about, and that advantage is going away with the next IE update. Mozilla has lots of great features like tabs and type ahead find and DOM inspectors, but the reality is that advantages don't sell a product. Actually, the disadvantages of the competitor are what makes people switch. An IE user might say "Look at all these popups and ads; this makes it very difficult to use; perhaps there's something better out there." Then, they might start using Mozilla (or Firefox). However, I can't imagine any ordinary user saying. "Look at how I have to select the Find command and then type in what I want to find on the page. I wish there was a way I could find text by pressing the slash key and then typing what I want and having it find the text incrementally." No user thinks this way, since most people aren't creative enough to think of the easier way. You have to show them the easier way. And make sure to show them, since ordinary users won't know which of the many Mozilla versions to try.
I'm sure there's some reason for having a new release or pseudo release every month. Perhaps it's for QA purposes so that people who aren't tired of updating software will always get the latest versions and test them. Maybe it's to get more feedback as people who aren't tired of updating software will always get the latest versions and provide feedback. Maybe it's for marketing purposes so that slashdot and other tech news sites post articles about the newest release. I'm not sure about the latter. Mozilla has so many releases that it hardly qualifies as news any more. Reporting about a Mozilla release is like reporting that the month ended.
In my opinion, if there is still a need for frequent releases, why not make the version numbering more sensible and release ten alphas and betas, then release a final build once a year or every nine months, like most other sofware? I'm sure someone will tell me that I'm all wrong, but, as an end user, I'm tired of updating software.