Saturday, January 11, 2003

Moving Toulouse
Industrie Toulouse has moved to A new home (toulouse.amber.org) and a new publishing system. Most of the archives will be there soon. The Radio site will remain up indefintely, but no new content will appear here.
12:24:27 PM  blips[]    




  Thursday, January 9, 2003

Some quick Safari Tips and Links
I'm generally liking Apple's new Safari web browser. I think it will actually open up some interesting competition in the Mac OS X browser world, at least between Safari and the Mac OS X native Gecko browser, Chimera. There's already been a lot of talk about Safari, these are just a couple of links and downloads that have stuck out for me:
  • Dave Hyatt's Surfin Safari weblog. Dave is the lead developer of WebCore, the rendering side of Safari. He's responding quickly to a lot of criticism and is already noting significant process in newer builds.
  • Speaking of newer builds, this slashdot journal details how to get at Apple's open source WebCore frameworks and replace Safari's rendering engine with newer builds.
  • Mike Pinkerton responds from a Chimera developer view.
  • Safari Enhancer is a tiny utility application that enables some hidden features of the Sarari beta, namely a handly little Debug menu.

I see some people posting huge lists of all of the other things that Safari should do. Stuff that. I say keep it small, lean, simple, usable.

Now, if Apple really wants to improve my web browsing experience, they'd come up with a way for me to sync my Bookmarks up over iSync/.Mac! I was reading some of the links above this morning before coming in, along with some Zope 3 posts that I just wanted to remember when I came in to work. I was all set to bookmark them, but then realized that I wouldn't have the bookmarks when I came into the office. Urgh. This is happening all too much lately.
12:41:15 PM  blips[]    





  Tuesday, December 10, 2002

State of the desktop?
The theme of today's conference was decentralization....
The theme of today's conference was decentralization. The first time the term appeared in DaveNet was in the first piece of 2001. That's another DaveNet tradition, like the Thanksgiving essays. I try to make the first essay of each year somehow express the most important idea of the year-ahead. It's always a guess. Some years I nailed it, desktop websites were the big idea of 2001, as we prepared Radio 8 for the market (it shipped in January 2002). And Werbach was right to pick it as the theme for the future in software-based technology. There's so much power on the desktops, both in the machine CPU and the human CPU, that isn't being well used in the centralized Internet architecture. [Scripting News]

Pfeh to the desktops. There's a lot of power in them, but I'm positive I'm not the only one using three machines throughout the day. There's nothing worse than realizing that the data you need is held hostage at home or at work - wherever you're not. There are plenty of times when I don't mind the separation - work's work, home's home. But there are certainly things that go in between.

I've been a fairly happy subscriber to Apple's .mac services, using my iDisk to ferry a few common documents and preferences (standardizing the subscriptions on all my instances of NetNewsWire Lite, Chimera bookmarks, etc). I'm using Apple's iSync Beta to keep two desktops, a laptop, and an iPod all synced up with the same address book and calendar data (I have a palm too, but I seldom use it any more).

Microsoft's "Active Desktop" vision wasn't entirely wrong. The implementation wasn't quite right, and definitely premature. But the lines between the desktop, the local network, and the global network, are fading away. Rendezvous makes local networking absolutely unbelievable in Mac OS X (well, it's believable to those who used the old AppleTalk, but it's remarkable in the internet age).

I don't know. The desktop web site idea isn't too bad (I'm using Radio right now), but I'll always prefer the Zope "Everything is done through the web" model. It's the comfort of knowing that fixes, updates, etc, can happen from anywhere, with pretty damn good security.
1:21:18 AM  blips[]    





  Monday, December 2, 2002

Docks and Dashboards
For as long as it's been possible, I've had my Mac OS X dock placed on the right side of the screen, pinned to the top (instead of the default middle). I even had Mac OS 8/9 doing this for as long as the Applications Menu could be torn off and manipulated to look like a dock. It's the NeXTStep place to put it. Generally, I like the Dock, and how it combines application launching and running application management into a single widget (as well as offering shortcuts to documents and access to minimized windows). It's especially nice in comparison to the plethora of taskbar/launchbar/dock options found in Windows (although Windows XP does take some nice steps to clean up cluttered taskbars) and the stuffed-full-of-applet bars often found in Gnome and KDE. Those bars all have their purposes and uses, but I prefer simplicity and the Mac OS X dock gives it generously. An especially nice feature (when it's actually used) is that applications can have their own Dock Menus. Certain applications take good advantage of it, others ignore it completely. Radio 8 uses it well, offering quick access to the page I'm currently using to write this post, as well as to some other quick actions. Apple's iTunes uses it well, offering quick access to track controls (next/previous/play/pause) and the title and artist of the current playing track. And Brent Simmons' excellent NetNewsWire Lite makes the dock a very useful headline scanner (see screenshot). Having access like this a click away in the Dock is very useful - I often run up the dock with my Mouse checking info from certain applications while keeping them in the background. So, Applications that use the Dock Menu well make me happy.
NetNewsWire Lite Menu
Some applications, however, do not use it at all, but they should! Apple's new (young) iCal calendering application doesn't use it at all, but wouldn't it be handy if it displayed events and todo items for the current day (or week or month, based on configuration)? Similarly, Mac OS X's built in chat program, iChat forgoes a dock menu in favor of a global menubar item. There's some good reason for this - you can be signed in on iChat without the program running - but it's annoying when doing my little dock information crawl to have to go somewhere else for timely information. My instincts (rightly) take me to the dock first, menu bar second, and as such I'd like to change my status and check my buddy list from the Dock where I generally do so many other little tasks (like pausing iTunes when stepping out of the office).

So, where do dashboards fit into this? It's interesting to see the progress in Microsoft's MSN 8 offering. MSN 8 has a dashboard which you can attach to one side (left or right) of the screen and configure with parts updated with information from various MSN Sources. Paul Thurrot gives a detailed review (with screen shots). Some interesting things are the flyout windows, like this one based on the MSN Calendar component. It shows current appointments with shortcuts to add new ones. This dashboard concept is a major part of Longhorn, the code name for the next major revision of Windows. The point of all this is rapid access to constantly changing information.

Generally, I like the concept. But, looking at the size of the dashboards for MSN 8 and Longhorn makes me like Mac OS X's dock all the more. All of the items on it are still normal items on the system, not specialized objects (the Docklings that existed briefly in Mac OS X's life were a bad idea, and I'm glad to see them gone). Notification of change is done on the icon itself (Apple's Mail and iChat programs, along with AOL for Mac OS X and NetNewsWire, add a number to their icon indicating the number of newly received items), and allows the dock to remain small and out of the way.

The Dock - quick launcher, control strip, task switcher, window holder, information center, easily usable with 32x32 icons. Nice.
3:19:59 PM  blips[]    





  Monday, November 11, 2002

Thoughts on Interface Cruft, pt. 3: Documents vs. Applications
One response to the "When Interfaces Go Crufty" article is this one by John Gruber. Some of Johns responses are in the same area as mine, so I'll quote liberally.

First, Matthew Thomas writes:

We have the power, in today[base ']s computers, to pick a sensible name for a document, and to save it to a person[base ']s desktop as soon as she begins typing, just like a piece of paper in real life. We also have the ability to save changes to that document every couple of minutes (or, perhaps, every paragraph) without any user intervention.

And Mr. Gruber responds (after mentioning dislike for automatic behavior in applications):

Even if you don[base ']t default to the actual desktop, there[base ']s no other default folder location that would be suitable for all new files. I don[base ']t save my Perl scripts to the same folder as my grocery list. Nor do I want applications choosing file names for me. If you don[base ']t choose the names for your own files, how do you identify them when you try to reopen them later on?

Since reading Mr. Thomas's article, I've examined my own behavior and application usage more closely. And I'm somewhere in the middle of the two viewpoints. And it's not just because I'm a developer and have Python classes that I definitely want to keep separate from my Quicken files, but because there really is room for both.

  1. Applications like personal information managers (at least, Palm Desktop, Microsoft Entourage, and Apple's iCal and Address Book) and personal finance managers like Quicken are all auto-saving applications. In the case of the above mentioned PIM's, one rarely deals with the actual data files. iCal, Address Book, and Entrourage all keep their data off in their own hidden database. You can export data, but you never really open your "Entourage Calendar" - you open the application. Even Quicken (at least on the Mac configurations I've used over the past few years) is this way. I know where my Quicken file is located, but I always launch Quicken itself, and all of my data shows up. Granted, these are all essentially single-document applications (you're always working with the same data set) and curiously enough, tie in to handhelds very directly. And in almost all handhelds, from the Newton to the Palm (and I assume Pocket PC), there's no manual "Save" action for the majority of data managed in them - you turn them on and just start scribbling/typing.
  2. As I've said before, OpenDoc offered an interesting solution. For most OpenDoc documents, you started from the file system by opening a piece of "stationary". It's similar to the starting templates in Office and AppleWorks, but at the file system / operating environment level. Opening a stationary document would fire up an OpenDoc shell and place you in an editor for the default document part, and at first save, you'd have to enter a name/place for the document. Windows has the "New" (or is it 'Create'?) file/contextual menu in the Explorer from which you can make not only new folders, but at least some pieces of content. So you could go to "proposals", bring up the "New -> WP Document" (shrug) menu item, and be given a new empty file for a particular application. You name it, open it, and go. I don't use Windows often, so I haven't really seen how well this menu item is suported by third party applications. But it is a nice idea.
  3. But, when it comes to big documents and applications, I like the current way of doing things. One reason is that since subscribing to .Mac and using its iDisk, I share some documents (namely a rather large OmniOutliner document) between work and home and sometimes in between. Auto saving would be bad due to iDisk's speed (which is not horrible, but it's definitely not fast like local drives). Another reason, as Mr. Gruber points out, is that life is often full of temporary scratch documents. And there are so many different documents for different purposes that it just doesn't make sense for some situations or fields.

The reason for so much variety could, however, be due to interface cruft. We're running on heavy old operating systems with shiny new interfaces (and sometimes ugly new interfaces). The handhelds, particularly the Newton, had a chance to be actually new, and to approach how the operating system and applications performed in a very different way than the desktop operating systems. On the Newton, you just entered in data in the Notebook and then - optionally - filed it into Folders. You could also route the data (mail/print/fax/beam), or combine it with other Newton applications (entering "dinner with Kate" and clicking "Assist" would make the Newton go "oh! Shedule! Tonight, 8:30, Dinner" and find entries in the address book that match "Kate". Contrast this with a five step "Create New Calendar Entry" wizard.

But again - this is generally in the PIM category of data. It's a curious breed of data.

I'm not sure I want to get involved in the "there should be no 'Quit' command". There are so many applications of varying sizes and purposes out there that I doubt it will go away any time soon. The big case-in-points are the professional applications, from the Office type of applications to the Adobe and Macromedia product families, which are often very large applications, and also the Pro Tools / Final Cut Pro type applications. These applications offer a lot of functionality and people tend to stay in them longer. Adobe GoLive 6.0.x is a very large application, and when I'm using it, I keep it open even if I have no open documents at the moment, just to make it easier to switch to. I'd be very frustrated if I closed a particular window and it caused the whole application to unload itself. In the case of Quicken, there are so many windows that open up and use for control, which one would be the reigning "close this and the whole thing goes" window?

On the other hand, there are the utility applications. Apple's iCal and Address Book both go away when you close the main window. Other smaller apps do the same. This effect is probably completely unnoticed on Windows since the global X app killer button is so ubiquitous, and multi-document apps and single document ones are harder to distinguish.

I'll (probably) wrap up my random thoughts in the next post in this series, in which I plan to talk about some applications and developers on Mac OS X that are leading the way away from cruft, and a look at where the major desktop operating systems are (finally) headed.
6:32:47 PM  blips[]    




Thoughts on Interface Cruft, pt. 2: Application Organization
Continuing my thoughts on Interface Cruft (sparked by this paper by Matthew Thomas), this is a quick post about one of the things that Mac OS X gets right (or at least - more right than others ).

Mac OS X is more of a system of compromises than it is a new operating system, due to the challenges of integrating the Unix and Mac OS environments, and due to compromises the NeXT team took to try to make NeXTStep friendly to certain environments (by building on Unix) while putting a nice Object Oriented shell on top of it.

The most interesting piece that has been used from NeXTStep 1.0 up to Mac OS X 10.2 is the use of Packages on the file system. These are objects on the file system that appear as a single item to the higher level operating environment, while they are actually file system directories that are full of smaller objects. The most common examples of this are applications. In Mac OS X's finder, bring up a contextual menu on an Application (especially well written Cocoa applications like OmniOutliner or NetNewsWire Lite) and select "Show Package Contents". A new Finder window will show up, most likely with a single folder titled "Contents". Inside there will be executables (with the ability to hold executables for multiple platforms) and resources (icons, Interface Builder documents) at the very least. But the package can also contain Help Files, PlugIns (which can be managed via the "Show Info" command in the Finder), other frameworks, scripts, and even other applications (OmniOutliner has "OmniGroupCrashCatcher", an application for reporting crashes to the Omni Group).

Essentially, it's a way of doing what the traditional Mac OS did with its resource fork in a manner that's friendlier to traditional file system expectations. It can also be viewed as a way of Object Encapsulation. There's one very clear advantage: since most Mac OS X applications are self contained, they can be freely moved around, shared, whatever. I can use iChat to send a friend a copy of NetNewsWire Lite by just going to the Applications folder, and dragging and dropping the application into the iChat window. Contrast this with Windows, the Linux desktop environments, and the classic Mac OS. The last time I downloaded Mozilla for Mac OS 9, the folder that Mozilla unstuffed to was filled with folders and odd little Mozilla support items, and the Mozilla application was just another icon in the middle of the mess. On Mac OS X, all of that is contained within the executable Mozilla package. If you open up the package contents of Chimera and drill down to the "Contents/MacOS" folder, you'll see all of the Chrome, Components, and Plugins folders. But instead of cluttering up the Finder, it's all contained cleanly within the Chimera package.

This also means that you can (optionally) put the local Applications folder onto the Dock, and have rapid access to all applications, similar to the Applications sub-menu off of the Windows Start Menu. Unlike the Windows start menu, which is essentially the old Program Manager from Windows 3.x, the items in the Applications Menu are the real deal, not some pointer to an executable buried in the messy Program Files directory. This also means that - with a few exceptions - removing an Application is simply a drag to the trash. The few exceptions are applications that are installed which also extend the system (things like iSync, or even iTunes which comes with device drivers). Writing about the Windows start menu, Matthew Thomas writes:

And naturally, rearranging items in this menu is a little bit less obvious than moving around the programs themselves. So, in Windows 98 and later, Microsoft lets you drag and drop items in the menu itself — thereby again breaking the general guideline about being able to cancel a click action by dragging away from it.

This Programs menu is the ultimate in cruft. It is an entire system for categorizing programs, on top of a Windows filesystem hierarchy which theoretically exists for exactly the same purpose. Gnome and KDE, on top of a Unix filesystem hierarchy which is even more obtuse than that of Windows, naturally copy this cruft with great enthusiasm.

So, while Mac OS X has made a lot of compromises in order to be friendly with long-running expectations of a user interface, and to be friendly with Unix expectations of file system layout, it does do a lot of things right. There are plenty of sore spots (including interface irregularities between different Apple produced iApps), but there is a pleasant clean feeling to it all. Generally, there are few alarms and few surprises. As Mac OS X continues to grow, I imagine that the situation will improve. And, for all of its cruft, the future of Windows has some interesting developments as well.

My next post on this subject will deal with some individual applications on Mac OS X that are taking the right steps away from interface cruft.
9:01:56 AM  blips[]    





  Saturday, November 9, 2002

Microsoft Share Source CLI release supports Mac OS X
An interesting development on the .NET front - Microsoft's Common Language Interpreter (CLI) can be compiled and run on Windows XP (naturally) and also on FreeBSD and Mac OS X, which essentially brings C# to Mac OS X.
1:20:07 PM  blips[]    




  Thursday, November 7, 2002

Thoughts on Interface Cruft, pt. 1.
Matthew Thomas writes an interesting post titled "When good interfaces go crufty". It's an interesting read and he raises a lot of good points: why we have to manually save (still!); the reasons for the "Quit" command in programs, etc.

That latter one was one of the things that Compound Document Systems like OpenDoc were supposed to save us from. When you opened an OpenDoc document, there was no "File" menu (it was replaced by "Document", at least when using Apple's OpenDoc Framework (ODF)), and there was no "Quit" command. When you wanted to start a new document, you were supposed to find the right stationary to start from. Stationary, in Mac OS terms, represents documents that upon opening are pre-populated, but are flagged as a New Document, so that the first time you did hit "Save" you'd have to choose a new name. The Office Suites (both big ones like Office and small ones like AppleWorks / MS Works) do similar on their startup screens. OpenDoc was significant because it put such functionality basically at the Operating Environment level instead of the Application Level.

Unfortunately, OpenDoc was killed before there was really enough computing power to make it work - it was painfully slow on the Macs that existed at the time. And, even though the paradigm should have been common to people who used the office suites (big and small), it was still really awkward to shift away from the application-centric paradigm.

"And the world has suffered for our silence..."

Windows has been interesting. From the whole "New >" contextual menu item that showed up in Windows 95 where you could create new text, picture, etc, documents to the more recent usage of multitasking to spawn separate instances of Applications for each document that still feel like a single multi-document interface (Internet Explorer on Windows has been like this for a while, Office has gone this way). But MDI on Windows can be just...weird, due to what Windows marks off as an application. It could be that I'm just used to the Mac. But, doing some Zope development on Windows lately, it was hard to figure out when TextPad would spawn a new application instance, and when it would open a text file in the main TextPad window.

So, on the Mac side, how are things in this area? I don't think that the application -> quit paradigm is going to go away anytime soon, partially because of Cruft. But things are changing. For one thing, due to Mac OS X's memory management, it's not that big of a deal to keep an application running even with no documents open. And many such Applications respond intelligently to the dock - when you click the Finder, IE, Terminal or other apps that are already running with no documents open, you'll get a new window (this behavior is often configurable). It varies between applications, but most of the time the apps do the right thing. When my cable modem was installed and my home iMac was still running Mac OS 9, I watched the serviceman click the running IE icon numerous times, obviously expecting a browser window to pop into view.

I'm cutting off this post here. It's late, I'm fresh home from the bar, but I hope to post more on this soon. It's a topic that interests me. It's interesting contrasting Microsoft's Tablet PC with the designs of the venerable Newton. I think that the Newton was one of the more interesting Operating Systems in recent memory, while Tablet PC is kindof like Mac OS X 10.2 with Ink recognition - basically Windows XP with...handwriting recognition... Nothing dramatically new. But there are interesting designs that are going deeper into the heart of Apple's and Microsoft's offerings that could be indications of where things are going. And again - I'll have to promise to try to get back to this topic very soon.
11:23:38 PM  blips[]