My Moodle 2.0: Difference between revisions

Latest revision as of 11:02, 26 August 2013

Moodle 2.0

Goals

To make the "My Moodle" interface a more usable space that provides each user with their own personal experience. The page should be a user's personal portal page in Moodle. My Moodle will be the place where information that is user-centric rather than course-centric will be displayed.

Portions of the My Moodle interface should be able to be made customizable by the individual users. Other portions should be able to be locked to certain roles.

It's also the place where you change your preferences and settings.

It should utilize current Moodle constructs such as blocks, themes and pages.

The user's profile page should be able to be configured by the user to allow choice of what can be displayed. This also should be manageable at the admin level.

Scope

Subpages (Canvases):
- Tabs in the diagram (navigation style themeable?).
- Should come with pre-defined pages for:
  - profile,
  - course list,
  - blog ,
  - reports,
  - home page / dashboard.
- Page can define whether blocks can be moved.
- Possibility for plug-in pages.
- Possibility for user added pages / canvases.
- Access to pages should be available – requires context (maybe implement later).
- Capabilities should be available – that is, standard pages may or may not be configurable to given roles.
Blocks:
- Like normal blocks.
- Whether or not they can be visible on My Moodle should be configurable.
- Some should be able to be added, moved and configured by any user.
- Need to able to be displayed in middle portion.
- Possible to define valid subpages they can be on

Solutions

Review drawings in MDL-19124 for ideas of how this could look.

Subpages

(Consider calling these "canvases" instead of subpages)

These are the actual pages that can contain the functions and blocks in the My Moodle interface. In the referred drawings, each of these would be a tab.

Each of these is a canvas that can be painted with blocks. The blocks would need to know which page they belonged to. By using blocks, issues such as the way a page looks, or the way information is ordered on a page, becomes an issue associated with the block and not with My Moodle itself.

Initially, My Moodle could come with specific pages:

home page / dashboard - A completely user configurable page where the informational blocks can be added and moved. User could have items such as news-feeds, calendars, etc.
profile - The same function that currently exists on the user profile page. If allowed on the site, provide options for the user to assign what information can be visible by what roles.
blog - Access to the user's blog (like the current tab on the user profile page).
course list - A better version of the current My Moodle page.
report - Access to various reports and logs on your activities.

Each page would be available to be enabled or disabled to the My Moodle interface.

Further Expansion

Adding a level of pluggability for subpages or canvasses would create an even more configurable experience for the user. Subpage plug-ins could be made available by simply dropping in a standard file layout into a My Moodle subdirectory, like reports. Even more could be provided by allowing users to create new instances of blank pages for their own My Moodle that they could then configure in any way they want.

This will add the extra burden of maintaining a page table per user to track whatever pages have been added to My Moodle for each user.

Subpages will require contexts, so that roles can be given different capabilities (CONTEXT_MYPAGE ?). (These could be extended contexts as described here: MDL-20045). Capabilities would allow some pages to be re-configured by certain roles and not others. This would allow administrators to set up 'locked' pages that would always be the same layout for all users.

Blocks

Any of the content on a My Moodle page should be able to be handled with blocks. The positioning of them is what is important.

My Moodle will add a 'content' region to display the centre block area.

Blocks should be able to specify whether they are eligible for "My Moodle" inclusion (through applicable_formats method). Additionally, they should be configurable to be eligible for specific sub-pages (this may be possible through the same function). Should this also be an administrative function?

Technical Plans

three types of pages: "dashboard", "public profile", and "course profile"
use navigation block instead of tabs

dashboard pages

/my/index.php
only users can see their own
users can customize freely
users can add their own pages
link to page for changing settings (in settings block)
admin can define default blocks that users can remove

public profile pages

/user/profile.php
everyone can see everyone's profile
admin can define blocks that are always seen
- users cannot delete these blocks
users can add new blocks (if they have the capability)

course profile

/user/view.php
picture, description, general information, private information (only displayed to teachers)
link to full public profile
- controlled by code (no editing by any users)

Other considerations

block permissions
- change accesslib to add role to user when in their own user context

@@ Line 70: / Line 70: @@
 ==Technical Plans==
-* allow users to see other users' My Moodle pages (subject to access control -- see below)
+* three types of pages: "dashboard", "public profile", and "course profile"
+* use navigation block instead of tabs
-===Blocks===
+===dashboard pages===
-* mdl_block_instances database entry
+* /my/index.php
-** blocks on a specific user's page, in a specific place: parentcontextid=user's context ID; showinsubcontexts=0; pagetypepattern="my-index"; subpagepattern=canvas name; defaultregion=side-pre/content/side-post
+* only users can see their own
-** block on all user's pages: parentcontextid=1 (system context); showinsubcontexts=0; pagetypepattern="my-index"; subpagepattern=canvas name; defaultregion=side-pre/content/side-post
+* users can customize freely
-* blocks may choose to display different content/different layout depending on what region they are in (e.g. if they are in the "content" region, vs. one of the side regions)
+* users can add their own pages
-** The region that a block is in can be obtained by $this->instance->region (is this the best way to find this out, or should there be an API call?)
+* link to page for changing settings (in settings block)
-* blocks can know which user's My Moodle page is being viewed through $PAGE->context.
+* admin can define default blocks that users can remove
-===Subpages===
+===public profile pages===
-* need a new database table: "mdl_my_subpages"(?) that stores
+* /user/profile.php
-** user ID of the subpage owner (or 0 for site-wide pages)
+* everyone can see everyone's profile
-** page name
+* admin can define blocks that are always seen
-** private/public
+** users cannot delete these blocks
-** locked? (for site-wide pages only)
+* users can add new blocks (if they have the capability)
-* start with a set of predefined subpages
-** user profile
-** my course list (the current My Moodle contents)
-* NEED: some way of (optionally) doing localization for names of site-wide pages (e.g. profile page)
-===Access control===
+===course profile===
-* users can access other users' public pages
+* /user/view.php
-* users with "moodle/my:viewprivatesubpages"(?) capability in the user's context can view the other user's private pages
+* picture, description, general information, private information (only displayed to teachers)
-* users can add/edit their own subpages if they have "moodle/my:manageblocks"
+* link to full public profile
-* users can add/edit other users' subpages if they have "moodle/block:edit" ( or a My Moodle-specific capability?) in the user's context
+** controlled by code (no editing by any users)
-* users can add/edit site-wide pages if they have "moodle/my:editsitewidesubpages"(?) in the system context
-===Questions===
+===Other considerations===
-* what happens when a user creates a subpage with the same name as a site-wide page?
+* block permissions
-** disallow this? (problems with: site-wide page created after a user creates their page)
+** change accesslib to add role to user when in their own user context
-** display both tabs separately? (prefix site-wide page names to prevent subpage name collisions?)
-** "merge" contents? (could this present a spoofing vulnerability?)
 ==See also==

Documentation