WebGUI - User event history - Content Management System | CMS | Open Source Content Management | Web Application Framework

patspam

Date: 12/23/2008 1:35 am · Subject: User event history · Rating: 0

I'd like to be able to keep a history of user events that are significant for a particular site, for example "Accepted Terms & Conditions", "Won the 2007 ACME code competition", "Started 12 week re-education program", "Ended 12 week re-education program", etc.. I'd then create an Account plugin so that users could view their history (a la the Shop purchase history account plugin), and also create a Flux plugin so that you can e.g. make a section of your site viewable only to users who have accepted the terms and conditions, display badges next to users who have won prizes, restrict access to users who are currently in the 12 week program, etc..

I'm interested to hear if that sort of thing would be useful to anyone besides myself and if so get some feedback on what the history mechanism should support.

The actual recording of events would need to be managed by your own custom code, for example the page that receives the Accept Terms & Conditions form post or the code that adds the user to the 12 week program.

What events are actually "significant" would obviously vary from site to site, and it would seem you'd want a way of configuring the site-specific list of recognised events (either via an API or through the Admin Console).

Patrick
http://patspam.com

Back to Top

Rate [ | ]

JT

Date: 12/23/2008 9:07 am · Subject: Re: User event history · Rating: -1

So let me get this straight. You want to create a group of groups, which organizes a group of users, to provide extra privileges for those users?

</end sarcastic reply>

Seriously though, I do think that the existing groups system will serve you well in the case. Allow me to explain.

Create a group called "Achievements".

Then create a series of other groups, one for each achievement the user has attained. Make each of these groups a member of the Achievements group.

Make the "Accepted Terms & Conditions" group allow users to add themselves to it. Then on your terms and conditions page, use: That will generate a link that will allow the user to add themselves to the terms and conditions group.

And finally, write an Account plugin that will display a list of all the groups the user is in that are members of the Achievements group.

I hope that makes sense.

Back to Top

Rate [ | ]

patspam

Date: 12/23/2008 5:31 pm · Subject: Re: User event history · Rating: -1

Yeah that's a nice approach too, it meets the same goal of Flux as allowing non-programmers to add dynamic behaviour to their site. Thanks for elaborating.

In this case though I'm more concerned with the history aspect than I am with permissions and whether flux or groups should be used.

Take the "12 week program" example from my previous email. What I didn't say is that users can enrol themselves in the program multiple times, or enrol in a program and then half-way through switch to another program. I need a history mechanism that can record all of those events (started program x, stopped program x, started program x again, switched to program y, etc..). Group membership doesn't preserve the timeline like that.

Perhaps it's too specialised to be of use to others. That's ok, I just thought it was worth putting a call out before I built it.

Patrick

On Wed, Dec 24, 2008 at 2:07 AM, <jt@plainblack.com> wrote:

JT wrote:

<begin sarcastic reply>

So let me get this straight. You want to create a group of groups, which organizes a group of users, to provide extra privileges for those users?

</end sarcastic reply>

Seriously though, I do think that the existing groups system will serve you well in the case. Allow me to explain.

Create a group called "Achievements".

Then create a series of other groups, one for each achievement the user has attained. Make each of these groups a member of the Achievements group.

Make the "Accepted Terms & Conditions" group allow users to add themselves to it. Then on your terms and conditions page, use: That will generate a link that will allow the user to add themselves to the terms and conditions group.

And finally, write an Account plugin that will display a list of all the groups the user is in that are members of the Achievements group.

I hope that makes sense.

http://www.plainblack.com/webgui/dev/discuss/user-event-history/1

--

Plain Black, makers of WebGUI
http://plainblack.com

Back to Top

Rate [ | ]

JT

Date: 12/23/2008 8:40 pm · Subject: Re: User event history · Rating: -1

Yeah, sorry, I didn't take that "preserve timeline" part away from
your original post. I'm trying to think of a generic use of that
history (outside the scope of what you're using it for). I could see
that being useful for groups, specifically for subscriptions. So a
user subscribes for a month. Then lets the subscription fade. Then
they subscribe for a year, and it expires again. It might be useful to
track the group history because you could then see what users are non-
consecutive repeat subscribers and maybe adjust the program to get
them to be consecutive subscribers. Beyond that I haven't come up with
a good example outside your use case. Perhaps others can suggest
something.

Back to Top

Rate [ | ]

perlDreamer

Date: 12/23/2008 9:36 pm · Subject: Re: User event history · Rating: -1

On Tuesday 23 December 2008 06:41:02 pm jt@plainblack.com wrote:
>
> Yeah, sorry, I didn't take that "preserve timeline" part away from
> your original post. I'm trying to think of a generic use of that
> history (outside the scope of what you're using it for). I could see
> that being useful for groups, specifically for subscriptions. So a
> user subscribes for a month. Then lets the subscription fade. Then
> they subscribe for a year, and it expires again. It might be useful to
> track the group history because you could then see what users are non-
> consecutive repeat subscribers and maybe adjust the program to get
> them to be consecutive subscribers. Beyond that I haven't come up with
> a good example outside your use case. Perhaps others can suggest
> something.

If you wanted to offer a discount for previous subscribers,
then keeping a history would make that possible:

Returning members get a 5% discount off their resubscription.

Or, if you wanted to keep track of arbitrary data that doesn't belong
in a group but could be recorded by a Macro or workflow, things like
Account creation, profile mods, taking a survey, etc.

Colin

Back to Top

Rate [ | ]

patspam

Date: 12/23/2008 10:11 pm · Subject: Re: User event history · Rating: -1

Or, if you wanted to keep track of arbitrary data that doesn't belong
in a group but could be recorded by a Macro or workflow, things like
Account creation, profile mods, taking a survey, etc.

The survey example is actually one that we're planning on using. In our case users complete a survey each time they enter and exit the 12 week program. We will use the history both to figure out when users should have access to the survey, and also to generate nice reports for researchers (who view survey responses) to flag responses as "start of program", "end of program" etc..

Since WebGUI::Crud will do most of the work for us (yay for that), I guess the only question is what fields the history table should have. In my mind it has:

a unique id
a timestamp
a userId to indicate who the event is for
an eventId corresponding to an entry in a second table of registered events
a json-encoded "extras" field where you put anything else specific to your event

The only reason I want events to be registered is so that you can find what you're looking for in the history table via sql without needing to fire up the json parser. The registered events table (also build with WebGUI::Crud) would simply have:

unique event id
description

At this level wG doesn't really care what your events are about, it just provides an API for recording them. Perhaps the event registration table should also have a json-encoded "extras" field where you can store extra event information, or maybe this should be left entirely up to you in your own code. That will probably become apparent as people start to use the API in real-world applications.

Patrick

Back to Top

Rate [ | ]

knowmad

Date: 1/9/2009 2:02 pm · Subject: Re: User event history · Rating: -1

Hey Patrick,

This rocks! Ever since doing the search presentation at the last WUC, I've been thinking of how to generate search reports. This would be the perfect mechanism to record what users are searching for, when they are searching and what results are coming back. The "extras" field would be vital in being able to record this additional level of detail about the search event.

William

Back to Top

Rate [ | ]

patspam

Date: 1/11/2009 7:31 pm · Subject: Re: User event history · Rating: -1

The WebGUI::History code is tiny (due to WebGUI::Crud), so I'm not sure if it's worth trying to get it into the core. In one sense it's just a simple pattern that wg devs are already using (so maybe I should just turn the code into a wiki article and be done with it).

Where it would become interesting was if we started making different parts of WebGUI History-aware and have them all use the single WebGUI::History mechanism rather than rolling their own, and add some History display/manipulation sugar on top of it all.

For example as you suggested a History-aware version of Search would let you turn on logging of Search results to the History. And then if we had some generic History report generation tools an admin could get search reports without writing a sinlge line of code.

It sound interesting but I'm not convinced if it's worth persuing, given that it's so easy to just roll your own history mechanism in code when the need arises.

Patrick

On Sat, Jan 10, 2009 at 7:02 AM, <william@knowmad.com> wrote:

knowmad wrote:

Hey Patrick,

This rocks! Ever since doing the search presentation at the last WUC, I've been thinking of how to generate search reports. This would be the perfect mechanism to record what users are searching for, when they are searching and what results are coming back. The "extras" field would be vital in being able to record this additional level of detail about the search event.

William

http://www.plainblack.com/webgui/dev/discuss/user-event-history/6

--

Plain Black, makers of WebGUI
http://plainblack.com

Back to Top

Rate [ | ]

knowmad

Date: 1/12/2009 12:58 pm · Subject: Re: User event history · Rating: -1

It sound interesting but I'm not convinced if it's worth persuing, given that it's so easy to just roll your own history mechanism in code when the need arises.

Hey Patrick,

Are you trying to provoke JT with that reply ? Seriously, what you're saying seems to go against the grain of his recent blog about making WebGUI Aspect-aware. I would think that this would be a nice implementation of Aspects, but then I still don't have a firm grip on how these work. Hopefully JT will step in and share his wisdom.

William

----
Knowmad Technologies
http://www.knowmad.com

Back to Top

Rate [ | ]

JT

Date: 1/12/2009 1:17 pm · Subject: Re: User event history · Rating: -1

I'm not sure how aspects apply here. Sorry William.

A user history as Patspam describes could certainly be useful if it were tied to flux, and flux were included in the core. I'm hopeful that we can do that as part of WebGUI 8, but lots of reviewing of flux has to be done first.

As far as search history goes, I don't think making that part of user history is a good idea. First, if you're going to tie it into privileges (as flux would do), you don't want it cluttered, you want it to be very fast to search. Second, I think it could be useful to tie what a user searched to what results were returned, and build custom interfaces for suggestions, statistics, etc. Third, I think you'd want to track not only what registered users have searched for, but also visitors as well. So it seems that a search history should be it's own thing, completely separate from user history.

I'm not opposed to either of these things making their way into WebGUI eventually. And search history is on my wishlist for WebGUI 8 when we redo the search engine.

Back to Top

Rate [ | ]

Previous · Next
User	Message
patspam	Date: 12/23/2008 1:35 am · Subject: User event history · Rating: 0 I'd like to be able to keep a history of user events that are significant for a particular site, for example "Accepted Terms & Conditions", "Won the 2007 ACME code competition", "Started 12 week re-education program", "Ended 12 week re-education program", etc.. I'd then create an Account plugin so that users could view their history (a la the Shop purchase history account plugin), and also create a Flux plugin so that you can e.g. make a section of your site viewable only to users who have accepted the terms and conditions, display badges next to users who have won prizes, restrict access to users who are currently in the 12 week program, etc.. I'm interested to hear if that sort of thing would be useful to anyone besides myself and if so get some feedback on what the history mechanism should support. The actual recording of events would need to be managed by your own custom code, for example the page that receives the Accept Terms & Conditions form post or the code that adds the user to the 12 week program. What events are actually "significant" would obviously vary from site to site, and it would seem you'd want a way of configuring the site-specific list of recognised events (either via an API or through the Admin Console). Patrick http://patspam.com
Back to Top	Rate [ \| ]

JT	Date: 12/23/2008 9:07 am · Subject: Re: User event history · Rating: -1 <begin sarcastic reply> So let me get this straight. You want to create a group of groups, which organizes a group of users, to provide extra privileges for those users? </end sarcastic reply> Seriously though, I do think that the existing groups system will serve you well in the case. Allow me to explain. Create a group called "Achievements". Then create a series of other groups, one for each achievement the user has attained. Make each of these groups a member of the Achievements group. Make the "Accepted Terms & Conditions" group allow users to add themselves to it. Then on your terms and conditions page, use: That will generate a link that will allow the user to add themselves to the terms and conditions group. And finally, write an Account plugin that will display a list of all the groups the user is in that are members of the Achievements group. I hope that makes sense.
Back to Top	Rate [ \| ]

patspam	Date: 12/23/2008 5:31 pm · Subject: Re: User event history · Rating: -1 Yeah that's a nice approach too, it meets the same goal of Flux as allowing non-programmers to add dynamic behaviour to their site. Thanks for elaborating. In this case though I'm more concerned with the history aspect than I am with permissions and whether flux or groups should be used. Take the "12 week program" example from my previous email. What I didn't say is that users can enrol themselves in the program multiple times, or enrol in a program and then half-way through switch to another program. I need a history mechanism that can record all of those events (started program x, stopped program x, started program x again, switched to program y, etc..). Group membership doesn't preserve the timeline like that. Perhaps it's too specialised to be of use to others. That's ok, I just thought it was worth putting a call out before I built it. Patrick On Wed, Dec 24, 2008 at 2:07 AM, <jt@plainblack.com> wrote: JT wrote: <begin sarcastic reply> So let me get this straight. You want to create a group of groups, which organizes a group of users, to provide extra privileges for those users? </end sarcastic reply> Seriously though, I do think that the existing groups system will serve you well in the case. Allow me to explain. Create a group called "Achievements". Then create a series of other groups, one for each achievement the user has attained. Make each of these groups a member of the Achievements group. Make the "Accepted Terms & Conditions" group allow users to add themselves to it. Then on your terms and conditions page, use: That will generate a link that will allow the user to add themselves to the terms and conditions group. And finally, write an Account plugin that will display a list of all the groups the user is in that are members of the Achievements group. I hope that makes sense. http://www.plainblack.com/webgui/dev/discuss/user-event-history/1 -- Plain Black, makers of WebGUI http://plainblack.com
Back to Top	Rate [ \| ]

JT	Date: 12/23/2008 8:40 pm · Subject: Re: User event history · Rating: -1 Yeah, sorry, I didn't take that "preserve timeline" part away from your original post. I'm trying to think of a generic use of that history (outside the scope of what you're using it for). I could see that being useful for groups, specifically for subscriptions. So a user subscribes for a month. Then lets the subscription fade. Then they subscribe for a year, and it expires again. It might be useful to track the group history because you could then see what users are non- consecutive repeat subscribers and maybe adjust the program to get them to be consecutive subscribers. Beyond that I haven't come up with a good example outside your use case. Perhaps others can suggest something.
Back to Top	Rate [ \| ]

perlDreamer	Date: 12/23/2008 9:36 pm · Subject: Re: User event history · Rating: -1 On Tuesday 23 December 2008 06:41:02 pm jt@plainblack.com wrote: > > Yeah, sorry, I didn't take that "preserve timeline" part away from > your original post. I'm trying to think of a generic use of that > history (outside the scope of what you're using it for). I could see > that being useful for groups, specifically for subscriptions. So a > user subscribes for a month. Then lets the subscription fade. Then > they subscribe for a year, and it expires again. It might be useful to > track the group history because you could then see what users are non- > consecutive repeat subscribers and maybe adjust the program to get > them to be consecutive subscribers. Beyond that I haven't come up with > a good example outside your use case. Perhaps others can suggest > something. If you wanted to offer a discount for previous subscribers, then keeping a history would make that possible: Returning members get a 5% discount off their resubscription. Or, if you wanted to keep track of arbitrary data that doesn't belong in a group but could be recorded by a Macro or workflow, things like Account creation, profile mods, taking a survey, etc. Colin
Back to Top	Rate [ \| ]

patspam	Date: 12/23/2008 10:11 pm · Subject: Re: User event history · Rating: -1 Or, if you wanted to keep track of arbitrary data that doesn't belong in a group but could be recorded by a Macro or workflow, things like Account creation, profile mods, taking a survey, etc. The survey example is actually one that we're planning on using. In our case users complete a survey each time they enter and exit the 12 week program. We will use the history both to figure out when users should have access to the survey, and also to generate nice reports for researchers (who view survey responses) to flag responses as "start of program", "end of program" etc.. Since WebGUI::Crud will do most of the work for us (yay for that), I guess the only question is what fields the history table should have. In my mind it has: a unique id a timestamp a userId to indicate who the event is for an eventId corresponding to an entry in a second table of registered events a json-encoded "extras" field where you put anything else specific to your event The only reason I want events to be registered is so that you can find what you're looking for in the history table via sql without needing to fire up the json parser. The registered events table (also build with WebGUI::Crud) would simply have: unique event id description At this level wG doesn't really care what your events are about, it just provides an API for recording them. Perhaps the event registration table should also have a json-encoded "extras" field where you can store extra event information, or maybe this should be left entirely up to you in your own code. That will probably become apparent as people start to use the API in real-world applications. Patrick
Back to Top	Rate [ \| ]

knowmad	Date: 1/9/2009 2:02 pm · Subject: Re: User event history · Rating: -1 Hey Patrick, This rocks! Ever since doing the search presentation at the last WUC, I've been thinking of how to generate search reports. This would be the perfect mechanism to record what users are searching for, when they are searching and what results are coming back. The "extras" field would be vital in being able to record this additional level of detail about the search event. William
Back to Top	Rate [ \| ]

patspam	Date: 1/11/2009 7:31 pm · Subject: Re: User event history · Rating: -1 The WebGUI::History code is tiny (due to WebGUI::Crud), so I'm not sure if it's worth trying to get it into the core. In one sense it's just a simple pattern that wg devs are already using (so maybe I should just turn the code into a wiki article and be done with it). Where it would become interesting was if we started making different parts of WebGUI History-aware and have them all use the single WebGUI::History mechanism rather than rolling their own, and add some History display/manipulation sugar on top of it all. For example as you suggested a History-aware version of Search would let you turn on logging of Search results to the History. And then if we had some generic History report generation tools an admin could get search reports without writing a sinlge line of code. It sound interesting but I'm not convinced if it's worth persuing, given that it's so easy to just roll your own history mechanism in code when the need arises. Patrick On Sat, Jan 10, 2009 at 7:02 AM, <william@knowmad.com> wrote: knowmad wrote: Hey Patrick, This rocks! Ever since doing the search presentation at the last WUC, I've been thinking of how to generate search reports. This would be the perfect mechanism to record what users are searching for, when they are searching and what results are coming back. The "extras" field would be vital in being able to record this additional level of detail about the search event. William http://www.plainblack.com/webgui/dev/discuss/user-event-history/6 -- Plain Black, makers of WebGUI http://plainblack.com
Back to Top	Rate [ \| ]

knowmad	Date: 1/12/2009 12:58 pm · Subject: Re: User event history · Rating: -1 It sound interesting but I'm not convinced if it's worth persuing, given that it's so easy to just roll your own history mechanism in code when the need arises. Hey Patrick, Are you trying to provoke JT with that reply ? Seriously, what you're saying seems to go against the grain of his recent blog about making WebGUI Aspect-aware. I would think that this would be a nice implementation of Aspects, but then I still don't have a firm grip on how these work. Hopefully JT will step in and share his wisdom. William ---- Knowmad Technologies http://www.knowmad.com
Back to Top	Rate [ \| ]

JT	Date: 1/12/2009 1:17 pm · Subject: Re: User event history · Rating: -1 I'm not sure how aspects apply here. Sorry William. A user history as Patspam describes could certainly be useful if it were tied to flux, and flux were included in the core. I'm hopeful that we can do that as part of WebGUI 8, but lots of reviewing of flux has to be done first. As far as search history goes, I don't think making that part of user history is a good idea. First, if you're going to tie it into privileges (as flux would do), you don't want it cluttered, you want it to be very fast to search. Second, I think it could be useful to tie what a user searched to what results were returned, and build custom interfaces for suggestions, statistics, etc. Third, I think you'd want to track not only what registered users have searched for, but also visitors as well. So it seems that a search history should be it's own thing, completely separate from user history. I'm not opposed to either of these things making their way into WebGUI eventually. And search history is on my wishlist for WebGUI 8 when we redo the search engine.
Back to Top	Rate [ \| ]