Protopage as Portal

I mentioned Protopage yesterday. It’s look-and-feel has so much more appeal than the standard Ajaxian portals (Google Homepage, Backbase, Start, etc.). Considering the others are more powerful functionally – given that you can do stuff like grab RSS feeds and search history – I wondered why I like Protopage so much more. There’s a lot to like, but I’ve decided one particular design decision was critical:

The portlets are free-floatingI.

By portlets, I mean all the little bits of self-managing content. In the standard Ajaxian portlet apps, you can drag-and-drop, but you’re constrained to a three-column layout, and each column must begin at the top and continue unbroken. Eschewing that approach and going for completely arbitary positioning gives Protopage several advantages:

  • It’s classical direct manipulation, the idea that made windowing desktops so popular. The user feels in control when they can move and drop content anywhere instead of being constrained by the desktop traffic laws. I’m saying “desktop” rather than web page because I can’t help thinking of protopage as a desktop right now (despite its name!).

  • Not only does the user feel in control, but the free-range arrangement makes protopage more valuable as a portal. With content arranged according to the user’s mindset, it’s easier to navigate and manage.

  • The design exploits whitespace. As building architects and town planners know, some space is good. It helps structure things and is visually appealling. The 3-column portals do contain space, but only by virtue of there being no content there yet – the user can’t directly create space.

  • Another benefit of the space is the background actually becomes useful. You can have a personalised desktop image, which can be any image URL. And the user has the power to work around any blurring effect because they are in complete control: they can move portlets around, change the background, and even change the colour scheme. Users can even arrange the portlets around the structure of the background image.

All in all, I’m impressed! Protopage is pure Ajax, one of the finest production-level Ajax apps to arrive since the hype began.

Greasing Greasemonkey Scripts

Tweaking a Greasemonkey script is easy. It’s just a single file, so you download the file locally, edit it, and install it the same way you’d install any other script.

I did this because I needed a quick fix for the super-helpful XMLHttpRequest Debugging script. Sometimes the console has a little trouble with positioning – using it with Google Maps caused it to sit behind the upper portion of the page due to layering. So I made two quick fixes – increased the z-index in the embedded stylesheet so it would appear in front and also changed the default coordinates (I’d adjusted them with “about:config”, but somehow that wasn’t picked up.)

All in all, I was able to tweak the script, not knowing anything about the GM API, and have it running in my browser in about 10 minutes. Had it been a standard Firefox extension, I would have been out of luck. I’d presumably have to download the original source, set up a dev/testing environment, and be able to package it all up including meta-info. Furthermore, I’d have to restart Firefox to test it, unlike Greasemonkey which works straight away. I’ve never tried all that with extensions, but that’s my perception from a little looking around.

I’m nowhere near as bullish as some about Greasemonkey, at least in the medium-term, as some people, because I think the whole Firefox extension mechanism is way too complex for most end-users, let alone the idea that you have to install Greasemonkey scripts on top of one of those extensions. But in any event, once you have the Greasemonkey extenstion installed, it’s a cinch to remould a script you come across.

The Ajax Desktop

I know. “The Ajax Desktop” sounds like I’m taking things just a bit too far. But I wanted to point out that people are experimenting with things you’d associate more with the web.

To wit:

  • Protopage:I was triggered to write this after discovering an awesome new Ajaxian app: Protopage (via FloatingSun). It’s essentially a start page, similar to the portal efforts. However, it feels more like your desktop, with configurable background, colour schemes, and sticky notes. One really nice feature is an “Add to Protopage” link for website owners – an update of the old “Bookmark This Page!” (Does delicious have this?). Some patterns here include:
    • Lazy Registration Register all you want, but the homepage really comes down to a unique URL, which is established immediately.
    • Drag-And-Drop Another desktop-like feature.
    • Popup For configuration.
  • Ajaxian Screensaver: A post on creating an Ajaxian Screensaver. I made a comment in the Ajaxian Blog posting that linked to it about the possibility of a SETI webapp. Mostly tongue-in-cheek, but I can see it happening. It would be trivial to create (and critics might say it would be sufficiently slow to make a trivial contribution too).
  • JSCalc: A calculator bookmarklet.

How far can it go? All we need now is a web-based splash-screen. Oh, wait!

Full-Text for Widgets

The other day, I noted the Ajax Patterns widgets have been broken down into content, form, and page architecture. The patterns for those are now complete. Give me yellow! Yellow is the colour for full-text descriptions, and the bottom of the page is starting to look a nice shade of yellow.

There are full summaries for each pattern on the homepage too. So the upshot is there’s a description for each of these:

Content Widgets

  • Drilldown To let the user locate an item within a hierarchy, provide a dynamic drilldown.
  • Microcontent Compose the page of “Microcontent” blocks – small chunks of content that can be edited in-page.
  • Microlink Provide Microlinks that open up new content on the existing page rather than loading a new page.
  • Popup Support quick tasks and lookups with transient Popups, blocks of content that appear “in front of” the standard content.
  • Portlet Introduce “Portlets” – isolated blocks of content with independent conversational state.

Form Widgets

  • Live Command-Line In command-line interfaces, monitor the command being composed and dynamically modifying the interface to support the interaction.
  • Live Form Validate and modify a form throughout the entire interaction, instead of waiting for an explicit submission.
  • Live Search As the user refines their search query, continuously show all valid results.
  • Query-Report Table Report on some data in a table, and support common querying functions.
  • Slider Provide a Slider to let the user choose a value within a range.
  • Suggestion Suggest words or phrases which are likely to complete what the user’s typing.

Page Architecture

  • Drag-And-Drop Provide a drag-and-drop mechanism to let users directly rearrange elements around the page.
  • Sprite Augment the display with “sprites”: small, flexible, blocks of content.
  • Status Area Include a read-only status area to report on current and past activity.
  • Virtual Workspace Provide a browser-side view into a server-side workspace, allowing users to navigate the entire workspace as if it were held locally.

Ajax Frameworks – JS, Server-Side, or Both

Jason Salas is a blogger-podcaster who’s been writing a lot of good stuff about Ajax lately. He notes the new ComfortASP .Net abstracts away the DHTML/JS so you can do everything server-side. The new Ajax JSP Taglib does that too. The idea’s been used previously with libraries like the struts validation module. Custom libraries are also useful – in the past I’ve hand-coded JSP taglibs to provide better user feedback in the browser, but prevent Java programmers from having to deal with the JS.

So of the Ajax Frameworks out there, there’s a fairly common theme: either libraries let you code everything in Java/.Net/etc, or they are pure DHTML/JS or sometimes both.

Two reactions:

  • In aggressive dotcom markets, the pure abstraction libraries won’t work. In mainstream intranet apps, they will be a big thing. There are already a lot of smart JS developers and many more coming on. Where Ruby is riding the Rails train, JS is surfing the Ajax wave (I know JS and Ajax are essentially the same technology, but it sounded cool. More accurately, JS is benefiting from the Ajax branding.) So you have the new JSAN project, all the stuff coming out of Scriptaculous and DOJO and Rico. And then you have talented guys like Jon Tiersen applying their Java/Agile expertise to improve JS tooling. So overall, you will be able to do a lot more with JS than pure abstraction. Market forces dictate that public dotcoms will be forced to work directly on the browser-side in order to keep their edge. However, in the other world of internal projects, where satisficing – doing enough to just get by – is the logical mode of development, these libraries will be superb. For typical intranet apps, the incremental benefit of hand-coding JS often isn’t there – there’s not enough users and it’s often more cost-effective to train users to work around problems. Very different story from dotcoms.
  • I’d like to see these pure server-side libraries offer some pluggable behaviour, to let users customise lots of browser-side appearance and behaviour if they want to. Provide sensible defaults so users can write pure server-side code, but let them tweak it later on. So, in the browser-side, you should be able to plug in new appearances, new event handlers, maybe even event interceptors. I understand Naked Objects is headed in that direction – it will autogenerate all GUI code from the domain model, but you can then hand-code a particular object’s look-and-feel if so desired. To me, that’s the key to a good framework: strong flexibility (but only where it matters), combined with sensible defaults.