Posts in GroupServer Development
As well as the Respond to Invitations page, I have the * Invite a User to Join Some Groups, and * Invite Site Members to Join a Group sending out invitations, and the invitations correctly redirecting the user to the Respond to Invitations page. The last three things to do are add some restrictions, clean up the Invite Site Members page, and hook Add New Member into the new system. The only restriction that I will add, at this stage, is to limit the number of invitations to a single group that can be sent to a single user without that user responding. The other restrictions that I mentioned earlier http://groupserver.org/r/post/2CPcvdSFQrROAeK7XBUvgG can be implemented, but I will not look at them until I need to. The Invite Site Members page has no supporting text at the moment. I would also like it if I could link to the users' profiles better. It should not take me too long! Finally, I the Add a New Member and Add New Members in Bulk pages need to be hooked up to the new invitation system. (That was, in many ways, the entire point of the exercise!) Once those tasks are done, I will release the code on OGN, and build a new tar-ball of GroupServer.
I have finished work on the initial Respond to Invitations page. The screenshot
below shows it in the OnlineGroups.Net livery. The main change from the
prototype is that every invitation says who created it, as I realised that a
user could have invitations from many different administrators. The Change
Group Email Settings section is also missing, but that is a nice-to-have
feature ☺
I am writing the interfaces backwards: from the end-user pages to the
administrator pages. The next page that I will write is the page to allow an
administrator to invite a single user to join multiple groups. It is very
useful for testing, so I would like it early. After that I will rewrite the
page that allows an administrator to invite multiple people to join a single
group.
The following file was added to this topic.
- Name: Screenshot.png
- Type: image/png
- Size: 53.25KB
Thanks for your comments, Steve. I am encourage to see that we are all
on the same page ☺ We have been thinking of the mechanism for preventing
people for being bombarded with invitations, as this is a privacy
breach. (Technically it is an invasion of privacy — but arguing privacy
semantics is dull at the best of times!) Exactly how the restrictions
will be presented is not something that I am very clear on, so I could
do with some guidance on that.
The way invitations-table is recording the invitation is with the
following fields:
* invitation_id
* user_id
* inviting_user_id
* site_id
* group_id
* invitation_date
* response_date
* accepted
When the invitation is sent out, we will write the first six fields.
When a user responds to the invitation we will write out the last two
fields: the date of the response, and if the user accepted the response
or not. This scheme allows us to restrict
* How many invitations a user can have
* How many invitations an administrator can send,
* How many invitations for a group can be sent out
* How many invitations for a *site* can be sent
* How long before an invitation can be re-sent if a user has not
responded
* How long before an invitation can be re-sent if the user has
declined.
By never deleting the invitations, I can implement all these
restrictions. In addition, I can also present a log of all invitations:
pending and past. (The log is what I am working on now.)
What the actual restrictions should be is something I will leave to the
configuration options. As you say, Steve, sites like the forums on
e-democracy.org will have quite different requirements to
OnlineGroups.Net.
The user not responding to an invitation does not tell you why the user
has not responded. We will need to work the bounce-detection into the
invitation subsystem to be able to give you any meaningful data.
From an hosts perspective it would be useful if you could put in a list of
e-mail addresses (one per line) or something.
However, for at least your OGN site I'd have a cap on the number of people you
can invite this way on any one day.
Also, I'd be interested in having an automatic reminder after one week or ten
days, "you didn't respond, if you don't with the next 2 days your invitation
will expire."
Also, when E-Democracy.Org launches a new forum we encourage people to recruit
elected officials quite heavily. Being able to quickly see who joined, who
declined, and who has not responded would be very useful. Also keeping a
listing
of expired invites would help reduce repeat invitations (or at least
unintentional ones).
One concern I have is folks inviting people indiscriminately. Upon declining
...
"Thank you for your response. If you would like to share a comment on why you
are declining, please share it here/e-mail X" This might create a feedback
loop
that would educate those using this feature.
Thanks,
Steven Clift
On Thu, 2008-06-26 at 14:06 +1200, Michael JasonSmith wrote:
> I just realised that when you subscribe to a group using email you are
effectively responding to your own invitation:
> 1. Send subscribe message,
> 2. GroupServer sends a confirmation message,
> 3. You respond.
> I see the potential to reduce code ☺
Definitely. I'm all for reducing code, but even better I think this
probably removes a template, and I'd definitely all for removing
anything Zope-side ...
I just realised that when you subscribe to a group using email you are
effectively responding to your own invitation:
1. Send subscribe message,
2. GroupServer sends a confirmation message,
3. You respond.
I see the potential to reduce code ☺
Really nice, Michael. Thanks for thinking this through so thoroughly.
Dan
Sorry!
The first image in my previous post should have been the one below.
The following file was added to this topic.
- Name: multiple-invite-user.png
- Type: image/png
- Size: 19.17KB
I have been working on the Group Invitations enhancement https://svn.iopen.net/projects/groupserver/ticket/277 and my design has come a long way. The system is simple in the simple case. 1. The user is invited to join a group. 2. The user receives an email message that contains links to accept or decline the invitation. 3. The user clicks on one of the links. If the user accepts the invitation, the user is taken to a message delivery settings page. 4. Success! The invitation would be generated by either the Add New User, Add New Users in Bulk, or Invite Site Members pages. I thought it would be nice to add some more features that make it easier to invite a user to multiple groups. My proposal is designed to carry out the following scenario. Jane expressed interest in joining the Knitted Frisbees Christchurch and Knitted Frisbees Announcements groups, so Kate decides to invite Jane to join the groups. Kate navigates to Jane's profile, and finds the Invitation page. She selects the Knitted Frisbees Christchurch and Knitted Frisbees Announcements groups [see the first image below] and clicks the Invite button. An email message is sent to Jane, inviting her to join the two groups. Now things become more complex. Jane has multiple invitations, which she may want to accept or decline. So, I propose an interface to support the following scenario. Jane receives an email message from Kate, inviting her to join the Knitted Frisbees Christchurch and Knitted Frisbees Announcements groups. Jane clicks on the single link in the email message and is taken to the Respond to Invitations page [see the second image below]. Jane accepts both invitations, by leaving the Accept option selected for both groups. However, Jane decides that she does not want to receive an email message whenever a post is made to Knitted Frisbees Announcements, so she changes her message delivery settings to Web only for that group. When everything is to her liking, Jane writes a short message to Kate, and clicks the Respond button. Kate receives an email message containing Jane's message and the invitations that Jane accepted and declined. The interface to accept or decline multiple invitations is complex, but only two actions are required to accept membership of multiple groups: * Click on the link in the invitation email message, and * Click on the Respond button in the Respond page. [Time for an expert user to complete the task is around 5.46s, not including page-load times and assuming no scrolling.] This leaves one hole: what should happen if the user is invited to multiple groups by multiple people? I propose showing the Respond to Invitations page, whenever any link is clicked in any invitation email message. This allows the user to quickly accept all the invitations, which will be the most common task. All of my proposed interfaces will supplement the existing Invite Site Members page [see the third image below] which I am planning to tidy. Mostly my tidy-up will involve showing a thundering-great-list of users with check boxes, instead of a "normal" list of users without check boxes. There is also a possibility of creating a page for inviting multiple site members to join multiple groups, but I will leave the visualisation of that interface as an exercise for the reader.
The following file was added to this topic.
- Name: multiple-invite-user.png
- Type: image/png
- Size: 21.81KB
The following file was added to this topic.
- Name: respond-to-invitations.png
- Type: image/png
- Size: 129.52KB
The following file was added to this topic.
- Name: multiple-invite-user.png
- Type: image/png
- Size: 21.81KB
I have made some minor tweaks to joining a group and registering an account using the Web: * I have improved the wording, * I have improved the destination page, and * I have over-determined the user (more). The most visible change is to the wording. Registration is now referred to as “sign up”. This is on Dan's suggestion, as he noticed that “sign up” was the more common term. I personally prefer the Latinate “register”, so I will still refer to the registration system, but we do not have to inflict my tastes on the rest of the World ☺ (Well, not always!) The destination page for registration has also been improved. Previously, once the user finished registration, he or she would end up on the site homepage, where a welcome message may be displayed. Now, the user will end up on the group-homepage, where a welcome message may be displayed. This is done by passing the registration system the URL of the destination page. The user is sent through the system, and ends up at the destination page once he or she has finished registering. The login system was the first to do this, thanks to a tweak by Richard, and I blatantly copied Richard's work. Finally, I have over determined the user a little more during registration, specifically with email-address verification. I was thinking about verification as Steve mentioned it http://groupserver.org/r/topic/3LBWeQCUs5UcE3jrK7lxFn Now the email-address verification page contains * The site title, * The heading “Address Verified”, and * The text “The address foo@bar.wibble has been verified. You can use this address to send messages to your groups, receive messages from groups, and log in to this site.” Substitute the address and site-name as you see fit ☺ The email-address verification page does not contain a link. Any link. No links to profiles, login, logout, sign up, or sign off; gone are group pages, groups page, groupserver, groupsense, group love, groupies, and group hug; absent are homepages, hot pages, help, hemp and hell. I toyed with putting a Close button on the page, but JavaScript can only close a page that JavaScript opens (for security) so I have to rely on the user knowing how to close a window. Sad but true.
At OnlineGroups.Net, we are aware that to achieve widespread installation, GroupServer will have to support languages other than English. Multi-lingual support is currently scheduled for GroupServer 1.2: Affogato to Start the Day, on the GroupServer development roadmap. http://groupserver.org/groupserver/roadmap/ GroupServer currently supports UTF-8 in posts and page content, which allows many character sets to be used. Here are some examples. http://demosite.onlinegroups.net/r/post/5PbAYyLUFGGbG8SFELIkZb GroupServer also currently provides the infrastructure for multi-lingual versions of static page content and forms in the interface. Thanks to the rebuilds of the page and form-rendering systems that we have completed, progress towards a multi-lingual interface no longer involves _undoing_ anything (a matter for celebration at our end). It will however require significant (but worthwhile) work, to build onto this infrastructure. The main steps required to complete the multi-language support are as follows. 1: Implement language-selection for page content and UI forms. 2: Translate UI forms. 3: Maintain translations of UI forms. Item 3 is potentially the most painful. For this reason, we would like to achieve as much stability as possible in the _english_ versions of the forms, something we aim to achieve in GroupServer 1.0: Gelato while Viewing the Sights. I should note that multi-lingual support is just one part of the internationalization (or "internationalisation") process. The timezone support that GroupServer already provides rather well, is another obvious example.
My apologies to those of you who will receive this twice, I've sent it out to the announcements group as well. This is the final announcement for the GroupServer 1.0 alpha release: Cream Freeze at the Beach. If it seems like it's been a long time since the last release... it has. The previous release was April 10th 2006. To try it out right away, you can find the buildout here: http://www.groupserver.org/downloads/ I'll give a rundown on what's changed, but first I think a bit of background on why the release has taken us so long is in order. The previous release was pretty good, but it was quite difficult to test, and had dependencies on a lot of 'through-the-web' code and templates (code stored in an object database, for those not familiar with Zope). This made it tricky to provide an upgrade path, and customisation for our different clients wasn't the easiest thing either. So we held back the release till we could get to the stage where upgrading was possible (because it's in our best interest for people to be able to upgrade to the latest version as easily as possible), and the code base allowed us to easily integrate changes from contributors. Obviously in all this time we've made other changes to the system. The one word summary of what has changed could be "Everything". Here is a longer version, in no particular order: - Much of the system data (but not yet all) is now stored in a relational database. - Still using Zope 2, but with extensive work undertaken to shift towards Zope 3 using the Five bridge. - The XML/XSLT processing framework has been all but completely removed from GroupServer. This was an interesting idea that was, for the most part, somewhat premature. - Performance has improved at least an order of magnitude in every area, and in some cases several orders of magnitude. - Many, many bugfixes and refactorings have occurred -- over 2900 revisions since the last release, including crushing some particularly annoying unicode bugs. - Chat feature -- a simple, AJAX based web chat client. - Skinnable using Zope 3 style skins - Complete rebuild of the message rendering interface, using search, AJAX for progressive rendering. - A huge number of other interface refinements, and many more management screens - Replaced the underlying javascript library. Twice. (now using jQuery: http://www.jquery.com) - Site and user-configurable timezones with support for Daylight Saving Time - Total rewrite of the registration, email verification and user profiles - The beginnings of a content management framework -- more of this will land before the beta release (based on WYMEditor: http://www.wymeditor.org -- an awesome editor) - Refined bounce handler - More extensive logging of user actions - Group participation statistics - Rewritten file library, now using search and fully integrating files with messages - Completely new search framework - Keywording of emails to produce automatic email summaries - More atom feeds - New redirection framework to allow shorter links to several types of content - Buildout based environment, making it easier to get a consistent development (and production) environment You can find more information about the direction of GroupServer here: http://www.groupserver.org/groupserver/roadmap/ As always, we are open to bribery when it comes to our roadmap -- Beer, Vodka and Money all work particularly well. At this stage we want feedback, bugfixes, feedback, documentation and feedback. Feedback would also be good. If you'd like to participate in the development process (encouraged!) we have two groups: GroupServer Development (discussion about new features, improvements to existing features, general ideas): http://www.groupserver.org/groups/development GroupServer Team (invitation or by request only, for those with commit access): http://www.groupserver.org/groups/groupserver_team This release has primarily been supported by: Advanced Business Education Limited http://www.abel.ac.nz/about/abel E-Democracy.org Forums http://forums.e-democracy.org/ Onlinegroups.net http://www.onlinegroups.net An extra special plug for OnlineGroups.net, without whom releasing GroupServer would not be possible -- Start your free hosted GroupServer public site today at http://onlinegroups.net/sites/start_a_site/
I did more than think about putting the password-setting text on the
Email Verification page, I tried it. However, it did not work very well:
it ended up being *more* confusing because it was *less* clear which
browser window you should use to complete the task of registering. While
you claim “some users will not find there way back to the tab that says,
"ah, you verified" set your password now,” I have seen no evidence to
suggest that the number of “lost” uses will be more than negligible. In
addition, we a few things in our favor
* The user (should) be very motivated to join the group.
* By the time the user has arrived at the Awaiting Verification page, he
or she has already expended considerable effort, so it not very likely
to just give up ☺
* The Awaiting Verification page clearly shows a disabled Next button.
* The title of the Awaiting Verification page is good, so the user is
able to find it quickly.
* The user may never see the Awaiting Verification page, as he or she
could have verified while changing the profile.
* Even if the user does not complete the registration, all that the user
has not done is set a password. He or she will still get messages from
the groups that were joined during registration. A password-reset will
get the user on to the site again ☺
Verifying an email address is the most confusing part of the entire
registration process. Basically, registration will always be confusing
because there is parallelism in the system. Richard and I spent a long
time with lots of graph paper trying to think of ways around the
parallelism, but we could not. You can see the problem in Step 5 of the
*first* post I made about registration
http://groupserver.org/r/post/1KOtevr6QTbZtnO4PBMuVu
You also see the problem in the state-transition diagram that I drew early
on
http://groupserver.org/r/file/705751-2007-09-26T030607Z/registration-state-transition.pdf
Thanks for the suggestion, Steve, but I think we will stick with the current
registration process ☺
On Groups.DoWire.Org I created a test account. When I clicked verify
from GMail it popped up a new tab and said:
The address <email obscured> has been verified. You can use
this address to send messages to your groups, receive messages from
groups, and log in to Democracies Online.
What I found confusing was that it already says I am logged in on top
and it didn't have a sense of connection to the other tab I had open
from the start of the process.
Since some users will not find there way back to the tab that says, "ah,
you verified" set your password now, have you though about adding the
option to set the password on the page people get from clicking verify?
Steven Clift
[Moving from the GroupServer Admin group http://groupserver.org/r/topic/78CFtuRXrc5jrgvyDQI7kG as this is about development.] Andrew, Seeing the delivery status of other group members would be interesting. I have short term plans to allow the group administrator to see the delivery settings and alter them http://groupserver.org/r/topic/6Y14i0ZsRPNAwteyggYDwH https://svn.iopen.net/projects/groupserver/ticket/251 One of the problems I have with displaying the delivery-settings is that it is easy to make a wrong inference. For example, I am a member of the (secret) OnlineGroups.Net Team, but I have email delivery turned off, as I use the Web feed to follow the group. However, I see and read every message posted to that group. I am also a member of the (public) Canterbury Issues Forum http://forums.e-democracy.org/groups/canterburyissues but I pay almost no attention to the email digests that I get from it. We have plans to make the members page better, including showing how many posts each member has made https://svn.iopen.net/projects/groupserver/ticket/272 while at the same time trying to dance around the privacy issues http://groupserver.org/r/topic/2wbglIk9Y93zuielw2WIWO
Michael JasonSmith wrote:
Hi John,
I am really glad that posting is working for you!
We did not do anything, as far as I know. I have been working on another
project, and had not had time to look into the oddities that have been
plaguing your attempts at posting using the Web interface.
Kind regards,
Michael
I posted two replies today. Neither of them were successfully processed.
Later in the day I also used a tab to access one of my groups and I
couldn't get in. The page wouldn't load.
Then I realised that those two tabs I used earlier in the day were
still "hanging" so I closed them.
Returning to the tab with the page that wouldn't open. Now it will.
Hi John,
I am really glad that posting is working for you!
We did not do anything, as far as I know. I have been working on another
project, and had not had time to look into the oddities that have been
plaguing your attempts at posting using the Web interface.
Kind regards,
Michael
Hello All
Good news.
Today Firefox is processing the posts as it should.
So did someone do something?
Or is this just fate?
Michael JasonSmith wrote:
Hi John,
Could you please confirm the following?
1. Your browser never returns (hangs) when you try and post by
* Starting a new topic, and
* Adding a post to an existing topic.
Correct.
2. Left to its own devices, your browser gets a timeout error.
No it sits inactive - nothing happens in the browser, even thought the
post has been logged at OLG and the email has been sent to that effect.
3. The browser you are using is Mozilla Firefox 2.0.0.14, running
on Microsoft Windows XP.
Yes
4. You *always* get an email message when you post.
I think so, that's never been a problem.
5. You are not running an http-proxy server on your own network.
I am running Trend Micro Internet Security. I looked to see if that was
the problem.
I turrned off ALL the Trend Micro protections, and restarted the
computer.
Opened the browser, and sent a message. Same problem.
Let me try Internet Explorer. System works on IE.
The post took about 30 seconds to process, but the screen did return to
the posting page showing the new post
I can see from our logs that my fourth point should be a lie: a duplicate-post
has been detected from you on at least one occasion, and that should not have
resulted in an error. Can you confirm this?
I may have stopped the browser and reposted, when I wasn't sure what
was happening.
> I can see from our logs that my fourth point should be a lie: a
duplicate-post
> has been detected from you on at least one occasion, and that should not have
> resulted in an error. Can you confirm this?
Sorry, the duplicate-post *should* have resulted in an error.