Ajax Programming Patterns – Podcast 1 of 4: Web Service Patterns

Whereupon a new podcast series begins …

As promised, a new series of Ajax pattern podcasts. This is the first of four podcasts on the Ajax programming patterns.

In this 73 minute podcast, we look at the seven patterns of web services as they relate to Ajax clients.

Click to download the Podcast. You can also subscribe to the
feed if you want future podcasts automatically downloaded - check out the
podcast FAQ at http://podca.st.

  • RPC Service Expose web services as Remote Procedural Calls (RPCs). (Note: In the book and wiki, REST appears before RPC.) (6:55)
  • RESTful Service Expose web services according to RESTful principles. (13:25 )
  • HTML Response Have the server generate HTML snippets to be displayed in the browser. (44:45)
  • Semantic Response Have the server respond with abstract, semantic, data. (49:00)
  • Plain-Text Message Pass simple messages between server and browser in plain-text format. (56:05)
  • XML Message Pass messages between server and browser in XML format. (57:20)
  • JSON Message Pass messages between server and browser in Javascript Object Notation (JSON) format. (59:55)

Thanks for your feedback since last time. Good, bad, or ugly, it’s all welcome – in the comments for this podcast or [email protected]

Minimalist IPod

You know, the reason I’ve been passionate about podcasting since the beginning is that I’m a bit thingy about the written word. It has its merits, but multimedia’s where it’s at for true absorbtion of concepts. It’s the way we’re wired to learn and the no.1 reason why universities survived the printing press.

So I could have spent an hour reading about simple, minimalist, design, but I think I just learned more by watching this fantastic video speculating on the fate of the ipod package if MS had its say.

Truth be known, the XBox shows that MS can get these things right when there’s enough will and effort, but the video nevertheless conveys the Apple attitude nicely.

Here are some screencaps (the video quality isn’t great).

Who Needs These Browser Warnings?

Setting up a new Windows PC today and not loving the browser warnings.

The messages, as I recall them: “You are about to submit the form. It’s dangerous.”, “You’re going to leave the page. It’s dangerous.”, “This page is encrypted. It’s dangerous.”, “This page is not encrypted. It’s dangerous.”, “This is H20. It’s dangerous.”

So my question is, who’s benefitting? At this stage, the majority of internet users have been submitting forms and using encrypted pages for 5+ years. And if they’re a newbie, is it any more useful to them? (Hint: No.)

The only thing it does is add overhead to setting up a new system. You have to stop and think, “Hmmm is this a negative, double-negative, or triple-negative question? Ah, okay, I think I’ll leave the checkbox unchecked so as to imply I don’t want to not submit the form. And also, I’ll leave the ‘Don’t show me again box’ so it doesn’t not show me again.”

Summary:

  • Only provide dialog boxes that are useful, otherwise users will ignore them all.
  • Avoid not excluding negative phrasing in your options. Even if the most likely value is negative, you should still phrase it as a positive. (“Remember this” as opposed to “Forget this” or “Don’t remember this.”)

More is Sometimes Less

Someone sent Don Norman a critique implying that a machine was more usable because it contained only one button. His response is interesting:

Nice story, but wrong. Fewer buttons do not necessarily mean easier use … When assessing simplicity, don’t get all hung up on the number of buttons. Look at the whole picture: more is sometimes less.

The sentiment will resonate with anyone who’s tried to set an el cheapo digital clock, the kind of clock that skimps on an hour button and makes you run through all 1440 minutes of the day. Slow. Or tried to set the time on a digital watch, whereupon you learn in the manual (if you’re fortunate enough to have kept it) that you must depress down “Button B” for 3 seconds. Confusing.

The same thing happens with language. Sometimes introducing a new term for something reduces complexity overall. When talking about software architecture, for example, life would be a lot more tedious if you didn’t have terms like “Factory”, “Singleton”, “Proxy”.

Mix ’06 and Ajax Design Principles

‘Tis Goud reports from Mix ’06, Microsoft’s web bash currently happening in Vegas. One of the presentations focused on the most important thing about Ajax: Usability.

The session started with referencing two sites with information on:

Thomas’s guidelines were the first serious look at Ajax usability and a big inspiration for the Ajax Patterns.

The patterns and the principles were apparently distilled to this list:

  • Feedback
  • Predict
  • Preserve
  • Share
  • Controls
  • Separate

If anyone has more detailed info on this discussion, please let me know!

As it happens, the third chapter of “Ajax Design Patterns”, the overview to the patterns themselves, explicitly identifies principles on which the patterns were based. Principles and patterns go hand-in-hand, so any pattern language I’ve worked on always comes with a set of principles, an explicit reference point for people to grasp where the patterns are coming from. You can even (with some energetic hand-waving) look at the patterns as being defined around the principles: “These patterns are written such that if you follow them, your system will adhere to these principles”.

Anyways, the principles are broken into two groups: Usability Principles and Software Design Principles. Maybe I ought to podcast them sometime.

These are the Usability Principles for Ajax.

  • Follow Web Standards
  • The Browser is Not a Desktop
  • If it’s Different, Make it Really Different
  • Provide Affordances
  • Smooth, Continuous, Interaction
  • Customisation
  • Make it Fun

These are the Software Design Principles for Ajax.

  • Embrace Javascript
  • Accept Workarounds Where Necessary
  • Tame Asynchrony
  • Develop for Compatibility
  • Reduce Bandwidth
  • Deal with Latency
  • Partition into Multiple Tiers
  • Go Easy on the Browser
  • Practice Graceful Degradation

It’s funny. The very first thing I think of when I see stuff like this is along the lines “SHOW ME THE PATTERNS!!!!”. I’ve got no patience for motherhood statements like ‘Tame Asynchrony’. But the reason for this annoyance is because you usually see these kind of principles in the absence of any explanations, examples, or patterns. Once it’s apparent that the principles are merely a background to more concrete advice, their presence has been justified.

Who’s Your Coding Hero?

Jeff Attwood asks, “Who’s Your Coding Hero?”. Not everyone has one, but you’re lucky if you do. For me, there’s no question about it: Philip and Alex rule. After seeing him speak (to an audience of perhaps 30-40 people!), I realised how much more there was to the web. The things you hear about Web 2.0 today, he was on to a decade earlier.

Here was a presentation where the form really did matter. Why? Because he delivered it using WimpyPoint, his own online presentation manager (familiar idea?). So what’s WimpyPoint all about?

WimpyPoint is a replacement for desktop bloatware such as Microsoft PowerPoint. You can build a slide presentation in WimpyPoint from any Web browser anywhere in the world. WimpyPoint will hold onto your presentation in a professional maintained and backed up relational database management system (Oracle 8 ). You can forget your laptop. You can drop your laptop. You will still be able to give your presentation anywhere in the world that you can find a Web browser.

That’s the thing I remember the most about his presentation. His quick dismissal of a desktop solution for presentations, as if it was the most insane thing anyone could think of doing. He also created the first well-known mashup, the Bill Gates Wealth Clock, and saw the point of publishing a book online. One of my favourite bits of tech writing ever is his intro to HTML:

[Y]ou already know how to write legal HTML:

My Samoyed is really hairy.

That is a perfectly acceptable HTML document. Type it up in a text editor, save it as index.html, and put it on your Web server. A Web server can serve it. A user with Netscape Navigator can view it. A search engine can index it.

On Java and Flash:

Maybe you have infinite money and can buy the book plus a raft of multimedia authors. It still might be worth remembering what brought users to the Web in the first place: control and depth. Software such as Java and Flash enables you to lead users around by the nose. Flash them a graphic here, play them a sound there, roll the credits, and so on. But is that really why they came to your site? If they want to be passive, how come they aren’t watching TV or going to a lecture?

It’s not surprising, then, that Joel Spolsky has cited Greenspun as a major influence. I feel extremely fortunate that people like Greenspun and Spolsky, who can certainly walk the walk, are willing and able to talk the talk.

Dynamic Favicons

Favicons should ideally be easy to manipulate, as easy as manipulating the web page’s UI. (Favicons are the little website icons you see in the address bar, browser tabs, etc.) For example, a chat app like Meebo could signal that your buddy’s trying to contact you, a mail app like GMail could indicate You Have Mail!

I’ve found surprisingly little info on this – is anyone doing it? Anyway, I’ve been wanting to play around with this for a while and having recently submitted the final book draft (post pending), I finally had some spare time to play with it. Fortunately, it turns out to be perfectly feasible – it seems that Firefox and Opera both use <link> tags to determine favico, and this can be changed dynamically to satisfaction. The only gotcha is that you can’t try to be too efficient – if you reuse an existing link object and overwrite its href property, the browsers won’t pay any attention. so you simply have to remove the existing link tag and add back a new one with the new icon URL. Unfortunately, IE and Safari don’t seem to use the link technique at all – I think they just use the “favicon.ico” file. If you know of a way their icons could be dynamically manipulated, please mail me or add a comment here.

So I’ve created a library, favicon.js, that lets you manipulate favicons with a single call – changeFavicon("theIconUrl.ico");. You can also set the document title, changeFavicon("theIconUrl.ico", "Hi Everybody!"), which just sets document.title. There are a couple of demos and a brief FAQ:

Ajaxify favicon demo

Implementation Details. Here’s the favicon.js code as it stands, all 32 lines of it :-).

javascript
< view plain text >
  1. var favicon = {
  2.  
  3. change: function(iconURL) {
  4.   if (arguments.length==2) {
  5.     document.title = optionalDocTitle;
  6.   }
  7.   this.addLink(iconURL, "icon");
  8.   this.addLink(iconURL, "shortcut icon");
  9. },
  10.  
  11. addLink: function(iconURL, relValue) {
  12.   var link = document.createElement("link");
  13.   link.type = "image/x-icon";
  14.   link.rel = relValue;
  15.   link.href = iconURL;
  16.   this.removeLinkIfExists(relValue);
  17.   this.docHead.appendChild(link);
  18. },
  19.  
  20. removeLinkIfExists: function(relValue) {
  21.   var links = this.docHead.getElementsByTagName("link");
  22.   for (var i=0; i&lt;links .length; i++) {
  23.     var link = links[i];
  24.     if (link.type=="image/x-icon" && link.rel==relValue) {
  25.       this.docHead.removeChild(link);
  26.       return; // Assuming only one match at most.
  27.     }
  28.   }
  29. },
  30.  
  31. docHead:document.getElementsByTagName("head")[0]
  32. }

Update (Two Days Later)

Crikey! Dugg and on Delicious Popular. And, well, Ajaxian too ;-). Digg is interesting … The last time I submitted my own story to digg, it got precisely two diggs (thanks to the other guy!). This time, I didn’t bother. Is there a moral here?

New, improved, with animate(). Most people get dynamic favicons, but some people have said this whole thing is about animation, about as useful as a blink tag, etc. Okay, that kind of misses the main point, which is about notifying the user while a tab is in the background. The FAQ makes it pretty clear that animated icons was a kind of afterthought (actually, it only occurred to me after I created the cycling demo – changing according to a timer was simply the easiest way to update a background tab, since there’s no chat functionality needed or anything like that). But, you know, when a simple idea like that causes seems so wrong to some people, there’s probably wheels in it. And while I did say animated GIFs are possibly more elegant in the FAQ, it since occurred to me that it’s a bit of a hassle for the casual developer to make an animated GIF. You also get the benefit of compatibility with Opera (and maybe others?). So I’ve added an animate() method, only 8 more lines in all, that lets you cycle through a sequence of images. I expect to post it over the weekend. Mmm…Eye Candy!

Captcha Impossibillis

(Update: Thanks ImageShack for deleting my images.)

I was wrong, the third character is apparently a nine.

There ought to be a Captcha gallery/blog for all these. Apparently I’m not the only one who feels that way. Oh well, blame the spammers.

But more to the point, what’s up with this Captcha brought to you by the letters “A…F”???? Hex captcha? Hey, why bother with letters at all, let’s just go with binary captcha.

Here’s how inaccessible Captcha should really be done. (My first in-blog form too :-)).

Your answer (in base 10, of course!):

SAG Ajax Patterns Review 3 – Call Tracking, Distributed Events, On-Demand Javascript, XML Data Island, Browser-Side Templating

Following from previous posts, here’s my notes from the third SAG (Uni. of Illinois CS Dept) workshop/discussion on the Ajax Patterns. See the initial post for a background on this series.

Note that there was a “2.5″th workshop on HTML Response, JSON Message, XML Message, etc – it happened, but there’s no audio, so I decided to skip it wrt the numbering (the present workshop is really Workshop 4).

 

Feb-20-2006 Third Ajax Patterns Discussion

0:00

Use the "hidden version" versus the wiki [MM Guys, definitely the hidden version - the wiki more or less stopped a few months ago.]

Mention of O'Reilly Rough Cuts - Takes a while to make something ready, do you want to deny people the advantage of seeing it?

5:00 Intros

5:30 Call Tracking

[MM btw On the wiki, this was the first full pattern I wrote and it's pretty awful. Virtually rewrote it for the book. (The book content should eventually find its way back to the wiki, but maybe something more like the book format, with Wizlite for annotation.)]

XMLHttpRequest Call didn't address the bigger picture Call tracking highlights the async nature of calls - several ways to track it. Hand-drawn, crude, diagrams.
[MM These diags are mockups for the O'Reilly illustrators] Could have global XHR object - but then limiting multi-processing Is this pattern worried about resources or reliability? - More about [TODO Clarify it's about Call Tracking.] From the wiki version, seems like resources etc. Ambiguous.

11:00 When start thinking abt async communication, can think about reflecting on the message. (??)

============================================================ 12:00 Distributed Events

Fits quite well with Call Tracking [TODO Check Related Patterns sections, add refs?]

Single object/entity might have interdependencies

Clear that it's like an Ajax version of publish-subscribe - "Distributed" name confusing, "terrible". - Sounds like multiple servers (no). - Using patterns like Observer, a different name referring to the same thing. - But he's focusing on the fact that the events are distributed. ie in Java usually listeners are all in the same ?space. - Yeah it's kind of distr'd events, but the problem doesn't fit in with it.

Solution didn't seem to get into the details. Focus went back and forth between events and. [TODO Observer pattern sidebar]

Interesting, the problem is a really different context. There's no vocab for that sort of thing, he's trying to create a vocabulary for it with this pattern. - Except that in MS case it's transparently distributed. Hook docs together, doesn't matter if docs are on same machine or not. Built into that (platform). Probably slower than JS. People have been building distr'd events systems for a long time. Interesting that it's become a big part of these JS systems. - So maybe problem/forces should say more about the complexity of the communication

19:00 browser-to-browser is not distrib'd. [TODO Clarify that it's the same browser.] - Last line "should be clear ...": Using a generic interface rather than making a specific interface. Could have model object with a list of views. Instead, we say the model has a list of dependents - Well yes, it's another level of indirection, but could have implemented update as a list of views. But the main thing is, we have a generic interface - you don't know if the dependents are views and what they'll do with it. If you know they're views and you call redisplay(), you'll know they'll redisplay. - Had the same feeling - less about extra layer of intermediation and more about the fact it's generic. - [TODO Reword] - Examples: APIs where there's a central mediator. Java listeners don't have a central controller, every event listener has its own [TODO Decision - central manager versus Java-style autonomous where each object maintains its own listeners. (See below.)] - Decisions: History or state. cf Memento pattern [TODO Ref Mememto (or sidebar)]

Enjoyed this discussion. Issues about reflection or whether interfaces are generic to the problem you're solving. As the event mechanism becomes more complex, tend to genericise. The event handling becomes the focus, the architectural locus of these dist'd environments. Temptation to overload the event mechanism - the idea of reflection comes in, interesting that we don't have the vocab to talk about it.

Tradeoffs - "better solution" by adding a layer of indirection. But that comes at a cost.

I think the heart of this pattern is "something changes, something then notified". Key is for Observer, should be named after what happened to the subject. If you have a system where you're calling your observers to go do something ... (different type of events). Events are always events relative to some subject, whereas if going to have some central repo with dictionary mapping subjects to listeners. Actually a fairly minor issue, but seems bigger because not addressed. As events get more complex, tend to centralise it [TODO Also depends on sophistication of inheritance and delegation mechannisms ... not so great in JS, which pushes toward centralising]

33:10 Observer mistakes: Forget to (un)register observer, forget to notify observer, forget to declare observer's handler. Some mistakes easier to catch than others, for me the ones that take longer are when I forgot to register it, esp if only in some certain conditions. From HotDraw, learned it doesn't pay to try to be efficient. e.g. Drag figure around a screen - must redisplay, therefore must be real fast, therefore didn't use observer. So easy to make mistakes when mixing those mechanisms (observer and direct call). Became a lot easier when committed to using observer for everything. [TODO Mention this - tip:]

There's a lot you could say about it, not sure author wants to say it. Good purpose: How to convert distr'd events into that style. Can see a lot of people doing it the stupid way - each display element asking the server if something's changed. [TODO Flag this risk, probly in Decision about central management?]

Code example: Show picture (e.g. interaction diagram) [TODO Diagram]

============================================================ 38:45 On-Demand Javascript

Just-In-Time JS Not convinced of author's motivation for this. Would have to be huge amount of JS to worry about it - it's nothing compared to an image. But I was excited about it for other reasons, could have dynamic behaviour depending on the user/context. [TODO Mention how images are different, they load in parallel and user can begin interacting beforehand. Can't say same about JS.] [TODO Emphasise the "behaviour messages" idea as well.]

Need to give performance reasons, could do with an eg in 2-3 sentences Also useful for cross-domain. "Conventionally best practice has been to include JS unobtrusively" [TODO Reword/elaborate if nec Maybe "best practice is ..."]

Should have a pattern for modularising your system [TODO More background info on this, if not separate pattern.]

Near the end of the Solution Variant: Question - What does it mean to add new members to the DOM? [TODO Clarify ie that nothing will actually happen.] Javascript Response - Reword to "Behaviour Message"

Didn't feel that I knew how to do it. Got the big picture, but not the details, even though lots of pointers. If author wants me to implement it just by reading the pattern, needs more details. - But I never feel like I can do anything unless I try it. [TODO Check (the book version has updated this, check that).]

Interesting if browsers could do this automatically. Cache JS. [MM Caching addressed in latest book version.]

Question on debugging: What if run eval(js) - if you look at src for the original page, it won't be there. How will you find those definitions when you're in the browser? That could be a good reason not to use it. [TODO Discuss Venkmann-handling (should work ok).]

============================================================================== 55:30 XML Data Island

Have a group of data you want to do something with - bring the XML in, display the table etc from that, and you still have the data.

What's the motivation of having it in XML? - They do say that - "could have a custom data format" etc.

Interesting. Stick an entire chunk of XML, which is gibberish to the HTML, but can still use it.

"Even without these browser-specific technologies ...", so the author thinks XSLT goes along with XML Data Island. - Then you do get this agreed-upon standard for doing these transformations. - HTML has a schema. - Ah but there's this special XML tag. Best thing is for the browser to ignore it - they can all ignore it in a portable way. (Laughter.) - Some people here speak other languages - we're all used to hearing a language we don't understand and we all ignore it - common human reaction, and somehow our programming languages don't do it. Only thing that's advanced enough to ignore things it doesn't understand is HTML. - Ajax is defiantly utilitarian - unrelentingly ugly and people just plow ahead. One thing now is that org's like Google can pay people to plough through the ugliness - crud to deal with, browser dependencies

============================================================ 1:05 This pattern answers why using XML. Ajax apps so dynamic, talking to the server all the time. - With HTML, could convert on the server [TODO Why not server-side XSLT] - Mentions you can offload work - Don't want the GUI to be hard-coded into the server. Story is weather info - just has to tweak the XSLT - doesn't change the XML coming from the weather place. Your portal can display it different from anyone else. - Fits with web services - cf Stylesheets [TODO Good to have links to tutorials on XSLT. Chiliplop pattern language (?) Book on XML patterns, never finished. On website.]

============================================================ 1:12:30 Browser-Side Templating

Didn't see any templates I really liked, even though should
be do-able.  Authors thinking it makes life easier for web
developers, I don't know.
  - My guess is that it makes life easier ... because half of
    them are below average, below-average programmers like
    when you can cut-and-paste etc
    [MM Surprised it's seen as a cut-and-paste technique -
    really just a means of separating presentation from
    logic.]
  - With JSP etc, can still let a web designer work on the
    template
    [TODO Explain why - ie to keep the HTML dependence in the
    web tier]