Tag: ajax

Jeremy Keith: The Beauty in Standards and Accessibility (Web2.0Expo, Berlin) [en]

*Here are my notes of [Jeremy Keith](http://adactio.com/journal/)’s session. He’s somebody I always appreciate listening to, and he also happens to be the creator (and provider) of [Buzzword Bingo](http://bingo.adactio.com/). Play with your neighbour when keynotes or sessions go down the buzzword path.*

*My notes are as correct as I can make them, but they may be missing bits and pieces and I might even have misunderstood stuff.*

Web 2.0 Expo 6 - Jeremy Keith

First define. Who knows about beauty? The poets.

John Keats: Ode on a Grecian Urn. “Beauty is truth, truth beauty, that is all ye know on earth, and all ye need to know.”

William Blake: Auguries of Innocence. “To see a world in a grain of sand, and heaven in a wildflower, hold infinity in the palm of your hand, and eternity in an hour.”

Looking deep beneath the surface. Close-up sketch of a flea. Micrographia. Beautiful. Viewing source. This is how we see the beauty of things.

This whole web2.0 stuff is not about details. We’re not using microscopes, but telescopes, looking at the “big picture”. Telescopes can be good: think “Galileo”.

He brought upon the world an *a priori* change. A new way of looking at the world, though the world had not changed. The earth revolves around the sun, and not the opposite.

Darwin: the world didn’t change from one day to the next when The Origin of Species was published, but our view of the world did.

We want to think about structure. How is the house built? It’s when you understand the structure that you can build solid houses. Same with web pages. This is where web standards come in.

Separation. Before: all mixed up (html, css, js). Now: separate. (cf. http://nataliejost.com) Progressive enhancement. An a priori change to how you design websites.

a) begin with your content
b) structure it (HTML)
c) think about how it’s going to look (CSS)
d) think about the behaviour (DOM Scripting)

Web 2.0 Expo 5

If you remove any of these layers, it will still work. It won’t look pretty, it won’t behave as well, but it will still “work”.

**CSS**

# in a separate document!
p { }
#foo { }

Then, add rules using selectors. From general to specific.

**DOM**

Very similar approach. Make it external. You don’t put it in the document. The vocabulary is different, but you also reference elements in the page pretty easily

document.getElementsByTagName(“p”)
documnet.getElementById(“foo”)

School of thought called “unobtrusive scripting”, “unobtrusive javascript”

**Beware**

First structure, then presentation. If you catch yourself doing this…

# wrong!

If you put behaviour in here, you’ve wasted a hyperlink.

Slightly better… but still bad

# JS equivalent of using the style attribute

*steph-note: I’m learning stuff about JS! yay!*

Bandwidth benefits in doing things the right way. Process benefits, you can separate the work. And also… the beauty of it. Flexibility. See how it reacts in situations you haven’t accounted for? It won’t fall apart if somebody accesses with no CSS, no JS, no images…

So, is this about making site accessible? Kind of. Note: go to the talk on accessibility Thursday morning.

Jeremy is talking more about universality. You’re not shutting out devices. Mobile. Search bots. Screen readers.

W.B. Yeats (April 1916) “All is changed, changed utterly: A terrible beauty is born.”

**Ajax**

Wonderful, beautiful, but can be terrible depending on how it’s used. *steph-note: reminds me of what we said of JS in 99-00*

The key to Ajax is about asynchronous communication with the server. XmlHttpRequest.

Jeremy’s definition: “A way of communicating with the server without refreshing the whole page.” Just part of the page.

Buzzword Hijax.

Here is how Jeremy thinks we should build an ajax application.

a) build a website in the old-fashioned way — buttons, links, for interaction with the server
b) then, come along with ajax — which parts of this page benefit from just being refreshed separately, and intercept the links/events. Hijack the requests. Bypass the whole page interaction.

Progressive enhancement rather than a terrible beauty that locks people out. Switch off JS, and everything still works.

Where? When?

Patterns: when I click a link/form, and when I submit it, I return to the same page with almost nothing changed.

– registration forms (specially for user name availability)
– comments on a blog/forum
– add to cart
– *steph-note: sign in links*

“Web 2.0” is not about web applications versus documents in the old “Web 2.0”. It’s a sliding scale. Most sites are somewhere in between documents and application. Applications work with documents! It’s not an either… or thing.

This kind of Ajax is more on the document side of the scale, roughly mid-way to the application end. Doesn’t scale to “more application”.

But at that point, why the hell are you building that with HTML, CSS and JS? The reason to use them is that they degrade gracefully. If you decide that all three are required, maybe you need to use another technology, like Flash. These technologies have their place for applications which cannot degrade gracefully. Flash is made for building web applications! But there is an insistance in building “2.0 Apps” in HTML/CSS/JS.

Maybe hesitancy because Flash isn’t a standard in the same way as HTML/CSS/JS?

Standards: you know your stuff will work, you know there’ll be support there. The best thing that Adobe could ever do in Jeremy’s opinion is to open it up truly (*steph-note: if I understood that correctly*).

History of standards.

ISO, ECMA, W3C…

Open data. API. RSS. XHTML.

If you’re going to release and API, look at what Google and Yahoo are doing and copy. Build upon existing conventions. Your own format is not going to make it.

If you allow people to access your data like that, you start to see emerging patterns.

Microformats! *steph-note: yay!*

Machine tags! *steph-note: yay again!* There is a [machine tags wiki](http://machinetags.org/wiki/Main_Page).

Jeremy, like many of us, really hates the “Web 2.0” label/buzzword. It had its place a few years ago, but now it’s really putting us in a box. Ajax is a good buzzword, because it allows to talk about a certain technology in a snappy way. Whereas Web2.0… ask ten people, and you’ll get 10 explanations.

Web2.0: people.

But we don’t need a buzzword for that. We already have a word for “leveraging collective intelligence”: the WEB!

Combine looking through the microscope and looking through the telescope.

Similar Posts:

Requirements for a Multilingual WordPress Plugin [en]

[fr] Quelques réflexions concernant un plugin multilingue pour WordPress.

My blog has been bilingual for a long time now. I’ve [hacked bilingualism into it](http://climbtothestars.org/archives/2004/07/11/multilingual-weblog/) and then [plugged it in](http://climbtothestars.org/archives/2005/01/23/basic-bilingual-plugin/). Other [plugins for multilingual bloggers](http://codex.wordpress.org/Plugins/Translation_and_Languages) have been written, and some unfortunately [got stuck somewhere in the development limbo](http://doocy.net/archives/2005/01/20/the-multilingual-acknowledgement/).

Defining specs is a hairy problem. They need to work for the person visiting the site (polyglot or monoglot). They need to work for the person (or people! translation often involves more than one person) writing the posts. They need to work for all the robots, search engines, and fancy browsers who deal with the site.

Here is what I would like a multiple language plugin to do (think “feature requirements”, suggestion, draft):

1. Recognize the browser language preference of the visitor and serve “page furniture” and navigation in the appropriate language. This can be overridden by a cookie-set preference when clicking on a “language link”.
– “WordPress” furniture can be provided by the normal localization files
– how do we deal with other furniture content in the theme (navigation, taglines, etc.)? should the plugin provide with guidelines for theme localization? do such guidelines already exist? extra information appreciated on this point
– “language links” shouldn’t be flags, but language names in their respective languages; can this list be generated automatically based on present localization files? otherwise, can it be set in an admin panel?
– upon “language change” (clicking on a language link), could the localization (action) be done in an [AHAH](http://microformats.org/wiki/rest/ahah)- or [AJAX](http://en.wikipedia.org/wiki/AJAX)-like way?
– inevitable hairy problem: tag and category localization
2. Manage “lazy multilingualism” in the spirit of the [Basic Bilingual plugin](http://climbtothestars.org/archives/2005/01/23/basic-bilingual-plugin/) and “true multilingualism” elegantly and on a per-post basis.
– allow for “other language abstracts”
– allow for actual other language version of the post
– given the “general user language” defined above, show posts in that language if a version for that language exists, with mention of other language versions or abstracts
– if that language doesn’t exist, show post in “main blog language” or “main post language” (worst case scenario: the wordpress install default) and show alongside other language abstracts/versions
– abstract in one language (would be “excerpt” in the “main” language) and existence of the post in that language are not mutually exclusive, both can coexist
– does it make more sense to have one WordPress post per language version, or a single post with alternate language content in post_meta? For lazy multilingualism, it makes more sense to have a single WP post with meta content, but fore “translation multilingualism”, it would make more sense to have separate posts with language relationships between them clearly defined in post_meta
3. Use good markup. See [what Kevin wrote sometime back](http://epeus.blogspot.com/2005_01_01_epeus_archive.html#110513233021128637). Make it nice for both polyglot and monoglot visitors. [Inspiration?](http://blogamundo.net/dev/2005/10/31/a-nice-language-switching-widget/)
– use <div lang="xx"> and also rel attributes
4. Provide a usable admin panel.
– when I’m writing the other version of a post, I need access to the initial version for translation or abstracting
– ideally, different language version should be editable on the same admin panel, even if they are (in the WordPress database) different posts
– languages in use in the blog should be defined in an options screen, and the plugin should use that information to adapt the writing and editing admin panels
– idea: radio button to choose post language; N other language excerpt/abstract fields with radio buttons next to them too; abstract radio buttons change dynamically when main post language is set; in addition to other language abstract fields, another field which can contain a post id/url (would have to see what the best solution is) to indicate “this is an equivalent post in another language” (equivalent can be anything from strict translation to similar content and ideas); this means that when WP displays the blog, it must make sure it’s not displaying a post in language B which has an equivalent in language A (language A being the visitor’s preferred language as defined above)
5. Manage URLs logically (whatever that means).
– if one post in two languages means two posts in WP, they will each have their own slug; it could be nice, though, to be able to switch from one to an other by just adding the two-letter language code on the end of any URL; a bit of mod_rewrite magic should do it
6. Integrate into the WordPress architecture in a way that will not break with each upgrade (use post-meta table to define language relationships between different posts, instead of modifying the posts table too much, for example.)
– one post translated into two other languages = 3 posts in the WP posts table
– excerpts and post relationships stored in post_meta
– language stored in post_meta

I have an idea for plugin development. Once the specs are drafted out correctly, how about a bunch of us pool a few $ each to make a donation to (or “pay”) the person who would develop it? Who would be willing to contribute to the pool? Who would be willing to develop such a plugin (and not abandon the project half-way) in these conditions?

These specs need to be refined. We should start from the markup/reader end and get that sorted out first. Then, think about the admin panel/writer end. Then worry about code architecture. How does that sound?

We’ve started a discussion over on [the microformats.org wiki](http://microformats.org/wiki/multilingual-brainstorming). Please join us!

Update: this post is going to suffer from ongoing editing as I refine and add ideas.

Similar Posts: