Don't crow over the eating of .mac ditto

As recently reported on many Mac-sites, and as witnessed by all present iTools users who received a personal email about it, Apple has decided to "extend" the deadline for erasing all iTools accounts (and the data saved there) that have not yet been "upgraded" to a .mac account. Fifteen more days before Data Armageddon. So how should we react?

A number of voices have already arisen, celebrating the victory of le peuple over the Monster of cAppletalism, and predicting that the company will make the tactical retreat more or less permanent by restructuring .mac into a multi-tiered service. I doubt it will happen.

To my mind, there is no doubt that Apple once again (as detailed in a previous MacBloQs) has come up with something that shows NO connection to, or consideration of, the situation of most of their customers. If they had, they would also know that only a minority of Mac users have the need or/and the financial background (ie, professional) to buy the full package of services at the suggested price. Furthermore, Apple has not considered the historical background -that iTools was free and, being intimately tied to the MacOS, part of what the user bought along with the computer.

Therefore, a better solution would have been to cut down on the iTools free deal but not terminate it, offer the present .Mac package at a lesser price than the present, and develop a Pro version for small businesses that don't want the hassle of setting up its own web/mail servers. The first could be called .mac Lite and include the present @mac.com account with the old storage limit, the AIM tie-in, and maybe a 5MB iDisk (mainly for demonstration purposes). The second, (.mac Classic? ;-> ), could cost $39.95 (after all, this IS Apple) per annum and be offered at an introductory price of $14.95. Buying a new Mac would include a free .mac Classic account for the first year.

This scheme would get many more iTools users onboard, new Mac owners would be hooked after the first, free year and would not want to downgrade to .mac Lite, and a new group of customers would be brought into the Net (no dot there) services fold. When a small business became a larger business, it would want to extend its use of the Internet and could do so almost seamlessly by moving its .mac services onto an xServe platform (for instance).

But that is not how it will be. Apple taught asses how to be stubborn so they will never openly eat crow. They will "make adjustments", as indeed they already have: first they added extra services to sweeten the deal, then they extended the deadline, hoping beyond hope to drag a few more thousand into the moneypress, and in a few days' time (or so the rumors go) they will announce special "Educational Packages" that make .mac accounts close to free for schools and other bulk purchasers. On top of that they will probably put one or two further services, last-minute extras (CD's with your photo on?), and possibly an added three months of .mac service (to reward your pioneering spirit, or the like). But no general price reductions, no tier-structure .mac, and NO free email accounts.

It is all about numbers. Jobs knows more than his tai-chi - saving face is all-important to him. And he is Apple. Apple needs to be able to show significantly better numbers on .mac adoption than it has so far, and it cannot be seen making price reductions to achieve it; that would be admitting defeat - no, stupidity. Choosing to reduce prices in order to support education does not come into that category; apart from adding a major boost to the numbers, it is an effort to shore up Apple's rapidly crumbling bastions in that market segment.

Apple may change its position to turn defeat into victory. But not if it is jeered at by a large chorus of derogatory press members. We cannot expect to crow about Victory Won now and expect Apple to give further, covert, admissions. Apple will not eat public crow - so we should stop crowing.

Melée, hotch-potch, and other UI terms (2)

The Dock functionality is hard to metaphorize - the maritime function implied is definitely too distanced to carry any associations beyond the single metaphor. Since the term seems to be used simply historical reasons (NeXT) is therefore unproductive, a new metaphorics should be developed (unfortunately, Tray is already in use). The term Docklings is actually good since it implies a number of small, yet individual, actions with an easily accessible visual representation. The strong, associative connection with the dock, however, is humorous rather than functional, and it certainly jars against the previously mentioned "dragon-puff".

The Finder window represents quite a problem. It is evidently intended to take over a good deal of the Desktop functionality, but it has also included a number of function which are duplications of what the Dock offers. Duplication is not necessarily a bad thing; activating commands through keyboard combinations instead of with mouseklicks in a menu is a good extension, since it is faster. But there is less overlap in the latter: it supports the basic "I see..." extension of one's range of commands and also clues one in on the existence of a second way of activating the command: the keyboard combination is written next to the command. The two possibilites are positioned in different domains: the movement/visual and the precise input ones. The Dock and the Finder window functionality overlap, on the other hand, tends to create some confusion: being in the same domain, they imply that their functions are dissimilar.

Another point is that the Finder window has taken over the structure of MS Windows windows: rather than just showing a representation of a collection of data, a set of commands are accessible at the top of the window. Closer scrutiny shows that the basic ideas are not the same: in Windows, the total set of possible "verbs" of action are tied by proximity to the set of data, but in Aqua they are split up into two: the verbs in Finder windows are concerned with the representation of various sets of data - shifting the virtual circumstances, not the virtual distance, of the representation of sets -; all the other verbs are collected in the general menu at the top of the Desktop.

It might be argued that the Windows way is more consistent (!), but Aqua (mostly) retains the superiority of method by nestling most of the verbs in menus against the upper edge, making use of whatTognazzi calls infinite depth: in order to "hit the target", all one needs to do is flick the cursor in the general direction and then slide it along in one direction. Now, mention Tognazzi in any forum of Mac-users, and immediate uproar will follow: half of those present will begin yodeling with their faces towards Silicon Valley (no, I don't mean Nicole!), and the other half will murderously start waving hacksaws and power drills that you didn't even know were in the room. Part of the problem probably is that the efficicacy of the principles he is advocating is unquestionable, based as they are on extensive scientific tests; however, their premise is that users principally use the mouse to interact with the computer. As just discussed, it is more complex: newer users look for commands, using the mouse, and they don't need speed, but seasoned users use the key command (whether built-in or invoked through third-party software) to achieve speed. Thus, what Tognazzi calls Fitt's Law is less relevant nowadays, and the superiority of Apple's choice is negligible for the power user when a keyboard shortcut is available.

Instead of merely using the "browser" metaphor and functionality in Finder windows, Apple has chosen to make things more complex. Quite apart from the interesting fact that the "browser" functionality now seems to be widespread enough to presuppose its superiority perception-wise , it is a clear step away from the hierarchical data presentation, towards a hypertextual concept based on a user awareness of the virtuality of the presentation. The Finder possibilities take this a step further, enabling the user to choose a grouping of data or programs based on individually chosen criteria (Favourites, for instance), and have them presented according to a number of other, more traditional (alphanumerical) criteria. In other words, to appreciate the functionality of this, the user has to be able to abstractize from the sector-based physicality of the harddisk and the hierarchical structure of the OS database, and work consciously with a motile presentation: the unit of differentiation is the choice, rather than inherent characteristics. But why not give the possibility of both?

The advantage is that all you need to do is define the criteria, rather than make the category and then find and place each data unit (and manually update the category whenever something has changed). And since the basic Sherlock search function has already been implemented in the Finder, why not go the whole hog? This is one possibility I sorely miss from the Atari ST Desktop, the ability to "blank out" irrelevant data from the data representation in a window. At present, OSX only allows the "grouping" activity - the individualized, virtualized representation of choice - which is very manual, demanding a "placing" of the individual program/data unit into the relevant category. Why not make a "data selection criteria" categorization possible, as it was in Sherlock2? In other words, you build a set of search criteria - all data units on your "Grassland" partition with the letters "cow" included in the name, for instance - and save it as a category at the top of the window. Clicking on it presents you with all the data units currently fulfilling these criteria. Oh, I almost forgot: why isn't it possible to use wildcards when searching? That was one of the major advantages of the Atari ST Desktop "blanking out" feature...

As you might have noticed, this is turning from being a critical review of the OSX GUI, and into a more general melée (!) of musings about interaction. However, gradually it will turn full circle and I will give more reasons why I find the OSX interface(s) confusion and frustrating. Until then...


---------------------------------------
* Please notice that I avoid the use of the terms "allegory", "analogy" and "parable". Instead the terms "metaphor" and "metaphorics" are used, the latter to indicate a set of associatively connected metaphors.