Fog Creek Software
Discussion Board




Making web applications work better

First some comments on Joel's items:

"Improved inline editing (step one: make contentEditable work in Gecko just like it does in IE 5.5+)"

Actually I think we should kill off contentEditable and whatever Gecko currently has.  It seems that contentEditable is really hard to use; most rich text entry boxes based on that are buggy.  It needs a pound of Javascript to make it work.  I propose adding fairly rich textarea (it's a form field) that has very simple methods for performing operations.

"Javascript features to do fast REST queries back to the server, so I can implement things like a lush spell checker with the dictionary on the server."

I agree that Javascript needs some simple ways to communicate back with the server.  I'd like to see two things: one is a simple method for making POST and GET queries to URLs on any server and returning the results in a string.  The second is a socket connection to the server that the page was loaded from.  These two interaction features should handle everything that is needed and be relatively secure.

"A rich set of standard controls for application development that provide better ways to upload files, better ways to drag and drop with the desktop, etc"

I agree.  But we shouldn't do too hog wild in built in controls.  Joel proposes "TreeView and ListView controls, and a standard way to make a toolbar/button bar" but I think that's too much.  Right now we can get TreeView and ListView controls build in DHTML and they look good and work good.  The only problem is, they aren't easily reusable and dropping them on a page is pain.

What we need are reusable "controls" that are written in DHTML.  These controls can be built up of HTML or, as Joel proposes, via a simple "canvas".  Users of the control can then just add it to the form as so:

<control type="TreeView" name="simpleList">
  <group caption="Item 1" value="1">
    <item caption = "child 1" value="2" />
    <item caption = "child 1" value="3" />
  </group>
</control>

The code to implement the Tree control is included elsewhere and can retrieve the contents of the <control> tag as string.  The control has events that fire when the form is submitted so that it can add it's values to the stream.

I would like to see a ComboBox added to the built in controls.  I'd also like to see something better for handling files -- perhaps access to the operating systems load and save dialogs.

"Compiled or compressed JavaScript, so that web applications can use really large amounts of JavaScript with decent performance"

JavaScript and HTML is generally already gz-encoded from the server so it's already transmitted in compressed form.  But I would like to see compiled Javascript.  The main reason is that there is a lot you can do with a compiled step.  Javascript compilers could understand browser compatibility and issue warnings or even automatically add alternative code. 

Also rather than being Javascript, I think it should be some kind of dynamic neutral encoding so that other languages could be used (or new languages developed).  Possibly even Visual Basic like languages where the source isn't code but rather a visual design and is transformed into compiled output and XHTML.  This neutral encoding should be designed entirely for ease of implementation and future-compatibiliy (not performance).

But even more important than compiled Javascript, I'd like semi-persistent (dropped in the cache) downloadable modules.  These modules could be controls, dialogs, code, or other reusable elements.  So if I go to www.joelonsoftware.com these components are downloaded (in the background if possible) and available to all the pages.  Then I can reference any code or HTML in those modules from my page.

"Better standardized windowing features. At the very least I'd like modal and modeless dialogs that pop up instantly,"

I'd totally love to see both modal (with some way to entire abort and dismiss -- the web is hostile) and modeless dialogs.  For the dialogs, I'd like to see them entirely contained with the browser frame -- that is, I don't want a web application to be able to open 50 dialogs on my desktop.

"a standard way to do a menu inside a web page (with ONE consistent UI, not everybody's wacky DHTML menu that are all a bit different)"

Ultimately what this is proposing is something like XUL where you're no longer visiting a web page in a browser.  Instead, all the browser features are gone (menubar, address bar, toolbar, etc) and instead you're looking at something very much like a regular application window.  And, of course, such a Window should have a native menu and maybe even native toolbars.  I reserve judgement on whether or not this is a good idea.

"A far richer set of events. At the very least I need to be able to use the entire keyboard. Combined with #6 I should be able to develop any custom control I want that is 100% client side."

Some people have thought that being able to use the entire keyboard is bad but I don't think so.  Obviously ALT-F4 and other system-level keys will not be trappable.  Being able to build your own controls with a canvas is a great idea.

"Things that don't have any chance of degrading gracefully on legacy browsers. You have to be able to construct an interface that gets better if you install Firefox, but still works on IE, without too much testing on the part of the developer."

If you are using something like the <control> tag you just have to add a <nosupported> subtag that is ignored by supported browsers and rendered by older browsers.  But honestly, if you're trying to accomplish something complex, you just simply won't be able to be backwards compatible within a page -- you're better off just presenting another page entirely to other browsers.

Now for some other ideas that have been proposed in this forum and elsewhere:

We need some kind of decent client-side persistence.  I should be able to set some variables on one page and have those same variables on the next page.  It's really as simple as that.  For security, they should have the same restrictions as cookies: When they are set, the domain and subdirectory it's valid for are provided. 

We need a method to prevent users from leaving pages before they have saved.  I've typed this entire message and one slip of the backspace key when this textarea doesn't have the focus and I'm hosed.  The tricky part will be to design this so that a user cannot be trapped in a single page forever.  Simple solution: allow only a modal dialog to presented in this case and if the user aborts the modal dialog (we must allow users to abort them) then the page change occurs.

I'd like see the onenterbackwards and onenterforwards events from WAP/WML brought over to HTML.  These events would fire when the page is entered to from the back button or the forwards button respectively. 

I'd also like to see the history stack that WAP/WML has. In WML, it's possible to mark a particular page in the history (push it onto a stack) and then unroll the history to that page.  This is used in the following way:

1) You're viewing listing of items
2) You click to edit an item, takes you to edit page.
4) You submit and return to the list.

Now with normal HTML all this is done in the forwards direction -- so when the user returns to the list and clicks the back button he is returned to the item he just edited.  Most likely, he wanted to return to the page before step #1.  In WML, you could push the listing page onto the stack and on the submission return to that page in the history.  When the user clicks the back button he gets the correct page.  And since it's a stack, it doesn't matter how many pages step #2 is.

Comments?  Suggestions?  (I really must get to work now)

Almost Anonymous
Friday, June 18, 2004

"I'd like to see two things: one is a simple method for making POST and GET queries to URLs on any server and returning the results in a string."

Can't you sort of do that now with frames?

Andrew Burton
Friday, June 18, 2004

I really miss better file uploading oportunities. I'd like to select multiple files at once for upload and upload bigger files than 8MB.

Andres
Friday, June 18, 2004

Andrew Burton: "Can't you sort of do that now with frames?"

Yes, but that's a HACK -- which is reason enough.  But if you want another reason: If you try and put XML in a frame without a style sheet most browsers will format it into HTML(!!) and so you can't get the original document.

There's been alot of talk about embedding SOAP and other high-level protocols in the browser.  I think that's a bad idea.  I'm also against embedding large complex controls (like TreeView).  The reason is that once you implement these high-level items you've immediately limited support to those.  If we had a generic URL-Fetch API we could implement SOAP and XML-RPC and My-Simple-RPC!  If we have a generic facility for building controls, then we can build TreeViews, ListViews, and My-Tree-Like-Grid!  Fixed controls and protocols are not future proof.

Almost Anonymous
Friday, June 18, 2004

Guys check out XmlHttpRequest, both browsers support it in one way or another and it lets you POST and GET to your server from Javascript without resorting to iframes.

Matthew Lock
Friday, June 18, 2004

My suggestion for making web applications: give me the ability to add type to an input.  There should be built in type validation - we shouldnt have to clutter our page with javascript for this.

-g

Greg
Monday, July 12, 2004

*  Recent Topics

*  Fog Creek Home