[OT] "Pre-announcement" of Python-based "computing appliance" project.
Alex Martelli
aleaxit at yahoo.com
Sat Sep 25 03:31:52 EDT 2004
More information about the Python-list mailing list
Sat Sep 25 03:31:52 EDT 2004
- Previous message (by thread): [OT] "Pre-announcement" of Python-based "computing appliance" project.
- Next message (by thread): [OT] "Pre-announcement" of Python-based "computing appliance" project.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Richard Hanson <me at privacy.net> wrote: ... > > search facilities _together_ with good organization of your materials > > (if you take the bother of the latter). Consider Mail.app: its search > > functionality works across all mailboxes or on a single mailbox -- > > you're _still_ encouraged to do a little decent filing of your mails, > > It *does* seem necessary to "educate" the database about our own > preferences and styles of organization and the like, as well as > "rating and filing" specific, individual objects. I'm interested in > figuring out ways to make it *very* easy to "add value" to the > database with a more efficient HCI -- unless it's very, very simple to > do (nearly automatic, even ;-) ), the user won't do it. There are many kinds of users. I essentially rely on automatic classification of mails into mailboxes based on a dozen or so rules/filters. But my wife Anna, who's worked as office manager etc for years, has filing as "second nature" -- _her_ mailboxes (Thunderbird, her preference) are neat and pristine, just like her filing cabinets. In real life whenever I have to look for some weird document I face hours of rummaging through papers trying to divine where I may have put it; when Anna is looking for a document in her archives, she reaches into the right folder, and there it is, period. On computers, with automatic classification rules and search engines &c, her advantage is not quite as pronounced -- but it's still there. I have known several people with a penchant for effective and systematic filing, though they are no doubt a minority, wrt us slobs. It's important for the system not to get in their way: for example, when they move a mail from folder 'pending purchase decisions' to folder 'purchases considered but rejected', the system must automatically and seamlessly update the indexes of both folders, and the global index of all boxes, too. Otherwise, if the system makes it _less_ effective to do good classification and filing, it will earn deserved scorn and enmity from those kind of users. > > though the search does make it more feasible to survive with the popular > > "one big inbox and never bother filing" paradigm;-). > > I'm thinking one database with some auto-indexing helped along with > specific user guidance re the "value-adding" aspect. Without some sort > of fast auto-indexing, of course, and without the easy ability for > user attribute-adding, the "one big box" paradigm could be painfully > slow for precise narrowing of large collections of heterogeneous > objects. Presumably, the above mentioned apps, and Google, of course, > do the auto-indexing part. Yes, and 'searchlight', Tiger's forthcoming search engine, centralizes the indexing (still needs SOME cooperation from apps, of course) as well as the search. The ability for the user to tag documents with arbitrary metadata is also a key part of this, I assume it's what you call the "value adding aspect"? > > Consider Google: > > it doesn't eliminate the advantage of well-organized, navigable sites, > > even though it gives you a chance of surviving the typical "designed by > > marketing, what's this ``usability'' newfangled thing?!" ones... > > Heh. Don't get me started re the latter... ;-) > > Apple's work definitely sounds like a step in the right direction. Is > there *complete* integration of *all* object types? Only in as much as applications cooperate with the central engine, at least in some aspects. That may be why Apple has been circulating alphas of Tiger to developers with such HUGE lead time, up to a year before it hits the shelves: Searchlight's value grows exponentially the more apps register their documents' metadata with it, and use it for their search facilities -- app developers need time to enable that. Say a user prefers Entourage or Thunderbird to Mail.app for their mails: such a user will find Searchlight less useful than a Mail.app user will _unless_ these other mail apps cooperate with Searchlight (sure, Apple might reverse engineer _some_ file formats for documents of some recalcitrant apps of particular importance, but that's more overall work, and will still tend to produce results not quite as satisfactory, than if the app's own developers did the job...). > As I see it, the user should be able to tap a button and change an > email into a snailmail doc, or vice versa, say, with the system > handling the details automagically. In Tiger, such import/export facilities remain fully up to individual apps -- there's just no way an indexing and search facility can have enough metadata on all aspects of documents of disparate types (including, crucially, formatting/presentation issues) to do the job. > And, with a few appropriately set > filters using attributes, sorts, and such, the user should be able to > see all the emails, documents, pics, sounds, flicks, etc. relating to, > for example, "Pink Floyd" -- all in one, narrowed view even though the > objects are of disparate types. Yes, this IS part of Searchlight's functionality, and part of the added value of a centralized indexing/search wrt per-app facilities. > > (Some of my early inspiration was XTREE for DOS from the 1980s -- > XTREE provided a global view which could be narrowed; although, things > were still a bit primitive back then.) > > I don't have access to the modern Macs -- they sound more interesting > to me than the Wintels I'm using. (Although, pedantically speaking, my > currently not-working Fujitsu laptop uses a Transmeta chip, not an > Intel one.) Heh -- Anna's got a Fujitsu with a Transmeta chip, too (P2000 Lifebook, works fine, alas not very fine with Linux yet;-). And all the Linux boxes in the house have AMD chips, better value-for-money (there _is_ an OpenBSD box with a pentium 75 that does routing, firewalling &c year after year since the dark ages, admittedly). Today's Macs don't have Tiger yet (unless an alpha-stage developer preview), though some of the (mostly per-app) search facilities are indeed excellent even in Panther, the current release of MacOS X. Tiger should be out in the spring of 2005, and it will cost about $150 (free with _new_ Macs, but $150 to upgrade existing ones). > Mike Meyer's link to an implementation of Jeff Raskin's work also > sounds quite interesting. I note from scanning the smaller zipfile > referenced in the link some similarity with my own ideas -- no save or > delete, for example, such being either unnecessary or is transparently > handled under-the-covers. Yes, Raskin's paradigms are definitely revolutionary, for good or for evil. Apple (and I guess MS for Longhorn) OTOH are living in the real world, where apps from multiple suppliers with their own separate documents (sometimes in proprietary formats, sigh) are a reality and users won't drop them (particularly as they need to keep exchanging docs with other people using other machines), so any paradigm shift must accomodate the likelihood of gradual and incomplete transitions... Alex
- Previous message (by thread): [OT] "Pre-announcement" of Python-based "computing appliance" project.
- Next message (by thread): [OT] "Pre-announcement" of Python-based "computing appliance" project.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list