MoodleDocs - User contributions [en]

Talk:Outcomes stage2

2013-04-04T09:09:24Z

Ralfh:

Outcomes stage 2 should be related with the badges development and global reports about
- user course enrolements
- global report about status in course
- report for user groups based on cohorts or user profile criteria (like department)

The report should include courses they rae unenrolled from or courses are deleted. So it will be possible to create a user history.

We should think outcomes not only in dimensions of schools. They are also relevant in corporate environments.
Ralf Hilgenstock 2013/04/04

Talk:Outcomes stage2

2013-04-04T09:08:50Z

Ralfh: Created page with "Outcomes stage 2 should be related with the badges development and global reports about - user course enrolements - global report about status in course - report for user groups..."

Talk:Files usability 2.3

2012-02-20T12:52:19Z

Ralfh:

Another nice usability idea: MDL-23044 thumbnails in the filepicker in more cases (My private files, Server files, Recent files and File system repository would be the obvious ones to add.)

Comment for C5: Server Files by Ralf Hilgenstock
- Show only courses where user has access to
- Course category names are often not in aware, so they could be hidden
- User expect that all fields used in course context are available here. This includes activities and ressources. What happens with third party modules?

Comment for D2: Add the ability to "replace" files by Ralf Hilgenstock
We discussed this with lots of clients. File versioning is not so easy to handle even if same files are used by several users.
Some cases:
.- Teacher 1 adds a file to several courses and wants to update the file in all courses. That is the standard situation. Mostly s/he is aware where the file is been used.
.- Teacher 2 adds a file to a long term syllabus to course 1a and has a course 1b with same topic in the next term. The syllabus is been updated for the course 1b and the file has the same name. The new syllabus should be used in courses 1b only. It should not be changed accidentially in course 1a.
.-Teacher 3 adds a file to his course. Student 1 reads the document this week. During weekend a new version is been uploaded and replaced the first one. Student 2 reads next week version 2. At the end of week the teacher discusses the document in the class and students will be confused because they red different versions.
.-Teacher 4 adds a document into a course. Teacher 5 takes the document into its own course via server files. Teacher 4 updates the document. S/he is not aware that Teacher 5 also uses the document. Teacher 5 don't get an information that the document is been updated and is confused if students read different content

During the discussions we found that teacher don't understand the the complexity of versioning of documents until its defined for different situations. Some aspects:
- who is document owner and who can update
- can I predefine what happens with a document that I initially upload to the pool/course/activity (i.e. never update, always update in own contexts, always update in other users contexts, select replacement individually per context where it is been used, send notification to all users with information about changes)
- is there a notification about all contexts where a document is used
- can I choose replacement for the different contexts
- did other users of a document get a notification if some else updated the document.

Talk:Files usability 2.3

2012-02-20T09:15:55Z

Ralfh:

Talk:Files usability 2.3

2012-02-20T09:15:24Z

Ralfh:

Another nice usability idea: MDL-23044 thumbnails in the filepicker in more cases (My private files, Server files, Recent files and File system repository would be the obvious ones to add.)

Talk:Files usability 2.3

2012-02-20T09:14:29Z

Ralfh:

Interface guidelines

2009-03-11T13:04:21Z

Ralfh:

This document is not authoritative, it is a collection of ideas and under construction.

==Keeping it simple==

Use the minimum interface required to get the job done.
Order the elements by contexts. Give the user a strong orientation where the places are to do several things.

==Standard pages==

===Activity modules===

*''index.php'' - lists all instances for that module in a course
*''view.php'' - displays a particular instance
*''config.html'' - configure an instance of the module

===Blocks===

*''config.html'' - configure an instance of the block

==One script per major function/page==

...

==Page layout==

# Print headings with print_heading, use the CSS hooks for IDs and Classes
# Print boxes around text using print_simple_box, use the CSS hooks for IDs and Classes

==Form layout==

# Show the more important settings at the top
# Each entry should have a label, and if necessary, a help file
# If there are more than 10 options, split them into required and optional/extra/advanced parameters

==Dealing with tables==

Use the print_table function whenever possible.

==Standard navigation tools==

# All pages should call print_header, and supply a standard navigation path to be displayed in it. Where possible, it should look like: COURSE >> INDEX >> INSTANCE >> SUBPAGES...
# Pages within activity modules should call navmenu() to generate the appropriate navigation menu.

==URLs==

# URLs should be as short as possible.
# No underscores in parameter names or files names
# Never use two words when one would do.

==Buttons vs links==

This is a hard one to define ...

The Google Web Accelerator issue definitely provides some pointers here:

# Actions which can modify the state of Moodle (data files, database, session information) should be performed through buttons
# At the very least, such actions which are implemented as links should forward to a confirmation page which *does* use buttons

==Language strings==

# Use your own language strings in a separate file. Don'tuse existing language files from moodle.php or other lang files. So translators can translate in the contexts in different ways as terms are used in the special learning culture.

==CSS naming==

* Don't add font, color or layout definitions in code. This belongs to CSS theme files.
* See [[Standards|theme standards]]

==Linking to help==

* Help buttons should be on the right of the thing (as an exception it can be left, if the thing is right-aligned)

==Related topics==

Robin Good's Latest News. "Interaction Design Meets Online Real Estate" 1 Mar. 2005 http://www.masternewmedia.org/news/2005/03/01/interaction_design_meets_online_real.htm

The article presents a view of virtual spaces with the focus on human actions. It reminded me of communicative approaches like Moodle. The interface serves as the handle of all the communication tools.

[[pt:Guia para interface]]
[[es:Manual de estilo de la interfaz]]
[[ja:インターフェースガイドライン]]

Interface guidelines

2009-03-11T12:59:11Z

Ralfh: /* Keeping it simple */

This document is not authoritative, it is a collection of ideas and under construction.

==Keeping it simple==

Use the minimum interface required to get the job done.
Order the elements by contexts. Give the user a strong orientation where the places are to do several things.

==Standard pages==

===Activity modules===

*''index.php'' - lists all instances for that module in a course
*''view.php'' - displays a particular instance
*''config.html'' - configure an instance of the module

===Blocks===

*''config.html'' - configure an instance of the block

==One script per major function/page==

...

==Page layout==

# Print headings with print_heading, use the CSS hooks for IDs and Classes
# Print boxes around text using print_simple_box, use the CSS hooks for IDs and Classes

==Form layout==

# Show the more important settings at the top
# Each entry should have a label, and if necessary, a help file
# If there are more than 10 options, split them into required and optional/extra/advanced parameters

==Dealing with tables==

Use the print_table function whenever possible.

==Standard navigation tools==

# All pages should call print_header, and supply a standard navigation path to be displayed in it. Where possible, it should look like: COURSE >> INDEX >> INSTANCE >> SUBPAGES...
# Pages within activity modules should call navmenu() to generate the appropriate navigation menu.

==URLs==

# URLs should be as short as possible.
# No underscores in parameter names or files names
# Never use two words when one would do.

==Buttons vs links==

This is a hard one to define ...

The Google Web Accelerator issue definitely provides some pointers here:

# Actions which can modify the state of Moodle (data files, database, session information) should be performed through buttons
# At the very least, such actions which are implemented as links should forward to a confirmation page which *does* use buttons

==CSS naming==

* See [[Standards|theme standards]]

==Linking to help==

* Help buttons should be on the right of the thing (as an exception it can be left, if the thing is right-aligned)

==Related topics==

Robin Good's Latest News. "Interaction Design Meets Online Real Estate" 1 Mar. 2005 http://www.masternewmedia.org/news/2005/03/01/interaction_design_meets_online_real.htm

The article presents a view of virtual spaces with the focus on human actions. It reminded me of communicative approaches like Moodle. The interface serves as the handle of all the communication tools.

[[pt:Guia para interface]]
[[es:Manual de estilo de la interfaz]]
[[ja:インターフェースガイドライン]]

Talk:Very flexible block system proposal

2009-02-11T23:09:45Z

Ralfh: New page: Hi Tim, very good ideas. Can you add the option to show course blocks in every activity as default setting by this development. It seems inconsistent that some activities/ressourse suppor...

Hi Tim,

very good ideas. Can you add the option to show course blocks in every activity as default setting by this development. It seems inconsistent that some activities/ressourse support blocks and others don't do it.

Ralf

Moodle-specific customisations to the HTML editor

2007-07-29T21:29:03Z

Ralfh: /* Summarly of the customisations we already know about */

In [http://moodle.org/mod/forum/discuss.php?d=76912 this forum thread] I summarise the position we have got ourselves into with the HTML editor. Moodle uses a WYSYG HTML editor called HTML area, which is now discontinued. We really want to switch to one of three other choices, but before we can do so, we need to work out exactly which Moodle-specific customisations we have made to HTML area to integrate it with Moodle, so we can make the same customisations to whichever editor we adopt in its place.--[[User:Tim Hunt|Tim Hunt]] 12:57, 29 July 2007 (CDT)

==Summarly of the customisations we already know about==

# Integrate the add image dialog with the Moodle course files area.
# Integration with Moodle's internationalisation system, instead of HTMLarea's one. Done via lang/en.php.
# Changes to integrate with roles and capabilites.
# Accessibility changes in Moodle 1.8, including making the editor code XHTML strict.
# Bug fixes.
# Usability. Should use the same processes like moodle uses at other places.

Hopefully any replacement editor we choose will follow accessibility best-practice and have known bugs fixed, 4) and 5) should not be required when integrating a new editor. However, we shoud audit the code of any new editor to make sure it is XHTML strict.

3) we should be able to find all the ways capabilites are used in the current editor by searching for the has_capability calls.

2) Will have to be redone, but is pretty trivial. (but not completed in existing editor (3thrd row of menu is not translatable)

1) is the only potentially difficult one.

6) Today the logic of file management in HTML editor is an other one than at the moodle file manager (i.e. Editor: choose file by click on the file name, File management: choose file by click on action). If it is not possible we have to think about the process in Moodle file manager.

==Three possible replacements==

All three of these are widely used by other open source projects, are under active development, with a release since May 2007.

Of these, only TinyMCE currently claims to support Safari, although FCK is aiming at it, and give a good justification why it is not there yet: http://dev.fckeditor.net/wiki/Compatibility

===[http://tinymce.moxiecode.com/ TinyMCE]===

LGPL licensed

===[http://xinha.webfactional.com/ Xinha]===

When HTMLarea was discontinued, this project was set up to continue development. Approximately BSD licenced.

===[http://www.fckeditor.net/ FCKeditor]===

GPL, LGPL or MPL tri-licence. I once talked to some people who had successfully got FCK editor working with moodle.

==Detailed analysis of Moodle-specific changes from the CVS logs==

===Unmodified files===

These were checked in to their current location (lib/editor/htmlarea) on 3rd April 2006 with the comment "Moving old editor to htmlarea folder." by [http://moodle.org/user/view.php?id=4057&course=5 Janne Mikkonen], who is the default assignee of editor bugs in the tracker.

I don't yet know where these files lived before the move, so I can't look further back in history than this yet.

From the readme, the code is based on HTMLarea 3.0 beta.

* images/* (except for images/kbhelp.gif).
* lang/en.js
* popups/about.html
* popups/blank.html
* popups/dialog.css
* popups/editor_help.html
* popups/popup.js
* dialog.js
* htmlarea.css
* index.html (blank file)
* license.txt
* popupdiv.js
* popupwin.js (well there were some changes, but only to the language of some comments.)
* release-notes.html

===Files with only XHTML strict and bugfix changes===

* popups/createanchor.php
* popups/dialog_ins_char.
* popups/dialog_ins_smile.php
* popups/fullscreen.js
* popups/insert_image_std.php
* popups/insert_image.php
* popups/insert_table.php
* popups/link_std.php
* popups/link.php
* popups/preview.php
* popups/searchandreplace.php
* popups/select_colour.php

===images/kbhelp.gif===

Added 30th November 2006 by [http://moodle.org/user/view.php?id=86470&course=5 Vy-Shane Sin Fat] with comment "New help button for keyboard shortcuts." - part of the Moodle 1.8 accessibility work.

===lang/en.php===

This is a Moodle-specific file to make HTML area use Moodle's internationalisation system, instead of the one built into HTMLarea.

===plugins/GetHTML/get-html.js===

This plugin was added on 3rd June 2006 by Janne Mikkonen. One change since then, to fix [http://tracker.moodle.org/browse/MDL-6106 MDL-6106] by [http://moodle.org/user/view.php?id=12863&course=5 Petr Škoda].

===plugins/SpellChecker/*===

There are loads of files in here. I have not looked at them at all.

===plugins/TableOperations/*===

There are loads of files in here. I have not looked at them at all.

===coursefiles.php===

Integration with course files, obviously Moodle specific.

===htmlarea_bak.php===

What a suspicious file name. Should this really be in CVS? Has had a few minor changes made. Is quite like htmlarea.php, but with quite a lots of changes too, according to diff.

===htmlarea.class.php===

Some minor changes for XHTML-strictness.

===htmlarea.php===

Loads of changes (we are up to revision 1.20), which I have not analysed yet.