I have started on the "Join and Leave Log" task (
https://projects.iopen.net/groupserver/ticket/341
), which requires a Leave page:
"It should say if the member will be able to join
the group again after leaving, and suggest some
delivery setting changes."
Michael and I discussed whether to include the ability to change delivery
settings on the leave page itself, or to link to the existing group Email
Settings page. We concluded that it would be kinder to the user to include the
form on the same page, and Michael made the excellent suggestion that the
potential for harm arising from having two buttons for quite different actions
could be avoided by including the "Leave" option in the same form.
Attached is a mock-up of the page. I have attempted to cover both the delivery
settings and membership options by labelling the page "Change Subscription to
[Group Name]" and the button "Change."
The bold text in the first paragraph will change according to the privacy level
of the group. In the attached example, "Test Group" is a secret group. For a
private group, I intend to have "cannot rejoin without applying", and for a
public group, "can rejoin at any time."
Suggestions on wording and so on welcome.
The
following file was added to this topic:
Thanks for working on the Join and Leave Log, Alice. It will be excellent to
get this out of the way.
My first suggestion is a minor one: have leaving as the default action. Getting
out of the way would be the best idea when people want to leave. The new page
is enough of a barrier to slow the member down.
For the joining-text I suggest a couple of changes. Mostly it removes the
negatives.
*Secret*
{The group administrator} must be invite you to
rejoin the group.
*Private*
You can apply to rejoin the group at any time.
*Public*
You can rejoin at any time.
If we do drop the idea of having one admin as "go to" person, then this:
> *Secret* {The group administrator} must be invite you to rejoin the
> group.
would not float. We'd have to say "the group administrator" and link to
a list.
On 08/07/10 10:18, Dan Randow wrote:
> If we do drop the idea of having one admin as "go to" person, then this:
> ...
> would not float. We'd have to say "the group administrator" and link to
> a list.
The plan is to have an adapter that figures out all the group admins for
a group. We can use that in combination with a variant of our
comma_comma_and utility (comma_comma_or?) to display the list of admins
directly.
After a good chat with Dan and Michael today, we came up with the
following improvements to the initial mock-up:
1. Introduce the options with more concise text: "Want less email?"
2. Reverse the order in which the options are displayed, so that
they are, from top to bottom, in order of least email to most.
3. Ensure that "Leave" is the default option, as Michael recommended.
This led me to wonder if there's any point in including "One email per
post" as an option at all. I can't think of a reason why someone who was
thinking of leaving a group would instead *increase* the amount of email
they got from the group, so I have left it off.
We also discussed the rejoining text, and decided that it required
further thought. After more pondering, I've concluded that it is the
timing of the text that was causing the difficulties — it comes after
the user has said they want to leave the group, but before that action
has been taken. In that position, we need to communicate that:
IF the leave action is taken (a hypothetical situation)
AND the user later wishes to rejoin (another hypothetical situation)
THEN certain other actions will need to be taken
It's just too awkward and quickly becomes too wordy. I think that the
more appropriate place is as part of the label for the "Leave" option.
There, we can at least get rid of the first IF above. And as a bonus,
the page becomes even shorter. My suggestions for the three labels are:
Secret
Leave {the group} (to rejoin, you must be invited by {the group
administrator})
Private
Leave {the group} (to rejoin, you can apply to {the group
administrator} at any time)
Public
Leave {the group} (you can rejoin at any time)
Latest mock-up attached. Again, suggestions for further refinements welcome.
The
following file was added to this topic:
You are right, Alice, the information on how to join the group was provided at
the wrong time. It is *far* better next to the leave option: the page is less
wordy and less awkward. You are also right that the "One email per post" option
should be removed.
I like the mockup that you posted
<http://groupserver.org/r/img/7966-2010-07-08T142944Z>. I think the proposed
Leave page will do its job very well.
Alice,
> The plan is to have an adapter that figures out all the group admins
> for a group. We can use that in combination with a variant of our
> comma_comma_and utility (comma_comma_or?) to display the list of
> admins directly.
Perfect.
> I can't think of a reason why someone
> who was thinking of leaving a group would instead *increase* the
> amount of email they got from the group, so I have left it off.
Doh! Well spotted.
> the more appropriate place is as part of the label for the "Leave"
> option. There, we can at least get rid of the first IF above. And as
> a bonus, the page becomes even shorter.
Excellent. Love it.
This will be a good change.
We have lots of folks who think the only way to stop the e-mail is to
unsubscribe completely.
You might consider text at top like:
"Please confirm that you seek to leave (unsubscribe) XYZ group. Or select the
delivery option to participate with less email."
I am thinking of the person who posts a few times each year and subs/unsubs
whenever they want to post.
Text might not be needed or a [?] explaining that under these settings they can
still post which is why they might want to remain a member.
Mixed thoughts.
Hi Alice,
I have the code in place for auditing the joining. The events are generated by
the "gs.group.member.join" subsystem, and the event-code is "1" (JOIN_GROUP).
Currently I have only tied the Initial Invitation Response page to the new join
mechanism <http://groupserver.org/r/topic/4lVwgvrfz0BD2dL5Pwhbo3>. I will now
go through and connect the other two ways of joining a group up to the new
audit code (existing user join, and existing user invitation).
The Join & Leave Log is now going. I've attached two screenshots. One is
a sample admin view, where the admin has opened the disclosure to view
more detailed joining and leaving information for one month. (If there
is no joining or leaving activity in one month, then no disclosure is
shown). If a member has been *removed* from the group, rather than left
voluntarily, then that information is also displayed.
In the non-admin view, there are no disclosures, only the plain-text status.
I'm now toying with the idea of changing the list styling from bullet
points to pluses for join events and minuses for leave events.
Any comments?
The
following files were added to this topic:
Nice work Alice, I'm sure the admins are going to love it :) Gives us
plenty of scope to add eye candy charts too.
--Richard
Nice work, Alice! I agree that + next to people who have joined and a - next to
members who have left would be a great addition. On a technical level the
easiest way to do that is to turn *off* the bullets in CSS
list:style: none;
and add the + and - in the HTML.
On Thu, Aug 5, 2010 at 11:54 AM, Michael JasonSmith
<email obscured>> wrote:
> Nice work, Alice! I agree that + next to people who have joined and a - next
to members who have left would be a great addition. On a technical level the
easiest way to do that is to turn *off* the bullets in CSS
> list:style: none;
> and add the + and - in the HTML.
Possibly, but why not give each list a different name, and render the
+ or - as the bullet marker from css? That would help to maintain good
layout on the page ...
Hi Jim,
I thought of using + and - as bullet items, and getting the template to
set the right class. However, there is no way to get a + character as a
bullet
<http://www.w3.org/TR/CSS2/generate.html#propdef-list-style-type>. I
even had a look at the CSS3 spec, to see if there was a chance that
generic glyph support had made it in, but alas
<http://www.w3.org/TR/css3-lists/#glyphs>.
We could use an image as the bullet. We would need to add both a + and -
image to the sprites that are shipped with GroupServer, then make six
variants for the different colour schemes our clients use, and update
all the CSS files… or we can say bugger it and just write + and - into
the HTML ☺
Hi Jim:
I just had a discussion with Mike about this, because I thought he
didn't quite answer your question :)
Basically, the choice is between having a list that shows joins/leaves
as a list of events, or as two lists showing joins and leaves. My
argument was that people often want to know who left, so they can see if
they can get them back. It's of passing interest that someone joined.
However, I like Mike's argument better -- that it's more interesting to
know that someone joined, and then they left a few minutes later. Or
that they only lasted two weeks. I think the best way to show that is in
a time ordered list of events.
Mike also proposes hooking them up to a JS filter so you can see joins,
leaves, or both.
Either way I think the information is going to be a lot more useful than
the absence of information that we had previously :)
I propose a minor change to Alice's excellent join and leave log. At the
top of the page add three tabs
┌─────┐ ┌──────┐ ┌───────┐
│ All │ │ Join │ │ Leave │
─┘ └─┘ └─┘ └─
* If All is selected some JavaScript is triggered to show all
events. This is the default state for the page.
* If Join is selected some JavaScript is triggered to hide all
leave events and show all join events.
* If Leave is selected some JavaScript is triggered to hide all
join events and show all leave events.
On Thu, Aug 5, 2010 at 1:43 PM, Richard Waid <email obscured>> wrote:
> I just had a discussion with Mike about this, because I thought he
> didn't quite answer your question :)
Oh, I thought he had, because I was only asking about using CSS to
provide the + or -, which he explained well. Now, although I'd been
thinking of styling the lists themselves, I would have hoped that CSS
allowed styling the bullet of individual list items. But I'm not CSS-y
enough to know, and given the answer to using random glyphs as bullet
points it's probably moot.
However, if its exposed another question that you thought I was
asking, I'll take the credit ... :-)
Thinking about it, you can sort of can sort-of style individual items
with css thanks to the ":before" pseudo-element
li.added:before {
content: "+ ";
font-weight: bold;
}
I would rather not do the testing for that ☺
Thanks for the comments, everyone!
I apologise for yesterday's email being so hurried — there are a couple
of things I should have mentioned:
* I did check out changing the bullets to + and -, and
obviously turned up the same information as Michael.
* After that, I did exactly what Michael suggested, and
switched off the bullets via the CSS, and added the
symbols to the text label instead, but found that they
came out unreadably small.
* Using background images seemed like a bit too much hassle
to me, too, unless enough people think that it would be
worthwhile.
I'm not convinced that background images would be *quite* as much work
as Michael suggests — I don't think different colours for different
skins are necessary — but updating the CSS files really is painful.
I had chat with Michael earlier, and I'm going to give the :before
approach a try. IE6 may pose some problems, but if it works, then I can
increase the font size on the symbols too.
Three tabs also makes truckloads of sense, so that's now on the to-do
list too.
The :before approach for the pluses and minuses works really nicely.
Preliminary checks suggest that IE6-7 won't get the benefit of these, but as no
functionality actually breaks, I'm not going to worry about it.
Tabs are... a little trickier. They're going, but the CSS styling is a slight
problem. The Join and Leave log will have as many tabmenus as there are months
with joining and leaving activity. However, our current CSS for tabmenus
assumes that there will only be one per page. This means that to make these
tabmenus appear correctly under every skin, I'm going to have give them a class
of tabmenu, and then edit the global CSS and the CSS for each site to apply the
right styling — just the sort of really painful change I was hoping to avoid.
I've attached a screenshot of the page as it currently stands. Note that the
tab styling is completely wrong, colour-wise. There are layout issues too,
which I will tackle once I've done the big change.
The
following file was added to this topic:
On Fri, Aug 6, 2010 at 2:00 AM, Alice Murphy <email obscured>> wrote:
> I've attached a screenshot of the page as it currently stands. Note that the
tab styling is completely wrong, colour-wise. There are layout issues too,
which I will tackle once I've done the big change.
For July 2010, that image claims "1 left, 3 joined" but I could only
see the joiners ... is that just a feature of the screenshot?
On 08/05/2010 10:37 PM, Jim Cheetham wrote:
> For July 2010, that image claims "1 left, 3 joined" but I could only
> see the joiners ... is that just a feature of the screenshot?
That one was because the Join tab was active :)
Great work, Alice!
I think that one tab-menu for the *entire* log would be fine ☺
On 08/06/2010 05:16 AM, Michael JasonSmith wrote:
> I think that one tab-menu for the *entire* log would be fine ☺
How would that work, when the log is split up by disclosures, by month?
I was finding the order of the statement confusing, so I have changed it
from, e.g.,
2 members: 1 left, 3 joined
to
2 members: 3 joined, 1 left
[The following post contains a many Unicode characters. I apologise to
those that see the missing-character character.]
Hi Alice,
I am supposing that the administrator is more interested in comparing
all joins than comparing the join-events in one month with the
leave-events in another.
What I have in mind is as follows. Initially (when the page first loads)
all the joins and leaves are shown when a disclosure is opened.
┌───────┐ ┌────────┐ ┌─────────┐
│ *All* │ │ Join │ │ Leave │
─┘ └─┘ └─┘ └─
*August* *2010*
▶ 1 member: 0 joined, 1 left
*July* *2010*
▼ 2 members: 3 joined, 1 left
+ Test Member 01 joined (July 20, 08:55 UTC)
- Test Admin 01 left (July 15, 09:46 UTC)
+ Test Member 03 joined (July 10, 16:05 UTC)
+ Test Member 04 joined (July 5, 07:23 UTC)
If the administrator then selects the Join tab, for example, then only
the join-events are shown.
┌───────┐ ┌────────┐ ┌─────────┐
│ All │ │ *Join* │ │ Leave │
─┘ └─┘ └─┘ └─
*August* *2010*
▶ 1 member: 0 joined, 1 left
*July* *2010*
▼ 2 members: 3 joined, 1 left
+ Test Member 01 joined (July 20, 08:55 UTC)
+ Test Member 03 joined (July 10, 16:05 UTC)
+ Test Member 04 joined (July 5, 07:23 UTC)
Does the above proposal make sense?
Thanks to the underground Berlin electronica scene Alice and I had a chat about
the Join and Leave log this morning¹. I thought I better write down the
conclusion of the chat.
The Join and Leave Log has three use cases for the administrator: getting the
pulse, seeing changes, and comparing months.
For getting the pulse of the group the join and leave log shows how many people
joined and left each month. I suspect that this will be the most common
use-case of the log, so by default the disclosures hide all the detail.²
The second use case involves the administrator drilling down into one month. By
opening a disclosure the administrator will be able to see if all the joins
happened on one or two days, or occurred throughout the month with a few leaves
scattered throughout.
Finally, the tabs allow the administrator to reduce the amount of information
that is shown so it is easier to compare two months. Alice suggested that the
summary information for leaving is dropped off if Join is selected, and vice
versa. I agree that this would be useful.
I hope that the design of the UI allows each of these use cases to be
discovered as needed. I should add that for *most* groups *most* of the time
the join and leave log will not be very useful. Most GroupServer groups
(including GroupServer Development one) have a small and stable membership.
*Footnotes*
1. Our chat was this morning in both Europe and
Australia, which is quite an achievement.
2. Sparklines would be an excellent way of showing
the pulse, but the effort required is a bit much
for Gelato or Spaghettieis
<https://projects.iopen.net/groupserver/ticket/315>
Since Michael and I had our excellent chat, I've implemented the single
tab-menu, and I'm rather pleased with how it's looking. I've attached
three screenshots showing the view when each of the three tabs is
selected. Comments?
The
following files were added to this topic:
I love the screenshots of the Join and Leave Log that you posted, Alice. There
is nothing I can see that needs fixing. You even managed to get the comma to
appear only when All is selected!
Hi Alice,
I tired the join and leave log out with my local install, and it looks great!
Below are three screenshots what the log looks like for a random group of mine.
The
following files were added to this topic:
Thanks for your comments and your screenshots, Michael! It does look
good with a bigger group!
> You even managed to get the comma to appear only when All is selected!
I must confess that I was rather proud of that one :)
All join and leave events are now audited, so the Join & Leave Log can start to
become useful. My next question is, where should it be linked from?
Michael has suggested the following pages, which all make sense to me:
* Members
* Member Directory
* Manage Members
I think the Posting Statistics page — or generic Statistics page/tab, if we
head that way (http://groupserver.org/r/topic/79GNtuuM4n2ka3vKcESe0n) — could
be good, too.
Any other suggestions or comments?
Yes, the Join and Leave Log page should be linked from the Group Statistics
page. Good idea, Alice ☺
I have updated the Members pages to link to the Join & Leave Log. The
updates to the Members Directory and the Manage Members page are
scheduled for deployment on Tuesday 28 September.
