Guy's Blog Blog from January, 2007

I gave a brief talk at last nights' GeekUp meeting in Manchester to show how easy it was to develop desktop-like functionality in the browser using YUI-EXT.

As mentioned in previous articles, we've been refining our sales process so I based the talk on a dialog we'd developed which allows contact details to be edited on invoices, etc. The talk was put together in a rush (30 mins to be precise) so it's not great but it seemed to be well received

I've attached the MS PowerPoint presentation to this page and hastily added some speaker notes - they are a bit choppy because I've had 15 phone calls and 26 emails to deal with whilst writing this blog post! If you just want to see the dialog in action, click here

Questions

The following questions were asked last night...

I assume that if the user doesn't have JavaScript or CSS enabled, it dies horribly?

Yes, if you create it purely from JS. However, yui and yui-ext have Graded Browser Support which handles this nicely - you can define all the content of the dialog in the HTML and then build the dialog by parsing that HTML. In this scenario, if anyone is browsing with JS turned off, they see the basic HTML version of the content - if they have JS turned on, they get the nice dialog

If you didn't have CSS, it would look very ugly but would still be usable.

How big is the JS and how will it affect modem users?

The JS can be a few hundred kilobytes if you include all of it as you'll have libraries for all kinds of things that aren't needed in there. The yui-ext download section has a nifty feature where you can just tick the components you want and it'll compile a single JS file with just those components and their dependancies! This greatly shrinks down the JS file size.

In addition, the yui-ext site also has a JavaScript Builder app which uses Rhino to compress the JS file (removing whitespace, etc) to further shrink it's file size.

Once the JS file has been loaded, it will usually be cached (if you give it an expiry date in the HTML headers then most browsers won't even check for newer versions until that date = even faster) so you only load it once.

Many developers are now including JS on-demand - for example, start with the minimum JS to get your interface up and running and then as the user digs deeper in to it load additional JS and eval() it as an when needed.

So, for a modem user it will add to the load time, but generally only the first time they use it.

How long has this thing been around for?

Not that long and it's one of the webs' best kept secrets!

YAHOO! developed the main yui framework and use it in all their online sites so it's very heavily tested and their documentation is amazing.

However, there's lots of legwork to be done when using the main yui library so Jack Slocum developed yui-ext to make it loads easier to develop desktop-like UIs with minimal effort.

Both libraries are very well documented and are in use in vast numbers of commercial applications. Once you find out about the libraries and start using them, it's impossible to imagine life without them. Just as most techies feel like their limbs are cut off if they don't have an Internet connection, any JS developer will feel similar pain if they don't have something like yui-ext!

How do you deal with timing issues and sequencing?

The libraries have a useful function for calling things based on events, eg. when the HTML document finishes loading - this is really useful in browsers like IE where any DOM manipulation done before the document has loaded will often cause the browser to break. Take a look at the online demo and view source - near the bottom of "address.html" you'll see the commands that trigger when the document has loaded.

There were several more questions, but I need to get back to business...

I'm in a rush, so I'll just post in a chunk of an email conversation - it has some useful info on the somewhat weird way I've developed the form part of the dialog...

Reading through your code it seems you have to do a lot to get a reasonably basic form in place, is using the Template approach the best way to do this (not a criticism, genuine interest as I'm not quite sure what I should be looking at, is this the way to do data binding? I had looked at JSONViews, and there was the XMLDataModel for the grid, but there didn't seem to be any shortcuts for doing common formy-things.

You are indeed correct - yui-ext hasn't covered forms yet. I too looked at the grid stuff and while I could have done the form a lot easier using the grid, it didn't present me with the UI options I wanted so I brewed my own way of doing the form. I've raised the issue with there not currently being dedicated form goodness in yui-ext on their forums and they've confirmed that it is definitely going to be part of a future release (they just got sidetracked with the new drag-drop and treeview stuff).

The reason I used a template to do the form (and a simple descriptor object for the fields in the form) is that I wanted to try and stick to a common yui-ext pattern so that at least some of it was consistent with the rest of the dialog.

If you look at the grid stuff, you'll see that there's a lot of the groundwork for some really amazing form stuff in there - eg. the various field types (number, string, date, etc), each with their associated editors and validation settings, etc. It's a pity they're so wired in to the grid at present but it's only a matter of time before they get more of the limelight. I envisage something similar to my props object (plus some extra properties for each field to define validation, etc) being capable of rapidly creating comprehensive and feature-rich forms just as easy as any other aspect of yui-ext later down the line. So far, forms have been the only thing that have been a PITA in yui-ext and even there not so much of a PITA that it wasn't trivial to overcome.

The dialog had to fit in to an existing architecture so there are certain weird bits in there - with a bit more planning it would have been a lot cleaner. We're using DWR to pull data in and out of the browser and because it remotes the server-side POJOs there is some oddity in the way the form binds to the data. We could have tweaked the server side stuff but decided to just add a little more mince to the dialog for minimum disruption amongst the rest of the system.

I can't help thinking that Rails, could improve my life significantly in terms of templating some of this stuff out, or have I missed a major point <g> Putting aside the fact that all these weird build/foox/.js stuff really doesn't fit the rails structures that well <g>

Yeah, yui-ext would benefit from that. I decided to go the long way because (a) I was remembering how to code after a 2 year break thus wanted to play a little and (b) I wanted everything self-contained in the dialog js. Both yui and yui-ext have a nifty feature whereby you can have HTML (eg. the form markup, etc) embedded in the normal web page and then use JS to parse it and turn it in to something sexy - a good example is shown by the URL below:

http://www.yui-ext.com/deploy/yui-ext/examples/layout/complex.html

As you can see, most of the markup has just been dumped in the HTML and then he's using yui-ext JS to parse that (based on the class names, etc) and turn it in to something altogether more sexy. This is also really useful for accessibility because it means if the browser doesn't have JS a heck of a lot of that stuff will still be usable (not sure about the grid but I'm sure there are similar things).

p.s. the form looked mint

Yeah, I kinda went overkill with it - as it's going to be a very prominent part of our online sales process, we wanted to add some wow-factor so that clients making casual license purchases would also think "hmmm, we should use these guys for development too". We're asking the end-user to make more clicks to edit the details in order to reduce the number of page refreshes (so the process feels much shorter) but we still want them to feel like they are doing fewer clicks - a bit of overkill helped with that also as their mind is distracted by the whizzy form which is almost a reward for them clicking the "Edit" button (well, for the type of clients we have)...

On that kind of subject, here's one of my favourite design articles:

http://www.alistapart.com/articles/flywheelsandfriction/

With this dialog I'm trying to transfer some "kinetic engergy" with the whizzy dialog immediately before the "friction" of editing a form happens. Don't know exactly how it will turn out, but will be interesting none the less

Back in the days of Builder 1.6, we sat down and pondered the specification for Builder 2.0.

We asked ourselves: When moving from one page to the next, why don't we just use AJAX to pull in the page content so there is no page refresh needed?

The answer to this question literally lasts several weeks, if not months. Pain, lots and lots and lots of pain. Sounds simple on the surface but the second you start looking in to it (in the specific context of Builder and Confluence at least), it gets truly complex - especially when you take accessibility requirements in to consideration.

Anyway, it's a question we keep asking ourselves. With every new release of Builder we keep going back to that same question. After all, there would be some extremely huge benefits:

• Drastically reduce bandwidth (and therefore page loading time, cost, server load, etc) when moving from one page to the next - no longer need to load all the navigation, page design and layout from page to page
• Extreme willy-waving "wow factor" and long-term wishlist goal achieved!

There is a long list of other benefits, but from my point of view those two alone are enough for me to keep pondering how to make this a reality.

But, like I said above, there is extreme complexity. No, really, it's very extreme and painful. I can't stress enough just how much pain... I wake up at night with random ideas, none of them hold water and I go back to sleep annoyed.

Then the brainwave landed. I was busy working with Alain on some tweaks to Builder 2.1 (which is shaping up real nice!) and the big lightbulb above my head not only lit up, it started flashing and dancing around. In an instant we worked out exactly how to not only make the idea a reality but also completely bypass ALL of the pitfalls. Hopefully...

I'm not going to say any more just now - we need to get Builder 2.1 (and of course our new sales process) out the door first. We then need to spend some time sleeping and probably also have some padded cells installed and get on-site medical advisors. Builder 3 will push the limits far beyond anything envisaged before

Now I have to go and lie down for a moment in a dark room...

Many web developers will be familiar with the term mystic meat navigation - it's used to refer to the super-confusing navigation that used on some sites.

For example, some sites display a screen with no obvious navigation - you have to move the mouse around randomly to try and find a link and even then you might not know what it does.

Generally, mystic meat should be avoided at all costs. However, I've just found a legitimate use for it!!

You may have seen the recent news article on our main site about Bach Academie de Montreal working on the 2007 version of their Confluence+Builder powered website.

Well, a new site home page has been created - click here to see it.

We instinctively put the default Builder menus on to that page (otherwise it would have been rather difficult to edit it, etc) but the client didn't want a menu bar across the top of the screen.

So I looked for the simplest way to hide the menu and yet still have it there...

The solution:

• Set the background colour of the menu panel to red
• Set the text colour in the menu panel to red

Voila! One invisible menu - if you know it's there and move your mouse over it (hint: the top left of the central red banner) you suddenly see menu items appearing out of nowhere.

Most end-users won't need to use the menu so the fact that it's invisible until you mouse over it simply results in the page looking super-clean. And when you do happen to mouse over it, it's a nice supprise

The biggest reason for us having that menu there (at least currently) is the somewhat important login option in the View > Account menu.

As with any site that's mid-development, things will likely change with time, but I'm jsut impressed that I've turned a technique that's widely despised in to something actually quite useful!