On Tue 2007-08-07 14:36:16 -0400, Scott Balneaves wrote: > It's just a bad design. Because it's not blatently obvious what you > should do. > > The same goes for forcing people to right click and select a menu > option to "eject" something that, really, doesn't physically eject > (like a vcr tape, or a cd, etc) anyway.
i totally agree that it's poor design and awkward usability. > ltspfs mounts the media with no cacheing, and unmounts in the > background promptly on idle usage. I've yet to receive a bug report > from anyone of corrupted media because of an early eject. This is great! But for the record, i don't want all of my USB- or IEEE1384-connected storage mounted without caching. Caching block i/o is a really useful optimization, especially if you're using the removable media in even a moderately intensive way. Maybe the best compromise from a usability perspective is to make the initial connection as you describe, but allow a user who wants to get the benefits of caching to simply and easily turn that feature on. The act of turning it on "optimize access" then becomes a learning point where the user realizes the attendant responsibility of disabling caching again by "ejecting" the device, or whatever you want to call it. I'm sure that someone with better UI skills could come up with a good, catchy pair of complementary terms to describe this process. People are already familiar with the "if i turn it on, i need to turn it off again" workflow. --dkg
pgpRYk6hshWn5.pgp
Description: PGP signature
-- edubuntu-users mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/edubuntu-users
