Note: You are currently viewing documentation for Moodle 1.9. Up-to-date documentation for the latest stable version is available here: Student projects/Usability issues/T5.

Student projects/Usability issues/T5

From MoodleDocs

Description of the solution of the usability problems:


Submit button at top

  • Link: MDL-4151
  • Possible solutions:
    1. Create a Movable-type interface that allows the user to specify where they want their submit button to be (at the top or at the bottom). It must be considered that option 1 can be implemented together with 2 and 3.
    2. Create a submit button at each end (top and bottom) would not go amiss.
    3. Create a submit button at top, bottom or both depending on the characteristics / functionality of the page.
    4. CTRL-Enter to submit (should work for Submit, Update, Send in Ratings, etc. and evaluation is needed in case of multiple submits)
    5. In this forum messagethe possibility is discussed of choosing to put submit buttons at bottom or at top.
  • Solution: 3
  • Reason for adopting this solution: It is more usable 3 because it has been followed the following criteria:
    1. Site Administration: the pages there are short and it makes more sense to put the submit button at the bottom. Usually they are in the settings page and in order to change an option you must read through all of them to find the one you need to change. Moreover the pages that need to have links repeated at the bottom and at the top (such as Accounts > Browse list of users) already have the links repeated.
    2. Administration of a course: here it makes more sense to have the submit option both at both ends because it is a mechanical job, the pages are long, and perhaps you know by heart the default configuration so what you want to do is save time. An example that has been changed is the backup functionality. Perhaps you want to backup the whole content of a course (which is the default configuration) so you don't have to scroll down all pages and you save time. This is the case for settings, grade preferences, edit course, backup and override permissions in course.
    3. Administration of a course with short pages: there are some pages which are short and does not make sense to have all buttons duplicated. This is for example the case for Groups. Having buttons at both sides can make the page more confusing and less usable.
  • Questionaire: Doodle page
  • How the problem has been solved (code):
    • In the backup and settings roles forms, some html lines have been added (there are two forms in the backup pages). It must be considered that it has not been added a button at top of the 3rd backup page because you should see if the backup has been done without errors.
    • In the Grade preferences and course settings php pages, it has been added
 $this->add_action_buttons()
  • The pages that have been modified are:
 backup/backup_form.html
 backup/backup_check.html
 course/edit_form.php
 admin/roles/override.html
 grade/report/grader/preferences_form.php

Multiple page view within discussion topics with ability to set max number of posts per page

  • Link: MDL-10120
  • Possible solutions:
    1. Nested view: Leave the posts correspondingly shifted in each page setting a maximum number of post per page or have several pages.
    2. Threaded view: Have several pages in this case or add a limit to the number of subjects appearing in the threaded view (probably want a larger limit).
    3. Optional: Collapse parts of a forum perhaps using AJAX functionality
  • Solution:
    1. Nested view: posts correspondingly shifted in each page. It is set a maximum number of posts per page which defaults to 30.
    2. Threaded view: There isn't a limit in the number of pages
  • Reason for adopting this solution:
    1. Nested view: as there are several posts there is a maximum number of post per page.
    2. Threaded view: no limit is set since only one post is displayed and the rest is only the subjects. The threaded view shouldn't have multiple pages, as users would be confused by this.
  • How the problem has been solved (code):
  • These pages have been changed:
 mod/forum/discuss.php
 mod/forum/lib.php
  • In discuss.php several new parameters are declared:
 Perpage: Maximum number of posts per page.
 Page: Page to display.

When trying to displaying a posts, we check whether they belong to the range of posts to be shown in the current page. Also the functions forum_print_posts_xxxx in lib.php have been changed so that they display the parent post too, which makes the code simpler and more logical.

For some languages, the strings get too long for the menu

  • Link: MDL-12753
  • Possible solutions:
    1. Create a function (eg "get_short_string(string_name)") that tries to retrieve the string_name with the prefix "short_". If found, return that one, if not, return the normal string_name value.
    2. Use the same get_string function.
    3. Add in advance the last parameter (short name) to all calls, so that only language files need be modified whenever one needs to add an abbreviation.
  • Solution: To prefix every menu entry that needs a short name with the word "short_".
    1. The same get_string function is used.
    2. A new parameter has been added to each new admin_page call.
  • Reason for adopting this solution:
    1. There is no advantage nor need to create a separate function, which would cause more confusion.
    2. It is a simple solution and does not rely on programming assumptions that should be documented (such as taking the short version equal to the long one by default if not specified).
  • How the problem has been solved (code): Files that have been changed:
 blocks/admin_tree/block_admin_tree.php
 lang/en_utf8/admin.php
 lib/adminlib.php 
 shortvisiblename is the short version of the visible name (used for the menu)
 adding shortvisiblename in the function function admin_category, admin_externalpage and
 function admin_settingpage
 lib/moodlelib.php
 Addition of function get_string($identifier, $module=, $a=NULL, $extralocations=NULL)

If the "Turn editing on" were of a different color or shape the usability would be better

  • Link: MDL-10182
  • Possible solutions:
    1. Change of color: the yellow colour would catch the attention of the user quickly but the meaning of the colours must be respected so this solution would not be the most consistent.
    2. Duplication of turn editing on: as it is duplicated in the administration menu of the main course page, it should be also duplicated in the grades page in the "choose action menu" as the first selection.
    3. Might we save some screen real estate by using an editing icon instead of the text 'Turn editing on'? The turn editing on button could change the colour depending on the state. Perhaps the best one would be yellow when it is on (so it would be more visible) and white if it's off.
    4. Would an icon confuse folks or be more consistent with how we use the editing icon in the gradebook? The international icon for on / off is Onofficon.jpg. So I would use this icon and the word "editing" as a substitute of "turn editing on". As this would be long I think this will confuse folks.
    5. When do we use an icon and when should we use a text labelled pushbutton? What would be the logic for determining when to use an icon or a text labelled pushbutton? When the icon is understandable for the major of people, is considered that can be used.
    6. Are there any UI standards that address these kinds of issues? There is a standard "ISO/IEC 11581 Icon symbols and functions" where some standard icons have been defined. Moreover, icons can be checked at /server/moodle/pix in order to check for consistency.
    7. Adding a help icon at the right side of "turn editing on": this button must be explained because perhaps the user doesn't know what he/she can do with the button. Moreover, it will draw user's attention on this button.
  • Solution: Duplication of "turn editing on" and addition of a help icon.
  • Reason for adopting this solution: Adding an icon would confuse folks and colour has a predefined meaning in Moodle to preserve consistency.
  • How the problem has been solved (code): to be done.

Wiki: error message too small (not noticeable) when upload file exceed file size limit (usability)

  • Link: MDL-14294
  • Possible solutions: Study the places within Moodle where there is an option to upload files and compare it with the wiki (why is it different?)
  • Solution: Ideally it should be only two types of uploading files:
    • The simple one: that would be applicable to Files, Frontpage Site Files, Import, Frontpage Questions and Upload users / upload user pictures. This interface would contain: An indication of the max size with a help question, browse, upload, cancel and [Other information depending on the type of upload file]
    • The detailed one: that would be applicable to wiki pages and other activities and resources (should not be changed)
  • Reason for adopting this solution: there are too many interfaces to upload a file and that confuses the user and they can be grouped in a simple and detailed way to upload a file.
  • How the problem has been solved (code): the colour of the error message has been changed but the major changes of the upload files interface remain to be done

Usability Problem with Moodle File Management System

  • Link: MDL-9513
  • Possible solutions:
    1. Most logical, consistent ordering of columns (how can we be consistent with other file management systems?)
    2. Would users prefer to have icons for rename, delete, unzip, list, restore or words?
    3. Another improvement would be the ability to click on the column headings to sort the files by username, file size, and modified date
  • Solution:
    • Most logical order: name, size, modified and rename
    • They would prefer icons because this icons have already been used in Moodle
    • It should be possible to click on the column headings to sort the files username, file size, and modified date
  • Reason for adopting this solution: explained at Moodle File Management System
  • How the problem has been solved (code):
 files/index.php: change two echoes and one print_cell
 to be done other issues talked about in this usability problem

Create a Bulk User Action to Force Password Change

  • Link: MDL-13557
  • Possible solutions:
    1. How users are added and removed from lists within Moodle
    2. Consistency (for example, available users on the left, selected members on the right etc.)
    3. Location of the pushbuttons so that they have a consistent look, feel, and function
  • Solution: Ideally there should be only two types of uploading files:
    • The simple one: that would be applicable to networking elements.
    • The detailed one: that would be applicable to other enrolment pages.

The checkbox next to the eye and question mark button should be removed.

Increase use of tabs on all mod activities

  • Link: MDL-14632
  • Possible solutions:
    1. Implement it with Javascript
    2. Implement it with AJAX
    3. Student_projects/Usability_issues/Tabs
  • Solution: Implement it with AJAX. Add and reorganize the tabs mentioned in the study. Highlight the tab selected option.
  • Reason for adopting this solution: AJAX increases responsiveness. Now tabs and buttons are combined and pages are not usable. The tab selected option is not highlighted and this can cause confusion when the tab number is high (and from now it will become higher).
  • How the problem has been solved (code): to be done

Ability to hide and activity or resource but still make it usable if I link to it

  1. The icon displays the current value, but if you put the mouse over the icon, the description is about the value to be implemented.
  2. When hoving the mouse over the show / hide icon, it should say "hide this week for students", not just hide. The whole information about the hiding must be displayed.
  3. When you show / enable something, the colour of the description should turn black or dark blue. If you hide / disable something, the colour of the description should turn into grey or light blue.
  4. Recommendation: it would be more standard and usable to change the visible / hide icon for a textbox "view" and a stand-alone checkbox in order to select if it's visible or not, at list in the tables where icons are not necessary because there is enough space.

Usability issue: send in ratings

  • Link: MDL-2572
  • Possible solutions: Student_projects/Usability_issues/Sendinratings
  • Solution: It would be better if there are two types of grading:
    • Type of grading 1: Includes the gradebook and quick grading that would have the following fields: Information about the user and time, Grade, Feedback, excluded, hidden, hidden until, locked, locked after, feedback, format, html format (that is all the information of the gradebook and the quickgrading).
    • Type of grading 2: Used in the Forum rating, you can grade (often you chose the grade with a select box) and a link to the first type of grading.
  • Reason for adopting this solution: explained at Student_projects/Usability_issues/Sendinratings
  • How the problem has been solved (code): to be done

It seems that group mode is not yet (fully?) implemented in Metacourses. I would appreciate very much this feature. An extension of "separate group mode" on all resources and activities would add even more usability for moodle use in multiclass-multiteach

Category Titles in Courses Block

  1. Courses - Indexing: it is not strictly necessary to index the courses alphabetically mostly because course hierarchy is possible (thanks to metacourses). However, it would be useful indexing by the name of the first level of the hierarchy.
  2. Courses - Sorting: in some cases could be useful to sort alphabetically (specially when the number of courses is really big or teachers don't know how to use metacourses functionality). So sorting aphabetically could be a desirable option.
  3. Courses - Filtering: the filtering of courses is really poor. Courses should be filtered by teacher, by group or by date of creation.
  4. Students - Filtering: perhaps it would be useful to filter students alphabetically and by group (specially when the number of courses is really big)
  5. Participants - Filtering: perhaps it would be useful to have a general search so participants could be searched per name / surname.
  6. Questions - Filtering: it would be useful to search by group (several groups can be associated to a course)
  7. Recent activity - Indexing: it would be more usable if there would be some indexing. This would be indexing chronologically by name (1 day ago, 1 week ago, etc.) when sorting by date is selected; and indexing by the name of the first level of the hierarchy when it is sorted by name.
  8. Recent activity - Filtering: it would be useful to filter by group.

Another task would be changing "front page" of the admin menu by "home page" or "site home page".

Add an "add to contact list" button in the profile viewing page

  1. Profile: general information(which contains photo and photo description, country, city / town, email address, phone number, web page and interests), contact information (which contains icq number, skype id, yahoo id, aim id, msn id) and Moodle information (which includes courses, last access, roles)
  2. Edit profile (with a set of privacy options to each group of items such as general information etc. associated to each group i.e. teacher, student, people from the contact list, etc.)
  3. Messages: inbox, contacts (here all contacts are displayed and can be filtered by name, role, group, interests, city or country), search (it would contain the current search options plus the search options mentioned for the contacts submenu) and here there is a button to import contacts from other applications (gmail, facebook, linkedin, flickr, windows live hotmail, hi5,...), settings and history
  4. Chat: online contacts, set status (busy, invisible, out of chat, other), chat history
  5. Forum posts: in a summary table version (title, date of the last reply, and number of replies)
  6. Blogs
  7. Activity reports (bookmarks, uploads/assignments/projects, wiki articles)
  8. [For the admin role: Roles]

Access control for moodle file directory

  1. Grading system
  2. Making comments
  3. Adding an entry of an activity
  4. In the description of the activity
  5. Import all the information of the activity module

Next after making the table of comparison of where files are uploaded at activity modules, it will be mentioned the places where uploading a file could be possible:

  1. Glossary: it should be possible to attach a file to the grading of the glossary not only from the grading system but also from the activity module.
  2. Chat: it should be possible to upload a file from the chat (while chatting) or at least a link that allows to send a message from the chat.
  3. Choice: it should be possible to give feedback and upload a file, and import the information of the choice questions.
  4. Lesson: it should be possible to comment a lesson with been able to upload an image.
  5. Survey: it should be possible to comment a survey with been able to upload an image. Moreover it should be able to attach an image to the description of the survey.
  6. Wiki: perhaps it should be possible to import a wiki with XML.
  7. Journal: it should be possible to comment a journal and attach a file if wanted.
  8. Workshop: it should be possible to attach an image to the grading (now this functionality is not available).
  9. Hot potatoes: it should be possible to attach a file to the grading of the hot potatoes not only from the grading system but also from the activity module.
  10. Moreover the uploaded file must follow the guidelines described at File Repository API

Help popups should display a navigation toolbar

  1. Add a short sentence to describe what he/she could find at the help file.
  2. Make a summary of the content of the help icon.
  3. Make a demo would be really valuable mostly for novice. There are several places where users can view demos which are not exclusive: Moodle Docs page of the demo, a tutorial page, in the pop up of the help menu and to a new popup that opens when clicking the video help icon (which would be next to the help icon)
Retrieved from "https://docs.moodle.org/19/en/index.php?title=Student_projects/Usability_issues/T5&oldid=42324"
Powered by MediaWiki