« September 2005 | Main | November 2005 »
Workshop Excerpt October 20
This section only | References/ Recommended Reading (0)
Meeting 9am-12pm, Oct 18
In today's session we look through the data model one more time. One issue is the permissions that are given to an invited contributor. The consensus seems to be that invited contributors cannot delete a project but can edit anything else. How would ownership of a unit be passed on from one person to another?
What happens if a person looses interest and abandons a meaningless project?
This section only | References/ Recommended Reading (0)
Notes Meeting 10/11
response to wireframes:
- all tools (eg: add to favourites) should be styled in the same way
- style of contributor management listings should be same order (ie:
projects/units/resources - each alpha sorted) & single column
objects (project & unit):
- confirmed we need description (limited size) & body fields
- searches done on description field
- need to decide on if/when description displayed & how to describe
purpose to contributor (eg: abstract, synopsis??)
resource:
- add author(s) field
- add bibliographic reference (unstructured text) field
- download filename generated from title (eg: first 16 chars w/ spaces
converted)
project-unit:
- add title field (unit title customizable for each instance)
decisions:
- should we allow a unit to be tied to a project as EITHER original
(only original creator can modify, therefore it might change/disappear)
OR copy (you gain control of further mods on it)? ONLY COPY
- can we use one CC license for all content? YES (therefore not
required in data model)
- resource can only be linked to unit (not directly to project)? YES
questions for next meeting:
- can contributor list more than 1 url in profile, if so how many?
(should be set max)
- should we allow unit resources AND content to be exposed in project
view on a per-unit basis? (this question previously noted)
- should we allow resource to be displayed inline in unit view on a
per-resource basis (where possible, given the type of resource, ie:
image, URL, etc)?
next meeting: tuesday, oct 18, 9-12:30
data model updated to reflect decisions made:
Download dlp-datamodel_051011.pdf
This section only | References/ Recommended Reading (0)
user profile text fields
regarding user profile text fields: name - should be 2 fields: givename,surname (its good to split these up for sorting) email - definitely needs to be in its own field as its their login title - i would drop: leave this up to them to put in their bio if they choose postal address - i could see city/town & country might be useful, might be too invasive to ask for complete address hyper links - if we want multiple it would be good to have a set limit to keep the data model from getting more complicated
This section only | References/ Recommended Reading (0)
Revised Data Model
the data model has evolved slightly.
changes:
- added 'resource:parentid' to capture whether resource is original or
modified version
- added 'contributor:sponsorid' to track number of new contributors
registered by an existing contributor
- added 'log:contenttype' to capture whether content is object,
resource, subject or contributor
- reversed one-to-many direction of the contributor-subject relation
(original was a mistake)
- hilighted 'log' to denote it as entity rather than relation
explanations:
- possible 'action' data in log:
create,modify,copy,delete,view,login,logout
questions:
- should we allow unit content to be exposed in project view on a
per-unit basis? (this question previously noted)
- should we allow resource to be displayed inline in unit view on a
per-resource basis (where possible, given the type of resource, ie:
image, URL, etc)?
- should we allow a unit to be tied to a project as EITHER original
(only original creator can modify, therefore it might change/disappear)
OR copy (you gain control of further mods on it)?
notes:
- i'm thinking about collapsing 'resource' into 'object' and just
making it another type. if you have any thoughts about this, please
bring them up at our next meeting.
revised data model attached (please disregard previous version).
This section only | References/ Recommended Reading (0)
Chris new interface
This section only | References/ Recommended Reading (0)
dlp-development_051003
dlp-development_051003 (TL)
-----------------------------
The following is a description of outstanding design decisions which need to be made in order to begin coding & to set up the database:
1) Position of links in content view:
Just to restate my opinion on the "print, related, copy, etc" links that we talked about last week:
a) All links that AGGREGATE content for a particular unit or project should be in the body of the content (ie: resource link in unit, etc).
b) All links that refer to EXTERNAL content (ie: related projects, etc) or that allow one to perform an ACTION with the content (ie: save, download, print, etc) should be in the toolbar menu.
In my mind, this is conceptually the cleanest approach, and helps keep different contexts clear for the user.
- RESPONSE FROM CHRIS, THOM, CHRIS MEETING FOR TOM:
We think that the external files (such as a .pdf of a resource) should be in the body as is demonstrated in Chris' design.
- The kirck server needs to allow users to upload WITHOUT downloading VPN or ftp-ing--
the upload interface should be through a web page interface
2) Interface styling:
Not sure if we came to a final agreement about this. Potentially we will have several CSSs applied to a given page. Here are my suggestions for your discussion:
a) one CSS for site navigation - ie: toolbar (customizable by site administrator via CSS file mod)
b) one CSS for site content - ie: home, background pages, search results, content header/footer, admin backend, etc (customizable by site administrator via CSS file mod) question - should this be separated into backend (admin, content creation, etc) & frontend (public view) CSSs to make it clear to user what mode they're in?
c) one CSS for a given project and all content tied to it (customizable by project owner via project admin interface which exposes project CSS - default given, stored in database)
- RESPONSE:
Users can only use ONE global color scheme
Instead of distinguishing project, unit, and resource through different css files we introduce
square, circle, and triangle to identify that the user is looking at this particular section
two css files:
-one global one for screen, one css sheet for admin
-second global one for print
3) Interface templates:
The interface will be broken up into sub-templates wherever possible to minimize duplication. These templates can contain variances such as "if the user is in contributor mode show these links, etc". Typically content is split up into sub-templates along the lines of header, body, menu, footer. Often something like the footer contains static content such as license, 'powered by', etc that appears on every page. The body could be one of several types of layouts such as project view, unit view, search results, etc. Chris should come up with a strategy for breaking up the interface into sub-templates and let me know what is as it will have bearing on the php code that deals with page generation.
- RESPONSE:
No, Chris will design global template for each main display in css and html, not in Photoshop and Tom writes code based on that/to integrate with that.
2) Roles & ownership of content:
Roles:Groups
public = access to published content only, no tools
registered = access to published content and myFovorite and myProfile tools
contributor = access to published content and myContributions, myFavorite, myProfile
-colaborator = group access to myContibutions
userAdmin = all lower access and tools and createModifyUsers tools
appAdmin = all lower access and tools and guiModification tools
By ownership I'm not referring to CC license, but rather DLP internal ownership of content which determines what control (permissions) a contributor has over it (ie: can they delete, modify or control access to it). Related to this concept we have the idea of groups that are tied to either the modification of or viewing access for content. We need to be clear on the rules around this. My suggestions for your discussion:
a) Public is an anonymous viewer that has not REGISTERED. A person who has not logged in.
- RESPONSE: Correct
b) User is anyone who is logged in
- RESPONSE: Correct
c) Contributor is a User who is approved by another Contributor or an Adminstrator
- RESPONSE: A CONTRIBUTOR CAN ONLY INVITE 10 PEOPLE IN A LIFE TIME TO BECOME CONTRIBUTORS.
d) Contributor can create a new Project and modify/delete/lock/"mark as draft mode" ones they have created
RESPONSE:
add "mark as draft mode
e) Contributor can create a new Unit and modify/delete/lock ones they have created
- RESPONSE: add "mark as draft mode
f) Contributor can create a new Resource and modify/delete/lock ones they have created
- RESPONSE: add "mark as draft mode"
g) Contributor can specify any Contributor as a member of Collaboration which can modify any unlocked content associated with given Project
RESPONSE: re-write :
contributors can specify collaborators as member of a project or unit. Collaboerators must have the role of contributor. Collaborators can modify any project they are a member of. Units they can modify or delete. Only the unit creator should be able to delete it.
h) Contributor can specify any User as a member of Group which can view any content associated with given private Project
- RESPONSE: No. Either contributors join as collaborators and can edit or they cannot see the draft stage at all. There is no point in just having them view it.
i) User Administrator has all the rights of every Contributor (ie: they can modify/delete any content) and can modify the access of any User
j) Application administrator has all rights of user admin plus can system-wide application changes
This section only | References/ Recommended Reading (0)
Meeting Tuesday Sep26/05
- meeting focused on response to interface wireframes presented by Chris
- the following organizes discussion points around topics that came up
Project Icon:
- project (as opposed to dlp) logo missing from current wireframe
- where to place it: top right (Tom, Thom), bottom right (Chris)
DLP icon
- should appear at absolute bottom right of page (Tom, Trebor)
Project/Unit/Resource Icons
- should be consistent between search and view interfaces
- simple (as per search wireframe example) versions better (Tom, Trebor)
CC license:
- notice need to appear on all content pages
- can we use 1 CC license? if not, license needs to be displayed for each resource,etc. what is the logic applied to mixed licenses in given unit (eg: unit has one, embedded resource has another)
- Trebor to report on license strategy
Breadcrumb:
- always exposed for units & resources in search, view & related links
- at very top of page in unit/resource view (Thom,Tom)
Related links:
- embedded in content as per wireframe (Chris,Trebor) or in right menu (Thom,Tom)?
- also include 'used in' links
Resource view:
- current wireframe displays description w/link in main window
- should display resource (where possible) w/description in new window (Tom)
Terminology:
- what to call 'Library' in wireframe?
- suggestion: 'Collection'
Content states:
- unpublished, restricted, published
- unpublished & restricted content exposed to searching so that other contributors could be made aware of related content which they could collaborate on (shown as unpublished)
- unpublished & restricted content is not copyable
- resource, unit, project can all be unpublished & restricted
- restricted content only viewable by specified user group
Unit:
- unit owner can reference unit in multiple projects without copying (to allow for global modification)
- unit owners can delete them
- others must copy unit to use in their project
- parent ID of copied unit saved as part of unit data
Download units & projects:
- zip download (Thom)
- would need to generate different links for internal package content (Tom)
- not currently high priority (Tom)
