Bryan Cantley wrote :
> I do not really
> disagree with any, except for the GUI component.. But perhaps for
> different
> reasons than have been discussed.
Having just noticed your .sig, and thus where your interests and
experience lie, I think you're probably right, and that we may have
been talking at crossed purposes.
> But what if you are mute? Or deaf? The argument for any "sense"
> specific
> interface is only partial, no?
Yep, absolutely. This is why the separation between UI and action is
so important, why MVC was one of the biggest "silent revolutions" in
computing, and why it's so much easier to develop GUI-based apps for
OSX than for Windows or, $DEITY forbid, X-Windows. The whole concept
of MVC, that the actions carried out are separate from the interface
manipulations required to make a give UI carriy them out, expresses
this perfectly - if the "model / controller" layers express the intent
of a piece of software correctly, then any view implementation,
whether an OSX clickable window, a web view on a remote application,
or a teletype, should be able to carry out those actions more or less
equally elegantly. Sure, it never works completely like that in
practice, but it's something to aim for.
>> Function first, form later.
>
> I disagree. Form and function together [but that is such a last phase
> paradigm argument]. I don't think the ideal OS is restrictive in
> EITHER.
> I don't think I;m talking "widget placement".. As much as im talking
> "visual
> interaction.. And aesthetic pleasure". But again, im trying to
> approach this
> from the viewpoint of the consumer who knows nothing about, nor
> cares about
> the technical mechanics..not the tech heads like us that "somewhat"
> understand "data hierarchy" [that sounds bad, but I hope you get my
> point].
>
I understand entirely. My argument would be that if your UI is
awkward, then either there's something severly broken in your UI
layer, simply bad UI design (often the case), or that something is
broken in the abstraction behind that layer. This latter is probably
more often the case than we, the developers, would like to think. In
that respect, the "form" serves to show the inherent flaws in
"functional" design, but it's function that should, at least in my
opinion, be the driver. Admittedly, at this point, there's a certain
amount of crossover between what is function and what is form - for
example, consider a program to send mail.
I might define a "functional" layer that allows you to add a recipient
to a mail, add a subject, add some body text, and send the mail. If
I'm stupid, I might specify that you have to do that in order, which
would make the majority of user interfaces particularly unwieldy, but
that would be a reflection of bad functional design (and, indeed, one
of implementing UI constraints within the functional layer).
I know this is going a bit techy again, and that the average non-techy
might well be completely out of their depth discussing stuff like
this, but I do think it's necessary. Apologies to anyone I'm
alienating, just slap me in a killfile :)
> The purpose of computing: u r correct
>
> The experience of computing: you are wrong
>
> There is a difference!
>
Oh, certainly, there's a massive difference. I feel that the current
approach is to favour the "experience" over the "purpose", that it's
deemed more important to have a shiny interface, to have web pages
that auto-complete text boxes, than to have something which is
functionally elegant, or, not to put too fine a point on it, useful.
I believe that, in many cases, the cart has been placed firmly before
the horse.
The paradigm of using "Applications" to manipulate "Files" is, I
believe, wrong, and the need to use a "Browser" to find tyour "Files"
in some hierarchical and arbitrary "Directory Structure" is a
fundamental abomination. OSX does, in many ways, avoid some of the
pain; it's better than most of the other contenders, but I still need
to use "Finder", I still need to tell the computer that I want to open
this particular text file with XCode, and this one with TextMate, and
that I'm gonna postprocess this one with LaTeX, and this one with gcc.
My ideal OS, interface issues aside, would provide a completely opaque
storage, allowing me to organise my data as I wish, on the fly, in
multiple, on the fly configurable views; so I might flag a piece of
data as LaTeX, but as part of such-and-such a project, maybe with the
project (and thus that piece of data) linked to a particular client in
my "address book". Another piece of data might be flagged as a piece
of C++ source code, also part of that same project, and thus linked to
the same client. I might be able to ask the system how much time I've
spent working on data linked to that project, take that report and
store it as a another piece of arbitrary data linked to the project,
and that I might then include via a filter into the original piece of
LaTex, which is, in fact, an invoice. The C++ data I might also say
should be available not only on my desktop machine, but also via the
web for browsing by the client, and also be something that comes "with
me" on my tablet device, and that changes should be version
controlled. I might, however, say that I only want to version control
the LaTeX data after postprocessing and at the point at which I send
the postprocessed data (which will, of course, also be linked to the
project and the client) to my client and my accountant.
When I go to a "view" of data linked to a particular project, I want
to be able to say "this thing is top priority, related to this task",
and have it appear, by magic, in my to do list. I don't want
applications, I want to be able to choose between *views* on a piece
of data, dependent on context. I want those "views" to have a
consistent interface. I want to be able to see what stuff hasn't been
version controlled, where its type would normally dictate that it
should be according to my rules. I want to be able to fly backwards
and forwards up and down the history of a piece of data, see what's
changed, see which changes were transient (Time Machine style backups,
for example), which ones were logged to version control, and by whom
so on and so forth.
When I pick up my tablet device, I expect to have all the data I need
already on it, no tedious "manual syncing". When I come back with my
tablet device, having scribbled down a bunch of notes in a meeting
with the client, I want those notes to be automatically linked to the
project (or projects) I was discussing at the meeting. That bit of
Ruby code I changed on the fly at the meeting as part of a demo needs
to be synced back to the main store, and the fact my colleage has
simultaneously changed the same piece of code off the project's
central repository neds to be flagged.
When I need new storage, I want the system to tell me. I want it to
say "you're running low of storage, go grab a new disk". When I plug
in that new disk, I don't expect to have to tell the system to move
this, that, and the other over onto it manually. I expect the system
to ask me "will this be plugged in permanently, can I use it for
expanding your storage?", and, if so, go about that automatically. If
I have loads of free space, I expect it to configure itself for high
performance RAID type access *automatically* after asking me if it
can. When I pull a drive that's being used for storage, I expect it
to say "hey, I was using that, are you removing it permanently?", and
if so, ask me to put it back so it can pull my data off it and store
it somewhere else, pausing only to wipe the drive completely if I say
so.
You get the idea. You know that large, crater-pocked satellite
orbiting around our planet? The one which isn't man-made? I want
that. On a stick. Now. And a pony.
All of that is hard, damned hard, but not impossible, and above all,
none of it presupposes any particular user interface technology.
To do it, you need not only files, and knowledge of the types of data
within those files (which we now have through the pitifully poor
"metadata" of file extensions), but arbitrary "other" metadata, which
metadata itself can have metadata and so on. It gets hideously
complex at a systems level *amazingly* fast - how far down the
metadata chain do you go when you're looking for potential actions to
carry out on a piece of data, for potential views of that data to
display, for potential filters of that data, for example?
Christ, I scare myself sometimes.
Simon
====================================================================
The NewtonTalk Mailing List - http://www.newtontalk.net/
The Official Newton FAQ - http://www.splorp.com/newton/faq/
The Newton Glossary - http://www.splorp.com/newton/glossary/
WikiWikiNewt - http://tools.unna.org/wikiwikinewt/
====================================================================
Received on Thu May 22 12:32:52 2008
This archive was generated by hypermail 2.1.8 : Thu May 22 2008 - 20:30:00 EDT