User testing - or - who speaks for the majority of the user base?
Nelson B
include SeaMonkey) have a large and long-standing user base, which (I
think) we want to preserve, or at least not drive away unnecessarily.
That user base has become quite accustomed to how Mozilla products work.
So, seemingly arbitrary changes to the behavior of frequently used
features can be perceived as product regressions, and can really upset
and drive away long-time users, something that (I think) we want to avoid.
Occasionally (pretty frequently) people come along and propose (in bugs or
RFEs) changes to the UI behavior of these products. In many cases, they
propose changes to basic behavior that has been the same since the very
first Mozilla browsers, and even before that (some features go back to
Netscape days, but I won't dwell on that). Often, but not always, these
proposed changes come from newcomers to the products, people who have
transitioned from some non-Mozilla product, and wish that the Mozilla
product worked more like the other product to which they were accustomed.
But sometimes they come from long time users who say "this has always
been wrong, and needs to be fixed".
Most of these changes have no security significance, and merely affect
user convenience. They would make happy those who dislike the present
behavior, and they might (or might not) make very unhappy a sizable
portion of that large loyal user base we want to preserve.
Disagreements about such proposed changes are not uncommon. Often in
such disagreements, both sides express the notion that they speak for
the majority of past (or future) users. Sometimes the representation
by one side or the other, that they represent the majority of users, is
laughable. But more often these are disagreements between two legitimate
points of view, and they point out that we simply don't know what the
majority of our *existing* user base likes and wants, or feels strongly
that we should preserve, or feels strongly that we should change.
We see campaigns for change waged in the newsgroups, and sometimes it
seems as if the noisiest group wins, even if they really do represent
only a tiny (but very vocal) minority. I personally don't believe
that the community of participants in these newsgroups is a truly
representative cross section of the mozilla product user base in
general. The loudest voices in these groups may well not represent
the majority of existing product users.
So, how do we (the Mozilla developer community) decide what UI changes
to make, and what not to make?
Putting the changes into a release, to see how it affects the user
community, seems like a high risk approach. It seems like we should
have a way to predict the user community response pretty accurately
BEFORE we commit a new feature to the product.
There are a number of such changes being considered now for FireFox
and ThunderBird, and I wonder: are we doing enough to ensure that we're
not going to upset our user base unnecessarily with some of these changes?
My point here is NOT to raise an issue out of any one (or two or ...)
specific issues, but to discuss the PROCESS by which we make decisions
in these matters.
Any thoughts about how we determine the desires of the majority of users?
--
Nelson B
Peter Potamus the Purple Hippo
> So, how do we (the Mozilla developer community) decide what UI changes
> to make, and what not to make?
by reading what users are saying, and asking, within the
support newsgroups.
--
Please do not email me for help. Reply to the newsgroup
only. And only click on the Reply button, not the Reply All
or Reply to Author. Thanks!
Peter Potamus & His Magic Flying Balloon:
http://www.toonopedia.com/potamus.htm
Mike Beltzner
> My point here is NOT to raise an issue out of any one (or two or ...)
> specific issues, but to discuss the PROCESS by which we make decisions
> in these matters.
Making decisions in these matters is -- to the best of my knowledge
-- the same as any other matter with respect to checking in code.
Final authority rests with the module owner, who can delegate peers
to assist with the decision making process, and who bases his opinion
on the advice and counsel of the community and other reviewers.
> Any thoughts about how we determine the desires of the majority of
> users?
This is entirely different from the process by which we make
decisions, IMO, and more similar to the process by which we determine
which technologies are worth investing in. That is to say that
building our understanding of the affected stakeholders and user
bases, and then determining (through primary or secondary sources)
what the needs of those audiences are.
I would welcome and encourage more user research -- for example, I
don't think there's been a really solid survey of what sort of tasks
people are doing on the web in several years, and there certainly
hasn't been any publically available ethnographic research done on
usage patterns for web browsers. Not all UI design decisions should
be based solely on research -- as in code, design is based on the
inferences and observations of experts, using research as well as
experience as a basis. That said, solid research is a good foundation.
cheers,
mike
Alex K.
> Nelson B wrote:
>> So, how do we (the Mozilla developer community) decide what UI changes
>> to make, and what not to make?
>
> by reading what users are saying, and asking, within the
> support newsgroups.
>
But you cut the previous paragraph, where he said:
"We see campaigns for change waged in the newsgroups, and sometimes it
seems as if the noisiest group wins, even if they really do represent
only a tiny (but very vocal) minority. I personally don't believe
that the community of participants in these newsgroups is a truly
representative cross section of the mozilla product user base in
general. The loudest voices in these groups may well not represent
the majority of existing product users."
And I tend to agree with that, especially the last sentence.
In a support group, the only people you hear from are *some* of the ones
who are having a problem or don't like something. You don't hear from
all the other people who are *not* having problems. You don't hear from
people who may not like a change, but either decide to live with it or
change to a different client.
Now, I'm not saying to ignore the newsgroups completely, just that there
needs to be more to it than that. I do agree with Mike Beltzner, who,
admittedly, posted after you did, so you may not have seen it as of the
time of this posting, but he said:
"I would welcome and encourage more user research -- for example, I
don't think there's been a really solid survey of what sort of tasks
people are doing on the web in several years, and there certainly
hasn't been any publically available ethnographic research done on
usage patterns for web browsers. Not all UI design decisions should
be based solely on research -- as in code, design is based on the
inferences and observations of experts, using research as well as
experience as a basis. That said, solid research is a good foundation."
I would guess, just based on the publicly available numbers, that the
Foundation probably has the financial resources to commission a study or
two, to develop that research. To find out what a *true* majority are
doing/needing/wanting, not just the "vocal" ones.
Just my $.02 worth.
--
Alex K.
Robert Kaiser
> So, how do we (the Mozilla developer community) decide what UI changes
> to make, and what not to make?
The decision is made by module owners, project leads and/or special UI
teams assigned by those.
As strange as it might sound to you, the ultimate decision is not up to
users, not even up to any majority vote or such, but up to hand-selected
project decision makers.
The decision makers will usually take into account arguments made by
users or whoever discusses the topic somewhere, they might take into
account any studies or whatever is present in such areas (if any), and
they will take into account what target audience their project has
(which can e.g. easily lead to different UI for SeaMonkey and Firefox).
They will likely not count how many people support which argument, but
go by the presented arguments themselves - but how they reach a decision
is completely up to them (and usually does exclude anything that might
sound democratic to you - but democratic software development will
probably always fail).
Ultimately, the developer(s) implementing the code has quite some
weight, as we can only take actual code, making software out of hot
words has not proven to be efficient.
Robert Kaiser
Peter Potamus the Purple Hippo
> Peter Potamus the Purple Hippo wrote:
>> Nelson B wrote:
>>> So, how do we (the Mozilla developer community) decide what UI changes
>>> to make, and what not to make?
>> by reading what users are saying, and asking, within the
>> support newsgroups.
>>
>
> But you cut the previous paragraph, where he said:
>
> "We see campaigns for change waged in the newsgroups, and sometimes it
but he didn't specify which newsgroups he was talking about.
As far as I'm concerned he was talking about the
developers group: One group wants this change and the other
group says no. You don't see that [noisiest group] within
the support groups, do you!?.
Besides, when I look up Nelson B in the credits, I see he's
a developer.
Peter Potamus the Purple Hippo
one of the major complaints from the users within the
"support groups" when FF went from 1.5 to 2.x was the
changes made to the UI. I'm sure there was complaints when
FF went from 1.0.x to 1.5. One of the complaints is
"Settings used to be there, now where are they?"
There have been several discussions within the support
groups and in the mo.gen group, that the developers do not
listen to the users. One of the complaints is "the
developers think they know what the user wants." When you
say: "The decision is made by module owners, project leads
and/or special UI teams assigned by those," well, that
supports that arguement very much.
Therefore, when debating change to the UI, consideration
from the End User should be taken into account. After all,
it is they who are using it.
Justin Dolske
> Putting the changes into a release, to see how it affects the user
> community, seems like a high risk approach. It seems like we should
> have a way to predict the user community response pretty accurately
> BEFORE we commit a new feature to the product.
Well, as has been mentioned recently, part of the point of Minefield is
to have a way to make new/experimental changes to UI (and code!)
available to a wider audience. We shouldn't make thoughtless changes or
break basic functionality, but otherwise I don't see the harm.
[Extensions have also been mentioned, and used, as a vehicle for trying
out changes before putting them into trunk.]
> Any thoughts about how we determine the desires of the majority of users?
Majority or plurality?
Justin
Nelson Bolyard
> Nelson B wrote:
>> So, how do we (the Mozilla developer community) decide what UI changes
>> to make, and what not to make?
>
> The decision is made by module owners, project leads and/or special UI
> teams assigned by those.
I didn't ask that question very well. As a module owner, I'm aware of
my special powers. :) Let me try again.
How *should* the module owners decide what UI changes to make (or not)?
How can we ensure that we consider all the users, and not just the
noisiest ones, and not just the mozilla (news) groupies and b.m.o users?
I personally monitor a number of non-mozilla-centered forums in which
mozilla products are nonetheless discussed, and I hear different voices
in them than I hear in mozilla's newsgroups, expressing different views.
But even so I think I'm still hearing a self-selecting community, not a
true cross section of mozilla product users.
> As strange as it might sound to you, the ultimate decision is not up to
> users, not even up to any majority vote or such, but up to hand-selected
> project decision makers.
That doesn't sound strange to me. I'm a co-owner of several modules.
That's part of the reason why I am sensitive to these campaigns for change,
(having been the target of more than one), and feel some need to balance
the loudest voices, the noisy minority, with the desires of those who do
not speak in our forums, but who do use the products.
The users who are happy with features (as they are) tend not to participate.
They are silent. They *may* be a "silent majority". I think they often
are, and their view goes unheard much of the time. As a module co-owner,
I want to be sure that I'm not merely being swayed by the loudest voices.
So I ask my fellow module owners, and the mozilla developer community in
general:
How can we give those silent users a louder voice?
How can we find a voice that is truly representative of them?
How can we hear from the people who do not participate in these news
groups, mailing lists, and bug reports?
When the loudest voices are clamoring for a change, how can the module
owner support his decision not to make that change? (Not that he needs
to do so, but it would be helpful at times to be able to be *certain*
of the majority view, and to be able to convince the noisy minority that
they *are* a minority.)
> The decision makers will usually take into account arguments made by
> users or whoever discusses the topic somewhere,
Right. I think the weight of the voices of users in mozilla newsgroups
and in bug reports is second only to the weight of the patch contributors.
But I'm not sure that any of those groups are representative of an
unbiased cross section of Mozilla product users.
> they might take into
> account any studies or whatever is present in such areas (if any),
... if there were any ... That's part of what I'm getting at here.
> and they will take into account what target audience their project has
> (which can e.g. easily lead to different UI for SeaMonkey and Firefox).
Yes, Agreed that those audiences are different. But can anyone accurately
characterize the differences between them, vis-a-vis UI likes and dislikes?
If anything, I think the SM users are mostly long term users, who liked
the App Suite so much that they chose not to switch to FF & TB. So
I suspect that UI changes do more damage to the SM user base than to the
FF base. So I'd think this would be of some interest to you, Robert.
> They will likely not count how many people support which argument, but
> go by the presented arguments themselves - but how they reach a decision
> is completely up to them (and usually does exclude anything that might
> sound democratic to you - but democratic software development will
> probably always fail).
I think that we as module owners have a duty to try to consider the needs
and wants of the whole user base. Within the walls of king Mozilla's
palace, we easily hear the voices of the courtiers, but the voices of the
multitudes outside the walls go largely unheard, I fear.
> Ultimately, the developer(s) implementing the code has quite some
> weight, as we can only take actual code,
Yes, the people who produce patches do carry the most weight with the
module owners, I think. That's only natural. The module owners are
frequently faced with a decision of "do I or don't I approve this patch?".
The decision factors are often "Is this patch technically correct?" and
"Is its effect on the software architecture reasonable and desirable?".
I want us to ask: "what will our mothers think?".
> making software out of hot words has not proven to be efficient.
Heh.
> Robert Kaiser
/Nelson B
Tony Mechelynck
[...]
> The users who are happy with features (as they are) tend not to participate.
> They are silent. They *may* be a "silent majority". I think they often
> are, and their view goes unheard much of the time.
...until an unpopular change gets implemented, and (once it's too late) loud
complaints suddenly rise out of the blue, about, let's say, this or that
widget which harmed nobody, which "we" used, and which developers suddenly
removed because they said "nobody uses it anyway, and besides, it isn't
discoverable".
[...]
> How can we give those silent users a louder voice?
> How can we find a voice that is truly representative of them?
> How can we hear from the people who do not participate in these news
> groups, mailing lists, and bug reports?
It won't be easy. If some extensions and/or themes enjoy a very high
popularity, that means that a lot of people want them. Depending on what that
add-on implements, it may then -- or may not -- be desirable to distribute it
as an installable option, together with the main product. But that's only a
very small part of "what most users like in Mozilla products".
[...]
> If anything, I think the SM users are mostly long term users, who liked
> the App Suite so much that they chose not to switch to FF & TB. So
> I suspect that UI changes do more damage to the SM user base than to the
> FF base. So I'd think this would be of some interest to you, Robert.
Could be. I used to be, not a Mozilla Suite user but a user of Netscape 4.75,
then of Netscape 6. I switched to Fx/Tb because, at the time, I felt that
Netscape wasn't updated often enough and that Mozilla (which most of its users
known to me then downloaded as trunk nightlies) wasn't stable enough. That was
about when Fx1 and Tb1 release-candidates came out. But I've always regretted
the abandon of the no-nonsense Netscape tree-like preferences interface (which
I now happily find back in SeaMonkey) in favour of something which seemed to
me to be too flashy and made to appeal to teenagers -- maybe, at 56, I'm just
too old-fashioned for it. Now that SeaMonkey (trunk) has a decent add-ons
version management system, I'm watching how extensions important to me get
ported to it (or don't), and how well (or how badly) those who were indeed
ported work on it. (Example: Local Install, Tab Mix Plus. The former works --
but only "after a fashion". The latter apparently won't be ported to Sm but at
least I've found out how to get a multi-row tab bar by means of
userChrome.css. I'd like to be able to make the tabs narrower though.)
[...]
> Yes, the people who produce patches do carry the most weight with the
> module owners, I think. That's only natural. The module owners are
> frequently faced with a decision of "do I or don't I approve this patch?".
> The decision factors are often "Is this patch technically correct?" and
> "Is its effect on the software architecture reasonable and desirable?".
> I want us to ask: "what will our mothers think?".
[...]
If you (still) have one, and she uses Mozilla products, ask her. Also ask your
girlfriend, your aunt, your brother-in-law, your daughter, your nephew,
whomever. Then weigh what they tell you (they won't all agree, or your sample
is too narrow) against what you think "feels right" for the product.
Best regards,
Tony.
--
"Plaese porrf raed."
-- Prof. Michael O'Longhlin, S.U.N.Y. Purchase
Robert Kaiser
> How *should* the module owners decide what UI changes to make (or not)?
They should do what they think is best. Software design is not about
democracy in the first place, so I wouldn't worry how to get it into the
process.
The module owner should collect arguments independent of the amount of
people raising them and decide based just on the arguments and his
target audience. Never count raised voices for such a decision or you're
doomed.
> How can we ensure that we consider all the users, and not just the
> noisiest ones, and not just the mozilla (news) groupies and b.m.o users?
We can't. But it doesn't matter, because loudness and voice counts
shouldn't have an influence.
> How can we find a voice that is truly representative of them?
We can't. Listen to your heart.
That's suprisingly the best way in many cases.
> When the loudest voices are clamoring for a change, how can the module
> owner support his decision not to make that change?
That's easy. He just stands by his decision and not changing it.
Sometimes one has to withstand the storm.
> Right. I think the weight of the voices of users in mozilla newsgroups
> and in bug reports is second only to the weight of the patch contributors.
> But I'm not sure that any of those groups are representative of an
> unbiased cross section of Mozilla product users.
And my point is that it doesn't matter if we have a representative
sample because that's not what we need for software design. Where we
want it, we should try to gather it in some way, but where we want it is
(hopefully) completely up to the module owner. I don't think you'd like
a newsgroup discussion here to determine how you should do your job as a
module owner, right?
>> and they will take into account what target audience their project has
>> (which can e.g. easily lead to different UI for SeaMonkey and Firefox).
>
> Yes, Agreed that those audiences are different. But can anyone accurately
> characterize the differences between them, vis-a-vis UI likes and dislikes?
There is a target audience specification for SeaMonkey on the wiki. Is
there one for Firefox? If so, you can compare them however you like. We
don't care about comparing them, we care about acting with our
definition in mind, whatever someone else's target audience is.
> I think that we as module owners have a duty to try to consider the needs
> and wants of the whole user base.
I think our responsibility is to just stick to the way we successfully
went, as this way is exactly what users expect from us. I don't see that
we need to do something different unless we are currently obviously
doing something wrong. I see all our products gaining currently though
(except the Mozilla-branded suite), so I see no need to change anything.
> Yes, the people who produce patches do carry the most weight with the
> module owners, I think. That's only natural. The module owners are
> frequently faced with a decision of "do I or don't I approve this patch?".
> The decision factors are often "Is this patch technically correct?" and
> "Is its effect on the software architecture reasonable and desirable?".
Good and reasonable questions, which have led us to be successful.
> I want us to ask: "what will our mothers think?".
Doesn't matter, unless your target audience is dominated by your mothers.
Robert Kaiser
Peter Potamus the Purple Hippo
You want to hear from the "silent users" and you don't know
how to contact them. Well, its right at your finger tips,
and you don't even know it.
This has to be the second most stupidest thing I've seen
from Mozilla. You install SeaMonkey [or Firefox. I'm using
SM as the example cause thats the program I use] for the
first time, or you update it. When you restart SM, what do
you get. I can't rememeber exactly what it says [as I avoid
it], but your wisked off to some Mozilla.org website that
has either a Welcome or a Thank You screen, or a notice that
the install or update has been successful, and I think it
also has something about release notes. There you go, its
right there in front of you, and thats got to be the most
stupidest thing Mozilla can have. Its going to waste. Its
being unused.
You have a tiny little Thank You message, and under that,
have a survey. Have something that says: "Help the SeaMonkey
Council to improve SeaMonkey. We'd like to hear from you by
taking this short survey below. If you're new to SM,
bookmark this page so you can come back to it after you've
taken SM for a test drive."
With this you method, you now have the attention of everyone
who uses SM. Well, just about everyone. When I install a
new version of SM, I get the profile manager on start up
asking me to pick the profile I want to use. If I cancel
that, and start SM my regular way, then I avoid that startup
screen.
Here's another method to get everyone's attention, and it
will work for even Thunderbird. After the install it
complete and you start up SM, you get a popup message.
There, now you've got everyone's attention. You'll have to
stress to people that this is a one time popup, and will
happen with every upgrade they do. Here you can tell people
that the SM Council is look for their help to improve SM,
and to click here to take a short survey [and another one to
cancel the message and not take the survey].
And while we're at this Thank You or Welcome Screen, do you
really need information about the release notes. I don't
think the average user cares. What he really wants to know
is where do I go for help? Maybe you can list some avenues
to get help, such as the Newsgroups or the Mozillazine forums.
There, I've given you some food for thought on how to get
the attention of the "silent users".
Ray Kiddy
<snip>
You might want to look around Mozilla. There are places where the things
you speak of are being addressed. You may not have seen some of it, but
not all things about Mozilla are visible from any one venue.
First, you might want to look at the SUMo effort
(http://support-stage.mozilla.org/). I think it is going to answer the
'Where do I get help?' questions you mention. And they would appreciate
more help from the community.
As for the install page, did you notice the post on planet.mozilla.org?
Just today, a post (http://www.intothefuzz.com/) talked about the
re-design of the post-install page.
I completely sympathize with your "WTF" impression of how MoCo does
things. I have felt the same way. I still, quite often, feel the same
way. Then I take a deep breath or seven and I usually find some other
thing to do about it. Or sometimes I will just leave that battle for
another day.
Other people do get what you are saying. But there are, also, positive
things to do.
thanx - ray
> Peter Potamus the Purple Hippo wrote:
>
>
Peter Potamus the Purple Hippo
> You might want to look around Mozilla. There are places where the things
> you speak of are being addressed. You may not have seen some of it, but
> not all things about Mozilla are visible from any one venue.
>
> First, you might want to look at the SUMo effort
> (http://support-stage.mozilla.org/). I think it is going to answer the
> 'Where do I get help?' questions you mention. And they would appreciate
> more help from the community.
>
> As for the install page, did you notice the post on planet.mozilla.org?
> Just today, a post (http://www.intothefuzz.com/) talked about the
> re-design of the post-install page.
you know, all these places are fine and dandy, but for the
average user, they don't know about them. I've been around
the Moz Newsgroups since November of 2006. I didn't know a
support-stage site existed. I've seen planet.moz before,
but its not for the average user. Just recently I
discovered http://air.mozilla.com/ and
http://airmozilla-videocast.podomatic.com/. And they too
aren't for the average user.
Thats why I say the "post-install page" should have special
information on it. Especially this:
http://www.mozilla.org/support/. Something similar to that
page, but something more that informs people where they can
get help. Or the addons site.
A few months back I received an email from someone. He saw
my posting on a forum on velocity reviews. He wanted to ask
me a question about FF, but couldn't reply on the site. I
told him I usually post on the mozilla.org newsgroups.
However, they get propogated to others services such as
velocity, big-boards, vnunet, and many, many others. This
person didn't know about the Mozilla newsgroups and wanted
to know to get them.
Thats why I say that the post-install page should have this
type of information on it. Something that the users can use.
Nelson Bolyard
I think you've got the start of some great ideas here.
> You have a tiny little Thank You message, and under that, have a survey.
> Have something that says: "Help the SeaMonkey Council to improve
> SeaMonkey. We'd like to hear from you by taking this short survey
> below.
Of course, we want people to take the survey AFTER they've used it for
a while.
> If you're new to SM, bookmark this page so you can come back to
> it after you've taken SM for a test drive."
Maybe even have that be a pre-configured bookmark?
> There, I've given you some food for thought on how to get the attention
> of the "silent users".
Let me suggest that you "flesh out" some of your ideas with some sample
start-up pages for these purposes.
/Nelson
Dan Mosedale
> Peter:
>
> I think you've got the start of some great ideas here.
>
>> You have a tiny little Thank You message, and under that, have a survey.
>> Have something that says: "Help the SeaMonkey Council to improve
>> SeaMonkey. We'd like to hear from you by taking this short survey
>> below.
>
> Of course, we want people to take the survey AFTER they've used it for
> a while.
I believe at least one survey has been done in the past on Firefox
users; I'm not sure if this effort is ongoing. mconnor might know more...
Dan
Peter Potamus the Purple Hippo
> I believe at least one survey has been done in the past on Firefox
> users; I'm not sure if this effort is ongoing. mconnor might know more...
it has. I never saw it. Oh well, perhaps its time for a
newer one.
Dave Townsend
>> I believe at least one survey has been done in the past on Firefox
>> users; I'm not sure if this effort is ongoing. mconnor might know
>> more...
>
> it has. I never saw it. Oh well, perhaps its time for a newer one.
>
Unless I'm misreading the code, the survey we direct users to when
uninstalling on Windows is still in place, and the stats are at
https://survey.mozilla.com/
Dave
Tony Mechelynck
Such a survey would of course not tell anybody anything about why which people
_keep_ using Mozilla products -- or about any difference between Windows users
and users of other OSes by respect to "liking Mozilla".
I might like to bet that some of the very reasons which make some users quit
Mozilla make others quite happy with it; but I won't, because I have no info
at all one way or the other.
Best regards,
Tony.
--
All the passions make us commit faults; love makes us commit the most
ridiculous ones.
-- La Rochefoucauld
Dave Townsend
> Dave Townsend wrote:
>> Peter Potamus the Purple Hippo wrote:
>>> Dan Mosedale wrote:
>>>> I believe at least one survey has been done in the past on Firefox
>>>> users; I'm not sure if this effort is ongoing. mconnor might know
>>>> more...
>>>
>>> it has. I never saw it. Oh well, perhaps its time for a newer one.
>>>
>>
>> Unless I'm misreading the code, the survey we direct users to when
>> uninstalling on Windows is still in place, and the stats are at
>> https://survey.mozilla.com/
>>
>> Dave
>
> Such a survey would of course not tell anybody anything about why which
> people _keep_ using Mozilla products -- or about any difference between
> Windows users and users of other OSes by respect to "liking Mozilla".
Don't get me wrong I agree, but at least it's something to go on. For
example the thing I found most striking with skimming through the
comments in the survey data was the number of complaints about Firefox
bundling Google Toolbar. A bit over 5% were complaints of this nature.
> I might like to bet that some of the very reasons which make some users
> quit Mozilla make others quite happy with it; but I won't, because I
> have no info at all one way or the other.
That's such a vague statement that I can guarantee it's accurate ;)
Dave
Peter Potamus the Purple Hippo
> Unless I'm misreading the code, the survey we direct users to when
> uninstalling on Windows is still in place, and the stats are at
> https://survey.mozilla.com/
>
> Dave
now I remember that. When I uninstalled FF, there /was/
something about a survey. But I couldn't bother and moved
on, cause I was going to reinstall it again.
Gervase Markham
don't want, is to ask them - and as far as I know, no-one has done that
recent for a statistically significant sample of continuing Firefox
users. Also, even then all you have is raw data. It's often said that
no-one told Sony they wanted a Walkman, but once they got one, they
loved it. The user doesn't always (some would say doesn't often) know
what they want.
In the absence of good data, module owners have to rely on usability
principles, trial and testing, and the input of people who have proved
themselves capable of thinking as if sitting in another's shoes, to make
what we hope will be good decisions.
Turning to proposals for change, I agree that there's a delicate balance
to strike between being responsive to input, and not wasting time
rehashing for the 32nd time exactly why transitioning SSL to an SSH-like
model is not a good idea. Be polite, courteous but firm: "I'm sorry, but
I don't have time to discuss this again. Please read the old discussions
in the newsgroup and only say anything further if it's a new contribution."
One suggestion: only get concerned about a proposed change if the module
owner shows some signs of making it. That step alone might obviate a
great deal of stress :-)
Gerv
Jay Garcia
--- Original Message ---
> The only way we can find out what users like or don't like, want or
> don't want, is to ask them - and as far as I know, no-one has done that
If you provide a simple means for the user to provide feedback, feature
requests, etc. "they will come". We've done that in Navigator 9 by
placing the "Report Bug" button on the toolbar. The response has been
overwhelming. However, I would change the name of the button to
something more generalized, such as "Feedback" or whatever else to
indicate this is the place to voice your request(s). Bugzilla is
confusing to most that have never used it as well as the name
"Bug"zilla. Most users new to the system think it's only for reporting
"bugs" whereas they don't consider a RFE a "bug".
Users are simply amazed and taken aback when they receive a personal
response from staff.
Just a suggestion based on user response thus far. The next release of
NN 9.0b4 will contain quite a bit of what we learned from users pressing
the button.
Cheers
--
Jay Garcia Netscape/Mozilla Champion
UFAQ - http://www.UFAQ.org
Gervase Markham
> If you provide a simple means for the user to provide feedback, feature
> requests, etc. "they will come".
I'm not saying it's difficult to get feedback, I'm saying it's hard to
get feedback from a group which is not self-selecting. And the
self-selection inevitably introduces bias.
Gerv
Jay Garcia
--- Original Message ---
The "feedback" will only come IF the means to convey it is simple is
what I mean (I think). What venues at present are provided for Firefox,
Seamonkey and Thunderbird that are simple enough for the average user to
use to provide feedback, etc. and more important who reads the
feedback, digests it and passes it along to the proper (moduele?)
owners? What I am getting at is how difficult is the process from user
to enhancement, bug fix, etc. ?
Gus Richter
> It's often said that
> no-one told Sony they wanted a Walkman, but once they got one, they
> loved it. The user doesn't always (some would say doesn't often) know
> what they want.
It's also been said that no-one told Ford that they wanted an Edsel and
once they got one they hated it. The vendors/engineers don't always
(some would say, hardly ever) know what the users want.
--
Gus
Gus Richter
> The "feedback" will only come IF the means to convey it is simple is
> what I mean (I think). What venues at present are provided for Firefox,
> Seamonkey and Thunderbird that are simple enough for the average user to
> use to provide feedback, etc. and more important who reads the
> feedback, digests it and passes it along to the proper (moduele?)
> owners? What I am getting at is how difficult is the process from user
> to enhancement, bug fix, etc. ?
Simplicity for sure.
The other thing is to actually do something with the feedback - respond
to them. It does no good whatsoever to ask for the users' help and then
do nothing with the contribution. People may come back and actually
contribute once again. It serves nothing to tell them that "nothing will
be done unless someone out there takes interest and does something about
it (i.e. a bug, rfe, etc.)" and that "if it's so important to you, then
go and fix it yourself" or else "go out and lobby for your item until
you convince someone to actually do something about it". Perhaps the
request for Feedback/Help should also mention the caveats attached?
--
Gus
Peter Potamus the Purple Hippo
for example, when someone asked in the SM support group:
when he clicks on the "Report Broken Website" does anything
happen?
Nelson B
> The only way we can find out what users like or don't like, want or
> don't want, is to ask them - and as far as I know, no-one has done that
> recent for a statistically significant sample of continuing Firefox
> users.
That seems like a really good way for Mozilla to spend some of its money.
I'll bet that every other project of this size (or bigger) does user testing.
> Also, even then all you have is raw data.
Yes, someone would have to compute some statistics, draw some conclusions.
That would be a very helpful non-code contribution.
> It's often said that no-one told Sony they wanted a Walkman, but once
> they got one, they loved it. The user doesn't always (some would say
> doesn't often) know what they want.
Has Sony ever removed basic features from Walkman?
In the context of Mozilla products, we're not talking about a brand new
nothing-like-it-ever-before product, we're talking about the evolution
of a product that's been in users hands in one form or another for
about a decade. The users ought to know what they like about it by now.
> One suggestion: only get concerned about a proposed change if the module
> owner shows some signs of making it. That step alone might obviate a
> great deal of stress :-)
There have recently been some feature changes and feature removals because
some newcomers have argued that the old features were useless, even though
some of us have used them for a decade or more now. Right now this seems
capricious. I think our long time users deserve better feature continuity.
But until we have a way of knowing what our users want, the discussions
will continue to be be one set of biases vs. another.
--
Nelson B
Ray Kiddy
> The only way we can find out what users like or don't like, want or
> don't want, is to ask them - and as far as I know, no-one has done that
> recent for a statistically significant sample of continuing Firefox
> users. Also, even then all you have is raw data. It's often said that
> no-one told Sony they wanted a Walkman, but once they got one, they
> loved it. The user doesn't always (some would say doesn't often) know
> what they want.
>
<snip>
> Gerv
There might be a way to re-cast this debate. Forgive me if I presume too
much by suggesting it.
Finding myself outside the core of MoCo developers, I have observed that
if I want to suggest a feature, the way to do it is to create an
extension that is the feature. Thus, there are a couple of things I have
asked for or suggested and I have stopped suggesting them or asking for
them. At MoCo, talk is cheap, and code talks, even preliminary and
badly-written code. So, I can do these features as extensions and then
nobody can say they cannot be done, and we can all see how they work in
the app.
So, what would happen if all Firefox features were added this way,
including those done from inside MoCo itself?
Perhaps having a whole bunch of very finely targeted, very specific
extensions would be hard to manage with the current UI. I think I would
suggest that is true. The UI for managing extensions could be fixed.
Perhaps having a whole bunch of very finely targeted, very specific
extensions would make it hard to find things, or harder to find things,
on AMO. Well, AMO could be fixed.
If MoCo thinks a feature would be valuable for users, they can put it to
the test. Put it in and make it easy for users to turn it off. Make it
easier for the average user to find and enable extensions in their app.
Gather statistics on the choices users are making and thus it will be
clear whether a feature is useful enough to justify the change it
brings, or if users prefer the app without it.
- ray
Peter Potamus the Purple Hippo
> Finding myself outside the core of MoCo developers, I have observed that
> if I want to suggest a feature, the way to do it is to create an
> extension that is the feature. Thus, there are a couple of things I have
> asked for or suggested and I have stopped suggesting them or asking for
> them. At MoCo, talk is cheap, and code talks, even preliminary and
> badly-written code. So, I can do these features as extensions and then
> nobody can say they cannot be done, and we can all see how they work in
> the app.
thats all fine and dandy for you, but not everyone knows how
to write code.
Ray Kiddy
>> Finding myself outside the core of MoCo developers, I have observed
>> that if I want to suggest a feature, the way to do it is to create an
>> extension that is the feature. Thus, there are a couple of things I
>> have asked for or suggested and I have stopped suggesting them or
>> asking for them. At MoCo, talk is cheap, and code talks, even
>> preliminary and badly-written code. So, I can do these features as
>> extensions and then nobody can say they cannot be done, and we can all
>> see how they work in the app.
>
> thats all fine and dandy for you, but not everyone knows how to write code.
>
I am sorry to hear that. You'll probably have a harder time getting
people at MoCo to listen to you than I do. MoCo is, after all, mostly
run by very technically competent engineers. They seem to do much better
talking to other technically competent engineers.
And as I said, this might be a way to re-cast the debate. It is not the
only way.
Also, implicit in the question "who speaks for the majority of the user
base?" is the question "does MoCo speak for the user base?". That is the
question I tried to suggest another answer for.
- ray
Tony Mechelynck
A variation on this last question could be: "Do users who are very technically
competent engineers speak for the user base?" I would venture that the huge
majority of users of Mozilla products couldn't write an extension or a patch
if their life depended on it. Their opinion and their preferences ought
nevertheless not to be ignored.
Best regards,
Tony.
--
Speak softly and own a big, mean Doberman.
-- Dave Millman
Jay Garcia
--- Original Message ---
That "user base", the non-technicals, is what makes or breaks an
application, not the engineer(s) so to speak. If the engineer(s) doesn't
listen to that "user base" then the app won't make it.
The "Report Bug" button in NN 9 is a huge success. Can't say what we're
including in NN 9.0b4 but the user has spoken and we have "listened"!! ;-)
timeless
> One suggestion: only get concerned about a proposed change if the module
> owner shows some signs of making it. That step alone might obviate a
> great deal of stress :-)
Totally useless. The module owner is the one asking for help.
timeless
> Unless I'm misreading the code, the survey we direct users to when
> uninstalling on Windows is still in place, and the stats are athttps://survey.mozilla.com/
Perhaps we should have the ability to offer users an upgrade survey.
It's the closest complement I can think of to an uninstall survey.
Most users should upgrade at least annually, so the sample size should
be sufficient for us not to ask everyone.
timeless
> they got one, they loved it. The user doesn't always (some would say
> doesn't often) know what they want.
On Sep 3, 2:19 am, Nelson B <NOnelsonS...@NObolyardSPAM.com> wrote:
> Has Sony ever removed basic features from Walkman?
The closest thing I could think of was the Sony MiniDisc Walkman. I'm
having trouble figuring out if they've removed it.
It's actually a very interesting question in general. I've been
listening to a discussion about devices recently, and there was talk
something along the lines of could we have built a tablet device that
didn't include notes/pdf reader/images/... instead of what we (nokia)
shipped with the 770.
Mozilla certainly has removed features (if only gopher) and support
(ssl2, thanks).
The other two companies to look at are Nintendo and Apple. They
reinvent themselves and their product lines, probably better than Sony
(Nintendo Wii trounces PlayStation 3; Apple iPod trounces Sony
Walkman).
Technically the Nintendo Wiimote has fewer buttons than the classic
controller, so technically Nintendo removed features (buttons) as part
of an upgrade. (There's a compatibility module available in the form
of the classic controller, but the question is whether vendors have
removed features).
As for iPods. Apple dropped the Firewire port as it introduced newer
iPods.
As a consolation feature drop, I offer that the iPod shuffle dropped
the screen and click wheel. Arguably that's probably a stretch.
> There have recently been some feature changes and feature removals because
> some newcomers have argued that the old features were useless, even though
> some of us have used them for a decade or more now. Right now this seems
> capricious. I think our long time users deserve better feature continuity.
> But until we have a way of knowing what our users want, the discussions
> will continue to be be one set of biases vs. another.
There are a huge number of features I'm trying to remove from the
browser we're shipping w/ the n800. We'll see how well I do (it'll
take at least a year for me to try to remove them).
I suppose an amusing one, our browser doesn't have any proxy settings
ui, it relies on the platform, which doesn't have a ui for setting up
a SOCKS server. So essentially the 770 and n800 browser "removed" the
SOCKS feature from Opera/Mozilla (because both had it).
Selected features that haven't been removed from the 770/n800 browser
UI:
Memory cache (kB): Off -- like users really want to do this or would
know how to configure this.
Enable automatic redirection: [x] -- like users really would ever want
to turn this off.
Things which I hope to remove soon:
Enable SSL 2: [ ] -- unfortunately this really does need to stick
around for a bit.
Tony Mechelynck
Hmm... what about "nightly tester" people, who upgrade daily (be it to the
next trunk nightly or to the next branch nightly)? I hope some method will be
found to avoid presenting them every day with a 20Q session (maybe with a
timestamp in prefs.js, and avoid triggering the survey again within some
interval tbd, let's say a month or so?).
Best regards,
Tony.
--
Although written many years ago, Lady Chatterley's Lover has just been
reissued by the Grove Press, and this pictorial account of the
day-to-day life of an English gamekeeper is full of considerable
interest to outdoor minded readers, as it contains many passages on
pheasant-raising, the apprehending of poachers, ways to control vermin,
and other chores and duties of the professional gamekeeper.
Unfortunately, one is obliged to wade through many pages of extraneous
material in order to discover and savour those sidelights on the
management of a midland shooting estate, and in this reviewer's opinion
the book cannot take the place of J. R. Miller's "Practical
Gamekeeping."
-- Ed Zern, "Field and Stream" (Nov. 1959)
Chris Ilias
I don't think surveys get info from the people we want info from. How
community driven user studies? Put together a survey for community
members to fill out, studying the *other* Firefox users. For instance,
I could watch a family member use Firefox, and you provide me with the
info I want me to look for (eg. do they use the keyboard or mouse, how
do they open tabs, anything they're having trouble figuring out or
finding, what did they expect to happen that did not happen, etc.)
The best example of this kind of study (to me) was the decision to put
the close tab button on each tab, which was the result of a user study
at Google
<http://weblogs.mozillazine.org/ben/archives/009210.html>.
On another note, on Windows, there is no "Uninstall Firefox" item in the
Firefox program folder in the start menu; so in order to reach the
uninstaller (and thus the survey), the user has to know to use the
Windows Add/Remove Programs control panel.
--
Chris Ilias <http://ilias.ca>
List-owner: support-firefox, support-thunderbird, test-multimedia
Ray Kiddy
And actually, I was suggesting that if it was made much easier for any
user to turn on and off extensions, then a 'community' of extensions
could build up. Developers want, by and large, the same thing that
regular people want. Because developers are also regular people.
If extensions are easier to identify, find, enable and disable, then the
users could "vote" for a feature by enabling it and vote against it by
disabling it.
If all features were packaged as extensions, developers could see things
like:
"Hmm. We put 12 new features in Firefox 4.1.2 and 90% of all users
disabled all but two of them in order to cut down on perceived
crashiness...."
This is the kind of information that could actually be used by developers.
- ray
Tony Mechelynck
[...]
> I don't think surveys get info from the people we want info from. How
> community driven user studies? Put together a survey for community
> members to fill out, studying the *other* Firefox users. For instance,
> I could watch a family member use Firefox, and you provide me with the
> info I want me to look for (eg. do they use the keyboard or mouse, how
> do they open tabs, anything they're having trouble figuring out or
> finding, what did they expect to happen that did not happen, etc.)
> The best example of this kind of study (to me) was the decision to put
> the close tab button on each tab, which was the result of a user study
> at Google
> <http://weblogs.mozillazine.org/ben/archives/009210.html>.
I still wonder why the corresponding pref (closebutton on all tabs / on the
current tab / at the end of the tab bar / omitted) didn't get a decent
rolldown or radiobuttonset in the Options UI.
Best regards,
Tony.
--
No violence, gentlemen -- no violence, I beg of you! Consider
the furniture!
-- Sherlock Holmes
Peter Potamus the Purple Hippo
you mean a UI like SM has!
Gervase Markham
> So, what would happen if all Firefox features were added this way,
> including those done from inside MoCo itself?
I think quite a few are. Larry the Passport Guy, for example, started
life as an extension (and I think he still is).
Gerv
Gervase Markham
> A variation on this last question could be: "Do users who are very
> technically competent engineers speak for the user base?"
Some do, some don't. Standing in the shoes of different types of user is
a skill, just like coding, UI design, or product management. Not
everyone has it.
But both of these positions are equally wrong:
- All technically competent engineers have this skill
- No technically competent engineers have this skill
Gerv