Sending things in a hurry is understandable, but regardless of how things are sent, the affects are felt. Not all of us receiving these emails work in the office, as Oliver states, so it alienates them especially as part of a larger tendency to leave them out of the loop in general, but nor are all the folks following this even staff. And while those of us who are volunteers, developers and users alike, understand that of course we will be left out at times, that doesn't make it any easier for us when a seemingly open discussion ends with 'this will be in the meeting' for the same reason we would be following in the first place - because we care. Because this affects us same as it affects all others working remotely who have to implement the results or implement around them, and because we will be using it. So please, be careful with what you say.

That said, it should not take an hour to do a simple icon. If it is part of an existing set with the general style already laid out, a single graphic like that should really be taking all of five minutes - if it isn't, there are probably deeper problems (perhaps with said general style?) at play. Perhaps if we talk later I might be able to help with that, but I suspect neither of us are in any shape presently to even deal with sorting that out.

On 31/03/13 05:05, Vibha Bamba wrote:
The previous email was simply an email sent in a hurry. And it is being treated out of proportion. 
I assure you we have no intent of working without consensus.

I sent an 'immediate follow up email' where I specifically stated that folks should join the 'Monday meeting' which has been set up for this purpose along with general feature roundup. Discussions and mocks will be posted on mediawiki to follow up for those who cannot participate so they can join in with comments. 

The reason this occurred is because the email was sent in a hurry.
I would also request everyone to understand that we are shortstaffed on the design team.
We have been unable to hire a visual designer since Lindsey left around September last year.
Munaf and I are covering production work on E2, E3 and Mobile & design Outreach. This includes both interaction and visual design.
Just to put things into perspective: It takes one hour to make a simple icon if it has to be done right. 

The email sent in a hurry because at any given time 2 designers are balancing a lot of work and sometimes we need to close things out or narrow solutions before we can manage a discussion between 15 people. 
Please recognize that we are doing our best to make sure teams are supported. We absolutely acknowledge that remote staff needs to and must be involved. 

If anyone has any concerns please feel free to chat with Howie and me. I would really appreciate that we close this thread.
It is simply a misunderstanding and nothing else.

Thanks
Vibha


On Sat, Mar 30, 2013 at 8:38 AM, Oliver Keyes <okeyes@wikimedia.org> wrote:
So, wide-in-scope-and-slightly-TL;DR followup:

I'd ask for us to avoid statements like "if you want to see them, come by my desk".

This is not something specific to this situation, and I want to take clear I'm not taking issue with anyone in particular (Vibha and I discussed the issue, the designs will be in the Monday meeting, no harm, no foul)., but: I think we have a tendency to have a lot of discussions in-office. This is something I noticed particularly on my most recent visit to the WMF HQ, when it became clear precisely how many discussions and ideas were being had and nixed and pushed forward before seeing the light of day from a remote worker's perspective, probably aided by meetings people like Siebrand, Tomasz, Arthur and I have been having with HR and OIT about bridging the office-remote divide. It's being done becaise we all want the WMF to work efficiently and quickly. This is understandable, it's laudable, it's inevitable given the state of perpetual pressure we're under; we have a thousand things we need to fix and only the resources to fix ten correctly. We need to move fast and we need to move in the right direction so that we can get *something*, the 90 percent product, out rather than spending eternity spinning our wheels on the 100 percent product. But, here's the rub: much like the relationship between quitting drinking and living longer, keeping things in-person doesn't actually make us move faster, it just makes it feel faster.

Like it or not, we've got geographically distributed employees. A lot of them work from SF, sure, but we've got people in Spain, the Netherlands, India, Australia, the UK. And when important discussions happen in-person, we exclude them from the conversation. This doesn't make things faster or better, because they *work here* - because they're tasked with implementing the outcome of the discussion, or providing feedback on it. And when they're excluded from the conversations, we end up having bits of them again and again because what's obvious context to someone who /was/ in the meetings isn't necessarily obvious to people outside them. We end up having fewer perspectives in decision-making, we end up with a dozen discussions with 13 participants instead of concentrating that into one meeting. We might find a resolution on Day 1, and take until Day 14 to have everyone on side. In other words: we're not working more efficiently at all; we're working less efficiently. Product Development is ultimately a process and sub-department that doesn't set much stock by hierarchy. We can't just declare "this meeting happened and a decision has been made" without getting at least stubborn acceptance of the idea by a lot of people. If they weren't in that meeting...more meetings. More conversations. Less speed.

I get the desire to move quickly, and I applaud it. But as a department, we need to get better at quickly crushing the voice that says "I'll just wander over to their desk", because some people don't have desks in SF. We have a duty to efficiency, which is not served by meeting after meeting on the same points with different people. We have a duty to transparency, which is not served by shutting our volunteers and a substantial chunk of our employees out of the inner workings of the sausage factory. We have a duty to Get Stuff Done Fast: and this is best served by having everyone on side and pushing in the same direction.


On 29 March 2013 23:50, Vibha Bamba <vbamba@wikimedia.org> wrote:
Also:
If anyone has ideas, please feel free to make simple wireframes and share them during the Monday syncup.
I think showing how this interaction will better anchor and guide the discussion.

Thanks


On Fri, Mar 29, 2013 at 4:48 PM, Vibha Bamba <vbamba@wikimedia.org> wrote:
Just to clarify: The shareout will be during the Monday meeting.
It seems like everyone is already attending this meeting.
As a follow up, I will post the mocks and conversation tot his thread so any folks who couldn't make it can participate.

Thank You.


On Fri, Mar 29, 2013 at 4:35 PM, Vibha Bamba <vbamba@wikimedia.org> wrote:
They are interactive mockups with motion and its too hard to share them without seeing them live.
I believe you will join the Monday meeting?



On Fri, Mar 29, 2013 at 4:33 PM, Oliver Keyes <okeyes@wikimedia.org> wrote:
Speaking as one of the several remote employees on the E2 team, I would suggest taking that sharing list in reverse order :).


On 29 March 2013 23:31, Vibha Bamba <vbamba@wikimedia.org> wrote:
I will also share these in the team meeting and then we can discuss the conclusion and I will post a PDF on Mediawiki.

Thanks
Vibha


On Fri, Mar 29, 2013 at 4:31 PM, Vibha Bamba <vbamba@wikimedia.org> wrote:
I have two prototypes to share that will help solve this problem that I can share on monday at my desk.



On Wed, Mar 27, 2013 at 2:59 PM, Benny Situ <bsitu@wikimedia.org> wrote:
I did not go through every thread in this conversation, what problem is 'clear/go away' trying to solve?  Is it because the notification topic is not interesting to the user or is it because it disturbs the user view in the flyout?  'clearing' existing ones doesn't prevent new ones from coming in.  Or is it just because we want to provide more UI control to end users?

I receive emails from amazon regularly and I would view them occasionally to see what's on sale , I would never check/delete them because I know that new emails will push them out of the first page.  If I am getting sick of receiving such email I would just unsubscribe.  I am not sure about implementing such function, I think it totally depends on personal preference ( in such case, majority rules, :) ).


On Wed, Mar 27, 2013 at 1:33 PM, Luke Welling WMF <lwelling@wikimedia.org> wrote:
I generally like the feature in its current form.

It's not exactly how I'd have specified it.  I think consistency in UX is vital so if it were just up to me, I would not have different handling for talk and system notifications.  But that's a relatively minor issue.

The big question I'd ask now is "Is there a realistic chance that we'll add fine grained control in V1.1?"

If there is, then type based disabling is dangerous. It limits what we can turn on later. For example, if somebody has turned off all page link notifications because they were getting dozens for a single uninteresting page they created, and we later add per page disabling of that type, we can't reasonably turn it back on for that user. Undoing their manual preference settings would be obnoxious. We've lost them from that feature forever even if we improve it.

Luke


On Wed, Mar 27, 2013 at 4:27 PM, Vibha Bamba <vbamba@wikimedia.org> wrote:
Ryan, can you request you to comment on tech feasibility analysis for 2 things:

-A simple 'Go away/Remove this notification'
-And a 'Clear All' for visible notifications in the flyout?


On Wed, Mar 27, 2013 at 1:25 PM, Oliver Keyes <okeyes@wikimedia.org> wrote:
That's an argument for 'they might not find the feature as useful'. Will they be directly inconvenienced by the feature? Not that I can see. But since we're in agreement that, well, we're not in agreement, it's probably worth mooting this conversation until there comes a time when we have more evidence on how things work in practise, or other people want to take up the baton.


On 27 March 2013 20:23, Vibha Bamba <vbamba@wikimedia.org> wrote:
Right. So I agree we need solutions that will work across a spectrum of engagement levels.
But turning categories off also doesn't work for new users, their volume and velocity of notifications is much smaller than the power user.


On Wed, Mar 27, 2013 at 1:19 PM, Oliver Keyes <okeyes@wikimedia.org> wrote:
I am certainly talking about the power user; my point is that we do have use cases here :). I strongly agree that new users are unlikely to create a volume of edits or articles in a single go, but given that our job with EE is to turn them into power users, and being able to create mechanisms to do this requires some kind of community acceptance, it seems illogical to make product decisions based on the short-term. I'm happy to wait until we have more evidence, and other people are convinced this might be worth looking into, but "I think you may be talking about the power user here" is never a valid argument for a feature that hits non-newcomers.


On 27 March 2013 20:02, Vibha Bamba <vbamba@wikimedia.org> wrote:
Oliver, I think you may be talking about the power user here:
New users are unlikely to create a volume of edits or articles in a single go.

Certain categories cannot be switched off:
-Systme Messages
-Talk Page messages

You bring up a very valid case, but I doubt that the solution is turning entire categories off from the flyout.
If it is spam for power users, they can turn things off in Preferences.

Facebook provides a very sophisticated level of control in the flyouts by letting you mute :

-Notification from User X (Not all talk messages) 
-Notifications about Event X (Not all events)
-Notifications from X wall Post (Not all your wall posts, just this specific one)
-Notifications from the status you posted (Not your entire wall)
-Notifications for a language from a service (Not even the entire app in all cases)

This is the level of control we may need for some categories, but it needs more thinking,
I dont think we are there yet.

On Wed, Mar 27, 2013 at 12:34 PM, Oliver Keyes <okeyes@wikimedia.org> wrote:
As someone who has spent time directly observing user behaviour for many years - we have lots and lots of evidence. For example; are you aware that users semi-automatically and/or rapidly create articles? Usually translated from other projects. I sincerely doubt that they will want a notification every time.


On 27 March 2013 19:32, Vibha Bamba <vbamba@wikimedia.org> wrote:
To clarify:

1) The safest thing that allows to build incrementally for now is  'Ive read this > Remove it' which is a really a simple 'Go Away'
2 ) In addition to this we could support a 'Clear All Read' from the flyout so a user doesn't have to dismiss one at a time.

This still leaves us with the problem of cross linking notification which may be large in volume > we could make that an 'Opt In'

The reason I think turning off categories in the flyout is problematic is:
  1. Dismissing entire categories needs more fine tuning. Users will want to unfollow specific things > Articles > Discussions etc.
  2. Switching off categories also prevents us from incremental fine tune controls in the short term.
  3. Other than cross links, so far we dont have enough evidence that users will want to switch entire categories off. We need more time and back end support to figure that out. 

On Wed, Mar 27, 2013 at 12:23 PM, Vibha Bamba <vbamba@wikimedia.org> wrote:
I propose:

1) The safest thing that allows to build incrementally for now is  'Ive read this > Remove it'
2 ) In addition to this we could support a clear all new from the flyout so a user doesn't have to dismiss one at a time.

This still leaves us with the problem of cross linking notification which may be large in volume > we could make that an 'opt in'

Dismissing entire categories needs more fine tuning.
Other than cross links, so far we dont have enough evidence that users will want to switch entire categories off.
Users will want to unfollow specific things > Articles > Discussions etc.
We need more time and back end support to figure that out.


On Wed, Mar 27, 2013 at 12:17 PM, Isarra Yos <zhorishna@gmail.com> wrote:
But having the option there at all, if its to be removed later for simplicity, could even cause problems - how quickly would users figure out that they dont want a kind of message? On the first one, it probably wont seem worth dismissing all of the type - might be interesting to get more. But once they get twenty in the next day, then it would probably sink in that okay, this is really annoying. But where did the option go? Wasnt there an option?

If anything it might lead them away from their preferences because their preferences are not where they saw the option initially.


On 27/03/2013 13:11, Matthew Flaschen wrote:
On 03/27/2013 03:09 PM, Isarra Yos wrote:
Perhaps Im misunderstanding something, but if someone is trying to
dismiss several, they wont want a dialog showing up every time, but at
the same time even if they dont want to disable all of the type the
first time that doesnt mean they wont want to do that later. The option,
if its going to be there, needs to be there somewhat consistently.
You can still disable the notification category in Special:Preferences .
  It may be worthwhile to keep the main Echo interface (not preferences)
simpler if they choose not to disable the category the first time.

Matt Flaschen


_______________________________________________
EE mailing list
EE@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/ee


--
-— Isarra



_______________________________________________
EE mailing list
EE@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/ee



_______________________________________________
EE mailing list
EE@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/ee




--
Oliver Keyes
Community Liaison, Product Development
Wikimedia Foundation

_______________________________________________
EE mailing list
EE@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/ee



_______________________________________________
EE mailing list
EE@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/ee




--
Oliver Keyes
Community Liaison, Product Development
Wikimedia Foundation

_______________________________________________
EE mailing list
EE@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/ee



_______________________________________________
EE mailing list
EE@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/ee




--
Oliver Keyes
Community Liaison, Product Development
Wikimedia Foundation

_______________________________________________
EE mailing list
EE@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/ee



_______________________________________________
EE mailing list
EE@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/ee



_______________________________________________
EE mailing list
EE@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/ee



_______________________________________________
EE mailing list
EE@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/ee




_______________________________________________
EE mailing list
EE@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/ee




--
Oliver Keyes
Community Liaison, Product Development
Wikimedia Foundation

_______________________________________________
EE mailing list
EE@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/ee





_______________________________________________
EE mailing list
EE@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/ee




--
Oliver Keyes
Community Liaison, Product Development
Wikimedia Foundation

_______________________________________________
EE mailing list
EE@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/ee




_______________________________________________
EE mailing list
EE@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/ee



-- 
-— Isarra