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. On May 20, 2006, at 12:38 AM, Philippe Bossut wrote:
In the Stamping Storyboards proposal, Email is just one form item update, the capital N form. Not something separate from item updates.
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.
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.)
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)?
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.
|
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
