scalability
We get a lot of feedback from our users, and a very clear pattern is that the users wish to be notified of different things that happens in the platform that is of relevance to them.
For instance they love the ability to subscribe to forums, announcements, and messages / inbox (allthough they seldom find out how to subscribe to the last one).
They most often say that they want an e-mail when this and that happens, which would be fine, but I don't think that sending all these e-mails is the best solution, neither the one that scales the best.
An activity / notification feed for ATutor
This has led me to think that we need some kind of activity feed or notification feed in ATutor, as popularized by Facebook and their notifications (you need to be logged in to Facebook to see this page), and Basecamps dashboard or project overview.
Here's a recent screenshot of my latest Facebook notifications:

The "items" (like photo / status / user) and "actions" (comments / likes) would be different in ATutor, and that leads to my questions to Atutor users and developers:
- What are the items and actions in Atutor that should be included in such a stream?
- How could we technically and design-wise implement this in ATutor?
We are hiring again, and will thus have two developers available to work on ATutor in the not-so-distant future, and this is one of the things we wish to prioritize. We're willing to do all of this work, get it into core and maintain it, given that we and ATRC agree on how it should be done. And yes, we know that this is a massive task!
Here's my initial thoughts on the two points above, please add your comments in the comment field!
Items and actions in ATutor
First, there are different items and actions depending on your status. Regular students need to see some things, while assistants needs to see other things, depending on their priviledge. The colored things in brackets are links and / or generic terms, comments in italic.
For normal students:
For the communication tools
- You got a [new message] from [user] (inbox)
- [User] wrote [new post title] in [forum name]
- [User] replied to [post title] in [forum title]
- [announcement title] was posted in [course name]
- [user] wrote [blog post title] in [blog title]
- [user] commented on [blog post title] in [blog title]
- [user] uploaded [file name] in file storage.
- [user] uploaded a revision of [file name] in file storage
- [user] commented on [file name] in file storage
For tests and assignments
- test [test name] is now available.
- test [test name] closes in 3 (?) days
- assignment [assignment name] closes in 3 (?) days
- [certificate name] is ready for download (our module, not yet released)
For content
- [content title] is now available (given that a release date is set)
- [forum title] was added (when creating a brand new forum)
- new [poll name] is relased
- [FAQ] is updated with [FAQ question]
- [Links] are updated with [link title]
- [Reading list] is updated with [resource name]
For courses
- [course name] is available (given release date is set)
- [course name] closes in 7 days (given end date is set)
In addition we will need some feed items that are specific for instructors or assistants with a given privilege, like:
- [user] requested enrollment in [course name]
- [user] answered [test title]
- [user] submittet [assignment title]
I have probably forgotten some as well.
How to implement it technically and design-wise
This is the hard part, and I basically have no idea what the best way to start would be. Initially I'm thinking that each module or core function that needs to feed into this notification stream should publish it's own customized RSS file, and that the notification stream function should read and process / sort these after some rules. Some things most of the RSS feeds would need are:
- Date (always needed for sorting)
- Item (announcement title, blog post title, forum title, forum post title etc.)
- Item link (the URL to the item)
- User name (if needed in the stream)
- Action type (like "commented" or "posted" / "wrote" or "submitted" or "requested" or "uploaded" etc)
- Course name
- More?
The placement is pretty much a given I think, this fits perfectly on a slightly redesigned user start page. Not in it's own sub page though, as I want it up front! We may want to add a feature for admins to turn this off and on.
I also belive the items should be sorted by date, with the most recent items on top. Alternatively it could be sorted by course name, then date.
And I believe we should have a cap on it, so you would at the most see the 20 / 30 / 50 (?) latest items.
Another important thing to think about is how we create the translation terms, as there are many different ways to write messages like this in different languages.
New modules would have to be able to use this so we would need to describe how they can. This should be a part of the module documentation.
How it fits in with the original user feedback
As I started with, our users crave notifications, and they also want them by e-mail. I don't think we should remove the e-mail notifications that are allready in place in ATutor, but you should also be able to get the notification stream in e-mail, I think LinkedIn does this really well:

The user would need the ability to set when this should be sent, like for instance:
- Daily
- Weekly
- Biweekly
Random other thoughts
First of all, ATutor just implemented the Open Social framework as a module. As far as I know it's also the first open source application that has done this - kudos for that!
I don't know the Open Social specs very well, but if this specification can be used to create the other feeds we need that would be really nice! Also, the ATutor Social module allready has an activity feed, and this is a feed I typically would like to include in a more general and site-wide feed.
So, comments are open! What would it take to implement this? What is a realistic time range to get it implemented? What have I missed? Or am I on the wrong track alltogether? :)
One more patch aimed at improving usability of ATutor. It enables group deletion of test submissions by replacing radio buttons with checkboxes and adding a "Select/unselect all" checkbox.
Also it fixes minor bugs found in that area (I've noticed as much as seven of them).
The change has already been included into the trunk for the next release, 1.6.2, while this patch allows users to benefit from it right now.
See the patch here: http://atutor.no/contribs/group-deletion-test-submissions-plus-bugfixes

