[Design] Sharing Notifications in Chandler

[Mimi Yin]

Hmm, I think there's a slight framing glitch that's getting in the  
way of complete mind-meld.

In my mind, Email and Sharing aren't really competing workflows.  
Email is 1 form/mechanism for Sharing. See more in-line.

Thx, Mimi :o)

On May 20, 2006, at 12:38 AM, Philippe Bossut wrote:

> Hi,
>
> I'm not convinced we should make a difference between Email and  
> Sharing as far as notifications is concerned, so no "N" or "n"  
> notification:
> - item updates or creations on a share are as important than Email  
> (or I wouldn't bother subscribing to the share)

In the Stamping Storyboards proposal, Email is just one form item  
update, the capital N form. Not something separate from item updates.

> - I'm afraid that users will send an email "just to make sure" the  
> notification is received, drowning the recipient a little bit more  
> in incoming flow

How we use the wiki today is a good example of why I don't think this  
will be a problem. When people make minor changes to wiki pages, they  
don't send Email alerting everyone. However, when people make  
significant changes that they would like to have reviewed, they do.  
That is the distinction between capital-N (Email) and small-n  
notifications.

>
> I think that, ideally, we'd like to wean people of using email for  
> everything but rather have email be one tool among others.

Email is the tool that allows Chandler users to actively PING others  
of important changes. The reason why we want to use Email is so that  
Chandler users can send the same PING to both Sharees and Non- 
Sharees. Otherwise, users will have to send 1 PING via Sharing to  
Sharees and create a separate PING via Email to Non-Sharees. Given  
that we can't track who actually subscribes to Shares in the UI, if  
we separate the Sharing Notifications from Email, users will  
literally not know who to PING via Sharing and who to Email. (Email  
also means that even Sharees can receive capital-N notifications in  
their email clients, rather than having to go check for PINGs by  
firing up Chandler.)

> If we do sharing of tasks and events correctly, I can imagine cases  
> where I would hardly send/receive emails, relying instead on the  
> notification mechanism so that whoever needs to know will know.  
> Somewhere, I think an RSS-like workflow is the best one. If the UI  
> could visually discriminate between new and updated items, that  
> would be perfect.

Yes RSS-like in my mind is the Sharing log, minus the ability to read  
the log outside of Chandler (which if it's easy to do, we should do).  
However, there still needs to be a way for users to actively focus  
someone else's attention on a new/urgent task or piece of  
information, which is essentially the 'capital-N notification via  
Email'. Otherwise, RSS-like sharing notifications cause the same  
problems. How does the user looking at an RSS change feed pick out  
the signals (Please review this update) from the noise (typo fixes)?

>
> Also, having things appearing automatically in NOW is somewhat  
> counter intuitive to me. NOW is a triaged section of carefully  
> selection stuff I want to give my immediate attention. Incoming  
> stuff (emails, notifications, etc...) are not triaged yet and  
> should be parked somewhere else, in a "non-triaged" section.

In a collaboration scenario, capital N updates are a way for someone  
else to 'focus' your attention on information for you. That's  
essentially what Email does as well. However, the prevalence of SPAM,  
mailing lists, etc makes it hard for people to pick out the important  
'requests for attention' from the noise.

So, in the Beta timeframe, if we don't expect people to be reading  
all of their email in Chandler, then I think it might be safe to say  
that the NOW section is a combination of self-selected 'Focus' items  
as well as items that others would like you to 'Focus' on, aka  
Requests for 'Focus'. Within the NOW section you can visually  
distinguish between NEW, UNSEEN items and SEEN, NOW items.

I agree however, in the long-term that we need to provide a separate  
NEW section in the Dashboard. However, very few people can resist  
'living' in their email client INBOX and don't really distinguish  
between what they're 'focusing on' and what's 'new and exciting' in  
their inbox.

As a result, the theory is that if we force a certain class of users  
to work with a separate NEW section in the Dashboard, they will end  
up 'focusing on', aka sitting in the NEW section and not really use  
the NOW section at all.

Instead, we should make it so that users who want/need to segregate  
NEW from NOW need to actively turn on the NEW section, as opposed to  
setting it up so that people who don't want/need to segregate NEW  
from NOW have to turn it off.

The theory is that it's
1.  More likely that people want a separate NEW section are  
explicitly aware of that desire and will look for the feature; and
2. Less likely that people who don't want a separate NEW section are  
explicitly aware of their desire and they are therefore less likely  
to look for the ability to turn off the separate NEW section feature.

>
> Cheers,
> - Philippe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20060520/578a1283/attachment.html