The Wiki Twitch

I can feel a case of the Wiki Twitch coming on …

Victims of the Wiki Twitch have a perfectionist tendency which causes them to optimise content they come across, for the benefit of others and for reasons of “enlightened selfishness” – the motivation to improve what they will likely read again in the future. Many of these Wiki Twitchers have spent hundreds of hours in front of a computer screen, browsing encyclopaedias, reading community-created theories, and some are mad enough to write entire books inside a wiki. The twitch may begin when using these systems, but after some time, Wiki Twitchers fail to differentiate between websites that are wikis and those that are static, leading to a general desire to edit all content, even that which is not open for editing.

When content is hosted on editable wikis, the Wiki Twitch can actually promote a general feeling of well-being. But outside that realm, on the Static Web, it can lead to ultimately unsuccessful gestures – “Wiki Twitches” – towards a non-existent Edit button. Over 99% of the web remains ineditable at this time, leading to frequent delusions of editability.

The situation may be different in the future. Some younger Wiki Twitchers will never know what it’s like to pick up a static encyclopaedia and experience the feeling that it’s immutable. They are increasingly growing up to know a world where everything they can see can be changed by consensus.

A further trend is revealed by the increased interest in Second Life and other Massive Multi Player Online Role Playing Games (MMORPGs). Its only a matter of time before the “everything is editable” delusion of the Wiki Twitch extends to real-world objects.

A significant sub-population of Wiki Twitchers are programmers who have succumbed to the related phenomenon known as Test Infection. The refactoring bug is the cause of this infection, and, though primarily involved in a symbiotic relationship with software code, it has a natural affinity with wiki content.

Individuals suffering Wiki Twitch are advised to spend more time inside the Editable Web. If pain persists, install an appropriate annotation tool, such as Diigo or WizLite.

Ajax Functionality and Usability Patterns – Podcast 1 of 4: Widgets of the Web

And so, a new series begins, based on the Ajax functionality and usability patterns (Book: Part 4, pp 327-530). We’ve already looked at the technical details, now we’re looking at what Ajax can do for users and how to implement these features.

I’m asking guests to join me for most of the remaining Ajax Pattern podcasts. Seeing patterns from someone else’s perspsective will make the discussion richer and hopefully cover more questions you might have as you’re listening to the podcast. The guest for this week is Andre Charland of E-Business Applications, widget guru and author of the upcoming Enterprise Ajax book.

This 83-minute podcast covers nine patterns of Ajax widgets:

Ajax Programming Patterns – Podcast 4 of 4: Performance Optimisation Patterns

The fourth and final podcast in this series of Ajax Programming Patterns. As always, the patterns are online at AjaxPatterns.org and covered in the book too, now available at Amazon. This 33-minute podcast covers seven patterns of Performance Optimisation:

(Note that the last two are recent additions to the wiki and just stubs at this stage.)

Okay, here endeth the series. I will soon be starting up a new series on the next group of patterns (Part 5 in the book): Functionality and Usability Patterns. There will be a change in the format, one I hope you’ll enjoy!

“So, Jesse, Is Ajax a Pattern?”

… That’s the question I finally got to ask the man who gave Ajax its name, following Jesse James Garrett’s keynote last week at The Ajax Experience. I consider Ajax a very standard, uncontroversial, example of a pattern, so I’ve wondered why it wasn’t introduced as such, in the original Ajax paper.

Jesse said he’s asked the question quite a bit. He didn’t answer the question directly – there wasn’t a “Yes” or a “No”. Essentially, he just made the point that patterns mean different things to different people, everyone has their own idea, etc. In other words, I think he either doesn’t want to get bogged down in the debate or doesn’t consider it important.

At first, that seemed rather anticlimatic, but on reflection, I can see his point. He mentioned in his talk how people (of a certain kind, I guess) mail him saying “I wrote this app in 2000, it uses IFrame yadda yadda … Is it Ajax?”. So he probably has enough trouble with the definition of Ajax to worry about the definition of patterns as well. Moreover, he’s a consultant, and probably talks to high-level managers who wouldn’t know a pattern from a shell script.

So it’s understandable from a pragmatic perspective why “pattern” isn’t used in the original definition of Ajax, even though Ajax fits the mould perfectly. However, it is a shame for software, and industry at large, that patterns aren’t the standard way people think about designs and processes. Framed as a pattern, a high-level architectural style like Ajax can evolve quickly, as people begin to consider examples, forces, rationale, and all the other standard attributes of a pattern. Furthermore, people can ask about the role of this pattern in the entire ecosystem of patterns. What are its alternatives and how does it stack up? What are the lower-level patterns that should be solve questions opened up by applying the high-level pattern?

That many managers don’t get patterns leaves a lot of potential for improvement within organisations. An open wiki of interlinked organisational, technical, usability, etc patterns should be an asset to any company. As explained in this visionary paper by Jed Harris and Austin Henderson. The 2020 scenario suggests how patterns might be navigated in the future.

Then she puts a probe into the guise and begins looking for the patterns that the guise uses to model market response to Heavy Metal.* Her office shows her the internal organization of the guise as a network of nodes whose size and clustering reflect how much they contribute to the guise’s current display. Each of the nodes is a small view of the associated pattern, showing its current state; if she focuses on a single node, she can usually tell how it is contributing to the display. Olivia thinks of this display as a “sea of nodes” because the ripples and swirls remind her of flowing water. She swims through the sea, getting a feeling for how Fred has put the guise together, and how the guise itself is interpreting the current behavior of Heavy Metal’s customers. After a little while she zeros in on the service and support patterns. By suppressing the contribution of some patterns and looking at what changes in the display, she eventually finds a pattern— Service is a Feature— that seems to be most involved with the aspects that have been bothering her.

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]

Take the Ajax Challenge: What Can’t Ajax Do?

Working (offline) on Richer Plugin, I’ve expanded the list of reasons you’d want to use a Richer Plugin, i.e. Flash, Java Applets, Standalone clients, Firefox extensions etc.

Here’s the list of things Ajax can’t do on it’s own – what else is there?

  • Browser morphing Adding buttons, toolbars, bookmarks, icons; changing browser behaviour.
  • Local file access Reading and writing files on the user’s hard drive.
  • Sound Playing music and sound effects.
  • Rich graphics Providing rich graphics, changing dynamically. (This is gradually changing with the introduction of SVG in some browsers, but it’s no match for desktop graphics.)
  • Keyboard shortcuts Providing a full range of keyboard shortcuts while avoiding conflicts with the browser’s own keyboard shortcuts.
  • Hardware access Input from devices such as microphones, webcams, and gamepads; output to devices like printers and portable gadgets.
  • Extended communication Communication from the client machine to locations beyond just the base server, and in protcols other than plain old HTTP.
  • Operating system interaction Catching events such as shutdown initiation; changing preferences; popping up alerts; reading hardware information.

Take the Ajax Challenge: What Can’t Ajax Do?

Working (offline) on Richer Plugin, I’ve expanded the list of reasons you’d want to use a Richer Plugin, i.e. Flash, Java Applets, Standalone clients, Firefox extensions etc.

Here’s the list of things Ajax can’t do on it’s own – what else is there?

  • Browser morphing Adding buttons, toolbars, bookmarks, icons; changing browser behaviour.
  • Local file access Reading and writing files on the user’s hard drive.
  • Sound Playing music and sound effects.
  • Rich graphics Providing rich graphics, changing dynamically. (This is gradually changing with the introduction of SVG in some browsers, but it’s no match for desktop graphics.)
  • Keyboard shortcuts Providing a full range of keyboard shortcuts while avoiding conflicts with the browser’s own keyboard shortcuts.
  • Hardware access Input from devices such as microphones, webcams, and gamepads; output to devices like printers and portable gadgets.
  • Extended communication Communication from the client machine to locations beyond just the base server, and in protcols other than plain old HTTP.
  • Operating system interaction Catching events such as shutdown initiation; changing preferences; popping up alerts; reading hardware information.

8 New Ajax Patterns (Diagnosis and Testing)

Cool! The Best Practices/Processes Patterns are now complete. They are the final eight Ajax Patterns for now – “final” in the sense of “the list is not yet finalised”. The patterns had been sitting there unattended for about four months now.

More details on the new patterns later, but here’s a quick summary …

First, there’s a new demo – the Ajax Patterns Reader – the best version to try is at http://ajaxify.com/run/reader/logging/realService/. The reader grabs the AjaxPatterns.org content and presents them Ajax-style. You actually queue up patterns in a playlist and click “Next” to “play” them. Yeah, a bit contrived, but it helped illustrate quite a few patterns! If I have time, I’d like to enhance it into a proper reader, and also offer an easy interface to leave feedback, which would be automatically appended to the wiki’s Discussion tab for that pattern.

BTW This further refactoring of the Ajax Patterns Reader illustrates the Scriptaculous GhostTrain tool. If you haven’t seen GhostTrain, have a look – the Javascript will track your activity and build up a test case dynamically (covered in the new System Test pattern). All within the browser. I’ve been in contact with the developers (Thomas and Jon), and discovered it’s still proof-of-concept, but if they can tie it all together, it will be an excellent way to create a system/functional test.

Next, there’s four patterns on diagnosis:

And finally, four patterns on testing:
  • Simulation Service Develop the browser application against “fake” web services that simulate the actual services used in production.
  • Browser-Side Test Create automated tests of browser-side Javascript components.
  • Service Test Build up automated tests of web services, using HTTP clients to interact with the server as the browser normally would.
  • System Test Build automated tests to simulate user behaviour and verify the results.

Basics of Ajax 1 of 3: DOM and Display Manipulation (Podcast)

The Basics of Ajax: A 3-Part Podcast Series

I’m beginning to podcast about specific Ajax patterns. To start with, a three-part series on the basics of Ajax development, covering all the Foundational Technologies patterns:

  • Podcast 1: Display Patterns and the DOM.
  • Podcast 2: Web Remoting – XMLHttpRequest, IFrame Call, HTTP Streaming.
  • Podcast 3: Dynamic Behaviour – Events and Timing.

These will be useful if your familiar with basic forms and CGI-type web development, and wanting an overview on Ajax development techniques.

If you do know enough Ajax to at least write the obligatory Ajax chat application, there’s probably not much new info here. The most interesting pattern will be HTTP Streaming, covered in the next podcast.

Note that the pattern names and structure are subject to change, but the basic ideas will remain valid.

Podcast 1: Display Patterns and the DOM

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.

This 42 minute podcast covers the DOM and the following patterns:

  • Display Morphing: Morph display elements by altering styles and values in the DOM, such as text and colour properties.

  • Page Rearrangement: Add, remove, move, and overlay elements by manipulating the DOM.

Credits and Production Notes

  • The podcast concludes with the world’s first HCI Rap, “We Got It”, from the multi-talented team at OK-Cancel (the website with the funniest usability cartoons around).
  • The theme, My Morning Jacket’s “One Big Holiday”, is back too.
  • For the podcasters among you, the podcast was produced on a Powerbook running the excellent Audio Hijack Pro, with Bias SoundSoap and Apple’s new AUAudioFilePlayer plugin to cue audio. For the podcasters among you, this is a nice, easy, setup: allows recording directly to MP3, real-time noise reduction, ability to cue up sound clips, tag the MP, run a script at the end (which could FTP the file somewhere). In theory, you could have a podcast up a few minutes after you’ve clicked the stop button. Rogue Amoeba, creators of Audio Hijack Pro, know how to make software that’s intuitive and seriously useful. There’s detailed instructions for podcasters in the manual and also a blog entry on podcasting with Audio Hijack Pro.

Pros and Cons of Ajax

I just updated the ajaxpatterns.org “What’s Ajax” page to include more info on Ajax Benefits, and added a new section on Downsides. Have I missed any?


Benefits of Ajax

  • Web as a Platform: The web is no longer just about websites that expose some information; it’s increasingly being used for full-blown applications. These applications demand richer styles of interaction.
  • User Frustration: The standard “click-and-wait” form-based model no longer suffices. Most people are now au fait with the basics of the web and are ready for something more.
  • Web 2.0 Zeitgeist: Ajax sits well in the “Web 2.0” umbrella, with many of the Web 2.0 poster-child projects – such as flickr and technorati – incorporating Ajaxian features (having started before the “Ajax” term came about). Web 2.0 is about new ideas and the $$$ to make them happen, and Ajax is certainly creating opportunities for new breeds of applications, as well as fodder for improving existing systems. Ajax is the “web” in web 2.0.
  • Multiple Access Points: Many people use more than one computer. People are using computers at home, at work, at school, in cafes. Laptops and portable hard drives offer one solution, but they are inconvenient, at risk of theft, and often not able to be plugged in. Hosting the data online is a more straightforward solution and accessing it from a rich web application is a natural fit.
  • Web as the only Platform Thanks to the widespread adoption of public internet access, the so-called technology gap between countries and between socioeconomic groups is closing. Many people don’t actually own a PC, but do have regular access to the web at internet cafes or schools or friends’ homes. For this diverse category of user, there’s no point installing applications and keeping their data locally. The web is their only platform.
  • Better Infrastructure: Many homes now have broadband, and server capacities have continued to improve in the past few years. Due to frequent back-and-forth between client and server, Some Ajax applications can be hungry for both bandwidth and server capacity. Furthermore, server-side storage is cheap enough for many individuals and companies to prefer holding data online, which makes it feasible to access via a web application.
  • Productive Development: For developers a web programming model can be far more productive than a the conventional GUI alternative. Developers only have to produce a single product for all platforms, they can upgrade the application frequently rather than in “big bang” style (have you ever seen a website version number?), they can choose whatever programming language and libraries they care for.
  • Browser Improvements: While the basics of Ajax have been present for several years, browser improvements in areas such as XML-processing and debugging support, as well as adherence to standards, have eased the pain for the Ajax development style.
  • Security Concerns: As security concerns have heightened, companies are now quicker to lock down desktops and forbid browser plugins. Web applications hosted on a company’s intranet are therefore a boon for security, and allow for tighter monitoring and access control.
  • Platform Diversity: The rise of Apple, combined with the ever-present desktop Linux, means that many applications must be developed in a portable way, and choosing the web platform is one popular way to achieve portability.
  • Browser Diversity: Flock, Safari, and Firefox have joined Mozilla and Opera in offering serious alternatives to Internet Explorer which can no longer be ignored by mainstream developers. Most Ajax techniques, being based on standard browser features – albeit more modern ones – can generally be applied on all the recent browsers.

It’s also worth noting why this information has spread through the community so quickly:

  • The ‘G’ Factor: Several prominent Google projects have been thoroughly Ajaxian, including Google Maps and GMail. When Google talks, people listen.
  • Simple Message: Ajax is a straightforward message: all you have to do is point someone at Google Maps. It’s a lot easier than explaining “the long tail” or “the folksonomy” :-P.
  • Rapid Dissemination: Due to RSS, blogs, and podcasts, any worthy information is rapidly disseminated. For the reasons above, Ajax struck a chord in the community. Once a name was there for this desirable style of development, everyone wanted to talk about it.

Downsides of Ajax?

Ajax is a trade-off. Any developer considering its adoption should be aware of the downsides, such as:

  • Limited Capabilities: Some Ajax applications are certainly doing things people never dreamed were possible on the web, but there are still substantial restrictions of the web platform. For example: multimedia capabilities, local data storage, real-time graphics, interaction with hardware such as printers and webcams. Support for some of these are improving in recent browsers, some can be achieved by delegating to Flash, but many are simply not possible, and if required, would rule out Ajax.
  • Performance Concerns: Constant interaction between browser and server can make an application feel unresponsive. There are, however, quite a few well-known patterns for performance optimisation such as browser-side caching. These usually suffice, even for fast-paced applications like stock trading, but Ajax still might not work for really time-critical applications such as machine control.
  • Internet Access Required: The user can’t access an Ajax application in the absence of a network connection.
  • Second Programming Language: Serious Ajax applications require some knowledge of Javascript. Many developers are discovering that Javascript is actually a more capable language than at first assumed, but there is nevertheless an imposition to use a language different to that on the server-side.
  • Easily Abused: As with any powerful technology, Ajax concepts can be abused by careless programmers. The patterns on this site are intended to guide developers towards more usable solutions, but the fact remains that Ajax isn’t always be used in a manner that supports usability.