Topic Archive: Widgets

GWT Widget: Rolodex

Dietrich Kappe, Wednesday, January 30, 2008 @ 5:21 am

Chris Jones of YesMail has written a pretty slick rolodex widget (see the Google groups thread about it).

Right now the animation images are generated by hand, but with a little bit of Java 2D, this can happen at compile time. You can kind of see some of the issues here of Flash v.s. DHTML. Flash has all sorts of image transformation goodness, while DHTML is a little handicapped here. You could use something like Reflex instead of compile time image transformation, though I haven't tried out how well it performs when animating.

Anyhow, nice work Chris. It's nice to see folks pushing the boundaries of what one can do with DHTML widgets.

Technorati Tags: ajax, gwt, yesmail, widgets

• Digg
• Reddit
• del.icio.us

Comments (1)

agile ajax

.Mac improvements: That’s it?

Brian Dillard, Friday, August 17, 2007 @ 5:30 am

Amidst all the hardware news at Apple's Mac-focused media event last week, it was easy to overlook the announcement of some tweaks to the widely reviled .Mac web-services suite. Easy to overlook not because the announcement got no play, but because the improvements were so underwhelming. Even with 10 times the online storage space (10 gigs, up from 1 gig) and a slick new Ajax-backed photo service, the upgraded .Mac suite still costs $100 a year. Meanwhile, most of its individual features continue to lag behind the functionality and performance of free services from a host of other providers.

Commentators here, there and everywhere have predicted - and in many cases advocated - the death of .Mac for a long time now. I wonder if Mac newbies' continuing propensity to pony up for the service has something to do with Google's inability to parse the period in ".Mac" and return some relevant search results for such phrases as ".Mac user reviews." [Here's a hint: search for "dot-mac sucks" instead.] There's no shortage of users who find the service disappointing, and the latest tweaks aren't likely to change that.

Based on the demo I've seen of the new .Mac Web Gallery, I can see why an iPhoto junkie might be persuaded to dump Flickr and give it a whirl. But why settle for syncing Safari bookmarks when you can use a social bookmarking service or a bookmark-syncing plug-in for your browser of choice? Why settle for viewing your Address Book entries from a primitive web interface when a service like Plaxo lets you edit them online, too? Why merely view iCal entries online when you can actually edit your Google or Yahoo calendar from any browser? Why use .Mac's painfully slow, frequently buggy online backup service when you can switch to Amazon's S3? Why use the old-school .Mac webmail client when all the major free webmail vendors offer snappy Ajax interfaces? Why host your personal site with iWeb when so many other free or low-cost solutions offer more flexibility and power?

No webapp is perfect, and no single provider offers the breadth of .Mac in a single suite. But cheap or free a la carte services from best-of-breed providers work better for all but the most dedicated (or lazy) Mac users.

Leander Kahney over at Wired stayed up late the night before Apple's presentation to say a prayer that Jobs & Co. would radically overhaul the service. But the best that can be said about the "new" .Mac is that its developers finally seem to be dimly aware that there's this whole Web 2.0 thing happening out there. The future promises some upcoming, though as-yet-undefined, .Mac webmail improvements that could help modernize the service. But the suite's most compelling features are the ones that link one Mac to another, such as Leopard's forthcoming Back to My Mac application. True Apple fanboys may get a lot from such utilities, but they're useless for people in the real world - the ones who log onto Windows boxes at work every day and still want access to the data from their personal MacBook Pros.

My real problem with .Mac isn't that its webapps are sub-par. It's that Apple's overall strategy in the PC marketplace is still so focused on a single, unified desktop experience geared toward the mythical "average user." (Thanks, Walt Mossberg, for making that the most overused phrase in technology writing.) It's such a Microsoftian strategy: continually cramming all the the things a typical customer might need into a suite of pretty-good apps and services whose only real advantage is their supposed integration.

Given that Safari is being positioned as the platform for iPhone software development, it seems likely that core pieces of the OS X desktop experience will eventually get better browser-based simulations. But as a Mac user, I want the data on my machine to play well with third-party webapps, too, in my user-agent of choice. The whole advantage of the web desktop model is that all of my data lives in the cloud and, thanks to public APIs, I can interact with it through a broad range of providers. I can use the out-of-the-box UI or create my own. I can aggregate Remember the Milk into my gCal with a widget instead of waiting for Google to come up with a first-rate to-do list manager. I'm not locked into a single piece of hardware, operating system or software vendor. But locking me into a monolithic suite seems to be the whole point of Apple's desktop strategy, .Mac included.

Right now, all .Mac does is sync data between Macs and allow me to access a subset of that data, in read-only mode, through the browser. That's simply not good enough, and it hasn't been for a couple of years now. Apple should be integrating each of its elegant, easy-to-use but fairly vanilla desktop apps into a web-services architecture. That way, I can use my Mac as an oasis of no-fuss desktop computing at home, but still have the power and the flexibility to do what I need to do from any other machine or physical location.

I get why Apple's user interfaces are geared toward somebody with my grandmother's level of technical proficiency. But why not set up .Mac so that third parties can create more powerful and varied UIs on top of the underlying services? That might actually be worth $100 a year. In the meantime, .Mac and the Macintosh platform are positioned as one-size-fits-all, all-or-nothing propositions. And there's nothing new about that, media event or no.

• Digg
• Reddit
• del.icio.us

Comments (0)

agile ajax

Cross-platform widgets: fact or fiction?

Brian Dillard, Wednesday, August 15, 2007 @ 5:30 am

For such a simple idea, widgets (or "gadgets" or "modules" or - ugh - "badges") are ridiculously complicated. Take three basic web technologies (XHTML, CSS and JavaScript), wrap them in a fourth (XML), and you should have a really simple, powerful way of deploying a platform-independent UI for your remote data. Yet between Yahoo Widgets, OS X Dashboard, Google Gadgets, Vista Sidebar, Netvibes Widgets and the umpteen other flavors out there, broad deployment is time- and cost-prohibitive. Pretty much every major implementation is incompatible with the others. Often, a single vender offers multiple overlapping versions of its platform, such as Google Desktop vs. iGoogle and Windows Live vs. Vista Sidebar. I'm all for healthy competition and the innovation it produces, but couldn't each big player at least release a unified API for all of its properties?

Amid all of this chaos, what's a would-be widget author to do? Probably the same things as widget users: weigh the options and pick a side. True, the WC3 is beavering away on a standards spec, but we all know how long that's going to take. By the time anything gets signed off on, the fad will either have died out or, perhaps worse, have become a long-term part of the web ecosystem. Imagine hundreds of thousands of legacy widgets written in proprietary formats, a huge number of which will never get refactored to meet the standards. And that's assuming the various widget platform vendors even agree to sign on. It's easy to imagine Google jumping on board, but much harder to hope the folks in Redmond will follow suit. Who knows about the other players?

True, tools have sprung up to translate certain types of widgets into certain other types. But these are stopgap solutions with often unpredictable results. Even when the widgets work, they often don't look pretty in their new homes. And nobody yet has come close to a write-once, run-anywhere SDK for widgets. Translation is the best option the marketplace has produced.

That said, I'm keeping an eye on UWA, the new Netvibes "Universal Widget API." This is another translation methodology, but instead of a third-party application that performs a one-way port of an existing widget, it's an actual spec for authoring widgets once and then compiling them to the various platforms. Thus far it mainly supports Netvibes itself, iGoogle and Dashboard. But Vista support is on the roadmap, and Yahoo support has been discussed. Best of all, they're planning to open-source it. If this API ends up being halfway as useful as it promises, perhaps it will offer a good middle path while the official standard takes shape.

[Lest I end on a completely hopeful note, here's a somewhat related digression: I'm also often depressed by the way the aforementioned standard web technologies get used in widgets. To a certain extent, pretty much all of the widget platforms force you to develop kludgy code. iGoogle and other Web-based platforms scale their widgets based on the size of the browser window. Some developers spend the time to come up with intelligent liquid layouts, but the limitations of fixed-height iframe wrappers make design compromises inevitable. A lot of the third-party widget-assembly shops just slap together some fixed-width design based on the worst-case scenario and built the entire interface out of a sliced-up PSD file. Forget font-scaling and other basic accessibility considerations. It's like the 640x480 viewport all over again, but in miniature. The more things change...]

• Digg
• Reddit
• del.icio.us

Comments (3)

agile ajax

MXGraph - Direct Manipulation Graph Component

Dietrich Kappe, Tuesday, June 13, 2006 @ 4:52 pm

Via Ajaxian: JGraph has release MXGraph, a direct manipulation visio-like beast. The web site says it's a thin-client component on top of JGraph (if you're not familiar with it, it is a -- shocking -- Java desktop visio-like beast). It has some nice things in it, such as a nice marquee selection tool and draggable everything. There are some small defects, like drag from the pallette not working quite right. Still, a very impressive piece of code (even if the code is obfuscated).

JGraph is open source, but some of the cooler stuff, like advance automatic layout, comes in the commercial Pro version. It'll be interesting to see what the licensing terms for the MXGraph component ends up being.

• Digg
• Reddit
• del.icio.us

Comments (2)

agile ajax

GWT Widget Library - Moving Fast

Dietrich Kappe, Thursday, June 8, 2006 @ 9:00 am

That didn't take long. Google just announced it's Google Web Toolkit (GWT) at JavaOne in mid May and a scant week later we already have the GWT Widget Library. This library wraps the Scriptaculous effects, adds image buttons (with support for PNG's in IE 5.5 and 6) and allows one to wrap existing HTML elements as widgets. There's a nice demo of using the effects with GWT here.

Also, if you haven't visited the GWT blog and the developer forums, you really should. Developer action is heating up and people are already starting to push the boundaries of the toolkit.

While writing Java to produce Javascript may offend purists, it is hard to argue with success. Google has delivered some of the most popular applications on the web using this technology. However, the two evaluation projects I've done so far with GWT have been somewhat disconcerting, with my guessing at exactly how the Javascript would be rendered. Also, 38k of Javascript for a simple little email submission widget seems obscene, but it and it's validation logic was a breeze to write and debug, though the equivalent raw DHTML and Javascript clocks in at under 1k.

Update 1: Here is another GWT-based widget library. Some overlap, but also some other things, like the rounded corners.

• Digg
• Reddit
• del.icio.us

Comments (1)

agile ajax

Widget Watch - Echo2 ColorSelect Widget

Dietrich Kappe, Tuesday, June 6, 2006 @ 9:00 am

If a component GUI framework just gives you your basic text box, button and other vanilla HTML form controls, it's not very compelling. It should give you something that you didn't think a webapp could do. Draggable windows were one of the first components to raise eyebrows as were expandable sections, like accordion panes. It's good to see some frameworks moving beyond the basics.

The Echo2 framework has been sprouting new components at a furious rate. One of these is the ColorSelect widget.

This component gives you the well known direct manipulation way of choosing an RGB color: just point and click.

As the AJAX component GUI frameworks catch up with the desktop, you'll be able to free your mind further from the notion that your building a web application. I myself can't wait.

• Digg
• Reddit
• del.icio.us

Comments (0)

agile ajax