Closed Bug 409315 Opened 17 years ago Closed 16 years ago

Distinguish between logged in end users and contributors

Categories

(support.mozilla.org :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: jason.barnabe, Assigned: jason.barnabe)

References

Details

(Whiteboard: sumo_only)

Attachments

(4 files, 4 obsolete files)

Previously, we were going on the assumption that only contributors logged in. Because of this assumption, many features meant for contributors only show when you're logged in.

Now that the forums are up, end users have a reason to create accounts. We need to have a way to differentiate between end users and contributors.

I suggest we create a Contributor group and let people assign themselves to it. This could be chosen at registration time and changed later via the user control panel.

Changing the various features to respond to a Contributor user rather than a Regular user will be handled in separate bugs.
Blocks: 409316
Blocks: 409318
Blocks: 409319
Depends on: 413585
Blocks: 416591
Attached patch patch (obsolete) — Splinter Review
Functional changes from base tiki:

-"Highlight group" setting determines the default group on registration
-Groups are displayed like "Name - Description" on registration instead of one or the other
-Choosing a group from User Preferences screen
-User Preferences does a redirect back to GET on submit
Assignee: nobody → jason_barnabe
Status: NEW → ASSIGNED
Attachment #303756 - Flags: review?(nelson)
Attached image registration screenshot (obsolete) —
This is what registration will look like after the patch. The user is presented with radio buttons to choose what group they want to be in. The choice of groups, the display text, and the default group are all configurable.
Attached image preferences screen for a normal user (obsolete) —
This is what a normal user will see on the preferences screen. The first choice's text is not configurable.
Attached image preferences screen for a contributor (obsolete) —
What someone who has chosen to be a contributor will see.
Feedback on the design on this feature and on the text presented would be appreciated.
What features do you want to disable for non-contributers that login?

My first reaction on seeing "Keep current group(s) - Registered" was wondering what groups other than "Registered" that I was in, and how to change that. My second reaction was to look for something I could click on to tell me what a group was, what side effects did signing up have (when you sign up for a yahoo group it defaults to sending you a email every time something is posted), and how to decide which ones I should be in.

If you're not going to have other groups for a while it would be simpler to just have buttons to select which of the two existing groups you want to be in for now (and enhance it later on), but that begs the question of how you can be in the contributer group without also being in the registered group.

It would help to know what other groups you envision, and whether you expect most people to join other groups. If its mainly just contributers and registered, it would be much simpler to just have a checkbox that enabled whatever features are only useful for contributers and skip the whole concept of groups and contributers. 



(In reply to comment #6)
> What features do you want to disable for non-contributers that login?

Take a look at the bugs that this one blocks, to start. After those, there are other things possible in the future like seeing poll results, marking solutions in threads as needing KB documentation, etc.

> My first reaction on seeing "Keep current group(s) - Registered" was wondering
> what groups other than "Registered" that I was in, and how to change that. My
> second reaction was to look for something I could click on to tell me what a
> group was, what side effects did signing up have (when you sign up for a yahoo
> group it defaults to sending you a email every time something is posted), and
> how to decide which ones I should be in.

Would including the description there like there is on the registration screen be helpful?

> If you're not going to have other groups for a while it would be simpler to
> just have buttons to select which of the two existing groups you want to be in
> for now (and enhance it later on), but that begs the question of how you can be
> in the contributer group without also being in the registered group.

All contributors are also in the registered group. I suppose the UI doesn't make that clear, but then again it's an implementation detail that shouldn't matter to the user.

> It would help to know what other groups you envision, and whether you expect
> most people to join other groups. If its mainly just contributers and
> registered, it would be much simpler to just have a checkbox that enabled
> whatever features are only useful for contributers and skip the whole concept
> of groups and contributers. 

There won't be any more groups to *choose from* in the immediate future, but there are other groups that you can get assigned to you, like Forum Moderators, Approvers, and Localizers.

"Most people" will be end users who should just leave it at the default.

It may be that this solution is a little too general and should be more specific to our situation, for example just having a checkbox as you suggest.
Attachment #303757 - Flags: review+
Attachment 303757 [details] uses clear wording that is easy to understand:

Contributors - People looking to help others
Registered - People looking for help

The other two attachments uses a much more confusing text:

Keep current group(s) - Registered
Contributors - People looking to help others

Why can't the text be the same as in attachment 303757 [details] in the preferences section as well? Isn't that clear enough?
I made it so it took into account people with other extra privileges, like moderators and approvers. They would get

Keep current group(s) - Approvers, Contributors, Registered
Contributors - People looking to help others
Register - People looking for help

I suppose I could just leave out the option for those people since they won't be changing it, and then using the same UI as on the register screen.
I vaguely recall some discussion about this long ago; but right now, I see users registering as a bridge be being a contributor. What's the harm in not distinguishing between the two?
(In reply to comment #10)
> What's the harm in not distinguishing between the two?

We wouldn't be able to show different UI to end users and contributors. For example, we would not be able to show contributors article comments and show end users the feedback polls. This is the big reason. Many features, current and planned, are disruptive, irrelevant, or potentially confusing to one of the groups. This is even bigger of a problem when we encourage end users to register so that they can get forum e-mail notifications (bug 398486).

We also wouldn't be able to generate some metrics, like number of active forum contributors and number of new contributors.

If you're concerned about end users not becoming contributors with this change, we can make sure that there's a fairly prominent "Want to help?" link somewhere, like in the User Tools box or on the front page.
(In reply to comment #11)
> We wouldn't be able to show different UI to end users and contributors. For
> example, we would not be able to show contributors article comments and show
> end users the feedback polls. This is the big reason. Many features, current
> and planned, are disruptive, irrelevant, or potentially confusing to one of the
> groups. This is even bigger of a problem when we encourage end users to
> register so that they can get forum e-mail notifications (bug 398486).

Why is seeing contributor comments bad for end-users who are logged in?
IMO, they should see contributor comments. We already want the 'Edit this page' link available to people not logged in.

What about when someone wants to become a contributor after registering?
(In reply to comment #12)
> Why is seeing contributor comments bad for end-users who are logged in?
> IMO, they should see contributor comments.

"show contributors article comments" as in "show comments made by end users on articles to contributors". These comments aren't helpful to other end users. I'm not sure what you're referring to by "contributor comments".

> What about when someone wants to become a contributor after registering?

They can do that with this patch from their preferences screen. Take a look at the screenshots.
(In reply to comment #13)
> (In reply to comment #12)
> > Why is seeing contributor comments bad for end-users who are logged in?
> > IMO, they should see contributor comments.
> 
> "show contributors article comments" as in "show comments made by end users on
> articles to contributors". These comments aren't helpful to other end users.
> I'm not sure what you're referring to by "contributor comments".

Having an 'Edit this page' link isn't necessarily helpful either. This is simply a way of encouraging people to contribute, similar to the way that bugzilla is open to the public.
Right, we have to weigh the benefits and the drawbacks in each case. In this case, you may want to have the link there for everyone, but have different behaviour - contributors just go directly to the edit screen, while end users go to a page that explains the system. This is bug 399871.

This bug is about giving us a way to tell the difference between the two groups. What we actually do with that knowledge will be covered in separate bugs (including the ones that this bug blocks).
Attached patch patch 2Splinter Review
A few changes since last time based on comments:

-I've dropped the actual name of the group from the options so we can have full customization of what we display. "Registered" isn't very indicative of the group's purpose, but it's hard coded into tiki.
-Drop "Keep current group" on the preferences screen. This makes it look like the registration screen. If you have anything other than "Registered" or "Contributors", it just lists your groups and doesn't let you change.
Attachment #303756 - Attachment is obsolete: true
Attachment #304651 - Flags: review?(nelson)
Attachment #303756 - Flags: review?(nelson)
Attached image registration screenshot
Attachment #303757 - Attachment is obsolete: true
Attachment #303759 - Attachment is obsolete: true
Attachment #303761 - Attachment is obsolete: true
Okay, I've had a night to sleep on this, and I still don't agree with this bug, and all of the bugs this blocks, except 'Common forum responses'.

- Most people registering are going to consider themselves users; and if they do start contributing, they are not going to think to flip a pref in their account settings. As a result, we've made their ability to contribute more difficult, by hiding content they find useful.

- The transition from user to contributor is almost never a conscious decision. It's usually a gradual process. Very often a person may consider himself a user, but answer the odd question, when he knows the answer. He may see a spelling mistake or grammar mistake in the KB, and fix that, but not consider himself a contributor. The contributions then get bigger and bigger.


I would prefer something like the folders in the Firefox Support "Menu" module, which are collapsible. But I really don't like the idea of seeing registered users in such a black and white way.
(In reply to comment #20)
> - Most people registering are going to consider themselves users; and if they
> do start contributing, they are not going to think to flip a pref in their
> account settings. As a result, we've made their ability to contribute more
> difficult, by hiding content they find useful.

Yes, they will have to do one extra thing *once* before they get the contributor tools. This "extra thing" won't be hard to find because we can explain it on the Contributor Home Page and various other places where someone might want to become a contributor, like the alternate "Edit this page" page. We could even make it a single-click button directly on the Contributor Home Page if you're that worried about it.

Contrast this problem with the problems we'd face when adding new contributor features. We'd have to make every feature in a way that isn't disruptive to end users while still being useful to contributors. We'd also have to design it in a way that end users won't accidentally do something that they shouldn't.

> - The transition from user to contributor is almost never a conscious decision.
> It's usually a gradual process. Very often a person may consider himself a
> user, but answer the odd question, when he knows the answer. He may see a
> spelling mistake or grammar mistake in the KB, and fix that, but not consider
> himself a contributor. The contributions then get bigger and bigger.

I think you're putting too much stock in the meaning of flipping the pref. Users can consider themselves whatever they want.

We can set it up so that they'll still be able to contribute. For example, they'll still be able to answer questions in the forum. Maybe they'll even be allowed to edit pages. They just won't see the ticked-out contributor interface.

> I would prefer something like the folders in the Firefox Support "Menu" module,
> which are collapsible.

If it's only about items in the sidebar, sure. But it isn't.

 But I really don't like the idea of seeing registered
> users in such a black and white way.

I don't see how you can complain about it being "black and white" when the current situation is "black".
Let's backtrack a bit. What problem does this bug fix?
The problem is that now we have to show the same UI and give the same abilities to two different groups of users (contributors and end users). This bug will make it so we can tell the difference between the two groups, allowing us to show different interfaces and give different abilities to each group.
(In reply to comment #23)
> The problem is that now we have to show the same UI and give the same abilities
> to two different groups of users (contributors and end users).

I don't see that as a problem, because there's a big grey area between being a user and a contributor.
It's a matter of too much information that doesn't apply.

Simply to be able to show the two groups different home pages, this is worth it in my book. We can make the contributor homepage contain the latest changes modules, and have links to administrative articles that would be of use, like the how to help pages for all 3 portions of SUMO.  Or anything else we want, like the number of unanswered threads, the number of out of sync articles. Same with the page for registered users, it can have more prominent links back to the forums, alert the user if there have been replies to threads they've posted in, changes to pages they're watching etc.

Then come all the different menus on the side which can be very confusing for end users as well, and would let us expose other things for contributors that we wouldn't want to for regular users.

I think we need to remember how *few* of the people who sign up for the forums are going to actually want to contribute.  Even the menus on the side are enough to confuse. We also don't want people who don't understand what's going on to start replying to the feedback on the articles.

If we do it right, flipping the pref to become a contributor will be simple. Maybe even offered to regular users whenever they edit a page.

I don't see a grey area between users and contributors.  Users are looking for help for themselves and don't know what's there.  Contributors are at the least there to get info for others, and might even only be there to submit and approve edits.
Okay, although I disagree with much of that, I seem to be the only one against dividing members into users and contributors; so I'll concede. :-)

Given that users don't have to resister to view articles or ask questions, I think someone who is willing to go through the process of registering is prime candidate for a contributor.

I still don't think people are going to manually switch the pref; so how about it be automatically switched to contributor if the member makes an edit to an article, or answers a question?
(In reply to comment #26)
> Given that users don't have to resister to view articles or ask questions, I
> think someone who is willing to go through the process of registering is prime
> candidate for a contributor.

Bug 398486.

> I still don't think people are going to manually switch the pref; so how about
> it be automatically switched to contributor if the member makes an edit to an
> article, or answers a question?

You could do it for editing an article, I suppose, but there's no way for tiki to tell whether a user posting in the forum is actually answering a question, or replying in their own thread, or asking a follow-up question on someone else's thread, etc.
I like Chris' idea of automatically (or by asking) changing the setting to contributor if you edit an article. Might also be worth asking this same question after x number of logins. Chris, feel free to file bugs for this, but let's hold off milestone targeting for now.
Are there any other comments on the updated UI?
The updated UI looks great, and I agree with the need to distinguish between registered users who just want to avoid captchas and easily get a notification for answered questions, and real contributors. The UI when loggin in can be daunting if you just want the former, and the ability to get statistics on active contributors is an important plus for the latter group.

In short, let's check this in.
Blocks: 419914
(In reply to comment #28)
> I like Chris' idea of automatically (or by asking) changing the setting to
> contributor if you edit an article. Might also be worth asking this same
> question after x number of logins. Chris, feel free to file bugs for this, but
> let's hold off milestone targeting for now.

Done. <https://bugzilla.mozilla.org/show_bug.cgi?id=419914>
Depends on: 424443
Depends on: 424445
Comment on attachment 304651 [details] [diff] [review]
patch 2

patch looks good but waiting upon blocking bugs
Attachment #304651 - Flags: review?(nelson) → review+
Target Milestone: --- → 0.6
How come this is up on the live server if we're still waiting for those blockers?

http://support.mozilla.com/tiki-register.php
I need to be able to edit the Registered group to show a proper description before we do this (bug 424445). I've reconfigured Tiki to not prompt for a group until we sort this out.
re comment #33, yes, it is just configuration, thanks for the action in #34.

this is now on support-stage as quickfix for bug 424445 is there as well.
Looks good on stage.

Filed bug 424898 on a follow up issue caused by this fix.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Live and configured!
Status: RESOLVED → VERIFIED
Whiteboard: sumo_only
Blocks: 510622
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: