Mozilla User Interface (MUI)
Steeg Lehman
I think the internet browser needs to take the next step and become a
standard cross platform user interface. Currently that means replacing
the desktop but I have confidence that this group will be able to see
beyond the desktop metaphor.
As we develope a desktop standard everyone will be able to program for
the MUI rather than *saying* they are programing for Window95 or Solaris
or Linux. (Longer term perhaps.)
I don't want to load mozilla I want it to become my interface to the
computer. Netscape has assured continued access to the API. (Even the
source)
How do we replace/extend explore.exe, CDE, etc? I think we should devote
significant resources here.
Mark Roth
I have to agree with Pat on this one... Web Browsers are for browsing
the web, not navigating your hard drive.
I do agree that it's about time for UIs for modern OS' to take the next
step, and integrate internet connectivity with the OS, but I think this
should take the form of integration of FTP with the explorer interface.
Certainly the web browser, a program for viewing public (or private) up
to date content, has nothing to do with sifting through files on your
hard drive!
- Mark Roth
Rinie Kervel
Mark Roth wrote:
> I have to agree with Pat on this one... Web Browsers are for browsing
> the web, not navigating your hard drive.
Why, If it can navigate the complex web, wouldn't it be easy to navigate
your drive.A Browser is for navigation and links. If you can represent a
directory with a HTML page + links
you have superior navigation. Also missing from an 'explorer' are
bookmarks: you favorite folders,
that are just one click away.
Rinie
Steeg Lehman
Pat Gunn wrote:
> > As we develope a desktop standard everyone will be able to program for
> > the MUI rather than *saying* they are programing for Window95 or Solaris
> > or Linux. (Longer term perhaps.)
>
> ? Perhaps you're referring to Java? That's in Sun's hands, not ours.
> I still hope they succeed...
Java is a cross platform programming tool yes. But I was thinking more of a
cross platform UI in this context. A kind of standard UI API if you
will.Perhaps Java's JFC collarboration is similar. I think something focused
on interface to the computer rather than to a program.
> Ack! This would be a very bad idea. Specifically, Microsoft is allowed
> to
> make drastic changes to windows,...
This is really the core reason for my concerns. Microsoft can arbitrarily
change the API interface without documentation.Currently they have the
ability to break or degrade any program that is written. Even the current
NPL assures an even playing field for *everyone* as regards the API.
> ...because they support it and they can
> support it. If we replace explore.exe, we will essentially make everyone
> who installs Nav on Windows be using an unsupported configuration.
> Microsoft
> won't help them, except to tell them to remove Nav, if they have
> problems.
> IMHO, this would be very bad. Also, it would require us to do this on
> MacOS,
> Unix, OS/2, BeOS, and every other platform in order to maintain
> feature equity, which is something that I think Netscape wants.
Certainly a project that only an open-source community can tackle. :)Yes,
These are very good points.
> Also,
> not
> every user, and I would think almost no "power users" would really want
> a browser as their GUI. I certainly wouldn't.
Even if you were able to define what that interface is? What if you could
open explore.exe, CDE or a command shell?
It could be fairly light I think.
Steeg Lehman
Mark Roth wrote:
> I have to agree with Pat on this one... Web Browsers are for browsing
> the web, not navigating your hard drive.
>
> I do agree that it's about time for UIs for modern OS' to take the next
> step, and integrate internet connectivity with the OS, but I think this
> should take the form of integration of FTP with the explorer interface.
> Certainly the web browser, a program for viewing public (or private) up
> to date content, has nothing to do with sifting through files on your
> hard drive!
>
> - Mark Roth
Life Streams has some ideas about other ideas about organising
information in a temporal manner.
I have nearly 20gig online now in my local machine. "Browsing" that
information is becoming increasingly difficult.
When does my computer become a part of the internet?
I will stop and think carefully about what all the comments are here.
It seams so logical to me, but I have been known to miss the obvious.
Mike Thirlwell
> A similar argument could be made for a word processor. If it can display
> a complex word processing document, surely it can display your hard drive!
> Or an image viewer... If it can view images, surely it can view your
> hard drive!
>
But surely that's the whole point. What do all of the above file-types have in
common?They're all *documents*. Why do we have to open a word processor
program before we can look at or edit a text-document? Why do we have to open
an image viewer before we can look at or edit an image?
More to the point, why do we even have to still think about files, directories
and drives?
We don't use or store paper documents in this way, we can look at or edit any
type of paper document without needing different viewers to do it. The
physical desktop is a powerful tool. I don't think we need to ditch it yet,
ther's life in the old metaphor yet.
IMHO we should be taking a more document-, rather than application-centred
approach to designing for today's machines. Let's face it, the majority of
home and business users use their machines for managing documents of some form
or other. Rather than twiddling with toolbars and bookmarks, we should be
thinking *bigger* and coming up with a new idea.
Now that would really be a Microsoft beater!
Mike
> There's no benefit to having a browser be your interface to your
> computer.
>
> --
> ---------------------------------------------------
> Pat Gunn, moderator:comp.sys.newton.announce
> comoderator:comp.os.os2.moderated
> "You can always judge a man by the quality of his enemies." -- Dr Who
> http://junior.apk.net/~qc
> ------------------------------------------------
Simon P Lucy
At 00:43 16/03/98 +0000, Mike Thirlwell wrote:
>> A similar argument could be made for a word processor. If it can display
>> a complex word processing document, surely it can display your hard drive!
>> Or an image viewer... If it can view images, surely it can view your
>> hard drive!
>>
(this example is taken from NT 4.0 with IE 4.0)
See the Active Desktop, enable web content in a folder with JPG's, GIF's or
BMP
or whatever you fancy. As you select each one a thumbnail pops up on the
right
unless you've switched them off.
Note, this is not a browser its just handing off the thumbnail display to a
DLL
based on the mime type. But the Explorer with web content enabled does render
HTML and if you look behind the scenes somewhat you'll see a JScript sorting
out the folder content.
>
>But surely that's the whole point. What do all of the above file-types
have in
>common?They're all *documents*. Why do we have to open a word processor
>program before we can look at or edit a text-document? Why do we have to open
>an image viewer before we can look at or edit an image?
>
>More to the point, why do we even have to still think about files,
directories
>and drives?
>
>We don't use or store paper documents in this way, we can look at or edit any
>type of paper document without needing different viewers to do it. The
>physical desktop is a powerful tool. I don't think we need to ditch it yet,
>ther's life in the old metaphor yet.
Use my desktop for a metaphor and you will end up with a FAT file system and
orphaned windows you can't enable anymore because they've become fossilised
into layers.
>
>IMHO we should be taking a more document-, rather than application-centred
>approach to designing for today's machines. Let's face it, the majority of
>home and business users use their machines for managing documents of some
form
>or other. Rather than twiddling with toolbars and bookmarks, we should be
>thinking *bigger* and coming up with a new idea.
Apart from Microsoft being generally Microsoft-centric they are attempting
this, it isn't very convincing and you have to be a Paul Allen company to get
in on the act it seems (witness Visio), but some of the scaffolding is there.
>
>Now that would really be a Microsoft beater!
>
Might be a Microsoft equaller but only if you had a bunch of applications that
understood the operating system, the file system that way. I've been thinking
it would be nice to steal their clothes and do a much better job and remain so
far inside their published specifications that it would be difficult for them
to break without breaking everyone else. In other words don't screw the user
over cos you don't like Microsoft but use what they do have for the benefit of
the user.
This does _not_ mean a browser operating system. It can mean writing
extensions to the shell that are useful to the user, like moving into an FTP
zone, thumbnailing web sites (someone elses wish list), sidestepping the MAPI
trap and so on.
However, anyone expecting Microsoft's specifications to stay put over any
length of time should also stay away from lottery tickets since they
indulge in
product drift even more than most publishers do. For the most part I don't
even think they do it on purpose but what else can you do if you have hundreds
of Product Managers?
Simon
-------------------------------------------------------------------------
Objective Software
Simon P Lucy
At 01:51 16/03/98 +0000, Simon P Lucy wrote:
>At 00:43 16/03/98 +0000, Mike Thirlwell wrote:
>>> A similar argument could be made for a word processor. If it can display
>>> a complex word processing document, surely it can display your hard drive!
>>> Or an image viewer... If it can view images, surely it can view your
>>> hard drive!
>>>
>
>(this example is taken from NT 4.0 with IE 4.0)
>See the Active Desktop, enable web content in a folder with JPG's, GIF's or
>BMP
>or whatever you fancy. As you select each one a thumbnail pops up on the
>right
>unless you've switched them off.
Ummm never ask me for directions, they are on the left of course.
==========================================================
Objective Software http://www.dev-com.com/~objective
(44)(0)1299-823321 Tel Mobile: 44-(0)976-361760
(44)(0)1299-879047 Fax
16 New Street
Stourport on Severn
Worcestershire
England
DY13 8UW
Simon P. Lucy
Support queries http://www.dev-com.com/~objective/support.html
Steeg Lehman
> Make a program that does one thing and does it well. Nav is good for
> browsing the web. That's all I want my browser to do. Everything else
> should IMHO be in separate programs.
The web is going through growing pains. I am finding it increasingly
difficult to set up systems for people to modify documents that are spread
throughout the organization. There is information inside databases some on
web servers, file servers, local hard drives. In many cases the information
is closely related but separated by a huge void of different access methods.
I find myself writing programs just to help people get information from the
web to their drive so they can edit the document. Then I write a program to
send it back for them. I am doing similar things with databases.
Some people have 15 network drives mapped just to make it easier for them to
work with the network. They probably use 2 drives 98% of the time.
In the enterprise information system I developing there are heart beats,
histories, status's. The information is not on a hard drive necessarily but
they are all accessible at any given moment. I am starting to feel the pain
of what seems to be very redundant coding. I dislike having to reinvent the
wheel. :)
I would prefer to that when a word processor said "open file" it used the
same interface but I am practical too. (Really, I am... ) :)
It seems easier to begin at the "here is this data" send it to the word
processor.
I would like the MUI to be more of an interface than a specific GUI. Open to
addition of speech streams, filestreams, datastreams, lifestreams[TM].
Input to Output mapping interface perhaps rather than the code to do the
translations. Leave that to the separate programs. :)
I too would like the MUI "mapping tool?" to be minimal. Compact enough to
program into my PDA in fact. (There goes practical...?)
Thank you for you comments, I will think hard about whether this fits into a
Mozilla sub project. I still think it does...but I find your input
insightful.
G. Sumner Hayes
Pat Gunn wrote:
>
> Mark Roth wrote:
> >
> > I have to agree with Pat on this one... Web Browsers are for browsing
> > the web, not navigating your hard drive.
> >
> > I do agree that it's about time for UIs for modern OS' to take the next
> > step, and integrate internet connectivity with the OS, but I think this
> > should take the form of integration of FTP with the explorer interface.
> > Certainly the web browser, a program for viewing public (or private) up
> > to date content, has nothing to do with sifting through files on your
> > hard drive!
>
> Plan9, for instance, already has that capability, as does OS/2
> (FTP sites appear to be part of the local filesystem)
And the HURD, and certain Unix installations at various levels (Linux's
UserFS binds FTP and HTTP (among others) directly into the FS; more
portably, mc, KFM, and EFS all supply FTP/HTTP transparency to the
user's file-browser/explorer/whatever-you-call-it to a greater or lesser
extent)
I think the web browser isn't a general enough interface to capture a
lot of important interaction with the system (unless you're using it
solely as a JVM, in which case you're not really talking about the
browser anymore). I think that the two will converge in an Opendoc and
CORBA-on-steroids influenced (but less nasty than those) UI at some
point, but I don't think that the result will bear much resemblance to
the current-day browser -- which is good, because the current browser
interfaces all suck. I don't mean to put Netscape's UI folks down; I
think Netscape's interface sucks less than most browsers, and suckiness
is a general property of almost all UIs at the moment (browser or
non-browser). UI design isn't a very advanced art yet. But in the near
term, I don't think trying to shoehorn Mozilla into a replacement for
the UI is a very fruitful endeavor. On a system with something
approaching a real UI (I use X on Unix, and mechanism doesn't a UI make)
it would be even less well-advised, IMHO.
So what should be done with Mozilla, from a UI perspective? Modularize
the parts that could be useful in a componentized interface. Other than
that, incremental adjustments are probably the way to go, sadly. One
nice thing would be to have the history maintain the nonlinear structure
of the web -- it's not the World Wide Line, and Back/Forward aren't
enough to navigate usefully around a lot of sites. A history mechanism
with a tree/graph structure would be pretty cool. Maybe even a Pad++
-ish zoomable history box, but that's probably too ambitious for a first
cut. It'd sure knock the pants of IE visually, and would actually be
quite useful in some situations as a bonus.
-Sumner
--
rage, rage against the dying of the light
Wouter Lagerweij
Pat Gunn wrote:
> Make a program that does one thing and does it well. Nav is good for
> browsing the web. That's all I want my browser to do. Everything else
> should IMHO be in separate programs.
I, as usual, agree up to a point...
Netscape could certainly make for a nice enhancement for something like
Windows Explorer. I very much like what's been done with kfm, the
filemanager from KDE, the desktop environment for X. It acts like a
filemanager, but the location of the files/directories is displayed as
an URL like in a webbrowser, and if you click on a HTML file, it views
it with it's internal HTML browser. In the same way it can also browse
the web. Works very nicely indeed, and I've heard the Gnome project is
thinking in the same directions for their filemanager.
I wouldn't want my whole desktop 'converted' to a web page though...
(OS/2 WPS is so much nicer:-)
greets
wouter
Wouter Lagerweij
G. Sumner Hayes wrote:
> So what should be done with Mozilla, from a UI perspective? Modularize
> the parts that could be useful in a componentized interface. Other than
> that, incremental adjustments are probably the way to go, sadly. One
> nice thing would be to have the history maintain the nonlinear structure
> of the web -- it's not the World Wide Line, and Back/Forward aren't
> enough to navigate usefully around a lot of sites. A history mechanism
> with a tree/graph structure would be pretty cool. Maybe even a Pad++
> -ish zoomable history box, but that's probably too ambitious for a first
> cut. It'd sure knock the pants of IE visually, and would actually be
> quite useful in some situations as a bonus.
That's right! I still miss that from IBM's WebExplorer. It saved the
history as a tree structure, viewable in a seperate browser window.
Wouter
Greg Scallan
> I have to agree with Pat on this one... Web Browsers are for browsing
> the web, not navigating your hard drive.
>
> I do agree that it's about time for UIs for modern OS' to take the next
> step, and integrate internet connectivity with the OS, but I think this
> should take the form of integration of FTP with the explorer interface.
> Certainly the web browser, a program for viewing public (or private) up
> to date content, has nothing to do with sifting through files on your
> hard drive!
Funny, I remember this same exact argument when Windows 3.1 came out. "We
don't need a bunch of silly icons to get a list of files. Why add the
overhead. DOS is just fine and fast."
Although I also agree and do not like the integration that exists today, it
is because of performance reasons. Win95 could run in 1MBof RAM and well
on a 486. Win98 is a total hog. Personally, I think it's very cool that I
can define a wallpaper and screensaver in standard HTML. Now, I don't need
to learn a proprietary Windows DLL format called .SCR in order to create my
own screensaver.
Greg
Chuck Adams
>A similar argument could be made for a word processor. If it can display
>a
>complex word processing document, surely it can display your hard drive!
>Or an image viewer... If it can view images, surely it can view your
>hard drive!
So you're saying that browsers should only be able to display documents that
are fetched over a network and NOT a local file? Does the file:// url mean
anything to you? Ever noted that most webservers will generate directory
listings? That PUT and DELETE is part of the HTTP spec? Sounds a whole lot
like file^H^H^H^Hresource management to me. Files do not deserve second-class
treatment as resources because they happen to reside locally.
Hm... I may have just successfully argued against putting the file management
functionality into the browser as opposed to a smart local server. But that's
a matter of implementation -- the immediate result, the interface, remains
the same. The desktop metaphor is firmly entrenched for better or worse, and
communication with the local server to perform file copies, moves, deletes,
and so forth is still most intuitive to the end user by means of methods like
point and click, and drag and drop. The server will need some enhanced
functionality to do this (for instance, moving a file with a PUT and DELETE is
not acceptable), and the browser will need modification to communicate with a
"smart server" like this.
Greg Scallan
> But HTML is relatively static. Why don't you just take an image, and
> find a screensaver program that will display it? No need to do it in
> HTML.
Maybe I'd like to add a little javascript to grab me quotes of several stocks and
current Major League Baseball scores and put that data as text over my static
image.
Greg
Gloppofreak Codfish
Gloppofreak Codfish wrote:
>>And the platform that 99% of the world uses - Windows. We're fighting
>>a losing battle, but there's no reason to give up NOW.
And Carl Johan Berglund replied:
> 99% is a little too much! Windows users may be a majority, but not as big
> as that. I read some statistics late last year about 20% of all European
> web surfers using Macintoshes (forgot the URL - sorry.)
I was exaggerating. But I'm sure it's somewheres in the upper eighties.
Either way, my point was that we can't turn our collective noses on Bill
Gates.
--gloppofreak codfish
gloppofreak somewhere in the vicinity of quackquack.com
send replies to the list only <- THIS MEANS YOU!
could somebody from moz.org change the default reply-to to the mailing
list addr?
Carl Johan Berglund
At 10.19 +0100 98-03-17, Braden N. McDaniel wrote:
>If the free software developer base cannot turn out software that users want
>to use, this endeavor will have helped Netscape very little. Win32 is an
>important target platform--quite arguably the most important. How you happen
>to feel about Microsoft is irrelevant--that's simply the reality of the
>situation.
But it should certainly be easier to beat Microsoft in Unix and Macintosh,
than in the platform they have written and control - Windows.
___Carl_Johan_Berglund_________________________
Adverb Information
carl.joha...@adverb.se
http://www.adverb.se/
Jon Babcock
>>>>> "Carl" == Carl Johan Berglund <carl.joha...@adverb.se> writes:
Carl> At 10.19 +0100 98-03-17, Braden N. McDaniel wrote:
>> If the free software developer base cannot turn out software
>> that users want to use, this endeavor will have helped Netscape
>> very little. Win32 is an important target platform--quite
>> arguably the most important. How you happen to feel about
>> Microsoft is irrelevant--that's simply the reality of the
>> situation.
One of the big reasons users will want to try new software, free or
otherwise, is that it is seen as being attractive to the pace-setters,
i.e. those who are perceived of as computer experts. Whether such
users _continue_ to use it or not will depend on the UI and such
things as stability.
Some have reminded us that end-users are the most important single
factor in developing software. Others have reminded us that suits
control the shots. Both of these positions seem to devalue the
attitude, OS-preferences, and spreading influence of developers
themselves. Technological leaders, both people and products, _can_
emerge that will influence suits and end-users. It is not always the
other way around.
Likewise, how developers feel about Microsoft _is_ relevant. This is
true of those who are ordered to develop for Microsoft, but who don't
really want to, as well as free developers who can choose to develop
for whatever OS they want. In the long run, the mind share of
developers and trend-setting expert users will be one of the two or
three most important factors in moving suits and end-users to question
their complete dependence on Microsoft.
Carl> But it should certainly be easier to beat Microsoft in Unix
Carl> and Macintosh, than in the platform they have written and
Carl> control - Windows.
This is a key point, but, like my message, it is perhaps only
indirectly related to the new UI.
Jon
--
Jon Babcock <j...@kanji.com>
Carl Johan Berglund
At 20.57 +0100 98-03-17, Gloppofreak Codfish wrote:
>I was exaggerating. But I'm sure it's somewheres in the upper eighties.
>Either way, my point was that we can't turn our collective noses on Bill
>Gates.
Actually 91% on one of the sites I work with. (4-6% Mac, 2-3% Unix, and
some don't know...) I'm sure that's over the web average, but it's not
untypical anyway.
However, that is not a cause for despair. New Power Macintosh G3's are
faster than the hottest Wintel machines, and the PowerBook G3 is the
fastest notebook in the world. Ultrasparcs are even faster, I guess.
What we have to fight is that o-so-common view that there is only one kind
of computer in the world, only one OS in the world, and (almost) only one
company in the world... I just came from a meeting about the computers in
my local church, where the others' opinion was to rip out our Macintoshes
(network, printer) and install PCs when we have the money to do that (in a
year, maybe). Mine was to use the money we have now to upgrade the Macs
now. That's where we're playing a losing battle.
>--gloppofreak codfish
>gloppofreak somewhere in the vicinity of quackquack.com
>send replies to the list only <- THIS MEANS YOU!
Well, since you didn't even send your msg to the list, I couldn't reply
there...
Steeg Lehman
Pat Gunn wrote:
One
nice thing would be to have the history maintain the nonlinear structure
of the web -- it's not the World Wide Line, and Back/Forward aren't
enough to navigate usefully around a lot of sites. A history mechanism
with a tree/graph structure would be pretty cool.
Karel Baloun
All,
I agree with Pat's statement that the web isn't linear. Displaying the
Communicator | History screen as a hierarchy, as news threads are
displayed, seems a Good Idea, and was mentioned several times today.
**The ability to do a search/find on all of the pages linked from a page
(to be displayed in a new window like search engine results), enabled by
pre-loading of text, a la something like the old freeloader, would be a
nice feature along that line.** Going farther, the web is non-linear,
so we should be able to show dynamic relationships in at least 3
dimensions. Consider the visual thesaurus at
<http://www.plumbdesign.com/thesaurus/> as a metaphore... the "distance
between (page title) nodes" could be any of the following: 1) web server
stored statistics on traffic patterns, 2) lexical similarity of the
pages or meta data (like weights in search engine results), 3) lexical
similarity to your own browsing patterns, etc.
Lifestreams seems to just combine several commonly existing ideas: 1)
chronological ordering, 2) saved searches (as substreams), and 3)
automatic content summarization. Their contribution is the integration,
though the leading professor's commercial article "The End of Academic
Computer Science as We Know It" <http://www.mirrorworlds.com/horizons/>
makes it hard to believe that he would be willing to deliver their work
under the NPL, as free and open source. Actually, psychological theory
equally would support the idea that memory is better aided by location
in space than by chronology. So if we want to get beyond space and
time, how can we best find something easily? Altavista claims that by
topical search, you can find a file faster on the internet than on your
desk. I think we naturally associate things and ideas by their
similarity and difference to other things and ideas. If we advance
beyond a one-dimensional dewey decimal system, to a personalized,
dynamic web of meaning, then ideas, files (and advertisements) will find
us.
This vision is not so far from reality. Translation software by Fujitsu
and others maps Japanese and English Concepts, not just Phrases. This
is the main purpose of Oracle's context software and any search engine.
I'm sure that expert systems (like Simon Laven's chatterbots
<http://www.student.toplinks.com/hp/sjlaven/>) applicable to this
problem already exist. The inclusion of >7 link types in HTML 4.0
(<http://cuisung.unige.ch/prod/HTML4/struct/links.html> or
<http://www.hut.fi/~jkorpela/HTML4.0/comments.html#links>) and XML
support demostrate the momentum towards even greater complexity and need
the need for better search/retrieval.
Outlandish, but exciting. AI and expert/fuzzy system technology will
impact computer interfaces... hopefully from graduate departments and
the open source community, not from Windows00.
Karel
Steeg Lehman
> Lifestreams seems to just combine several commonly existing ideas: 1)
> chronological ordering, 2) saved searches (as substreams), and 3)
> automatic content summarization. Their contribution is the integration,
> though the leading professor's commercial article "The End of Academic
> Computer Science as We Know It" <http://www.mirrorworlds.com/horizons/>
My reading as well.As an individual I organize spatially and so I am much
more interested in your ideas for maps. I have noticed that the business
world is still very temporal in the memory. The offices move around, people
leave, names change but the records seem to flow around time. If you are
collecting and storing your path through the business days the lifestreams
may have a good use. If you are an explorer finding your way through an
environment of information then the spacial will be more useful.
I would like to see many projects moving forward in this area. Lifestreams
has a vision (not mine, and not unique). I think they could realize their
model in a living context by starting a mozilla project. *That* is very
interesting to me.
If we can get a good Java porting project together I will be interested in
putting that promised 3D API to good use. A series of histories models
sounds good as any and better than most.
G. Sumner Hayes
Pat Gunn wrote:
>
> Karel Baloun wrote:
> >
> > All,
> >
> > I agree with Pat's statement that the web isn't linear. Displaying the
> > Communicator | History screen as a hierarchy, as news threads are
>
> that that wasn't my statement...
I'll take the blame for it.
> I was going to complain about them
> removing my quote but leaving my name in, making it look as if I said
> it,
> but I guess I was too slow :)
Just as a general note (not intended as an attack on whoever was
responsible; they left in the correct attribution as well as a special
bonus attribution to Pat that careful readers could figure out wasn't
for the quoted material), these newsgroups/mailing lists seem much worse
than average about maintaining attributions. It's helpful to keep them
in, as I'll often archive a message without noticing the attributions
are fried. When I go back (months) later and have an idea I want to
discuss with the author, it can be difficult to find the right person.
It's especially important in a forum like this where most people don't
know each other yet; knowing who said what helps you get a feel for what
people's skills and interests are so that you can get a handle on your
co-conspirators.
Braden N. McDaniel
Pat Gunn wrote in message <350C62...@ibm.net>...
>Rinie Kervel wrote:
>>
>> Mark Roth wrote:
>>
>> > I have to agree with Pat on this one... Web Browsers are for browsing
>> > the web, not navigating your hard drive.
>>
>> your drive.A Browser is for navigation and links. If you can represent a
>> directory with a HTML page + links
>> you have superior navigation. Also missing from an 'explorer' are
>> bookmarks: you favorite folders,
>> that are just one click away.
>
>A similar argument could be made for a word processor. If it can display
>a
>complex word processing document, surely it can display your hard drive!
>Or an image viewer... If it can view images, surely it can view your
>hard drive!
Bingo. But I think you're looking at things rather backwards from the way in
which the integration will actually take place...
>There's no benefit to having a browser be your interface to your
>computer.
Care to substantiate this? 'Sokay, I'll provide a counter-argument anyway...
Why do we have "file viewers" per se? One simple reason, really: file
viewers can typically afford to be much smaller, leaner apps than their
editing counterparts. And thus viewers are generally faster to load and
cheaper than editors. But consider: *if* it were technically and financially
feasible (forget speed and money considerations for just a moment), wouldn't
it be damn convenient if every viewer on your system was an editor, too? And
those editing features were *immediately* accessible, whenever you needed
them?
Now consider the technology trends:
* Computers keep getting faster by leaps and bounds.
* Quality software gets cheaper, and with each OS release, more
functionality that had been relegated to other apps is incorporated into the
OS (not just talking Windows here, though it's certainly the prime example).
The sharp distinction between editors and viewers on the average desktop
machine has a limited lifespan. Before too long, we *will* have the clock
cycles and the cheap software to make this unified interface a reality.
Microsoft's incorporation of IE4 into the OS is just one of the baby steps
getting us there. Application development for this environment will amount
to the equivalent of devising a sort of "plug-in" to the comprehensive OS
shell program.
If Netscape is to compete with IE, it *must* do things better. Where users
are concerned, UI is *the* most important part of the equation (aside from
not crashing too much)--the Web developers are the only ones who will be
tearing their hair out over glitches in standards support (now, before I get
lynched for that one, realize I'm a Web developer, too ;-). To remain
competitive, Netscape must integrate itself into this new UI.
Suggestions that Netscape can avoid fully addressing the "UI picky" crowd
miss the mark. UI superiority is absolutely critical to Netscape's continued
viability as a Web client. Applications live and die by the quality of their
UI relative to the competition. The techies are just the hold-outs. They
will not persist as even a viable niche user base if the UI isn't up to
snuff.
Prismatic Booger
Braden N. McDaniel, bra...@shadow.net
<http://www.shadow.net/%7Ebraden/>
Braden N. McDaniel
Pat Gunn wrote in message <350E01...@ibm.net>...
>File management can be done in a better manner with platform-specific
>stuff rather than something cross-platform like Nav.
And that cuts to the quick of it. Less--probably *much* less--of Navigator
needs to be cross-platform in order for it to remain viable on popular
desktops.
Frankly, I have serious doubts about the viability of the notion of
cross-platform development. I'm not convinced that a product can remain
feature-consistent across many platforms (especially the number Netscape
aims to address) *and* still remain competitive with regard to users'
demands for new features. But while I'm not convinced, I'm not ready to rule
it out either. I think it would be great if Netscape were to decisively
convince me. So far, they haven't.
The overwhelming majority of users don't give a rat's ass about
cross-platform--they only care if it works on *their* platform (and most
users only use one platform). The cross-platform nature of Netscape
Navigator has been a boon to Web developers--not end users.
Well, the days when Netscape can drive the user base through Web developers
are gone. There just aren't enough people left who will download a browser
because they saw an animated GIF button on a Web page recommending that they
do so. Netscape can't needle its way into the hearts and minds of users
anymore. It's got to resort to sex appeal.
Braden N. McDaniel
Pat Gunn wrote in message <350E3A...@ibm.net>...
>> The overwhelming majority of users don't give a rat's ass about
>> cross-platform--they only care if it works on *their* platform (and most
>> users only use one platform). The cross-platform nature of Netscape
>> Navigator has been a boon to Web developers--not end users.
>
>fight Microsoft. It worked -- we're here. It does mean a few things
>about the future of Navigator's development:
> We're going to spend more time on stability, clean interfaces, etc.
> than frills
> We believe that cross-platformness is important
> Many of us are Unixy, many more than the average development group
> in Joe Random Company
> We dislike Microsoft
>
>I don't speak for everyone, but I'm certain that I speak for a lot of
>people.
I'm reminded here of Jamie Zawinski's remark a few days ago about how the
Linux developer community is generally 180 degrees out of sync with what
users want.
If the free software developer base cannot turn out software that users want
to use, this endeavor will have helped Netscape very little. Win32 is an
important target platform--quite arguably the most important. How you happen
to feel about Microsoft is irrelevant--that's simply the reality of the
situation.
Prismatic Booger
Braden N. McDaniel
Pat Gunn wrote in message <350E39...@ibm.net>...
>> Why do we have "file viewers" per se? One simple reason, really: file
>> viewers can typically afford to be much smaller, leaner apps than their
>> editing counterparts. And thus viewers are generally faster to load and
>> cheaper than editors. But consider: *if* it were technically and
financially
>> feasible (forget speed and money considerations for just a moment),
wouldn't
>> it be damn convenient if every viewer on your system was an editor, too?
And
>> those editing features were *immediately* accessible, whenever you needed
>> them?
>
>makes programs that feel like Visual Basic programs -- mushy, slow,
>and far too concerned with glitz to have any real substance.
You're citing an extreme case, overlooking the *fact* that user interfaces
have indeed improved as the number of available clock cycles has increased.
This hasn't prevented apps from advancing in other areas as well. I see no
reason why these current trends of improvement should change. User
interfaces *will* continue to improve, and suck up more clock cycles and
memory as they do so.
>> Now consider the technology trends:
>> * Computers keep getting faster by leaps and bounds.
>> * Quality software gets cheaper, and with each OS release, more
>> functionality that had been relegated to other apps is incorporated into
the
>> OS (not just talking Windows here, though it's certainly the prime
example).
>
>Quality software is already free. You can't get cheaper than that.
Please. Linux has begun to be competitive with NT in server setups, but it's
still a *long* way from being competitive on the computing desktop at large.
As far as apps go, there are a relative handful of free apps that don't have
significantly superior commercial competition.
>Basically though, as computers keep on getting faster, applications
>gobble those cycles. People who have their apps try to do everything
>will *NEVER* have a computer that feels fast for more than 2-3 years.
>Speech recognition, AI, and other technologies will gobble all those
>cycles just as fast as they come.
>
>OTOH, those of us who have apps that are designed to do a limited task
>well will have snappy systems.
But that scenario accounts for a rather limited number of potential setups.
Most users want an integrated, unified interface to what computing
technology has to offer. And they'll get it--with or without Netscape, with
or without free software.
>> The sharp distinction between editors and viewers on the average desktop
>> machine has a limited lifespan. Before too long, we *will* have the clock
>> cycles and the cheap software to make this unified interface a reality.
>> Microsoft's incorporation of IE4 into the OS is just one of the baby
steps
>> getting us there. Application development for this environment will
amount
>> to the equivalent of devising a sort of "plug-in" to the comprehensive OS
>> shell program.
>
>Ummm... why do we think that the distinction will go away?
Could you be more specific as to what part of the material you quoted you
didn't understand?
Paul Yurt
Paul Yurt wrote: So my question is...do you use different tools to touch
different object in the real world? Why do you need to use a different tool
to touch and manage files? Doesn't it seem more logical to use one interface
for all objects?
Glynn Clements wrote in message
<13580.2273.5...@cerise.sensei.co.uk>...
>
>Rinie Kervel wrote:
>
>> Mark Roth wrote:
>>
>> > I have to agree with Pat on this one... Web Browsers are for browsing
>> > the web, not navigating your hard drive.
>>
>> Why, If it can navigate the complex web, wouldn't it be easy to navigate
>> your drive.A Browser is for navigation and links. If you can represent a
>> directory with a HTML page + links
>> you have superior navigation.
>
>But a file manager isn't just for `browsing' your drive. You need to
>be able to make modifications as well.
>
>> Also missing from an 'explorer' are bookmarks: you favorite folders,
>> that are just one click away.
>
>Use shortcuts/symlinks.
>
>--
>Glynn Clements <gl...@sensei.co.uk>
>
G. Sumner Hayes
Braden N. McDaniel wrote:
>
> Pat Gunn wrote in message <350C62...@ibm.net>...
> >Rinie Kervel wrote:
> >>
> >> Mark Roth wrote:
> >>
> >> > I have to agree with Pat on this one... Web Browsers are for browsing
> >> > the web, not navigating your hard drive.
> >>
> >> Why, If it can navigate the complex web, wouldn't it be easy to navigate
> >> your drive.A Browser is for navigation and links. If you can represent a
> >> directory with a HTML page + links
> >> bookmarks: you favorite folders,
> >> that are just one click away.
> >
> >a
> >complex word processing document, surely it can display your hard drive!
> >Or an image viewer... If it can view images, surely it can view your
> >hard drive!
>
> Bingo. But I think you're looking at things rather backwards from the way in
> which the integration will actually take place...
>
> >There's no benefit to having a browser be your interface to your
> >computer.
>
> Care to substantiate this? 'Sokay, I'll provide a counter-argument anyway...
>
Okay, I'll presume that by "browser" you mean "Web browser". The web
browser mechanism is far less general than the sum total of my user
interface to my machine. It doesn't allow you to select multiple
files. It doesn't allow you to perform meaningful edits on the file
system (like node and link creation, attribute/permission alteration,
etc). It doesn't have a well-defined way of handling the tree-like
nature of the file system, since it's designed for a graph-style web
where a lot of tree-based operations make no sense.
Microsoft recognized these problems with the Active Desktop, which is
why they added a lot of file manager capabilities to IE. Throwing all
of your applications together into one big binary is certainly one way
to go, though I'd prefer a more Opendoc-ish model myself. Active
desktop certainly has a lot of problems even with the generalizations MS
made to it; they're enough that I have yet to meet someone who actually
prefers it to the standard win95 fs interface.
> Why do we have "file viewers" per se? One simple reason, really: file
> viewers can typically afford to be much smaller, leaner apps than their
> editing counterparts. And thus viewers are generally faster to load and
> cheaper than editors. But consider: *if* it were technically and financially
> feasible (forget speed and money considerations for just a moment), wouldn't
> it be damn convenient if every viewer on your system was an editor, too?
No. The interface I want in a viewer is almost always quite different
from what I want in an editor. Example: in a web browser (viewer), if I
click on a URL I want to follow that URL. In an HTML editor, if I click
on a URL I want to move the cursor to where I clicked. Amaya tried to
unify the two and wound up with a mediocre editor and a browser that is
fairly hard to use. I can say the same about most things -- Photoshop
is a way cool image editor, but would really suck as an image viewer.
In general, a viewer needs to have the primary UI interface be on
presentation and navigation. An editor needs to have a large portion of
the interface be dedicated to selection of regions for edits and tools
for applying those edits; it also needs to allow access to internal
structures that will affect how the document is presented on various
platforms that a viewer only needs to render at a high level.
It might be nice to have an easy way to toggle back and forth between
edit and viewing modes, but designing such a thing with enough user
feedback to avoid confusion would be paramount lest we wind up with the
sexy GUI equivalent of vi. (Flames from vi lovers will be cheerfully
ignored, especially since vi is my editor of choice.)
> The sharp distinction between editors and viewers on the average desktop
> machine has a limited lifespan. Before too long, we *will* have the clock
> cycles and the cheap software to make this unified interface a reality.
It's not a matter of clock cycles; there is no good, unified interface
because the problems are different and the users want to interact with
them differently.
Just because we have a cool hammer doesn't mean everything's a nail.
> Suggestions that Netscape can avoid fully addressing the "UI picky" crowd
> miss the mark. UI superiority is absolutely critical to Netscape's continued
> viability as a Web client. Applications live and die by the quality of their
> UI relative to the competition.
Agreed. Trying to shoehorn the browser into tasks it isn't suited for
is a horrible idea. Trying to improve the UI for Netscape is a good
idea, as is taking ideas from browser interfaces as starting points for
modifying/improving a more general UI.
nu...@bayside.net
wether anyone realizes it or not, time is passing. RIGHT NOW, time is
moving. just like DOS was the de-facto standard for commercial computer
software a few years ago, it's virtually obsolete (except for some games)
now. i don't want to hear this "microsoft owns the computer industry, deal
with it", because they don't own it.. they own it NOW.
like MS-DOS, i always thought we were so dependent on it and its software
that it'd always be around, forever. but now i haven't used a DOS app on
my machine since 1997 :)
let time take its course!
change always happens!
> Carl> At 10.19 +0100 98-03-17, Braden N. McDaniel wrote:
> >> If the free software developer base cannot turn out software
> >> that users want to use, this endeavor will have helped Netscape
> >> very little. Win32 is an important target platform--quite
> >> arguably the most important. How you happen to feel about
> >> Microsoft is irrelevant--that's simply the reality of the
> >> situation.
>
_ _ __ __ _ _ _
| / |/ /_ __/ /_____ | Nuke Skyjumper |
| / / // / '_/ -_) | "Master of the Farce" |
|_ /_/|_/\_,_/_/\_\\__/ _|_ nu...@bayside.net _|
Braden N. McDaniel
Pat Gunn wrote in message <350E6E...@ibm.net>...
>> I'm reminded here of Jamie Zawinski's remark a few days ago about how the
>> Linux developer community is generally 180 degrees out of sync with what
>> users want.
>
Certainly. The main question is if it will help *Netscape* *enough*. Not
that I have any personal affection for the company, but I'm sure it's
healthy for the industry and good for consumers for Netscape to remain
competitive.
>Hopefully,
>increased
>capabilities and stuff will attract more average users, and Netscape
>will
>gain lots of support from power users. It's all about mindshare.
>
>> If the free software developer base cannot turn out software that users
want
>> to use, this endeavor will have helped Netscape very little. Win32 is an
>> important target platform--quite arguably the most important. How you
happen
>> to feel about Microsoft is irrelevant--that's simply the reality of the
>> situation.
>
>Users will want to use the software.
Why? Not just because it says "Netscape" on the label. It must be better
than what they're currently using. "Better" doesn't just mean technically
better under the hood. That isn't enough to convince most users. If you
doubt that, look at the popularity of Microsoft's products: most of them
didn't get where they are by being technically superior.
On a day-to-day basis, I mostly use IE4 <dodges stones>. The reasons are
simple. I spend most of my time on Win32 boxes, where IE4 is easily and
quickly accessible, it has a superior interface, and it's functionality is
adequate for most of what I need to do.
Believe it or not, most users don't necessarily want *the* most efficient
way of doing things. They want a reasonably good way that feels pretty
efficient and is easy to understand.
> I'm just stating that it's likely
>that
>work on stability and a clean underbelly is likely to have a lot more
>work done than eye candy.
Then you've missed my point entirely. I'm not talking about simple eye
candy. I'm talking about genuine improvements to the user interface.
> Win32 may be important to you, but I
>personally
>care very little about it, except in that I care about having
>Communicator features being implemented cross-platform.
I think we should take a good hard look at the feature set of Mozilla, and
separate the "UI features" from the "core features". The latter should
remain cross-platform. The former should be allowed to diverge.
Gloppofreak Codfish
>Microsoft recognized these problems with the Active Desktop, which is
>why they added a lot of file manager capabilities to IE. Throwing all
>of your applications together into one big binary is certainly one way
>generalizations MS made to it; they're enough that I have yet to meet
>someone who actually prefers it to the standard win95 fs interface.
download. You must download IE4 to get, for example, the program
scheduler and Start Menu upgrade. It's insane. Netscape's in deep
doo-doo if MS can get away with packaging Shell Update w/ IE4. I am
probably one of the millions with it on my system just for the su.
David Ghandehari
nu...@bayside.net wrote:
> like MS-DOS, i always thought we were so dependent
> on it and its software that it'd always be around,
> forever. but now i haven't used a DOS app on
> my machine since 1997 :)
Not to be too off-topic, but Windows95 is pretty much a DOS app.
-Dave
Simon P Lucy
At 09:51 18/03/98 +0000, Gloppofreak Codfish wrote:
>>Microsoft recognized these problems with the Active Desktop, which is
>>why they added a lot of file manager capabilities to IE. Throwing all
>>of your applications together into one big binary is certainly one way
>>Active desktop certainly has a lot of problems even with the
>>generalizations MS made to it; they're enough that I have yet to meet
>>someone who actually prefers it to the standard win95 fs interface.
>Hi! I use IE4's shell update. MS should package that as a seperate
>download. You must download IE4 to get, for example, the program
>scheduler and Start Menu upgrade. It's insane. Netscape's in deep
>doo-doo if MS can get away with packaging Shell Update w/ IE4. I am
>probably one of the millions with it on my system just for the su.
This is the part I try and emphasise. So far as Microsoft's anti-competitive
practices go it is not the browser but the packaging of O/S functionality,
like
the shell, with the browser.
I understand that in pushing their case Netscape emphasise the browser because
that is an easier thing to explain to non-technical lawyers but it is not
point
at all. It is the insistence on having their particular browser in order to
get increased functionality from either their operating system or their
applications.
This is a point that the DOJ and most users seems to have missed entirely. I
see a lot of it here as well where there is the war about the browser browsing
the local file system and using IE4 as an example of it. Whereas it is shell
extensions that provide that and not IE4. There is no reason why mozilla
based
shell extensions could not be built, it isn't simple but I know a man who can
:-).
Simon
==========================================================
Objective Software http://www.dev-com.com/~objective
(44)(0)1299-823321 Tel Mobile: 44-(0)976-361760
(44)(0)1299-879047 Fax
16 New Street
Stourport on Severn
Worcestershire
England
DY13 8UW
Simon P. Lucy
Support queries http://www.dev-com.com/~objective/support.html
G. Sumner Hayes
Steeg Lehman wrote:
>
> The issue is: How do we provide *any* *individual* in the world access to all the
> information in the world. Maybe the world isn't big enough, universe?
Sure, okay. That's an extremely useful subset of a computer's
functionality; an interface that provided only that would be ideal for
many situations.
> Any OS that censors what you should or should not see is a problem. Any OS that
> distorts or manipulates information without an *individual's* consent must be
> changed.
Depending on your definition of information, I'd disagree with this
pretty vehemently.
> We will incorporate the fabric of the OS into mozilla and mozilla into the fabric
> of the OS. The mozilla project ceased to a browser as soon as the source release
> was announced. mozilla is the process of providing *individual* *open* access to
> the world's information.
I see why you and I disagree so much on this point. A unified, useful
UI for data visualization and manipulation is a noble goal, and one that
I think should be pursued. It's a very different problem than the
Mozilla one, though; IMO, Mozilla is a useful source of ideas for a
really small subset of the UI problem. Probably very little of the code
is directly applicable, though, and looking at CORBA, DCOM, and Opendoc
for ideas (at one level) and Pad++, Visage, and Lifestreams (at another
level) is much more directly related to the UI problem than Mozilla is.
Trying to shoehorn Netscape into the general UI is asking for
spectacular failure, IMO, and we'd be a lot better served by treating it
as a stopgap solution available for incremental modification while
working on the UI issue separately. Sure, some ideas from Netscape
could be used in the UI arena; I think that it's a lot less useful than
you are implying, though.
So, yeah, I think a cool UI is a good thing; I also think it's very
off-topic for the mozilla mailing lists/newsgroups.
G. Sumner Hayes
Glynn Clements wrote:
> Netscape does a perfectly good job of _viewing_ different types of
> data, e.g. text documents or the contents of a directory. However,
> viewing is a passive activity.
Even there, it's pretty limited in what it can do. Text streams with
[animated] images is a fairly poor set of primitives for modeling lots
of data sets, and there's basically no UI for non-link-following
interaction with the data set.
Steeg Lehman
<SERIOUS>
I don't think that "edit" or "view" is the mUI issue. Nor do I think "show local
file system" or "don't show local file system" is the mUI issue.
The issue is: How do we provide *any* *individual* in the world access to all the
information in the world. Maybe the world isn't big enough, universe?
*The issue begins as soon as the computer is turned on. *
Any OS that censors what you should or should not see is a problem. Any OS that
distorts or manipulates information without an *individual's* consent must be
changed.
We will incorporate the fabric of the OS into mozilla and mozilla into the fabric
of the OS. The mozilla project ceased to a browser as soon as the source release
was announced. mozilla is the process of providing *individual* *open* access to
the world's information. Cross-platform is not just a good idea it must be
exactly what we are doing. If file systems don't lend themselves to sharing then
we will create new ones. If HTML is limited it will be extended or replaced. If
we can't organize the data we will make new forms of databases to store it.
Netscape is the FIRST corporation to realize that they cannot do this alone. No
one can. Not even the open-source community.
mozilla with its self styled little m should not be seen as a Monster application
that needs to be extended.
mozilla is the process that we use to modify our OS and draw in *all* technology
to explore all information systems, to explore the Internet.
I personally will be crafting my tools in Java. What are you working on right
now? How could that make a better mUI?
Let's all admit we are going to change the world and get on with the project. :)
</SERIOUS>
:)
Paul Yurt
Glynn Clements wrote in message
>Paul Yurt wrote:
>
>> > > > I have to agree with Pat on this one... Web Browsers are for
browsing
>> > > > the web, not navigating your hard drive.
>> > >
>> > > Why, If it can navigate the complex web, wouldn't it be easy to
navigate
>> > > your drive.A Browser is for navigation and links. If you can
represent a
>> > > directory with a HTML page + links
>> > > you have superior navigation.
>> >
>> >be able to make modifications as well.
>>
>> different object in the real world? Why do you need to use a different
tool
>> to touch and manage files? Doesn't it seem more logical to use one
interface
>> for all objects?
>
>
>In the real world, we use different tools to _manipulate_ different
>types of objects, e.g. a screwdriver for screws and a hammer for
>nails.
>
>Netscape does a perfectly good job of _viewing_ different types of
>data, e.g. text documents or the contents of a directory. However,
>viewing is a passive activity.
>
>far more specialised toward the specific type of data being modified.
>
>--
>Glynn Clements <gl...@sensei.co.uk>
>
I understand tools are needed for complex manipulation yet the best of
designs allow manipulation without tools. For example I can control my car
with my feet and hands and the key to the car. A well designed piece of
furniture I can be assembled with only a screwdriver or better yet with only
my hands. If the design is weak then I will need a bag of tools and I may
get confused about how to assemble it. The same for data and programs. A
good interface should take care of all the layers of distinction, I as a
user only want to choose what I wish to manipulate and then act on that. I
do not want to be told that manipulation is not viewing, (i.e. Composer Vs
Navigator). The best interface will "figure out" what I want to do and will
switch to "composer-mode" when I "touch for manipulation".
In the real world If I want to park my car I don't need a parking-mode key,
I simply change the way I interact and then I am doing the "parking
manipulation".
Paul Yurt
Martin Nilsson
Braden N. McDaniel wrote:
>
> You're citing an extreme case, overlooking the *fact* that user interfaces
> have indeed improved as the number of available clock cycles has increased.
> This hasn't prevented apps from advancing in other areas as well. I see no
> reason why these current trends of improvement should change. User
> interfaces *will* continue to improve, and suck up more clock cycles and
> memory as they do so.
I don't think that a good interface need to use a lot of clock cycles, I
don't even think that that is the case even today. I think that several
companies industrial methods of creating software is the thing to blame.
By moving from programming to program modeling with big routine
libraries, whose optimization suffers from lack of priority, more time
can be spent on making user interfaces and small talking paper clips
instead of small, fast programs.
Besides, I don't think that there has been much of improvements in user
interfaces lately. It's more of converting functions from expensive and
advanced operating systems into mainstream operating systems.
--
/Martin Nilsson
Austin Ziegler
[just mozilla-ui]
Carl Johan Berglund wrote:
>
> At 10.19 +0100 98-03-17, Braden N. McDaniel wrote:
> >If the free software developer base cannot turn out software that
> >users want to use, this endeavor will have helped Netscape very
> >little. Win32 is an important target platform--quite arguably the
> >most important. How you happen to feel about Microsoft is
> >irrelevant--that's simply the reality of the situation.
>
> But it should certainly be easier to beat Microsoft in Unix and
> Macintosh, than in the platform they have written and control -
> Windows.
The goal isn't to "beat" Microsoft. It is to write a better browser that
can be used in more places than the competitors. Anyone who is entering
this project with "beating" Microsoft as their goal has entered it for
the wrong reasons.
-austin
--
austin ziegler * fantomeATvnetDOTnet * http://fantome.vnet.net/
---------------* azieglerATvcelaDOTcom * -------------------------
Remove the stars to email me * Love: n. the condition in which
----------------- * the welfare of another becomes essential to your own
our lives are ova before they begin
Carl Johan Berglund
At 23.36 +0100 98-03-21, Austin Ziegler wrote:
>The goal isn't to "beat" Microsoft. It is to write a better browser that
>can be used in more places than the competitors. Anyone who is entering
>this project with "beating" Microsoft as their goal has entered it for
>the wrong reasons.
To write a better browser than Microsoft is more or less the same thing as
beating Microsoft in the area of browser-writing.
___Carl_Johan_Berglund_________________________
Adverb Information
carl.joha...@adverb.se
http://www.adverb.se/
Glen Parker
>But surely that's the whole point. What do all of the above file-types have
in
>common?They're all *documents*. Why do we have to open a word processor
>program before we can look at or edit a text-document? Why do we have to
open
>an image viewer before we can look at or edit an image?
>
>More to the point, why do we even have to still think about files,
directories
>and drives?
Those are the documents you want to be thinking about, aren't they?
If your shell can make a determination of what needs to be done to display a
certain file (document), which most shells do pretty well these days, the
fact that a word processer is being 'run' can/should be totally transparent!
If the files on your hard drive were organized a little better (not a big
deal), instead of putting 'Word for Windows' in your start menu, you would
just find the document you want and open it.
Instead of putting programs in the start menu, there should be links to
documents and document directories.
>We don't use or store paper documents in this way, we can look at or edit
any
>type of paper document without needing different viewers to do it. The
>physical desktop is a powerful tool. I don't think we need to ditch it yet,
>ther's life in the old metaphor yet.
>
>IMHO we should be taking a more document-, rather than application-centred
>approach to designing for today's machines. Let's face it, the majority of
>home and business users use their machines for managing documents of some
form
>or other. Rather than twiddling with toolbars and bookmarks, we should be
>thinking *bigger* and coming up with a new idea.
Glen Parker
>So you're saying that browsers should only be able to display documents
that
>are fetched over a network and NOT a local file? Does the file:// url mean
>anything to you? Ever noted that most webservers will generate directory
>listings? That PUT and DELETE is part of the HTTP spec? Sounds a whole
lot
>like file^H^H^H^Hresource management to me. Files do not deserve
second-class
>treatment as resources because they happen to reside locally.
The distinction is not based on where a file lives, but on what you want to
do with it.
If you want to copy it to somewhere else, use the shell.
If you want to view or edit, use the appropriate program.
In either case, location and method of access *should* be transparent.
Glen
Simon P Lucy
At 02:41 25/03/98 -0800, Glen Parker wrote:
>>But surely that's the whole point. What do all of the above file-types have
>in
>>common?They're all *documents*. Why do we have to open a word processor
>>program before we can look at or edit a text-document? Why do we have to
>open
>>an image viewer before we can look at or edit an image?
>>
>>More to the point, why do we even have to still think about files,
>directories
>>and drives?
>
>
>Those are the documents you want to be thinking about, aren't they?
>If your shell can make a determination of what needs to be done to display a
>certain file (document), which most shells do pretty well these days, the
>fact that a word processer is being 'run' can/should be totally transparent!
>If the files on your hard drive were organized a little better (not a big
>deal), instead of putting 'Word for Windows' in your start menu, you would
>just find the document you want and open it.
>Instead of putting programs in the start menu, there should be links to
>documents and document directories.
>
The docucentric problem is that whilst developers have relatively few
documents, users, organisations have vast numbers. The retrieval of those
documents is far worse on a computer system than on conventional document
storage.
Riddle-me-ree magic like viewing documents as a stream doesn't fit either.
Sophisticated searching techniques can get the document you want, all too
often
they give you pretty much every other document as well.
So in an organisation with 30 million documents a year how do you get just one
document to match for a user?
For the most part with business information its the application that retrieves
that information most successfully. Accounting systems, contact management
systems process tracking, machine utilisation, etc, etc.
Shells are very bad at organising information because it is by and large
context free. There are some interesting things you could do with name
spaces,
but for the most part its a pile of needles in a bunch of boxes in a tree.
Folders and files are comfortable metaphors for business users, its why we use
them. But, we don't carry that metaphor to the desktop, instead we use a
familiar computer science paradigm of a heirachical tree. This is generally
understood by everyone but it is the least efficient way to interface because
we don't actually store documents that way.
Financial applications store documents fairly efficiently within their own
domain, its a rare accounting system that couldn't give you an invoice
within a
very short space of time. General office applications, word processors,
spreadsheets etc, are very bad at storing documents because they both allow
the
user to save it pretty much anywhere and make it extraordinarily difficult for
them to store it in the right place.
So companies end up with dumping grounds called data, or data98 or some such.
Simon
-------------------------------------------------------------------------
Objective Software
Scott Wimer
Glen,
I think there are two radically different views of how computers should
help us do work.
1. Monolithic OS, small applications.
2. Small OS, small, tool oriented applications.
The first is reminiscent of the Microsoft approach to Operating
Systems. The second is more Unix like. Amongst power users and
developers (at least, those familiar with both OS families) the small OS
view has always made for faster, more stable, more reliable computing.
But, there has always been one important missing piece - integration
amongst the various applications.
With netscape currently having good integration amongst its various
component parts, I think that we (the software using world at large)
would be better off avoiding the "Monolithic" approach.
I personally find the monolithic approach an offensive waste of my
computing resources. But then, i've always been a tool using kind,
which made Unix feel very natural, and windows feel like I was trying to
pound in a screw with a wrench.
Just my 3 cents worth (upped the ante).
scottwimer
[ Sender Cc'ed ]
Glen Parker wrote:
[ SNIP ]
> Hmmmmmmmmmm... This could be a pretty big application!
>
> The way things work now, where we have a shell that enables us to manipulate
> files, among other thing, works pretty good. You just have the draw the
> line between manipulating files (e.g., copy/delete/create/move) and messing
> with the contents of those files. The shell should continue to do the
> manipulation, and we should have smaller, not larger programs that mess with
> their guts.
>
> Where I do think the job of the shell should be expanded is in the area it
> already owns. That means the shell should do FTP, DFS, NFS, and any other
> way you can think of to _manipulate_ files, as transparently as possible.
> You shouldn't have to run a program called 'ftp.exe', for instance.
>
> Just my $.02 worth...
> Glen
--
Scott Wimer http://www.cgibuilder.com/
sco...@cgibuilder.com - play
sco...@earthlink.net - work
Braden McDaniel
Martin Nilsson wrote:
>
> Braden N. McDaniel wrote:
> >
> > You're citing an extreme case, overlooking the *fact* that user interfaces
> > have indeed improved as the number of available clock cycles has increased.
> > This hasn't prevented apps from advancing in other areas as well. I see no
> > reason why these current trends of improvement should change. User
> > interfaces *will* continue to improve, and suck up more clock cycles and
> > memory as they do so.
>
> I don't think that a good interface need to use a lot of clock cycles, I
> don't even think that that is the case even today. I think that several
> companies industrial methods of creating software is the thing to blame.
That might be an aggravating factor, but it is nonetheless true that a
more human-friendly interface will typically consume more clock cycles
than an interface that is closer to the computer's internal model of
doing things (and thus easier to program).
> Besides, I don't think that there has been much of improvements in user
> interfaces lately. It's more of converting functions from expensive and
> advanced operating systems into mainstream operating systems.
We haven't had a breakthrough of the proportion of the archetypal Xerox
GUI. But we've also come a long way since then, in a lot of more subtle
ways.
--
Glen Parker
>Paul Yurt wrote: So my question is...do you use different tools to touch
>different object in the real world? Why do you need to use a different
tool
Yes! You may not use different tools to _remember_ which objects you need
to 'touch', but when it comes time to do the touching, you have wrenches and
screwdivers and coffee cups.
mmmmm gurgle gurgle... coffee
>to touch and manage files? Doesn't it seem more logical to use one
interface
>for all objects?
Wow! Think about what you are saying!
If you took this to the logical limit, we would have ONE program running on
the computer, and it would do EVERYTHING. Let's start a list...
Edit/view .doc files
Edit/view .html files
Unzip/uncompress archives
Clean the registry
Install other apps (oh wait ;-)
Copy/add/delete files
Add/subract/multiply/divide numbers
Compile .C, .CPP, .pas, .java, .bas files
Also edit the above source files
Also debug the programs from the above source files
Play Quake
Edit Quake map files
List all apps running (oh wait ;-)
Steeg Lehman
Scott Wimer wrote:
> Glen,
>
> I think there are two radically different views of how computers should
> help us do work.
> 1. Monolithic OS, small applications.
> 2. Small OS, small, tool oriented applications.
I'll throw two more working approaches into the mix and suggest an additional:
3. The bloated document.
4. The plug-in identifier.
The bloated document: The document contains the program used to display and
edit it.
The plug-in identifier: Document is of type <blah> find <blah> plug-in.
Another approach is to add another layer onto the internet. The current internet
is information content oriented. Why not add code to the domain structure.
We are looking for an interface that will allow an individual access to all the
information in the world. I think we need a network of tools that constitute the
interface.
Perhaps the addition of a Universal Tool Locator to complement the Universal
Resource Locator. This would allow the mUI interface proper to become a mapping
tool. Dynamically Mapping URLs to UTLs.
An editing interface for an HTML document could be provided by pointing the UTL
for the document to a local copy of vi. Java would really come into its own with
the possibility of laying out a distributed network of public code blocks for
manipulating information. We wouldn't *have* to have all the UTLs for our
interface pointed locally.
Does anyone know of any projects setting up public domain structure for code?
Course I see no resaon that a UTL couldn't point to a URL... :)
Jonas Liljegren
Mike Thirlwell wrote:
>
> > A similar argument could be made for a word processor. If it can display
> > a complex word processing document, surely it can display your hard drive!
> > Or an image viewer... If it can view images, surely it can view your
> > hard drive!
>
> common?They're all *documents*. Why do we have to open a word processor
> program before we can look at or edit a text-document? Why do we have to open
> an image viewer before we can look at or edit an image?
>
> More to the point, why do we even have to still think about files, directories
> and drives?
>
> type of paper document without needing different viewers to do it.
This was all done in OpenDoc. Insted of having diffrent programs for
diffrent documents, you could have ONE document viewer. This viewer
would use the appropriate code to view its diffrent parts. It would also
give you the ability to edit the document.
Just select the part of the document you would like to edit, and the
menu bar will partly change to show the commands for the module that
handles that type of data.
It was wery sad that OpenDoc seemd to be too big and complicated to gain
acceptance. The web browser Cyberdog was created as an illustration of
what you could do. If Netscape would use it, the world today would be a
wounderful place!
But maby we need some compromise? HTML succeeded becuase of its initial
simplicity. HTML was an simplification of SGML. Maby we should make
mozilla a simplified OpenDoc?
Maby Java could play a role in this? Take a look:
http://www.software.ibm.com/ad/opendoc/
http://summary.net/~breck/java-opendoc.html
--
/ Jonas Liljegren
http://paranormal.o.se/myself/index.html
Geek Code 3.1 GIT/P/Od-s+:-a24C++US++P++LEW++N++
o?K?w!oM!VPSPE-Y--PGP-t+5X++R@tv+b+!DID++Geh!!r!y+
Bradley Keith Neuberg
>
> But maby we need some compromise? HTML succeeded becuase of its initial
> simplicity. HTML was an simplification of SGML. Maby we should make
> mozilla a simplified OpenDoc?
I agree. Maybe we could extract one or two key ideas from OpenDoc, and
then implement them.
Jonas Liljegren
Steeg Lehman wrote:
>
> I'll throw two more working approaches into the mix and suggest an additional:
> 3. The bloated document.
> 4. The plug-in identifier.
>
> The bloated document: The document contains the program used to display and
> edit it.
> The plug-in identifier: Document is of type <blah> find <blah> plug-in.
> Does anyone know of any projects setting up public domain structure for code?
OpenDoc was most of what I envisioned of the future web interface. That
is; interchangible components for everything, directly from the net.
Everything configurable and expandeble.
Take a look at:
http://summary.net/~breck/java-opendoc.html
http://www.software.ibm.com/ad/opendoc/
Jonas Liljegren
Braden N. McDaniel wrote:
>
> Pat Gunn wrote in message <350C62...@ibm.net>...
> >There's no benefit to having a browser be your interface to your
> >computer.
>
> Why do we have "file viewers" per se? ... wouldn't
> it be damn convenient if every viewer on your system was an editor, too? And
> those editing features were *immediately* accessible, whenever you needed
> them?
This is the same line of thought as the OpenDoc standard. We should
make Mozilla in the same fashion. IBM gives away the OpenDoc code for
free! Learn about OpenDoc:
http://www.software.ibm.com/ad/opendoc/library/odshap.html
My dream of the future web enviroment is a place there you could every
detail in the documents or in the interface, and replace it, extend it,
and it would still work in the whole. Some ideas of the types of use is
gathered here:
http://www.eng.uci.edu/~sroussey/NetVision/software/od_parts/
W.H.Alex Schleber
Paul, Glenn,
I think I must agree with Paul, use your imagination
a little, all you need is full XML rendering in NS, and
I can think of ways to buil a file system explorer right
in the browser window. Then give me a scripting language
such as JavaScript with an enhancement to run scripts
on your OWN "server side" only (your PC is in a way your server),
that allow you to do more stuff that you would not want
a script passed from another site to be able to do, e.g.
delete files, copy files, etc. (VBScript within ASP would be an
example of this kind of thing, although I hate VB, but it
has some rather useful object APIs),
and I can see a fully functional Explorer that I call from my
bookmarks as file://C|/Explorer, looking something like this
in the XML
<directory name=root>
<directory name=Documents>
<file type=doc>Doc1</file><button action="delete_file.script" file="Doc1">DEL</button>
etc....
<file type=doc>Doc2</file>
<directory name=TechDocs>
<file type=doc>XMLspecs</file>
</directory>
</directory>
<directory name=Program Files>
<file type=exe>Netscape50</file>
</directory>
<directory name=Temp>
</directory>
</directory>
... and pronto, there you would have the whole
directory tree structure (could make those little
+ - symbols for branch expansion part of the
rendering mechanism), and then all you need is
a few buttons (as hinted to after the first file)
or links or programmed HOTKEYS
for DELETE/COPY/VIEW/etc. that execute scripts
that do just those things.
-- Alex
R.V.Guha
So, you have all this in the source that you have.
It uses RDF, an application of XML. Right now, Its more
functional on windows and mac than on X.
NavCntr, which is driven by RDF can be
used to do full file management, etc.
Guha
Murple
Steeg Lehman <st...@probes.com> scribbled on netscape.public.mozilla.wishlist:
-> I don't want to load mozilla I want it to become my interface to the
-> computer. Netscape has assured continued access to the API. (Even the
-> source)
-> How do we replace/extend explore.exe, CDE, etc? I think we should devote
-> significant resources here.
I think you'll find a large portion of Unix users (not to mention a pretty
sizable chunk of Windoze users) would abhor the idea of browser-as-desktop.
Personally, I think the MSIE desktop idea is one of the most idiotic ideas
to ever come out of Microslop. If I want to run a browser, I'll run a browser.
I sure as hell don't want it cluttering up my desktop, much less BEING my
desktop. This is a hideously bad idea.
--
.-'~~~-. Craig Schenk
.'o oOOOo`. <mur...@erols.com>
:~~~-.oOo o`.
`. \ ~-. oOOo.
`.; / ~. OO:
.' ;-- `.o.'
,' ; ~~--'~ "The opposite of a correct statement is a false
; ; statement. But the opposite of a profound truth
_\\;_\\//_ may well be another profound truth." -Niels Bohr
Murple
Paul Yurt <b...@doitnow.com> scribbled on netscape.public.mozilla.wishlist:
-> Paul Yurt wrote: So my question is...do you use different tools to touch
-> different object in the real world? Why do you need to use a different tool
-> to touch and manage files? Doesn't it seem more logical to use one interface
-> for all objects?
Hey, yeah, youre right. I'm throwing out everything in my kitchen but the
refridgerator. I'm going to use it too cook my food, store stuff, wash dishes,
and mop the floor. Gee, why didn't I ever think of this before?
Web browsers are for WEB browsing. Is that such a difficult concept to grasp?
MSIE is, in my opinion, a broken product, even more so for it pitiful attempt
to be a desktop metaphor.
Murple
-> furniture I can be assembled with only a screwdriver or better yet with only
-> my hands. If the design is weak then I will need a bag of tools and I may
-> get confused about how to assemble it.
Then perhaps you shouldn't be building furniture.
-> The best interface will "figure out" what I want to do and will
-> switch to "composer-mode" when I "touch for manipulation".
This is an idiotic idea.
Angus Davis
Note that the current code for Aurora knows how to look at a native file system and expose it
through the RDF back end's hypertree API. This API, in turn, is exposed to JavaScript (actually,
this last bit of code is still being hacked on ... should be done in a week or so by jg). Check
out the documentation on mozilla.org on RDF and XML. Also, visit the new RDF newsgroup for
questions.
-angus
Bradley Keith Neuberg
Actually, if we use RDF, can't we rethink some of the original ideas
underlying file systems? Why use a traditional hierarchical file system
when the web is much different? How can one stucture a file system for a
hypermedia operating system (which is what the OS is becomming)?
Guha
Bradley Keith Neuberg wrote:
>
> Actually, if we use RDF, can't we rethink some of the original ideas
> underlying file systems? Why use a traditional hierarchical file system
> when the web is much different? How can one stucture a file system for a
> hypermedia operating system (which is what the OS is becomming)?
This is a really good point. Instead of having just having
a simple tree structure of folders and files, one can
have much richer structures. e.g., xxx is an email message
sent by yyy about zzz which is described in file aaa.
You can then imagine dynamically generating html out of these
structures and using that as the basic way of navigating
around information. Now, that would be true desktop-web
integration. All the infrastructure to do that is in mozilla.
Guha
Peter Trudelle
Glen Parker wrote:
> >But surely that's the whole point. What do all of the above file-types have
> in
> >common?They're all *documents*. Why do we have to open a word processor
> >program before we can look at or edit a text-document? Why do we have to
> open
> >an image viewer before we can look at or edit an image?
> >
> >More to the point, why do we even have to still think about files,
> directories
> >and drives?
>
> Those are the documents you want to be thinking about, aren't they?
No, not any more than you want to be thinking about paper and ink when you are
using documents in the physical world. It is as if we were forcing users to
specify how to mix the ink, create the paper, cut it, construct a quill, and
monitor the flow of ink onto successive sheets. When working with a document,
most people would rather be thinking more about the logical document - the
contents, and attributes about the document that make it what it is. The fact
that it is stored as one or more files in some arcane indexing scheme should be
hidden. Indeed, the very concept of 'saving' a document is strange to those
who have not yet been tamed by the computer. Watch someone enter content into
a window on any application for the first time. When they're done, they'll try
to close the window and will be asked "Do you want to save this", or even "Are
you sure you want to discard changes?". They don't even understand the
question. Of course they want it saved, why else would they have entered it?
In order to become 'users', we have forced people to think about documents in
terms of copies in memory and on volumes as files using only a short, cryptic
filename and a fixed location on some physical storage medium for retrieval.
The file system works okay for storing files, but we have been lazy in just
exposing that to the user as their document archiving and retrieval system. We
should be allowing them to flexibly add whatever information they would like to
associate with the document, and allow them to use that information to retrieve
it, not C:\ProgramFiles\Netscape\Users\Foo\BarFY98.xls
> >IMHO we should be taking a more document-, rather than application-centred
> >approach to designing for today's machines. Let's face it, the majority of
> >home and business users use their machines for managing documents of some
> form
> >or other. Rather than twiddling with toolbars and bookmarks, we should be
> >thinking *bigger* and coming up with a new idea.
Yes, exactly. Let's design software for people rather than trying to force
people to adapt to software the way it is written today. The vast majority of
people still either don't use a computer at all, or don't feel comfortable
using one. We need to make it as easy, useful and reliable for them as the
phones, TVs, cars and other appliances that they are using comfortably.
Peter
Peter Trudelle
Glynn Clements wrote:
> Peter Trudelle wrote:
>
> > When working with a document,
> > most people would rather be thinking more about the logical document
> While this might be a nice idea, I'm not entirely sure how far it is
> feasible to take this. After all, all of this is implemented using an
> actual computer with actual limitations. To some extent the underlying
> details need to be exposed.
I'm not sure either, but the point is that we have made almost no effort to hide
these silly implementation details from the user. With the hardware we have today,
it is shameful that we have not gone far beyond the interfaces we have been using
since computers measured memory in kilobytes, processor power in single-digit
megahertz and storage in tens of megabytes. We typically have a thousand times the
power of those machines, and it is being wasted in inefficiency, bloat and idle
loops.
> If a file is on the zip drive, the file goes with them when they take
> the disk away. If it's on a fixed disk, then it stays in the machine.
That is a detail that a user of a zip disk would like to know, not something that
everyone working with a document cares about.
> A hard drive has finite capacity. What do you do when it becomes full?
> The user needs to be able to understand that deleting file X will free
> up a certain amount of memory.
Why not set up policies that allow the machine to manage all storage in an efficient
manner? It can easily migrate files from RAM to hard disk to tape or other media as
needed according to usage patterns. It could alert us in advance that we are
running out of space and offer to purge duplicate files, compress, compact, remove
old versions, etc. It could ask us to pop in another Zip/Jaz disk, floppy, or tape
in order to handle the remote case where all storage is fully and efficiently used.
As storage gets larger and more complex, it is much more difficult for the user to
have to manage it manually. Since they have a powerful computer, why should they
need to constantly devote attention to this clerical task?
> > Let's design software for people rather than trying to force
> > people to adapt to software the way it is written today.
>
> I'm sure that developer do try to achieve that.
If only that were true. However, most developers are so used to the way computers
work that they frequently never even question it, nor do they regularly consider the
viewpoint of non-developers. Most of us just assume that our own viewpoints are
valid or even typical, and that we are capable of building software for people
without involving them in the process.
> However, the constraints imposed by the underlying hardware can't just be waved
> away with a magic wand.
Computers _are_ a magic wand, or at least they could appear that way to the user.
Today's software doesn't even come close to using their full potential, even the
best of it.
> Even if radical advances are made in UI design, you can't just throw
> away everything that has gone before. You still need to be able to use
> the vast amounts of existing data and applications.
Most of what has gone on before has already been thrown away, much of it without
ever having been useful. Using the existing data is a far different problem than
making new designs that are more usable.
> Computers are vastly more complex than phones, TVs, cars and other
> appliances. The range of tasks that they can perform is, to all
> intents and purposes, infinite, and many of those tasks are inherently
> complex.
That viewpoint just betrays a more intimate knowledge of computers than of phones,
TVs and cars. In fact, these are all converging, and there is very little to
distinguish them. There are now computers that can do telephony and video; phones
have long been nodes in a vast computer network and many now subsume the
capabilities of a computer; and I hear that the average American car now contains 40
microprocessors, with some cars even including Internet workstations. These are all
highly complex, and for all practical purposes infinite. That still would not
justify their presenting complex, infinite human interfaces.
> You can avoid unnecessary complexity, but you can't simplify something
> which is inherently complex. The only way that you can make a computer
> as simple as a TV is to reduce the set of possibilities to those of a
> TV, i.e. choosing from N predetermined options.
We not only can make the complex more simple, I feel we must. Whether we can make a
computer as simple as a TV is an artificial question. Is a bicycle as simple as a
pair of shoes? It doesn't matter, they are both elegant and well worth the value
they provide.
Peter
Peter Trudelle
Bradley Keith Neuberg wrote:
> On Thu, 30 Apr 1998, Peter Trudelle wrote:
>
> > Yes, exactly. Let's design software for people rather than trying to force
> > people to adapt to software the way it is written today. The vast majority of
> > people still either don't use a computer at all, or don't feel comfortable
> > using one. We need to make it as easy, useful and reliable for them as the
> > phones, TVs, cars and other appliances that they are using comfortably.
>
> Peter, I like your thoughts on this. How should we expose the system to
> the user? Should we make everything persistant, so that if you place an
> object somewhere it just stays there? Don't forget that another new major
> task is now a part of normal computer use: browsing hypermedia networks.
> Right now computers are split between two different 'paradigms' that are
> exposed to the user. The first one is the traditional file system for a
> user's local PC, and the second one is the browser which works over the
> world wide web. The OS is becomming more about working with hypermedia
> networks, information, and applications, rather than simply being about
> local document management. Where should we begin? What is the
> appropriate metaphor for hypermedia OS's?
Thanks for your kind words Brad, but I sure don't have all the answers. I just
wanted to add a little 'design for usability' into the discussion. I think we
should focus on what is essential, and try to eliminate everything else, or at
least get it out of the way. How that is done depends entirely on the context of
the user and the task or use.
For instance, what made the browser so popular was the content and the simple
interaction with it that made widespread communication via an associative network
practical. We have gone far in 'adding value' to this, but how much of what we
added was essential? I think that much of it is gratuitious, quickly thrown in
because we could easily do it, and perhaps because it seemed like a reasonable
idea to someone at the time. This has left us with a bloated app that has more
complexity, chrome, crud and cruft than content. We need to be very cautious
about adding new things, ensuring they are essential, and that they are added in
such a way as to retain the simplicity, utility and delight of the whole.
At this point, I think we are like an enthusiastic student writing the first draft
of a long paper. We have thrown in all kinds of questionable facts, opinions,
maps, quotes, pictures, sound clips, and anything else that will take up space.
The task now is to craft what really matters into the next draft, even if it means
throwing out most of what we have collected that is making us look so productive.
Peter
Peter Trudelle
Glynn Clements wrote:
> The point that I am making is that the location of a document within
> the underlying filesystem is relevant to the user. Your original
> message seemed to imply that it wasn't.
I think I more than implied it. It is not necessarily of any interest to the user, who
just wants to be able to retrieve the document from storage. When you go to a library to
get a book, do you care what shelf it was stored on? No, that is an implementation
detail that can vary widely. What you care about is getting the book you want. Sure,
there are people who are so used to using the file system as the only storage and
retrieval mechanism that they would still insist on storing it by physical location. But
I'm sure that if they could just hand the document off to some agent whom you could rely
on to retrieve the document based on a flexible specification, then even they would get
used to it. I don't see many people insisting on placing the individual blocks of a file
into physical locations on the disk. I'm just proposing a further abstraction.
> > Why not set up policies that allow the machine to manage all storage in an efficient
> > manner? ... Since they have a powerful computer, why should they
> > need to constantly devote attention to this clerical task?
>
> Because the computer can't read the user's mind. Even if you can
> automate the tasks, the user ultimately still has to understand enough
> to be able to decide meaningful policies.
The user doesn't have to decide the policies. Provide reasonable defaults and the vast
majority will happily live with them. It is only a tiny few who would insist on managing
the details of storage.
> > > However, the constraints imposed by the underlying hardware can't just be waved
> > > away with a magic wand.
> >
> > Computers _are_ a magic wand, or at least they could appear that way to the user.
>
> That isn't relevant to the preceding sentence.
My point is that the constraints are remote, we have an almost limitless tool - a magic
wand.
> > Today's software doesn't even come close to using their full potential, even the
> > best of it.
>
> The days when it was even possible to utilise the full potential of a
> computer vanished once the amount of storage started to exceed a few
> dozen kilobytes. Nowadays you could spend (literally) a hundred
> billion dollars on developing a package and it still wouldn't come
> close to using the full potential of a current PC.
It sounds like you are agreeing with me, but a you also implying that it is impossible,
so we shouldn't try?
> > > Computers are vastly more complex than phones, TVs, cars and other
> > > appliances. The range of tasks that they can perform is, to all
> > > intents and purposes, infinite, and many of those tasks are inherently
> > > complex.
> >
> > That viewpoint just betrays a more intimate knowledge of computers than of phones,
> > TVs and cars. In fact, these are all converging, and there is very little to
> > distinguish them. There are now computers that can do telephony and video; phones
> > have long been nodes in a vast computer network and many now subsume the
> > capabilities of a computer;
>
> In which case they are computers. And if they are to allow themselves
> to be used to their full potential, then they will ultimately be as
> complex as any other computer.
Not really. They may contain computers, but they are specialized devices using this
technology to provide more utility and ease of use for their particular purpose, not to
turn themselves into general purpose information devices. I'm reminded of workshops of
many years ago that had only one motor, so they came up with a Rube Goldberg-like
arrangement of belts and pulleys so that the motor could be used to its full potential to
power all of the devices in the shop. That is similar to one thread in the evolution of
computers, resulting in complexity that increases without bound. In modern use, motors
have all but disappeared inside special-purpose devices, even toothbrushes. This is a
more plausible evolution for computers as well, since it avoids runaway complexity.
> > and I hear that the average American car now contains 40
> > microprocessors,
>
> Maybe, but most of them don't provide user-visible functionality. The
> most complex computer in the world can be made easy to use if all it
> permits the user to do is to play Pong.
The functionality is user-visible, it is the processor that is hidden. Drivers don't
care how the fuel is mixed, they just want acceleration and efficiency.
> > with some cars even including Internet workstations.
>
> Which is no different to any other Internet workstation; the fact thatit's bundled with
> a car doesn't change it or the car.
It changes both, just as the bundling of cars and radios did.
> > These are all highly complex, and for all practical purposes
> > infinite. That still would not justify their presenting complex,
> > infinite human interfaces.
>
> Infinite possiblity implies infinite complexity. If the abstract
> system that is exposed to the user is Turing-complete, then you have
> the same (infinite) level of complexity however you expose it.
So we've been wasting our time trying to evolve user interfaces these past 50 years, we
might just as well give the user a Turing machine? I'd still rather have a magic wand.
> > > You can avoid unnecessary complexity, but you can't simplify something
> > > which is inherently complex. The only way that you can make a computer
> > > as simple as a TV is to reduce the set of possibilities to those of a
> > > TV, i.e. choosing from N predetermined options.
> >
> > We not only can make the complex more simple, I feel we must.
>
> You can change the balance of complexities, but I suspect that
> ultimately it's a zero-sum game.
Exactly, making it simpler for the end-user is much more complex and difficult for the
developer. All too often, developers do what is easy for them, and put the complexity
off on the user. In order for most people to feel comfortable with computers, we'll have
to reverse the balance.
Peter
Mark Evans
Pat Gunn (pgu...@ibm.net) wrote:
:
: You might want to better phrase that so as not to be windows-centric.
: Plan9, for instance, already has that capability, as does OS/2
: (FTP sites appear to be part of the local filesystem)
There is also an FTP filesystem in the Linux "userfs" package,
and there has been for quite some years. It appears that such things
are not widely useful.
--
Mark Evans
St. Peter's CofE High School
Phone: +44 1392 204764 X109
Fax: +44 1392 204763
Robert P. Krajewski
In article <6jrt8q$2h...@secnews.netscape.com>, m...@stpeters.eurobell.co.uk
(Mark Evans) wrote:
> There is also an FTP filesystem in the Linux "userfs" package,
> and there has been for quite some years. It appears that such things
> are not widely useful.
The underlying problem is that FTP is an incredibly creaky protocol over
which to layer something that looks like a useable file system interface.
Beleive me, I watched some folks try to hammer FTP access into a
preexisting Lisp Machine file access scheme, and it was ugly. Navigator's
FTP interface is quite good for what FTP has to offer.
Jamie Zawinski
Pat Gunn wrote:
>
> > Beleive me, I watched some folks try to hammer FTP access into a
> > preexisting Lisp Machine file access scheme, and it was ugly. Navigator's
> > FTP interface is quite good for what FTP has to offer.
>
Further, I used that Lispm FTP file system for years, and I think it
worked great. The Emacs ange-ftp/EFS packages (which do essentially
the same thing) works surprisingly well, too.
--
Jamie Zawinski http://people.netscape.com/jwz/ about:jwz
Robert P. Krajewski
In article <35629C7E...@netscape.com>, Jamie Zawinski
<j...@netscape.com> wrote:
> Further, I used that Lispm FTP file system for years, and I think it
> worked great. The Emacs ange-ftp/EFS packages (which do essentially
> the same thing) works surprisingly well, too.
Err, I think I misunderstood this gist of this thread -- for some reason,
my feed lost quite a few of the articles before the most recent ones. Let
me make myself a little clearer.
It's hard to turn FTP into a service provider that can support file i/o in
a way that programs that view files as *streams* would want to see them,
through stdio-like interfaces (as an example). FTP wasn't designed to do
it, although in some ways the transfer architecture is very flexible,
which came in handy when 36-bit machines ruled the net. Maybe there are
extensions for unambiguously representing file properties like
permissions, dates, and lengths, but they weren't standard last time I
looked. And those things are just as important as getting data from A to
B.
Of course, that doesn't mean it can't be done with a heroic programming
effort, such as on the Lisp Machine and Linux. Note your use of the word
"surprisingly" above -- I bet you have some inkling of what a mess there
is out there. (That's why Symbolics did NFILE.) But these days I think
that NFS and perhaps, more realistically, CIFS/SMB are the way to go.
(Samba is an open source Unix CIFS implementation.) A lot of people will
retch over the latter's PC heritage, but it's flexible enough to support
things like Mac-to-Mac interaction (see DAVE, www.thursby.com) and it
supports Unicode pathnames and byte-range file locking. And, of course,
HTTP is kind of/sort of an FS access protocol. (Sometimes it seems like
its *real* raison d'etre is to breach firewalls.)
Does the Emacs EFS stuff allow elisp code to treat FTP sources and
destinations just like anything else (like an OS-supported file access
type) ? Great !
But I think that this kind of nitty-gritty stream-level stuff wasn't the
point of this thread. I am familiar with FTP front ends that match the UI
conventions of their host systems, like Cute-FTP (Win32) and NetFinder
(MacOS), and they are pretty impressive. You can even change file
permissions of a Unix-hosted file in a Finder-like panel in NetFinder, for
example. But these programs, and the Netscape FTP front end, have at
various times said in their release notes that they have incomplete
support for this or that type of FTP server, and they try to use
heuristics to figure out what kind of file systemis on the other end. The
result is that the developer has to do things like write "ls" output
parsers to support a lot of servers out there.
So, one possible project for Mozilla is to adapt the simple Samba CIFS
client (not the kfs, but the command-line utility code from smbclient) as
a back-end driver for the file-browser that is now seen as Moz's "FTP"
mode. Different protocols, same user interface. There might even already
be a CIFS URL scheme defined, at least unofficially. Anyway, I think
that's something that could be useful.
Robert P. Krajewski
In article <3564C3...@ibm.net>, Pat Gunn <pgu...@ibm.net> wrote:
> Robert P. Krajewski wrote:
> > So, one possible project for Mozilla is to adapt the simple Samba CIFS
> > client (not the kfs, but the command-line utility code from smbclient) as
> > a back-end driver for the file-browser that is now seen as Moz's "FTP"
> > mode...
> Considering what happens with most FTP sites, FTP is
> more appropriate for common usage on the internet than
> something like CIFS.
Well, for posting files to the Internet, FTP will probably be the way to
do things most of the time; FTP is probably lighter weight than CIFS,
which would be a consideration for public servers that allow anonymous
access to potential hundreds of users. There aren't many public CIFS
sites, but they exist. (There are public AppleShare IP sites, too.)
On the other hand, for an intranet of personal computers, those computers
will likely be running CIFS servers and not FTP servers, at least for
Windows and OS/2 boxes.
Shawn Rutledge
> In article <35629C7E...@netscape.com>, Jamie Zawinski
> <j...@netscape.com> wrote:
> is out there. (That's why Symbolics did NFILE.) But these days I think
> that NFS and perhaps, more realistically, CIFS/SMB are the way to go.
WebNFS, definitely. I went to a BOF at JavaOne at which a couple of Sun
guys explained the Java support for it. I forgot most of the details of that,
but basically WebNFS is NFS without all the complex authentication - seems
NFS uses multiple ports and thus firewalls usually prevent regular NFS
from working. Sun servers have had WebNFS servers for a while; I'm not sure
who else does (I imagine Linux either does or will very soon). But it seems
like a pretty decent standard, and it beats adopting some MS junk just
because it's there.
--
_______ KB7PWD @ KC7Y.AZ.US.NOAM ecl...@goodnet.com
(_ | |_) Shawn T. Rutledge on the web: http://www.goodnet.com/~ecloud
__) | | \__________________________________________________________________
* emusic * Linux * card-carrying member of the procrastinati * TCP/IP packet *
Robert P. Krajewski
In article <1998052216...@goodnet.com>, ecl...@goodnet.com (Shawn
Rutledge) wrote:
> > [rpk]But these days I think
> > that NFS and perhaps, more realistically, CIFS/SMB are the way to go.
>
> WebNFS, definitely. [...] basically WebNFS is NFS without al
> the complex authentication - seems
> NFS uses multiple ports and thus firewalls usually prevent regular NFS
> from working.
Good. I'd be curious to see if it they've fixed various shortcomings in
NFS as I know it, but most of them (like file locking) aren't really
issues for file browsing anyway.
> Sun servers have had WebNFS servers for a while; I'm not sure
> who else does (I imagine Linux either does or will very soon). But it seems
> like a pretty decent standard, and it beats adopting some MS junk just
> because it's there.
I respectfully disagree; CIFS implementations are installed now in a lot
of places were FTP and NFS (let alone WebNFS) aren't found. And, as I
pointed out before, there is already open source code for CIFS clients out
there that can be adapted. (If it exists for WebNFS as well, cool. The
more the merrier.) I agree that CIFS is crufty in places, but it's a real
standard now (the Open Group is managing it). And most end-users just
don't care about these issues -- they just want access.
But I will make two arguments against using non-FTP protocols, just to
illustrate some of the other issues that should be addressed if file
browsing were to get pumped up in some way. (Sorry, I don't have enough
time to contribute to this effort.)
* Why should Mozilla contain a feature that's likely to be implemented at
a system level on the client OS ? (At least for certain OSes.) Isn't that
a waste of effort ? Some justifications: (1) Browsing the entire Internet
might be more convenient with Mozilla. Native OS facilities for browsing
usually work better at the intranet/workgroup level. (2) Mozilla can hand
off to the OS once the starts doing anything more than simple
browsing/uploading/copying operations by mapping a URI back into an OS
pathname where appropriate, especially when doing things like launching
viewer applications. (3) For OSes that don't support a particular
protocol, you are doing a lot of users a big favor. MacOS and Windows
users get WebNFS, a lot of Unix users get CIFS support, and so on.
* What about all these protocols ? Users want features and don't want to
remember URL schemes for FTP, WebNFS, or CIFS. There are a couple of ways
around this. The first is to enhance Mozilla's interpretation of the file:
scheme to try various protocols. But that has a problem: trying and
failing is kind of slow for the first resolution of the URL. However,
there is a proposed service-finder protocol that might speed things up.
Unfortunately, I haven't looked at it in detail, but if it's anything like
the old Symbolics service-finding stuff based on their namespace system,
that might be the right thing to use...
Francis Hwang
> Actually, if we use RDF, can't we rethink some of the original ideas
> underlying file systems? Why use a traditional hierarchical file system
> when the web is much different? How can one stucture a file system for a
> hypermedia operating system (which is what the OS is becomming)?
The question isn't really "Can we do this?" Sure we can. But do we want to?
A heirarchical file structure is there so that you can intuitively look for files and apps and whatnot
without having to go through a lot of mental gymnastics to do it. If I want to look for a letter I
wrote to my mom last September, I might not remember exactly what I titled it, but I can look in a
path like
My Documents: Letters: Family Members
But if my hard drive were organized like the web is -- that is, barely at all -- I'd have to go to a
hard drive search engine (!) and enter something like
+mom +dear +"How are you?"
... which might still return 602 search results, at which point I'd have to get more specific. Either
that or I'd just turn off the computer and forget about the whole thing.
The reason the web isn't heirarchical is because it's too huge and chaotic, and imposing that kind of
an organizational structure on it makes no sense. But a hard drive is an entirely different creature
-- it has only a few users who are allowed full organizational freedom. The web's lack of organization
is not a feature -- it's an inconvenience we put up with because it also allows for a massive amount
of content to be shared.
Francis
W.H.Alex Schleber
point well taken, I just feel there should be both.
For example, for my bookmarks I have for a while
now been using a more DB style method similar
to what the other guys have been suggesting, simply
because all those deeply nested category folders were
becoming cumbersome.
Basically, you want the tree view AND something like
a find utility, which should of course be much nicer than
say the current Windoze "Find", i.e. more accessible
and with full regex matching, etc.
-- Alex