Actions

Difference between revisions of "Proposals/Multipage Views"

From Mahara Wiki

< Proposals
(Created page with "<span style="background-color: rgb(255, 204, 0)">Please visit Multipage Views Take Two after reading this …")
 
(2 intermediate revisions by the same user not shown)
Line 3: Line 3:
 
<div id="section_1">
 
<div id="section_1">
  
==== Preamble ====
+
====Preamble====
  
 
Being able to group views together into mini "websites" is an oft-requested feature in Mahara.  Not only does it provide a way for users to layout their content in a more comprehensive way for larger views, but it also enables them to add access at the "website" level without having to duplicate it across many different views of related content.
 
Being able to group views together into mini "websites" is an oft-requested feature in Mahara.  Not only does it provide a way for users to layout their content in a more comprehensive way for larger views, but it also enables them to add access at the "website" level without having to duplicate it across many different views of related content.
Line 9: Line 9:
 
</div><div id="section_2">
 
</div><div id="section_2">
  
==== New Terminology ====
+
====New Terminology====
  
 
<div id="section_3">
 
<div id="section_3">
  
===== Site =====
+
=====Site=====
  
 
We will introduce a new top-level item, which will be called "Site". A site is a list of views (which may be renamed to "Page"), together with some structured navigation, which can include a nested hierarchy.
 
We will introduce a new top-level item, which will be called "Site". A site is a list of views (which may be renamed to "Page"), together with some structured navigation, which can include a nested hierarchy.
Line 19: Line 19:
 
</div></div><div id="section_4">
 
</div></div><div id="section_4">
  
==== Implementation Notes ====
+
====Implementation Notes====
  
 
Views can be in more than one website.  Access can still be given on the View level, even if a View is in one or more websites.  We will have a new (optional) URL parameter "site" for view/view.php, and if it is present, access will be checked on the site level, not the View level.
 
Views can be in more than one website.  Access can still be given on the View level, even if a View is in one or more websites.  We will have a new (optional) URL parameter "site" for view/view.php, and if it is present, access will be checked on the site level, not the View level.
Line 29: Line 29:
 
</div><div id="section_5">
 
</div><div id="section_5">
  
==== User Interface ====
+
====User Interface====
  
 
<div id="section_6">
 
<div id="section_6">
  
===== Adding/Editing Sites =====
+
=====Adding/Editing Sites=====
  
 
We will introduce a new second level navigation item, "My Sites" under "My Portfolio".  On this page will be listed the current Sites the user has, with controls to add, delete, edit details edit, edit access.  The page will be very similar to the My Views page.
 
We will introduce a new second level navigation item, "My Sites" under "My Portfolio".  On this page will be listed the current Sites the user has, with controls to add, delete, edit details edit, edit access.  The page will be very similar to the My Views page.
Line 45: Line 45:
 
</div><div id="section_7">
 
</div><div id="section_7">
  
===== Changes to My Views =====
+
=====Changes to My Views=====
  
 
There will be no changes to My Views, except a banner at the top of the access screen explaining that any Site access will override the View access when the View is being looked at independent of whatever site(s) it is in.
 
There will be no changes to My Views, except a banner at the top of the access screen explaining that any Site access will override the View access when the View is being looked at independent of whatever site(s) it is in.
  
<span>'''Displaying My Sites'''</span>
+
'''Displaying My Sites'''
  
 
We will write a new blocktype, "My Sites" which will be very similar to the "My Views" block, and can be placed on the profile View.
 
We will write a new blocktype, "My Sites" which will be very similar to the "My Views" block, and can be placed on the profile View.
Line 55: Line 55:
 
</div><div id="section_8">
 
</div><div id="section_8">
  
===== In-Site Nagivation =====
+
=====In-Site Nagivation=====
  
 
We have two different options for how to deal with Site navigation while looking at a View in the site:
 
We have two different options for how to deal with Site navigation while looking at a View in the site:
Line 61: Line 61:
 
<div id="section_9">
 
<div id="section_9">
  
====== 1. A navigation block manually added by the user ======
+
======1. A navigation block manually added by the user======
  
 
This would be added manually to any Views by the View owner, and would display something different, depending on what context the View is viewed in.  The block would have no config of its own, it would just read the navigation information attached to the Site that the View is in.  The benefit of this approach is that it gives the user more control, and it can be placed wherever they want in the view.  The downside is that it looks different in every context, and will be hidden completely sometimes for Views that have access in their own right.  There is no smart way to display a preview of this block in edit mode.
 
This would be added manually to any Views by the View owner, and would display something different, depending on what context the View is viewed in.  The block would have no config of its own, it would just read the navigation information attached to the Site that the View is in.  The benefit of this approach is that it gives the user more control, and it can be placed wherever they want in the view.  The downside is that it looks different in every context, and will be hidden completely sometimes for Views that have access in their own right.  There is no smart way to display a preview of this block in edit mode.
Line 67: Line 67:
 
</div><div id="section_10">
 
</div><div id="section_10">
  
====== 2.  Automatically generated navigation that is not editable by the user ======
+
======2.  Automatically generated navigation that is not editable by the user======
  
 
The benefit of this approach is that it's much simpler to implement, and less confusing for the View owner.  The downside is that it's less flexible, and might be hard to layout in a way that isn't too obtrusive.  We could use the strip along the top, but horozontal space is not necessarily very good for tree-style navigation.  We could use tabs and subtabs, similar to the Mahara navigation itself, but that too might not scale for views with many pages.  We could also do it in a block-style tree approach.  One option is to give the user a config option (on the Edit Site page probably) which of these three approaches they want, but this is a lot more work.
 
The benefit of this approach is that it's much simpler to implement, and less confusing for the View owner.  The downside is that it's less flexible, and might be hard to layout in a way that isn't too obtrusive.  We could use the strip along the top, but horozontal space is not necessarily very good for tree-style navigation.  We could use tabs and subtabs, similar to the Mahara navigation itself, but that too might not scale for views with many pages.  We could also do it in a block-style tree approach.  One option is to give the user a config option (on the Edit Site page probably) which of these three approaches they want, but this is a lot more work.
Line 73: Line 73:
 
</div></div></div><div id="section_11">
 
</div></div></div><div id="section_11">
  
==== Technical Implementation ====
+
====Technical Implementation====
  
 
We will create new tables, site_access*, identical to the view_access* tables, but to hold site access.
 
We will create new tables, site_access*, identical to the view_access* tables, but to hold site access.
Line 81: Line 81:
 
<div id="section_12">
 
<div id="section_12">
  
===== site =====
+
=====site=====
  
 
The site table will contain id, owner, ownerformat, title, description, group, institution, startdate, stopdate, ctime, atime, mtime and submittedgroup just as in the view table.
 
The site table will contain id, owner, ownerformat, title, description, group, institution, startdate, stopdate, ctime, atime, mtime and submittedgroup just as in the view table.
Line 87: Line 87:
 
</div><div id="section_13">
 
</div><div id="section_13">
  
===== site_tag =====
+
=====site_tag=====
  
 
The site tag will just be the same as the other _tag tables.
 
The site tag will just be the same as the other _tag tables.
Line 93: Line 93:
 
</div><div id="section_14">
 
</div><div id="section_14">
  
===== site_structure =====
+
=====site_structure=====
  
 
This table holds the list of Views that make up the Site, with hierarchy information and a flag as to which is the default View.  It probably makes sense to materialise the path for a nested structure (like 1/6/7) so we can retrieve information in the correct order without having to order it in php.  When editing the structure, it is simplest to empty and repopulate this table so that the records can be inserted in the correct order.
 
This table holds the list of Views that make up the Site, with hierarchy information and a flag as to which is the default View.  It probably makes sense to materialise the path for a nested structure (like 1/6/7) so we can retrieve information in the correct order without having to order it in php.  When editing the structure, it is simplest to empty and repopulate this table so that the records can be inserted in the correct order.
Line 99: Line 99:
 
</div></div><div id="section_15">
 
</div></div><div id="section_15">
  
==== Outstanding questions and statements ====
+
====Outstanding questions and statements====
  
 
<div id="section_16">
 
<div id="section_16">
  
===== Site and Institution Views =====
+
=====Site and Institution Views=====
  
 
This structure will work well for creating sites out of user views.  There is no reason it shouldn't work in a very similar way for group views, but at this time it doesn't make sense to implement for site views or institution views, as they're only being used for templates.  Once we build support for creating Site Views to be used for CMS-style functionality, it will make sense to implement this there as well.  This is out of scope for this specification.
 
This structure will work well for creating sites out of user views.  There is no reason it shouldn't work in a very similar way for group views, but at this time it doesn't make sense to implement for site views or institution views, as they're only being used for templates.  Once we build support for creating Site Views to be used for CMS-style functionality, it will make sense to implement this there as well.  This is out of scope for this specification.
Line 109: Line 109:
 
</div><div id="section_17">
 
</div><div id="section_17">
  
===== View Copying =====
+
=====View Copying=====
  
 
The subject of copying sites hasn't been yet discussed. It could be implemented but is out of scope of this specification
 
The subject of copying sites hasn't been yet discussed. It could be implemented but is out of scope of this specification
Line 115: Line 115:
 
</div><div id="section_18">
 
</div><div id="section_18">
  
===== LEAP2A support =====
+
=====LEAP2A support=====
  
 
A discussion is underway with the LEAP2A community about this but we suspect this will be an extension of a selection, perhaps with some Mahara LEAP2A extensions.
 
A discussion is underway with the LEAP2A community about this but we suspect this will be an extension of a selection, perhaps with some Mahara LEAP2A extensions.

Revision as of 18:21, 12 May 2011

Please visit Multipage Views Take Two after reading this document, it contains the updated specification

Preamble

Being able to group views together into mini "websites" is an oft-requested feature in Mahara.  Not only does it provide a way for users to layout their content in a more comprehensive way for larger views, but it also enables them to add access at the "website" level without having to duplicate it across many different views of related content.

New Terminology

Site

We will introduce a new top-level item, which will be called "Site". A site is a list of views (which may be renamed to "Page"), together with some structured navigation, which can include a nested hierarchy.

Implementation Notes

Views can be in more than one website.  Access can still be given on the View level, even if a View is in one or more websites.  We will have a new (optional) URL parameter "site" for view/view.php, and if it is present, access will be checked on the site level, not the View level.

Some viewtypes are not able to be put into a website (for example profile views) - since viewtypes are not pluggable, this will just be maintained in a static final data structure on the View class.

Nesting navigational structure is able to be defined, but this has no semantic meaning other than for organisational purposes.

User Interface

Adding/Editing Sites

We will introduce a new second level navigation item, "My Sites" under "My Portfolio".  On this page will be listed the current Sites the user has, with controls to add, delete, edit details edit, edit access.  The page will be very similar to the My Views page.

The Edit Details screen will include the name, description and tags.  It will look extremely similar to the Add/Edit View Details screen.

The Edit screen will allow the user to pick which Views make up the site, arrange their navigational structure, and "bless" one as the Default Page (similar to index.html in a website), which will be displayed by default when someone views the Site.

The Edit Access screen will be almost identical to the Edit View Access screen.

Changes to My Views

There will be no changes to My Views, except a banner at the top of the access screen explaining that any Site access will override the View access when the View is being looked at independent of whatever site(s) it is in.

Displaying My Sites

We will write a new blocktype, "My Sites" which will be very similar to the "My Views" block, and can be placed on the profile View.

In-Site Nagivation

We have two different options for how to deal with Site navigation while looking at a View in the site:

1. A navigation block manually added by the user

This would be added manually to any Views by the View owner, and would display something different, depending on what context the View is viewed in.  The block would have no config of its own, it would just read the navigation information attached to the Site that the View is in.  The benefit of this approach is that it gives the user more control, and it can be placed wherever they want in the view.  The downside is that it looks different in every context, and will be hidden completely sometimes for Views that have access in their own right.  There is no smart way to display a preview of this block in edit mode.

2.  Automatically generated navigation that is not editable by the user

The benefit of this approach is that it's much simpler to implement, and less confusing for the View owner.  The downside is that it's less flexible, and might be hard to layout in a way that isn't too obtrusive.  We could use the strip along the top, but horozontal space is not necessarily very good for tree-style navigation.  We could use tabs and subtabs, similar to the Mahara navigation itself, but that too might not scale for views with many pages.  We could also do it in a block-style tree approach.  One option is to give the user a config option (on the Edit Site page probably) which of these three approaches they want, but this is a lot more work.

Technical Implementation

We will create new tables, site_access*, identical to the view_access* tables, but to hold site access.

There will also need to be:

site

The site table will contain id, owner, ownerformat, title, description, group, institution, startdate, stopdate, ctime, atime, mtime and submittedgroup just as in the view table.

site_tag

The site tag will just be the same as the other _tag tables.

site_structure

This table holds the list of Views that make up the Site, with hierarchy information and a flag as to which is the default View.  It probably makes sense to materialise the path for a nested structure (like 1/6/7) so we can retrieve information in the correct order without having to order it in php.  When editing the structure, it is simplest to empty and repopulate this table so that the records can be inserted in the correct order.

Outstanding questions and statements

Site and Institution Views

This structure will work well for creating sites out of user views.  There is no reason it shouldn't work in a very similar way for group views, but at this time it doesn't make sense to implement for site views or institution views, as they're only being used for templates.  Once we build support for creating Site Views to be used for CMS-style functionality, it will make sense to implement this there as well.  This is out of scope for this specification.

View Copying

The subject of copying sites hasn't been yet discussed. It could be implemented but is out of scope of this specification

LEAP2A support

A discussion is underway with the LEAP2A community about this but we suspect this will be an extension of a selection, perhaps with some Mahara LEAP2A extensions.

Files

  • Mahara-sites.png