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(a)wikimedia.org
<mailto: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(a)wikimedia.org
<mailto: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(a)wikimedia.org <mailto: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(a)wikimedia.org <mailto: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(a)wikimedia.org <mailto: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(a)wikimedia.org
<mailto: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(a)wikimedia.org
<mailto: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(a)wikimedia.org
<mailto: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(a)wikimedia.org
<mailto: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(a)wikimedia.org
<mailto: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(a)wikimedia.org
<mailto: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(a)wikimedia.org
<mailto: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(a)wikimedia.org
<mailto: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(a)wikimedia.org
<mailto: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(a)wikimedia.org
<mailto: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(a)wikimedia.org
<mailto: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(a)wikimedia.org
<mailto: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(a)gmail.com
<mailto: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(a)lists.wikimedia.org
<mailto:EE@lists.wikimedia.org>
https://lists.wikimedia.org/mailman/listinfo/ee
--
-—
Isarra
_______________________________________________
EE
mailing
list
EE(a)lists.wikimedia.org
<mailto:EE@lists.wikimedia.org>
https://lists.wikimedia.org/mailman/listinfo/ee
_______________________________________________
EE
mailing list
EE(a)lists.wikimedia.org
<mailto:EE@lists.wikimedia.org>
https://lists.wikimedia.org/mailman/listinfo/ee
--
Oliver Keyes
Community
Liaison,
Product
Development
Wikimedia
Foundation
_______________________________________________
EE mailing
list
EE(a)lists.wikimedia.org
<mailto:EE@lists.wikimedia.org>
https://lists.wikimedia.org/mailman/listinfo/ee
_______________________________________________
EE mailing list
EE(a)lists.wikimedia.org
<mailto:EE@lists.wikimedia.org>
https://lists.wikimedia.org/mailman/listinfo/ee
--
Oliver Keyes
Community Liaison,
Product Development
Wikimedia Foundation
_______________________________________________
EE mailing list
EE(a)lists.wikimedia.org
<mailto:EE@lists.wikimedia.org>
https://lists.wikimedia.org/mailman/listinfo/ee
_______________________________________________
EE mailing list
EE(a)lists.wikimedia.org
<mailto:EE@lists.wikimedia.org>
https://lists.wikimedia.org/mailman/listinfo/ee
--
Oliver Keyes
Community Liaison, Product
Development
Wikimedia Foundation
_______________________________________________
EE mailing list
EE(a)lists.wikimedia.org
<mailto:EE@lists.wikimedia.org>
https://lists.wikimedia.org/mailman/listinfo/ee
_______________________________________________
EE mailing list
EE(a)lists.wikimedia.org
<mailto:EE@lists.wikimedia.org>
https://lists.wikimedia.org/mailman/listinfo/ee
_______________________________________________
EE mailing list
EE(a)lists.wikimedia.org
<mailto:EE@lists.wikimedia.org>
https://lists.wikimedia.org/mailman/listinfo/ee
_______________________________________________
EE mailing list
EE(a)lists.wikimedia.org
<mailto:EE@lists.wikimedia.org>
https://lists.wikimedia.org/mailman/listinfo/ee
_______________________________________________
EE mailing list
EE(a)lists.wikimedia.org
<mailto:EE@lists.wikimedia.org>
https://lists.wikimedia.org/mailman/listinfo/ee
--
Oliver Keyes
Community Liaison, Product Development
Wikimedia Foundation
_______________________________________________
EE mailing list
EE(a)lists.wikimedia.org <mailto:EE@lists.wikimedia.org>
https://lists.wikimedia.org/mailman/listinfo/ee
_______________________________________________
EE mailing list
EE(a)lists.wikimedia.org <mailto:EE@lists.wikimedia.org>
https://lists.wikimedia.org/mailman/listinfo/ee
--
Oliver Keyes
Community Liaison, Product Development
Wikimedia Foundation
_______________________________________________
EE mailing list
EE(a)lists.wikimedia.org <mailto:EE@lists.wikimedia.org>
https://lists.wikimedia.org/mailman/listinfo/ee
_______________________________________________
EE mailing list
EE(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/ee