#Interface Design
51 messages in this thread
< changing to appropriate thread topic>
Well, when you put it that way….
We all have different ideas of the way the interface should appear. Fine.
I lament the fact that each application programmer implements things that
are common to all applications to suit his or her personal taste. That is
going to be different than my taste or your taste.
Given that you can't please everybody I think the Amiga community as a
whole would benefit from things like file requesters working (not
neccessarily appearing) the same across all applications.
We all know how terrified novices are of pushing the wrong button. The
lower the anxiety level of neophytes, the more computers C= will sell.
Yes, novices are afraid to push the wrong buttons, but do we want to make
it so that the programmers are afraid to push the frontiers? Do we want to
have only one file requester that defines the limits of what a file
requester can be? Should it be like the FR that comes with DPaint? ARP?
PCLO? CEDPro? Access? Or should it be like some FR we have yet to see? Are
there even more nifty and more intuitive ways of doing the functions of
file selection that are just about to be invented? Do we want to stifle
that process?
The answer may lie in some other form than the forcing of a particular
set of user interface standards. Perhaps user configurability will turn out
to be the real answer. The system of disk based, shared libraries provides
one way to allow common features that are not cast in stone. What if there
were a library that only implemented a file requester, windows, and
gadgets? What if it could be replaced easily? What if it were able to be
'plugged' in to a common library of user interface functions so that any FR
call would get the one the _user_ wanted, rather than the one the
programmer wanted, or worse, the one that the programmer was forced to
use?
I don't think we've reached the pinnacle of user interfaces yet, and
don't want to see the Amiga's growth stunted like the Mac. Let's leave room
for innovation and progress instead of having the arrogance to presume that
there is no more progress to be made.
Larry, I would disagree with you on not wanting to have a "standard"
interface on the Amiga. A computer user can only benefit from such a
standard. The poor guy will not have to learn a new set of keys/buttons or
whatever, each time he tries a new program. The easier and the more
*consistent* the interface is, the more useful is the machine. As far as
limiting creativity of the developers, I disagree here as well. For
example, the musical scale has only 12 notes in an octave – sort of a
standard – but you don't hear musicians complaining about stifled
creativity (well, maybe some avant-garde guys 😉 ). A standard is only a
"suggestion" anyway, so it can be bypassed if there is a really good
reason.
I think the Amiga developers waste more time re-inventing the user
interface (i.e. look how many file requesters are there), instead of being
really creative and coming up with some application that will blow
everyone's boots off. Although I agree that technically the Amiga is a
better machine than the MAC, the MAC's user interface has been more thought
out. Having the same interface for most programs (I use the MAC at work
BTW) makes the machine very usable.
Poor interfaces result in legions of people who suffer and lear the product
and then refuse to switch – think about all those WORDSTAR or LOTUS-123
user.
I think perhaps you have misunderstood my statement. I am not against
consistency ad standardization, provided it is not an enforced restriction.
It does not matter whether that restriction is enforced by the OS or by
the company producing the computer or by the wishes of the majority of
users. Restrictions are restrictions, and if a standard stifles
experimentation and innovation, it cannot be said to be altogether good.
I'm afraid I have to disagree with your feeling that a machine is made
useful by a standardized user interface. It is made more easily learned by
the novice, but can, on the other end of the expertise scale, frustrate and
limit the experienced user.
What if the musical scale had only one note? What if all music were
nothing more than variations in timing of that one note? Would you perhaps
think that someone, somewhere, would create more notes to use? With a
'standard' file requester, we don't have 12 choices; we have one. Whether
it is the best or not depends entirely on the user's subjective opinion of
it. Yes, you can bypass the standard, at the cost of more overhead _in the
program_, and I think that would be a bad thing. The reason developers are
reinventing the wheel when it comes to file requesters is because there is
considerable difference of opinion as to how a file requester should look
and act. Providing a fixed, immutable 'system file requester' is not the
answer.
Do you have any real objections to a file requester that is provided in
the system in such a way that it allows an easy method of replacement, and
in such a way as to be completely transparent to the calling program?
I'm glad you're not totally against standards. I agree with you that too
restrictive standards can stifle development of new ideas. However, I
believe that a consistent user interface is good not only for novice users,
but also for experienced users, even hacker types too. A particular task
should be accomplished in the same way, no matter what program you are
using. For example, I would not use an editor that doesn't allow me to use
the mouse to position the cursor. That's an example of a standard. I think
there is only so much you can do with file requesters. All I need is a list
of files I can scroll through and be able to select a file via double click
of the button. I believe that too much time is being wasted on that one
thing. Instead of working on file requesters, someone should come up with a
nice library of text handling routines (like the one on the MAC) so that
handling text would be easier and consistant for developers and users.
Yeah, it would be nice to have file requester that can be configured by the
user, completely independent of the program, but that's overkill. Noone
will buy and AMiga because it has fancy file requesters. People should buy
it because it's the only machine that can do _______ (fill in the blank
here – I don't know what such a product can be).
Well, a standard is nice indeeed, but the ideal is a standard the
individual is most comfortable with. File requesters, though only part of
it, are a hotly debated and highly visible part. Consider the variety of
features in file requesters… some provide a parent gadget, gadgets for
devices, file sizes, free space on the disk, sorting (in a variety of
flavours), 'hot' selection, delayed or dynamic display, and so on. You
couldn't possibly expect a file requester to please evreryone, or even for
a file requester existing that has all the features (and no more0 that any
randomly chosen user would desire.
In other areas, yes, there should be similar flexibility in the way
things are presented. Libraries of common routines for text handling,
though not as visible to the end user, would certainly help the programmer
to build his interface.
People don't buy a machine siolely because of a file requester, but they
do place heavy emphasis on the user interface, if they are like the
majority of users who have been exposed to window/icon/mouse machines. It's
the icing on the cake when the machine ill not only do what you want it to
do, but will do it in a way that makes it easy for you. The real beauty of
configurability is that nobody is forced to change the configuration.
I agree that the file requester is very, very important and that its
design should not be frozen into a standard. Most of the early file
requesters had to deal with an 880K floppy only. Now that big Hard drives
are becoming common, people just keep making subdirectories in their
subdirectories. I have trouble trying to get the Analyze! requester to find
the following file {Spaces added to allow Whap! to format}: "DH0(GVP):
Spreadsheets/ Registrations/ 1989Primary/ 1117NDB". I have not yet seen the
perfect file requester; nor have I seen a program that lets me modify its
file requester. Until one of those two options occur, I evaluate the file
requester quality as a part of my decision on whether or not to buy the
software. If we had a standard, I would loose that option. To that extent,
I guess I am in your camp.
A solution for the 'File Requester' problem, that I would like to see
implemented, is a _standard_ calling procedure to request it, and give the
user the ability to system-wide define his/her personal preference. One
way to do this would be to use a IFF type of file structure that the user
could edit to include the interface modules that (s)he prefered. That file
could be scanned at startup and a library node constructed that linked each
module to a standard library offset. Adding new functions to the standard
would be easy, just tack another lib vector on. Changing your preferences
would just mean removing the old module from the IFF file and replacing it
with the new one. Thus each user could in one fell swoop configure all
supporting programs to his/her preference. And developers could concentrate
on the imporntant stuff – writing correct code. -Dean
Thanks for the support in this. I really am baffled by those who put
something down, even though it won't affect them unless the want to
implement it. I think it's very do-able, and it would give us the best of
both worlds; standardization and choice.
The Amiga already has a structure to allow user expansion, it's called a
library. It's trivial to patch a library to replace certain functions by
new one. Witness the programs which replace the DisplayBeep() function for
a real audible beep function. The same could easily be done for a standard
file requester library.
There are real problems with using the SetFunction routine that have
come to light. If you are simply replacing a function, permanentaly, then
there is no problem. However, if you attempt to reverse a SetFunction,
chances are quite good that you'll crash the machine. (example.. You
SetFunction a routine. Someone else SetFunction's it too. You then restore
the old pointer value back to what it was when you got it. You have now
destroyed the link to the second SetFunction.) SetFunction works fine if a
developer understands the problems involved, and is willing to work around
them. But what we were discussing is a procedure to allow a USER to
customize their system. For that we need a much more robust and friendly
solution. You know that when a user gets a new file requester, the first
thing that will be done is to switch back and forth between it and the old
one, just to get a feel for the new code. With SetFunction, you'd be almost
gaurenteed to crash the machine. And THAT is something nobody needs.
That's a good point about Setfunction(). It has been bandied about since
shortly after the Amiga appeared. One of the best solutions to the problem
I have heard suggested was to have SetFunction() keep track of all calls
to itself, and to keep a linked list of 'old function pointers' that would
take care of restoring the old pointers to only valid code.
While it's really the job of the OS to provide this service, there is
really nothing stopping some enterprising programmer from doing a
SetFunction() on SetFunction(), and making it clear that the scheme will
work. I think CBM would probably add it in 1.4, especially if it can be
shown to be workable.
Maybe I'll get the DAS people to work on it. 🙂
There is a method that works somewhat like SetFunction that has been
talked about around CBM. Basicly what it does is to leave a small stub of
code in memory that contains the vulnerable portion of the routine. While
this method does prevent the possibility of crashing, it does have a few
non-fatal problems. First, if there are a large number of these installed,
there is a definate chance of badly fragmenting memory, especially on a
512K machine. Second, these routines work well for allowing the programmer
access to the data being passed to the library function, but cause problems
if you want to replace the function. (the idea was to allow multiple
'Wedges' into the lib function, a replacement would confuse any other
'Wedges' installed. They would also be sensitive to installation order.)
I think you're making things much worse than they are. You say "there's a good
chance" and "almost guarantedd" to crash. It is in fact the opposite. It works
99% of the time, it's that 1% which is the killer. Relatively simple mechanism
can bring this up to very near 100% efficiency. There still always remains that
window in which a crash is potential. The only way I see to correct this would
be to apply the concept of drivers used by the printer device. Simply have an
extry in preferences that would allow the user to select among various
requesters. New requester? Just copy in Devs:Requesters or something…
-Martin Taillefer
First of all, you are the one who suggested using SetFunction. I was
simply pointing out that SetFunction is not suited for that type of
operation. While under normal circumstances, a SetFunction can be done
safely, the number installed on a single library vector is directly related
to the probability of a failure. What we are talking about is a USER
instigated SetFunction, which means that there is no real upper limit on
the number of SetFunctions done.
An entry in Preferences to indicate what File requester to use is
fine, as long as File requesters are the only user configurable item that
is implemented. If however, we wish to implement a Pallette requestor,
standard text functions, ect.., every time another type of function is
added, requires another OS revision.
While the method I proposed may not be the best, it follows what I
consider to be one of the MAJOR strengths of the Amiga, extensibility! This
is the same philosiphy that gives us shared disk based libraries, and
actually, libraries in general. (The fact that the machine uses only one
fixed address, all else is determined at run time)
Actually that is something that I'm just starting to play with.
I don't know if my SimpleRequest() function has made it here yet, but it's
a first draft at a possible library of Intuition-related functions. Things
like just asking the user to click one of n number of gadgets, or getting a
file (the way I'm doing the SimpleFileRequest() is to use the ARP one if
it's present, otherwise put up a simple "Enter file name:"-type
requester).
If we're going to create a standard, now's the time to do it. James
Bayless already presented a whole ton of ideas to us – which do we like,
which do we dislike?
I like a default file requester. Being able to change it would be nice,
but how would it work?
Should the format of everything be changable? Requesters? The look of
'Wait' mouse pointers?
Has anyone considered what sort of maintenance tasks will arise, if more
and more libraries are added to the system? At least, libraries should get
icons, and LIBS: get an icon. A tool to list the version numbers of the
libraries in LIBS: would be good, too.
I totally agree. It's the same for fonts and devices. For some
philosophical reason, C= has refused to provide standard icons for these
drawers so people could actually install stuff in there without going to
the CLI.
If the Amiga had had a file requester in ROM, like the Mac, like GEM, like
Windows, do you think that a) anybody would have written their own, and b)
anybody would have cared about how standard it is?
I know people who have written their own file requesters for Windows. It's
horrible. And people are redesigning the file requester for the Mac so far
that it's virtually unrecognizable. An attempt to ram a standard down
developers throats will eventually fail, as both of these are failing.
Better to have the developers have flexibility, and have *them* decide what
the standard ought to look like. (Sorta like we're doing in this
discussion… <grin>)
I can assure you that many would have written their own file requesters,
unless by some major miracle, the supplied requester pleased virtually
everyone. The Mac went too far, placing a file requester in ROM, and yet
it is still being reinvented, at considerable cost to the programmer, and
at the risk of irritating those who want their comfortable, Mac supplied
requester. The Amiga is wide open to any and all kinds of file requesters.
Why not try for the best solution, an easily replacable one that globally
shows up when you do replace it?
As far as I understand it, the Mac file requester isn't really hard coded,
but that it gives you the pieces for a requester, if you want to rearrange
it, or introduce your own buttons and imagery.
I didn't know that about the Mac file requesters. If that's the case,
then it is a step in the right direction. It does not go far enough though.
It still leaves the file requester strictly in the hands of the programmer.
With the way the Amiga OS is set up, it is a simple matter to prvide a
standard call for things, and for programmers to use those standard calls,
leaving the choice of the resulting imagery (or whatever) to those who want
something a little different.
A good example is something like BeepIt or SetBeep. If a programmer
hard-wires an audible signal into a program because _he_ doesn't happen to
like the DisplayBeep(), he is robbing the user of the choice of staying
with DisplayBeep() which could be extremely annoying to the deaf, to cite
one example. Staying with the standard DisplayBeep() gives the _user_ the
choice of audible, via another program, or visual, via not going to the
trouble of installing that replacement.
Why do you have so much trouble accepting the idea of allowing the user
to choose?
Like I said earlier, I think the success of a system file requester has
been proven, and the failure of each application doing his own has been
proven (on the Amiga). There are too many Amiga programs that have
terrible file requesters.
Well, when I see all those programs with terrible file requesters, I
start to wonder what a standard system file requester would look like. I
might like it, you might hate it. Where would that leave us?
Noticed your message earlier about getting Dpaint III and it still doesn't
have "Double click to Load"! And here I sent away for the upgrade 🙂
The file requesters on most Amiga programs leave *alot* to be desired. In
fact I HATE most of them! Let's take Electronic Arts again for example, and
their "PhotoLab" package. I usually work in hi-res. When the requester
opens up, you get only 5 files showing. I've just measured the window
height and it is just under 1 inch. Imagine that, a hi-res paint program
allowing me to see 5 files at a time, 2 feet from the monitor, in a tiny
window under one inch high. And I've got around 16megs of graphics on my
hdrive… And you think that radio/tv interference was caused by solar
flares! Sorry, it was me, swearing 🙂
PixMate has a decent requester (you can see 10 files) but still no trophy.
CEDpro has 10 (they've come up with a killer requester, so they say, but I
haven't seen it yet).
Awhile ago I realized the sort of requester I would like: DiskMaster. In
hi-res, it has two windows showing 47 files in each (47 x 2 = 94). I can
move stuff around, rename, copy (and delete those damn "xxx.info" files
that DpaintII always spits out). I can check to see whether there are any
important filenotes associated with the file. And I can hi-lite 10 files
for loading into CEDpro to edit. It works even better than CED's requester
🙂
The question is how to be able to tap into the requester calling routine
that programs have? If I couldn't patch in DiskMaster, I sure would spend
the time required to come up with something useful with Arexx. Larry's
ROBBS concept again holds promises. Add whatever module you want/need to
your basic requester per calling program.
The Mac's user interface is less a function of their OS (although it did
help a little bit that they had some standard controls defined and a file
"requester"…) than a result of Apple's stuffing a document called the
"Human Interface Guidelines" down the developers' throats. The problem is,
of course, that Apple never followed it's own guidelines. About a year or
so ago, Apple had finally managed some consistancy, and then they came out
with Hypercard and Multifinder. Right now, it's a mess. At least, from the
developers point of view. (Apple is still trying to shove more Guidelines
down developers' throats, but can't even get them straight anymore…) The
main problem with Apple's method of doing things was that it simply could
not cover EVERY eventuality. So as people found a need to do something
different, they each kludged up their own method of bypassing the existing
interface. So now the consistancy which marked Apple's early applications
is dissapearing. Personally, I think going in the opposite direction is
better. Find out *what* is wanted, provide it, but allow for people to do
things a different way if needed. –>Steve Bennett
I know that the MAC environment is not that "developer friendly" (I know
few people who program MACs), but it is "user friendly" – I use a MAC all
the time, and I never had too read a manual. The Amiga O/S and developer
environment is much nicer. However, the user interface (i.e Workbench) was
slapped together without much thought. It would be very easy to provide the
Amiga with standard user interface tools via the library mechanism. Then
whoever wanted to follow the "standard" would just use these libraries. It
would also be possible to improve the interface by replacing the libraries,
without the need to modify old program (or maybe with some minor
modifications). I don't think going the opposite way, i.e. anarchy, is the
best way. If you asked people what they wanted (before the MAC), they would
say MS-DOS is fine, who needs windows and mice!!! We've already been down
that road anyway (with other computers) and what people want is something
that's easy (read "consistent") to use. Also, a lot of smart people (at
XEROX etc) have been looking into computer/human interface. They have come
up with good ideas, and it is really a crime to know a good idea and use
it! … Richie
In my last message I meant to say "It is really a crime to hear a good idea and
*NOT* user it!"…..I have to speak to my fingers….Richie 😉
No, the Mac environment is NOT user friendly. It is *NOVICE* friendly. It
makes it very easy to do the simple things. Unfortunately, it makes it
hard, if not impossible, to do some of the more powerful things computers
are capable of doing. Also, the Mac environment has nothing to do with how
friendly or hostile a particular program is on the Mac. It is just as easy
to write a very hostile and hard to use program on the Mac as it is on any
other machine. What Apple did which most other companies have NOT done was
write up a document which said that programs for the Mac should be written
with a user interface of a specific type, using these basic features, and
looking like every other Mac application. *That* is the difference. Sure,
they supplied a standard file requester, and that's about the ONLY thing
they supplied which the Amiga has not. And more and more applications
nowadays *bypass* or change the standard file requester, since it just
plain doesn't do what is needed. I think what we need here on the Amiga is
not a change to the OS, but rather the establishment of standard guidelines
on user interface writing. –>Steve Bennett
Right STeve, that's all we are talking about – standard guidelines on user
interface writing. It would also be nice to have some of these things provided
with the system, so that developers would not waste too much time redeoing the
same thing. I guess, the best thing would be to put one's code, where one's
mouth is and devolop such a document and a corresponding library. Then everyone
could use it. Just like it happened with ARExx, which now is the "standard"
glue for putting things together on the Amiga.
BTW MAC also has a bunch of standard text handling routines (on the other
hand< i don't think that there is "ReadPixel" and "WritePixel" routine on the
MAC). I use a MAC at work for drawing simple diagrams, and for project
management stuff. These programs are pretty easy to use..
.. Richie
I agree.
I think if we really want to push the Amiga to the business world, we
should stop thinking Innovation and Creativity (not in general, but just in
those applications), and start thinking simplicity, speed, and power.
The PC shows you a list of files and makes you pick one. Nobody says
anything about file requesters on the PC… Windows has a standard one and
everybody uses it. Same with OS/2. Same with Gem.
I think a file requester SHOULD be part of the operating system, and should
not be different for each application. The idea of being able to "plug in"
your favourite is not necessarily a good idea – because chances are every
second developer will make his own "favourite" file requester, and plug IT
into the user's boot disk.
And I personally think the ARP 1.3 file requester is very good. I hope it
does end up in ROM.
(This is for Larry…) I don't think it's possible to have a computer
interface that *forces* you to do things a certain way. You can always
write around what's there to accomplish most user-interface type tasks. I
think it's important to have some higher-level system routines, or at least
a guide to common interfaces. The Amiga has neither. I think it's
misguided to claim that the Mac "forces" you to do something a certain
way. I dunno, Larry, I've played in orchestras that only had 5 notes
available for use, plus gong, and the music was just fine. 🙂 Where was
the difference of opinion about file requesters? If no standard file
requester existed, then people were forced to write their own. Because
they turned out different is not evidence that they were striving to be
different – other factors come into play, like time, desire, creativity,
etc. Some programs still have just a string gadget for a file requester.
Did they do that to be better than other programs?
A very good point. I think the practicalities of user-customizable
routines have yet to be imagined, proven or solved. If it's a standard
library called "requester.library", then everyone could be writing over the
standard one, because their customized requester "must" be installed for
their program to work.
Not so. A user customizable file requester is not only practical, but can
be implmented right now for those programs that use ARP. All that is needed
is for someone to write a file requester and use SetFunction to replace the
ARP requester. The replacement would have to follow the same calling
conventions, callbacks, and return conventions, but from the time the new
requester was installed, you would have that new requester for all programs
that used the ARP call.
In the case of a person not wishing to install a custom requester, the
standard one would still appear. Why should a program fail if the user has
not chosen to install a replacement? If CBM were to supply one as a ROM
call, there would never be any question of a program 'not working' because
a user decided to boot from it without installing a replacement.
Cars are often used as an example of a consistent user interface, and of
course steering, accelerator, and brakes are the building blocks most often
cited, but what about the other building blocks? The speedometers,
odometers, wiper/light/defogger switches, gearshift levers (or buttons),
are often quite different, yet we don't hear anyone ranting about how tough
it is to learn how to use the rental car user interface.
I am currently renting a car that has a speedometer marked in MPH and
KPH. There is nothing forcing me to use the switch that changes the units,
and the manufacturer has given _me_ the choice. You would certainly hear
screams if the driver had no choice, and the units were in furlongs per
fortnight.
I don't think it would be beyond the ken of most concerned Amiga
programmers to sit down and define a set of functions that a file requester
should have. If it starts doing the wash for you, it's not a file
requester. Yes, I think we could learn alot of from the Mac requesters, or
the NeXT requesters, or whereever anyone wants to look. Given two file
requesters, who would disagree that the simpler one would be more appealing
to the novice? How many complex functions could be added on top that
simple requester, without clutter? What set of shifted keys could make the
requester do complex things? Far too often, the religious discussions about
file requesters circle around someone who has already coded a requester,
and doesn't want to change their code. I don't recall any requester that
was created from the ground up, from text descriptions to IFF pictures and
finally to code. It's too difficult to change user interfaces on the
Amiga, and far too often, that's behind the reticence of programmers.
Does it really matter how many people sit down and define what a file
requester should be? Does it make a difference to the fellow who wants a
different one?
Yes, we can learn a lot from other file requesters, and that is certainly
not limited to the machines you mentioned. In addition, we can learn a lot
from new ideas for them, as yet untried on any machine. I'm afraid I am one
who would agree that a simpler requester is better for the novice, simply
by virtue of it being simpler. Consider the extreme case, where a file
requester does not allow double-click to select a file, where there is no
provision for selecting a parent directory, where the only way to enter a
directory is by typing its name in to a string gadget. Simpler? Yes.
Better? Hardly.
The idea is not necessarily to add complex functions. The idea is to
provide all the functionality possible without clouding the ease of use.
I most certainly am not kidding, but I wonder if you are, or perhaps you
just like to ignore what I have said for the sport of disagreeing.
I am saying the opposite of what you accuse me of. I am not saying to not
even try different ways of doing things. I am saying that we _should_ try,
or more correctly, allow programmers to easily try different things. I can
assure you that I will not try to force yu into replacing any
system-supplied user interface items with third party ones. What possible
objection can you have to allowing user customization? Are you as arrogant
as Apple to think that the interface you want should be forced upon
everyone?
You can call people who want a particular functionality nerds if you
want. Don't think for a moment that it makes any difference to the matter
though. A lot of those 'nerds' are tired of programs with interfaces that
are unsuitable for no other reason than that the programmer decided for
them exactly how things would be done.
And John… please be aware that I am using file requesters as an example
only. Would you prefer that I mention all possible user interface items in
each and every message?
Somehow I never felt very strongly about a file requester (all
sarcasm intended). I am aware of the arguments for a single interface, but
as long as the requester allows you to do other things, such as typing in a
filename, while it is reading the directory, I like it. Beyond that, they
aren't very tough to learn.
Maybe I missed something you said. What do you mean by "user
customization"? How does it apply to file requesters? Are you talking
about drop-in library file requesters, or user-movable buttons? What is
Apple "forcing" on anyone? It seems to me that Mac programmers willingly
accept the system routines for many functions, not because they are
straightjackets, but because they save time, and make applications
consistent. The Dialog Police do not arrest you, but a magazine reviewer
might complain. Even on the Mac, someone could always write their own.
File requesters do differ between Mac programs, but you'll always see a
"Disk" button, for example.
Use the RM Function to read
these messages.
On the Mac, and correct me if I'm wrong, because I only rent time on them
occasionally, and don't own one, the Disk button in a file requester clears the
filenames from the scrolling list in the file requester, and replaces them with
the names of all the available volumes in the system. Then you can click on
one of those disk names, to look at files on that disk. What about drawers? As
I recall, I think they come up like file names, except they have a little box
next to them.
Not quite. The "Disk" button in the Mac requestor switches to the next
mounted volume. When you hit it on the last volume, it switches back to
the first one in the list. It's actually a fairly good idea. (One of the
few Apple has had… <grin>)
Hmm, I have 10 mounted volumes on my A2000, seems I'd have to click
that button a few times to get to the volume I wanted! Personally I like
the idea of a list of volumes to select from.
*10* volumes?!? I can see maybe 4 hard disk partitions and two floppies,
which would make 6 volumes, but *10*??? What on earth do you have? In any
case, I think the majority of users would have about 3 volumes on average,
in which case toggling amongst the volumes would be a very effective
method…
Steve – I also have many volumes. Remember, that every mounted partition on
a HD is a volume (currently, I have 6 mounted) the ram disk(s) are
volume(s), floppies are volumes, and there may be other classes of items
that are volumes.
In my file requester design, there are three lists – one is for the files
of the target type, one if for directories that are located in the current
requester search level, and finally there is one that contains all the
mounted volumes, and (this is important) it can ALSO contain all the
active ASSIGNMENTS. That lets the user decide what volumes are available,
and what constitutes a volume as well.
You click to the item you're interested, and you're there – clicking on a
volume gets you there, on an assign gets you there, and on a directory gets
you into that dir.
Clicking on a file selects that file.
I don't think that any approach which makes any of these levels into a
round-robin type of dance is acceptable in the Amiga environment,
especially since the Amiga environment is extensable by the user to almost
any degree imaginable.
If you include assigns in a requestors capability (which you sure ought to)
then it's not only impractical, it's downright silly.
I have the same problem with Prowrite's file req. The volume I want is
invariably at the end of the list. click, click, click, click….. — Art
And this from the man who wants to make things easy for novices. <sigh>
Who knows. I must have been thinking of the ARP requester. Then the Mac
requester works just like the requester in all the Syndesis products. The
Disk button advances through the volumes. I agree, once you get a few
partitions going, plus floppies and the RAM: disk, it can take a few
moments to get to the drive you want.
Okay, this I could live with. The system provides default tools with the
ability to set global vectors (perhaps via preferences) to change them to
whatever.
We all use file requestors as the easy target but functionality of the
application as a whole is the larger issue. For example, all file requesters
should let you double click on the name to perform the pending action. A user
using a new application should be able to confidently retreive, save or start a
new project without recourse to the manual. Analyze has (had?) "Archive" as a
menu choice with "Save" nowhere to be found – hideous. I saw an experienced
Amigan unable to quit Project D becuase "Quit" was located on the second menu
bar – silly, but frustrating. Cut, copy paste (if applicable) should be on the
same menu and have the same keyboard shortcuts accross applications. That's
not too much to ask, I think. — Art
Second, I don't think the Mac has been stifled by its file requesters. I've
never heard that criticism. The process of creating new file requesters
and new interfaces is not "stifled" by the presence of some agreement about
what these little things should look like. Are you kidding? If someone
wanted to create their own file requester, they'd still do it, but you're
saying, let's not even try, because Ced, TxEd, DPaint, ARP and Access have
different requesters. I think you've got the cart before the horse, they
are different only because there is no concensus. They have different
layout, but essentially the same core of functions. I don't think
libraries are the answer, either. Only the nerds want to redesign their
system for no reason. Most users simply want to get something done quickly
and effectively. Most of all, file requesters are not the
be-all-and-end-all concern of people worried about user interface.