Metaphor for structuring all information

Hi Jodok,

Jodok Batlogg wrote:

> Richard Boyd wrote:
>> I have
>>designed them all using a standardised metaphore across all parts of the
>>site. This standardisation on an easily understood metaphore should help
>>novices move around the site freely and encourage adoption by teachers,
>>the key to the success of an educational intranet.
> 
> 
> can you explain this "metaphor"? 

Here is a discussion of my metaphor:

It involves throwing out general purpose folders and creating 
aggregation types with specific purposes. I think folders can hide 
things and hinder information organisation if there is not a well 
understood structure. I considered using ZTopics for everything, but 
that provides no structure to help people conceptualise the information. 
People like to know that there is a canonical organisation of 
information, even if there are other ways of accessing it. This metaphor 
provides a strict structure which will be augmented with Topics for 
sorting/finding information.

As a basic rule, I think users in a shared system should be allowed the 
minimum flexability required to store their information in a 
standardised, meaningful way. This helps others know where to expect the 
information and to easily comprehend its structure.

Also, I think that hierarchy depth should be strictly limited to enhance 
a users ability to conceptualise the site, and so that a user knows when 
exactly when they are going to stop browsing menus and get content. I 
like the way that wikis achieve this. They would map nicely to a "book" 
in the following structure.

My metaphor involves 3 aggregation meta-types, each with their own 
purpose: area, project, book. Each meta-type is sub-typed so that it can 
hold the information necessary for a particular application, but the 
structure of the information is determined by the meta-type.

Basically, a project is a heterogenous aggregation while a book is a 
homogenous aggregation. Project and book sub-types are created by 
setting the types that are allowed in their aggregations. Projects can 
allow any number of book types, while books should only allow 1 (2 if 
really necessary) content types. All content items are stored in the 
leaves of the structure, in the books.

This could allow very flexible browsing of content. Users could jump 
around anywhere in an area using a project slot and book slot. A project 
page could be viewed as a slashdot-style blog, or a site map, or a 
type-ordered folder, or a topic map. A book could be a simple blog, or 
an index page with summaries, or ... . A document could also be 
designated as the index-html page for the book or project because 
navigation slots would still be available. Any of these navigation 
techniques could be easily plugged in, as the scripts creating these 
views know exactly where the content is and how the site is organised.

At the bottom of this message is a discussion of a complimentary 
meta-type "filing cabinet" which can be used in the same structure where 
the project/book modelling is not appropriate.



Here is a more in depth discussion:

An intranet is made up of "areas" (I havn't figured out a better name 
yet). An "area" contains "projects", a "project" contains "books", a 
"book" contains content items.

An area simply defines the purpose of a part of the internet. Is it for 
adminstration, learning, course design, or is it a personal area? 
Certain groups of users may be able to browse the project titles in 
particular area, or even have administrative rights in a particular 
area. An area may have its own presentation style or slots. A particular 
area will have certain types of projects. For instance the 
"administration" area will not have "learning module" projects. Apart 
from that it is a fairly basic aggregation type.

An area could be seen by the user as a seperate site using Zope's 
virtual hosting. This could help keep the hierarchy flat.

A project is primarily for assigning user roles for a collection of 
information. Users are given browse, create, review, and manager rights 
for a project. A project can contain any number of books of different 
types. Projects restrict the types of books that can be created. For 
instance a Department project will have "meeting", "accounts", and 
"mail" books, but will probably not contain a "play" book which only 
"learning module" or "course instance" projects can contain. The only 
difference between types of projects is the types of books that they can 
contain, so although they are different Plone types, they are the same 
Zope type.

A project should also define the keywords allowed for cataloguing the 
items it contains. It can also, if necessary, contain presentation style 
customisation, especiialy when the project is a department's public webarea.

A book is a collection of content items, and is much more restrictive 
than the other types. It is a homogenous aggregation type, more like a 
list or array rather than a record or object.  For instance, a meeting 
will contain a list of agenda items/resolutions, which would not be 
appropriate in "play", "account", or "mail" books. Books can always 
contain generic documents for an introduction page (preface) and 
possible extra information and references (appendices), but apart from 
that should be kept as homogenous as possible. A book must be keyworded 
with the approved keywords for the project. A book will automatically 
order its contents for easy browsing.

Each item can be an arbitrarily complex object as is required for the 
application. However, if it involves too much complexity, it should be 
turned into its own project. The book would then contain a list of 
references to this new project type, and the new type should be stored 
directly in a top level area. For certain instances, new top level areas 
may need to be made to store new complex types. An example is the 
"learning design" area which contains "course models" and "unit models" 
etc.. This means that course models are directly accessible, rather than 
  being stored deeply inside the department that teaches the course. The 
department will contain references to items in the "learning design" area.

An item may also be keyworded if it contains information not covered by 
the book keywords. It may also contain any number of references and 
comments.

Although this may not directly model every required object, it seems to 
be flexible enough to handle most objects that I want.  An heterogenous 
aggregation type containing homogenous aggregation types can 
theoretically handle anything. The biggest advantage is that people 
always know where the information actually is (in the leaves of the 
tree), and where user rights are managed (in the project). It is easy to 
shift books and projects around or even merge or divide projects as 
necessary without upsetting the site structure. It is easy for people to 
share information (make a shared project) . Any scalability issues could 
be handled by having two layers of "areas" rather than just one.




**** Filing Cabilinet type ****




There is a the possibility of some types being very badly modeled by the 
  project/book analogy, in which case the project and book could be 
switched around to create an homogenous list of heterogenous collections 
of items. This could be a "filing cabinet" type which contains similar 
heterogenous collections(folders), where the heterogenous 
collection/folder is typed with the specific document names that are 
allowed in the collection (always allowing for some flexability). The 
metaphor name would need to be changed to prevent conceptual conflicts 
with the existing metaphor which also uses the word "folders" :-), but I 
hope you get the idea. This filing cabinet metaphor is a complimentary 
metaphor which could easily be used in the same "areas" as the 
project/book metaphor. The filing cabinet would take on the same tasks 
as the project and the "folder" would take on the same tasks as the "book".

In fact, as "projects" are defined by the books that they contain, a 
"project" with only 1-2 "books" allowed automatically becomes a "filing 
cabinet", while a "folder" type needs to be created that is a "book" 
with certain allowable/encouraged item names.

I guess there is nothing stopping projects from containing folders, and 
filing cabinets containing books ... it is up to whoever creates the 
specific Plone type. None of this should affect the project/book Zope 
types (much?).


Hope all this makes sense

Richard





-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/