Created by Michael Steigman, last modified by Michael Steigman 09 Dec 2009, at 06:09 PM
What can we provide now?
* WIKI
new pages this week
average: new pages per month
page edits this week
average: page edits per month
average: editors per page
* FORUMS
new threads this week
posts this week
average: new threads per month
average: posts per month
average: forum notification subscriptions per month
ratio: posts per thread (monthly?)
example queries:
hub=# select to_char(r.publish_date, 'YYYY-MM') as month, count(*) from cr_items i join cr_revisions r on (i.item_id = r.item_id) where parent_id = '2239905' group by month order by month desc;
month | count
---------+-------
2009-10 | 123
2009-09 | 394
2009-08 | 410
2009-07 | 671
2009-06 | 158
2009-05 | 4
2009-03 | 8
2009-01 | 4
2008-12 | 56
(9 rows)
hub=# select to_char(o.creation_date, 'YYYY-MM') as month, count(*) from cr_items i join acs_objects o on (i.item_id = o.object_id) where parent_id = '2239905' group by month order by month desc;
month | count
---------+-------
2009-10 | 2
2009-09 | 31
2009-08 | 38
2009-07 | 71
2009-06 | 39
2009-05 | 2
2009-03 | 4
2009-01 | 1
2008-12 | 12
(9 rows)
hub=# select max(count) from (select count(distinct creation_user) as count from cr_items i join cr_revisions r on (i.item_id = r.item_id) join acs_object\
s o on (o.context_id = r.item_id) where parent_id = '2239905' group by i.item_id) a;
max
-----
7
(1 row)
hub=# select avg(count) from (select count(distinct creation_user) as count from cr_items i join cr_revisions r on (i.item_id = r.item_id) join acs_object\
s o on (o.context_id = r.item_id) where parent_id = '2239905' group by i.item_id) a;
avg
--------------------
1.4900000000000000
(1 row)
hub=# select count(distinct creation_user), i.item_id from cr_items i join cr_revisions r on (i.item_id = r.item_id) join acs_objects o on (o.context_id =\
r.item_id) where parent_id = '2239905' group by i.item_id;
count | item_id
-------+---------
2 | 2239907
1 | 2240099
1 | 2240101
2 | 2240276
1 | 2240751
1 | 2240763
1 | 2240769
7 | 2240772
1 | 2248445
1 | 2249069
1 | 2249119
1 | 2249149
...
2 | 2714595
1 | 2716420
1 | 2721530
1 | 2722191
2 | 2724344
1 | 2731842
1 | 2752093
(200 rows)
What could we provide in the future?
average: # new/departed group members per day/month/year
average: visit length of group members
2 day answer rate for new threads
average: uploads/downloads per month
average: first answer time for threads
ratio: page view per post (lurk)
etc.
Created by Dave Bauer, last modified by Dave Bauer 02 Nov 2009, at 09:00 PM
Spec for File Management Overhaul on Hub
Michael Steigman (09/25/09) Updated 11/2/2009
User interface mockups
Big Picture
File management in OpenACS is a complicated affair at the moment. There are
several ways to upload and link to files and this has led to duplicate files, broken links
throughout content blocks and “embedded” files in rich text that are difficult to manage
(among many other issues). We are aiming to unify the file upload, linking and
management model and UI across the site, in order to make it simple to upload, update,
share, reference and delete files.
Organization of Files
To help users in a community or on a site collaborate, weʼd like to allow them to
organize and view files in ways that are intuitive. Taking from OS X, Google, Zoho, Windows et.
al., we envision a series of organizational areas in the files UI corresponding to different
filtering criteria.
Places - within a community, default “places” will include all applications and any other
subfolders the admin wishes to include. All users will see these places.
Views - the views area will include some basic views which should cover a lot of
scenarios (search for in OS Xʼs finder) and will expand with custom views created and
saved on the advanced tab.
Favorites (or bookmarks?) - this organizational area will display folders and files in the
personal file area which the user has marked as interesting anywhere on the site.
Shared - implied by the title, this area shows up in the personal file space and shows
files shared by and to you.
Upload and Linking Mechanisms
We want to allow users to link to/attach/upload files to any type of content and present a
consistent UI when doing this. The easiest way to do this would be to provide the same
interface users normally browse by, as OS X does. The WYSIWYG editor will have to
replicate this environment in a plugin setting. Apps that donʼt use the richtext widget
should be able to “include” a version of the browsing interface that allows for single (and
multiple?) file selection.
Much like hard links in Unix, we envision multiple links to each files. The links should be
viewable at the fileʼs canonical location (visible in the mockups). When no more links to
a file exist, the file can be deleted (think callbacks on link removal). Storing a checksum
for the file upon upload so that we can determine if it already exists within the
community would be beneficial.
Metadata Requirements
We need to be able to map from link to destination file. Within this link, we need to
capture some information - the object weʼre linking from being the primary bit of
information. If this link were to be an instance of a dedicated object type, it could also be
permissioned (i.e., a proxy). It could also point to a particular revision, which would
enable a learning module to point at a stable revision and prevent teaching material
from moving beneath a module author. These do not need to be part of the initial
implementation but should be considered.
Navigation and Page Requirements
We should provide an generic overview page (detailed in the mockups) that describes
the files attached to a piece of content. We need to be able to generate navigation for
content such as wiki pages or forum posts that include a link to the overview page if files
are attached. We also need a single, permanent page to display information about a file (File View in the
mockups).
Shared Folders
Referece Google Docs Shared Folders Feature http://docs.google.com/support/bin/answer.py?hl=en&answer=158074
Reference Zoho Document Management http://www.zoho.com/online-document-management/share-documents-collaborate.html
Use Cases
Upload File From Subsite/Group Files tab
User clicks "Add File" link or button from "Subsite->Files" page.
User sees upload dialog and chooses a file from their computer to upload.
File is added to subsite default folder.
Creation_user is the uploading user.
Parent_id is the default folder for the subsite.
Permissions are inherited from context_id, all members of subsite can view this file.
Context_id is the default folder for the subsite.
Upload file as attachment to Forums Message (or wiki page, etc.)
(note forums post workflow is not addressed)
User chooses to attach a file to a forum message.
User sees upload dialog and chooses a file from their computer to upload.
File is added to subsite default folder.
Creation_user is the uploading user.
Parent_id is the related object, ie: forum_message
Permissions are inherited from context_id, all members who can see the forum post can see the attached file.
Context_id is the parent_id.
Attach existing file from subsite folder as attachment to Forums Message (or wiki page, etc.)
User chooses to attach a file to a forum message.
User sees file chooser dialog (embedded filter view of subsite files).
User chooses existing file.
Acs_data_link created between forums_message and the uploaded file.
Upload file to personal folder
User browsers to their "workspace" (blah) and chooses Files.
This shows the My Files view.
User chooses Add File.
File is added to user default folder (child of user object).
Parent_id is the user default folder.
Context_id is the parent_id.
Permissions are inherited from the context_id.
Noone else can see or manage these files except the user.
Attach Existing file from personal folder to a forums message etc.
User chooses to attach file to a forums message.
User sees file chooser dialog (embedded filter view of subsite files).
Somehow the user chooses to list My Files and sees a list of all files this user has created.
Use chooses file from personal folder.
User sees message that they will share this file with the group/subsite/community with a checkbox to acknowlege.
A cr_symlink is created (this is the manifestation of "share" in this case.) in the subsite default folder.
Acs_data_link created between symlink and the forums message.
Permissions, parent_id, context_id of original file do not change!
Parent_id of symlink is default folder.
Context_id of symlink is parent_id.
Permissions
are inherited from context_id, all members of the subsite can view the
symlink (which resolves to the file) as long as it is being shared (the
symlink exists.)
View subsite files
User sees a list of files in the subsite folder or any subfolders, that they have permission to see (by default all of them.)
Shows filename/title, description, updated date/time, tags, creation user???
User
sees list of Places (packages in the subsite.) Each place filters files
that have acs_data_link to objects owned by that package.
User can
search filenames(titles/descriptions/tags) using the Search Within
feature. Just like google docs. Does not search file contents??
Clicking on a file name opens it but there should be an obvious place to view file information (permissions, revisions, links)
Clicking on a folder shows files/folders in that folder.
User can sort by name or date (asc/desc options, perhaps arrow next to name/date sort option?)
What do we do with pagination? How does search/sort affect pagination?
Experimental!! Sharing a Folder
User creates a folder or chooses an existing folder to share.
Symlink is created in group or target users folders to the shared folder depending on sharing level.
Permissions are granted on the ORIGINAL folder based on the sharing settings.
NOTE:
how do we do this without screwing something up? That is the sharers
are not allowed to DELETE or ADMIN the original folder. But we want to
simplify dealing with the items IN that folder.
