Nicholas, thanks for the note.
I couple of comments below.
"N. C a r r o l l" wrote:
> ----- Original Message -----
> From: Eric Armstrong <email@example.com>
> > I believe this system has come up for discussion before.
> > But as I've had occasion to take a closer look, I thought
> > I'd share these comments from the Grooves pdf file:
> Eric, some thoughts on Groove I got from Abbe Don, a high-end
> interface designer in NYC:
> Here's my critique:
> We set up a "space" called "Drumming Workshop."
> We then tried out all of the different features.
> As a user interface designer I feel confident in my report that the
> user experience was confusing, difficult
> to use, and at times very frustrating. In addition, we "cheated" and
> augmented the experience with a
> telephone conference call.
> Some of the very significant issues that have not been addressed in
> the Groove UI:
> 1. turn taking-->
> It's very important to know who is "in control" and who has taken what
> actions. (Due to connection speeds) my colleagues saw things and
> were acting on them and commenting on them but my screen was not
> updating.... This was most problematic when we were all
> working on the outline tool at the same time. In fact, it doesn't
> really make sense to have more than one person updating the
> outline at a time even though it's technically possible to do that.
It's good to have that confirmed. That looked like a weakness, and
I wondered whether the ability for multiple people to work at the
same time was worth it. Apparently, it's not.
> 2. Co-presence-->
> There's no real sense, in the interface, of having other people
> physically present. Some systems use an Avatar, which of course,
> can be too cutesy. Other systems use "shared cursors" wherein
> each cursor is a different color so I can at least discern
> where the other people are on the screen and (see) what they're doing.
Groove has a list of people who are a member of the space. The list
should probably be a hierarchy, with documents they have opened under
it. Clicking a document in that list should send a message to the
person, asking if you can have it. Clicking an inactive user in the
list should open up a mail message. Clicking an active user should
start a realtime chat session.
> 3. Coherence-->
> The tools currently feel like separate applications which happen to be
> usable by more than one person at a time. Does the technology support
> more "activity" centered collaboration where the tools are brought to
> the activity rather than feeling as if all users must "go to" a
> particular tool to accomplish a task.
Basically, Groove should point to files to share. It should have
control mechanisms, rather than copying everything into internal
XML files and controlling all interactions on them. We need to
avoid the same mistakes.
> Also, from a user interface design point of view, one of the
> limitations of Lotus Notes and of Lotus Domino
> is that the database design and its associated hierarchy is
> inextricably linked to the user interface. I can
> usually tell if a website has been built on top of Domino because of
> the UI.
Lee's notion that the architecture should be equivalent to a "file
system" is pertinent here. It's something your applications can use,
not an "Office Suite" that dictates which applications are available.
> I did read the "peer to peer" white paper and there are obviously some
> very interesting ideas there.
Yes. The PDF file contains some very interesting general statements.
The implementation however, is tres flawed.
Community email addresses:
Post message: unrev-II@onelist.com
List owner: unrev-IIfirstname.lastname@example.org
Shortcut URL to this page:
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
This archive was generated by hypermail 2b29 : Wed Feb 28 2001 - 15:27:36 PST