Message-Id: <l03110705b0f7aaa4ebe7@[128.101.88.19]>
In-Reply-To: <199801301515.JAA23754@brutus.network.com>
Date: Fri, 30 Jan 1998 10:08:03 -0600
To: calvin-ui98@dagobah.stwing.upenn.edu
From: brad hokanson <bhokanson@che2.che.umn.edu>
Subject: Re: radical proposal
>This is the message I thought I sent out earlier. I must have sent it to the
>wrong address, since my test message made it through and this earlier one did
>not.
>
>My proposal is to rescope our project to remove the file transfer parts
>at the beginning and end. The advantages of this are threefold: we
>narrow our anticipated base of users; we don't need expectk to implement
>our working product; we can spend more time implementing aspects that
>are more central to the operation of the product.
>
>We also won't need to worry about storing user passwords, which we would
>have with a full implementation. (Since the source for a tcl application
>is difficult to hide, whatever implementation we had of password encryption
>would have been easily broken.)
>
>We can relatively easily revise our proposal and our task descriptions
>to take into account our more focused scope. (I think "more focused"
>sounds better than "reduced" or "simplified.")
>
>dsc
I would say that that makes sense; we should include it in the scope of the
"final" project to be implemented at a later date; within the interface we
could illustrate it but not make it usable.
I'm mulling over a couple of representations of the interface; one a spread
out FTP pair or more of windows with numbers of sites to pull from and go
to, another something that draws lines between where the stuff is and where
it should go, and something in the accordian mode; expanding for expert
users. These are less critical given the downplaying of the FTP gather and
scatter functions; do we have enough remaining tasks?
brad
Brad Hokanson
UC Coordinator
Department of Design, Housing, and Apparel
University of MInnesota, St. Paul.
612.624.4918 voice
612.624.2750 fax