GSOC - Dashboard for Admins/Owners/Moderators
Yash Mehrotra writes:
*My Ideas - * through all the pages for changes. I think we should show all the mailing
- One issue currently as mentioned is owners of multiple lists have to go
list's requests,subscriptions etc. all in one page.
This isn't a dashboard-level issue; this should be a facility at the core level -- the core knows which lists the user is responsible for, and what the pending tasks are for each. Are you sure Mailman 3 + Postorius doesn't have this capability already?
- The new list features should be opened from a different tab as a list admin doesnt do this every day.
*The primary focus should be - to make it easy for an admin to do his daily activities.*
I agree with the general statement, but are the new list operations really a problem if displayed on the main dashboard?
- So, the index page will contain stuff mentioned on point 1, and the there will be different pages for other stuff like - create/delete list, view statistics ( see next point)
My experience with a non-web-based moderation system is that most moderation/subscription requests can be judged from a one-line display, and for more complex operations (eg, banning an apparently abusive would-be subscriber) use Web 2.0 tech like Javascript popup menus. Of course they have to degrade gracefully if JS is disabled, and even if CSS is disabled. But the main interface probably can include list creation/deletion and a few interesting stats.
- We can also provide some basic statistics for a mailing list like which user is most active, how many avg, mails are sent in a day etc.
I don't understand why this belongs specifically on an admin dashboard. In most cases subscribers probably care more about it than admins do.
- We also also give each list its individual page, so the admin can do list specific functions like, say change settings ,
That's an ancient interface, and doesn't really come up to the expectations people have when they hear "dashboard". All your pending tasks (including those you initiate like list creation) should be available conveniently as soon as you log in, and as much as possible which features are available should not depend on the currently.
ban user etc.
This will almost certainly turn out to be horrible UI. Experience shows that banning a user based on an abuse detected during moderation or subscription approval, and so it should be available without leaving the dashboard.
- One more cool feature would be to color code different types of things for visual ease. Eg. Subscription requests can be color A. Held messages can be color B. and so on. This will not only help the administrator but also would visually good to look at.
Maybe. On the other hand, maybe users will prefer to have the tasks grouped (a group for subscription requests, a group for moderation, a group for admin-initiated actions like list creation if permitted, etc). Maybe color coding will "look nice", but IMHO it's unlikely to be a big efficiency enhancement compared to grouping.
I will add more stuff based on your feedback.
Sorry, that's not the way this works. Part of GSoC to determine requirements. You tell us what you plan to do, we decide whether we like it better than somebody else's proposal. Most likely, if you seem to have overestimated your productivity we'll tell you you can cut back your proposal, and where to cut. But if you propose something trivial, mostly you'll get the simple comment "this is not enough to be a good GSoC project."
A dashboard that gives convenient access to all tasks a user is assigned seems like a GSoC-sized project to me (maybe bigger).
The main thing you need to add is a schedule. See also http://turnbull.sk.tsukuba.ac.jp/Blog/SPAM.txt.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 16.03.2015 um 03:04 schrieb Stephen J. Turnbull:
Yash Mehrotra writes:
*My Ideas - * 1. One issue currently as mentioned is owners of multiple lists have to go through all the pages for changes. I think we should show all the mailing list's requests,subscriptions etc. all in one page.
This isn't a dashboard-level issue; this should be a facility at the core level -- the core knows which lists the user is responsible for, and what the pending tasks are for each. Are you sure Mailman 3 + Postorius doesn't have this capability already?
Sure, implenting such a user-based lookup of all roles and action-items in the core-API would facilitate things on the UI side. Currently this would involve several different HTTP calls to collect the data.
But I think this is an implementation detail (and ideally possible solutions for this are part of any application for this project). To me the most important feature of the dashboard is exactly this: A single spot to show me where action from my side is required.
- The new list features should be opened from a different tab as a list admin doesnt do this every day.
*The primary focus should be - to make it easy for an admin to do his daily activities.*
I agree with the general statement, but are the new list operations really a problem if displayed on the main dashboard?
- So, the index page will contain stuff mentioned on point 1, and the there will be different pages for other stuff like - create/delete list, view statistics ( see next point)
My experience with a non-web-based moderation system is that most moderation/subscription requests can be judged from a one-line display, and for more complex operations (eg, banning an apparently abusive would-be subscriber) use Web 2.0 tech like Javascript popup menus. Of course they have to degrade gracefully if JS is disabled, and even if CSS is disabled. But the main interface probably can include list creation/deletion and a few interesting stats.
That's what we currently have on the list-specific message moderation pages in postorius: A single row for each message, details (body/headers) in a model window if needed. IMO this could look similar on the dashboard.
- One more cool feature would be to color code different types of things for visual ease. Eg. Subscription requests can be color A. Held messages can be color B. and so on. This will not only help the administrator but also would visually good to look at.
Maybe. On the other hand, maybe users will prefer to have the tasks grouped (a group for subscription requests, a group for moderation, a group for admin-initiated actions like list creation if permitted, etc). Maybe color coding will "look nice", but IMHO it's unlikely to be a big efficiency enhancement compared to grouping.
I think you need to a bit careful here. Different colors might make it easier to distinguish between types of action items, but they will most likely also introduce an implicit prioritization. But IMO the priority of different types of action items can vary a lot depending on lists' characteristics. Also, every admin might have a personal idea of what's important and what's not.
Florian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1
iQEcBAEBAgAGBQJVBxSgAAoJEEceGbPdavl7QwUIAKL/vHVfznp2mjzeKjssTZRq 1T5gLfqP1qRHUNO58bBX9b1jyZYqMCea6lXL3Zt6x2pEKka7tiIr84cysBXhcJtA OfB7oaUujpjExKFlPrTMFwwSyj+Gp4R213wloKtM78jcTE0OLas6oZt4dnywiec0 AglOyDqqfkK4kyjkNeLc9wG8cvrtu5/QRAxWKVtvjir9UH38CYT0TFzXM9TEOuY/ oegEMj2+082eVe1hDHm3jjRQ7Qg4qGY26QnFonS5asdVZaZopX34+wxfRNpKMY9r eZ9Ef/L9gnMfs6ddg5Lty4+43PyQTlafj61NWkHJqzvUAG0EMkyUSQs1mxNJWfE= =1zw2 -----END PGP SIGNATURE-----
participants (2)
-
Florian Fuchs -
Stephen J. Turnbull