Jeffrey Veen, echoing what Mike Arrington said ("Millions of people may have their first interaction with Ajax in the coming days."), asked Is Ajax ready for prime time?
This feels like a relatively big step in the evolution of what is possible to achieve with web interfaces. Not that these simple interactions and browser-based technologies are particularly new - the effects on the Yahoo! page could have been produced years ago. Rather, it will help a far broader set of people become accustomed to a new set of expectations for the sites they use every day.
Indeed. One thing Yahoo has always been good at is brining new technologies to a mainstream audience. Sometimes we even get it right. :-)
But this has other benefits that hadn't occurred to me...
Perhaps more interesting, though, is the technological precedent being set. Much like Doug Bowman's standards-based redesign of Wired News years ago, Ajax at Yahoo may signal to conservative IT managers that it's finally ok to loosen the reigns a bit. This technology is in the hands of the majority of users. Let's use it!
Perhaps that means that our internal applications (expense reports, trouble tickets, travel booking, etc.) will start to suck a little bit less? One can only hope. :-)
But the Yahoo! home page isn't the only place that's getting some Ajax love. Over on the Yahoo! User Interface blog is a list of Ten Things Yahoo! Is Already Doing with the YUI Library:
Since the YUI Library was released under an open-source BSD licence in February, we’ve gotten a lot of questions about YUI. One of the questions we’ve fielded more than any other, though, is also one of the best and most relevant: Who at Yahoo! is putting this stuff out into production? The answer is that almost everyone at Yahoo! is using YUI to some degree, including some of our most highly trafficked and high-profile sites.
If you're a web developer and haven't seen that blog or YUI (offered up as part of the Yahoo! Developer Network), check 'em both out. YUI is really helping to Ajaxify Yahoo! and it's all packaged up and ready to use on your site(s) too.
See also: Dustin's article 15 Things You Can Do with Yahoo UI
Posted by jzawodn at July 19, 2006 02:47 PM
I like AJAX on a 'Web Application' like mail, calendar etc. However, for me Y! homepage is still a 'Web Page' and don't really give a damn if its ajax or not. Heck, I don't even remember the last I was at www.yahoo.com
Lot of people think AJAX is for the look and feel, but I think ajax helps make a web application respond and work like a desktop app and that's where AJAX really needs to be used.
Good upgrade to the Yahoo page. Only hitch is that it got Ajaxified a few eons after Google's. Lotsa portals trying to say "me-too" and playing catchu-up with Google.
I didn't know yahoo "salted" new technologies. I think you meant "bringing" not "brining". Of course, I could be wrong.
Well i'm actually wondering what the Yahoo! Notepad will look like once implemented in Yahoo! Mail...I cross my fingers to get a Writerly-like application. It's taking quitea while to get the calendar as well...both would really benefit from AJAXHowever there is this company, Backbase, which ajaxified the Yahoo! search engine.
http://www.backbase.com/demos/bbsearch/
...that was dumb...so slow, completly useless
Bharath: Google hasn't ajaxified their home page. You might be thinking of their experimental personalized home page, but the vast majority of Google users never see that, do they?
It's definitely spiffy. What are the odds that along with these spiffications Yahoo! will move more towards standards compliance on their pages? HTML Validator in Firefox is complaining about 247 warnings - mostly about unescaped "&'s" and tags without a "type" attribute. I imagine these kinds of things aren't too difficult to implement...
Abu, standards-compliance and valid HTML are two different things. If a page works & looks right, what's the problem with some harmless markup/css warnings?
Three ActiveX security prompts, all declined (life's too short to read all the code behind the site and its advertisers to see what controls are potentially being used or exploited) and a this page may display incorectly. Not the friendliest of new page designs for the security-conscious IE user.
there is a line you cross from productively using these technologies to fetishizing them. yahoo being yahoo, they will overshoot this.
i take issue with some common design idioms emerging:
- the notion that page reloads are an error case to be "fixed". page reloads are a well understand idiom for expressing state change. browser memory consumption and common user scripting implementations (bloated/leaky javascript) tells me that long-lived, heavily scripted pages will irk users. yahoo mail classic has a long vibrant life ahead of it.
- drag and drop. people will disagree with me but i feel this has no place on any web page. its pure frosting...the very definition of dhtml fetishization. it also should irk standards weenies since the timer functions required by animation are outside of the ecmascript standard.
- replacing perfectly functional form mechanisms (pulldowns, radio buttons etc) with highly stylized dhtml widgets. i understand browser widgets are ugly. they work.
- json. to me it is cleartext activex, but basically just as dangerous. while xml may be "bloated" in comparison (oh my god, i have to download 15 more bytes!), it is only bound, not executed.
i eagerly await the inevitable "retro purist" backlash movement bringing the web back to page-oriented data.
The problem I see with Yahoo! is not some missing parts of technology (of course, everything should be HTML4 Strict, ECMA Script, CSS2 compliant and validated; yes, I love Craigslist :-)). After all talks about beauty of AJAXified Mail Beta after couple of years I went back, just to find that Yahoo! marketoids still did not allowed POP3 for free accounts. You know, I can understand their reasons (after all they are using Mail just as a tool to deliver more ads to their users -- nothing against that, it's a honest sleaze), but still with this decision they made a lot of people (I am quite sure I am not the only one) one more good reason why to switch somewhere else (I don't have to repeat G-word here, do I?), where it is possible to actually use mail as my main mail provider (which means of course with desktop MUA) and use webmail only when I am out of my computer. Their idiotic decision to eliminate POP3 from free email makes me (and many others, I guess) to go from Yahoo! Mail completely. So although I have been using rest of Yahoo! at least since 1996, I set up immediately after I learned about switching off of POP3 filter saying that email which has @ in From: field should be deleted. Oh well.
I know this is kind of off-topic, but it seems to me that it would be more useful to deal with real problems than with coolness and following the latest fads. And I really had to get of my chest frustration with Yahoo! which doesn't seem to care for what I think is real problem (BTW, I don't complain against forbidding Auto forwarding of everything -- it is probably stretching it really too far).
Best,
Matěj
Nathan,
To address your point, the adherence to standards, while somewhat more difficult initially, ensures healthy development and promotes a culture of cooperation, rather than the stubborn, "It works on this platform, and that's my audience" kind of attitude. Moreover, while some decisions regarding standards seem a little outlandish, in hindsight they allow for a more natural migration to pages that tend to be easier to maintain, reuse, and work on a broader set of sites. Sure, we're using IE/Firefox on a Windows platform today, but tomorrow we could be using cell phones (today?), watches, or some other hitherto unforeseen method to view pages.
Part of the bloat and slowness of many browsers today, and the ability for exploitation, includes the fact that rendering a webpage today requires quite a complex set of special cases to handle all the accepted practices which break the standard. Whereas, had everyone stuck to the standards, and accepted a broken page as a broken page, there's no need for a rendering engine to be more than a tokenizer, more or less. But look at how much work it takes to bring browsers up to the spec where they can render a simple smiley face (see the ACID test - http://www.webstandards.org/action/acid2/). Even Firefox cannot properly render this (Opera, Safari, & Konquerer have made it, however). Granted, the ACID test also tests that a browser FAILS properly, but that is part of the spec as well.
Little things like unescaped "&'s", unclosed tags, and errant ECMAScript, while tolerated with the standard base, utterly decimate the hopes of an accessible web that is free from one particular type of user agent. It's just short-sighted thinking.
I agree that the Google personalized home page isn't the "default home page" seen by most users for starts. But after the first sign in (assuming cookie persistence), the personalized home page becomes the default; that's the page that comes up for the address www.google.com. And I do believe that a number of users do see that page now (if one is to go my the popularity of the IGoogle widgets).
And speaking of user sessions, most of them are persisted (and monitored) for the "convenience" of users by the respective toolbars & desktop widgets that Yahoo and Google are scampering to bundle with every other third party desktop app.
Hehe... I always find it funny when people talk about all the exciting features at Google. I had yet another "out of Valley" experience and found once again that most people, even those who use the Internet every day and are pretty savvy, don't really know or care about many of Google's half-assed experiments like GTalk. Of about a dozen people I asked over the course of my trip, only 3 had even "heard something about Google doing online chat" and 0 of the 12 had tried it, even though 4 of them had gmail accounts (that they seldom use). Of those I asked, only 1 uses Firefox... which isn't far off the ~6% market penetration number. So before people get all masturbatory over AJAX stuff and Google v. Yahoo battles, it's good to remember that there's a real world out there where concern for this stuff is nonexistant... all that matters is that the user experience is positive.
Jeremy, I am excited that AJAX is making the prime time and Yahoo is enabling users to have a richer web experience. That being said, I feel that this is a bit of a "technology-push" with respect to UI design. In particular, I would think that some of the affordances that are set up on the site are a bit hard for "mom and dad" to deal with. How did the user tests go for the new front page relative to the old page? Was it really that much more compelling for users to use the AJAX version? Just curious! :)
Hi,
Ajaxification of web sites today is a most sought after task by the web developer community. Developers today wish to ajaxify every page they can put their hands on. This blind run may backfire if not properly analyzed and done.
Decision whether to ajaxify a page should be based on historical data on user behaviour. I personaly find it very irritating if answers keep appearing even while i am typing the query. It feels like over energetic/intelligent child spitting out answers even before the question is complete. Its not a good communication practice :-)
In search, ajax will be helpful by making navigation faster. It would be more useful if the result summary expands in layers to show more info about the subject.
Yahoo, no doubt is doing a wonderful job in the field of Ajax, however even they cannot afford to blindly ajaxify all interfaces.
regards,
sujith
YUI components are nicely documented, including example code and a nice set of color-coordinated cheat sheets ( http://developer.yahoo.com/yui/docs/assets/cheatsheets.zip ). And...if you choose, your local page can load its YUI components off one of the co-located Yahoo servers, so you always have the latest version and save local storage. I've tried this just to see if Internet latency would be an issue; so far, it hasn't. Of more concern: Will Yahoo will make API upgrades backward compatible so my old pages work with updated components? If I could rely on this, I could begin to conceive YUI components the way I conceive DLLs.
Walt
