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