GWT Conference Videos and Slides
From the Pearson conference in December, the Youtube collection, and the slides.
Technorati Tags: ajax, gwt, conference
From the Pearson conference in December, the Youtube collection, and the slides.
Technorati Tags: ajax, gwt, conference
Every so often I’m rudely reminded that much of the information I get comes from a source who’s goal is to sell rather than inform. It is those times that I’m also reminded of the critical role that design plays in supporting the goals of the organization (wether they be to inform or to sell) by shaping user behavior.
Case in point. I use Yahoo Finance to track my stock portfolio and stay financially abreast of the day. I choose Yahoo over the many others out there because I’m used to it. It has a simple interface and I know where everything is located. It also has great tools, and it aggregates information from many many other sources in one place, which I find invaluable. However I just recently noticed that Yahoo Finance is serving some text ads on the site now. I wouldn’t otherwise be too bothered by them, but they’ve been designed for the express purpose of looking like real (un-sponsored) content. They’re right up there on the right hand side of the page, occupying the top of one column in a three column layout. The ad titles are just about the same color as the headlines and links on the rest of the site. And while the other section titles are all orange and bold–designed to give structure to the page and let you know what section your in– the only way you can tell that your reading ads is from the truly inconspicuous (light-grey on light blue, thin, all caps) ‘Advertisement’ header.
This really infuriates me, especially because it’s a finance site, and I can’t help but notice the content of the ads. For instance, right now I’m looking at the front page, from left to right I see a snapshot of the Dow’s performance today, a headline saying ‘Stocks mixed ahead of jobs report’ and a couple of blurbs on ‘Hottest China Stock’ and ’16 Hot Dividend Stocks’. Now I’m sure you can guess which ones are ads. And yet I can’t help but see the ads and incorporate them into my understanding of the days financial news. They were designed to be scanned, and that’s exactly the kind of information I need to be able to filter out when I’m scanning a page like this.
The fact that these ads persist is a clear indication that Yahoo is concerned less about an informed public and more about using its real estate to extract as much equity as possible.
Powered by ScribeFire.
I simply love finding these little gems on my weekly web excursions. This time it’s a fascinating new piece of software out there called Dasher, and it allows you to write without typing or scripting. What’s that you say? How else can you write? Well…The basic idea is that current methods of typing are inefficient, because they don’t learn. Let me explain. Although there are x number of letters in the alphabet, every pressed key reduces the number of available choices for the next key press, and increases the odds that other specific keys are pressed next. For instance, ‘E’ is much more likely to be pressed after ‘H’ than ‘B’ is, and ‘O’ more likely after ‘G’ than ‘C’. On current writing technologies it’s up to the user to learn to be more efficient at writing He than Hb or Go than Gc. But that doesn’t need to be the case. By taking advantage of the learning and memorization power of the computer, it’s possible to create writing interfaces that guide you through the process rather than just recording what you type. If you’ll indulge me in some metaphor, imagine rowing down a river. Dasher is the river with a strong current to wherever your going, and existing typewriting technology is the river with no current whatsoever.

What Dasher does is use language patterns to present likely letters and words to the user based on the letters or words they have already written. The goal is to make writing more efficient by reducing work. There are no keys to press using dasher. In fact the mouse is never clicked. The interface allows one to write by simply navigating the mouse down a path–or tree–through the alphabet. The start screen displays all 26 letters of the English alphabet. You select a letter by moving your mouse next to it. As letters are selected, Dasher displays all available letters again, but this time those more likely to be chosen are larger and therefore easier to select. As you write, you move forward through the tree, and entire words and phrases are displayed in order of likeliness.
Dasher needs some work before I start using it instead of my keypad, but the idea has real merit, and it deserves to be explored more. As an interface designer I see at this tool as a great example of how simple interactions, when thought about creatively, with nothing held sacred, can have potentially revolutionary effects on the way we interact with technology.
Powered by ScribeFire.
The Facebook application platform is less than a year old, and Facebook JavaScript (FBJS) made it out of beta less than four months ago. It’s therefore unsurprising that comprehensive developer resources for both are a little thin. Most of the real content comes from official Facebook properties. Still, a little digging helped me uncover some decent tutorials and a wealth of open-source wrapper libraries for Facebook’s RESTful API. Interestingly, I didn’t uncover any big attempts at Prototype-style FBJS toolkits – just a few scattered examples of utility classes. It seems that Facebook development experience is still enough of a competitive advantage that the experienced few aren’t rushing to create helper libraries for their hapless peers.
Read more »About a month ago I reviewed the GWT history manager and lamented its less than full support for the (admittedly buggy) Safari 2. Since then I’ve chatted with Joel Webber of GWT and gotten more insight into his team’s approach to the Safari question. According to Joel, it all comes down to iframes: The approach taken to Safari 2 by the .Net history manager, Really Simple History and other libraries falls apart when the history-enabled application makes use of iframes – which, of course, are required by rich-text editing widgets. The GWT team tried to code around this using cookies, but that approach tanked when multiple copies of the same app were open simultaneously. Rather than provide support that didn’t work for some of its core widgets, GWT history fails gracefully in Safari 2. It works beautifully in Safari 3/Mac because the Webkit team fixed the bugs that required all this hackery in the first place.
It’s interesting to chat directly with other history-management developers and get a better understanding of how they make their peace with inconsistent or downright wrong browser behavior. As for Really Simple History, I’m still hard at work preparing a beta of 0.8.
As I’ve posted before, I’m pretty leery of prognostication. My colleageus Noel and Dietrich have already made their predictions for 2008, anyway (here and here) so who am I to join the fray? Instead, let me dust off another hoary device and share my programming resolutions for 2008.
Read more »