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