Share this:

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.

Share this:

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.”)

Share this:

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”.

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.

Share this:

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.

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:

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!

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).

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. (??)

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?]

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).]

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.]

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]

Share this:

G’Day

Welcome to Michael Mahemoff's blog, soapboxing on software and the web since 2004. I'm presently using HTML5 and the web to make podcasts easier to share, play, and discover at Player FM. I've previously worked at Google and Osmosoft, and built the Ajax Patterns wiki and corresponding book, "Ajax Design Patterns" (O'Reilly 2006).
For avoidance of doubt, I'm not a female, nor ever have been to my knowledge. The title of this blog alludes to English As She Is Spoke, a book so profoundly flawed it reminded me of the maturity of the software industry when this blog began in 2004. I believe the industry has become more sophisticated since then, particularly the importance of UX.
Follow @mahemoff