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 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 2a and 2b. 2a) Create a submit button at each end (top and bottom) would not go amiss. 2b) Create a submit button at top, bottom or both depending on the caracteristics / functionality of the page. 3b) CTRL-Enter to submit (should work for Submit, Update, Send in Ratings, etc. and evaluation is needed in case of multiple submits) 4) In this forum messageis discussed the possibility of choosing to put submit buttons at bottom or at top. Solution: 2b Reason for adopting this solution: It is more usable 2b because it has been followed the following criteria: A) Site Administration: the pages there are short and it has more sense putting the submit button at bottom. Usually they are settings page and you want to change an option so you must read all options. Moreover the pages that need to have links repeated at bottom and at top (such as Accounts > Browse list of users) they already have the links repeated B) Administration of a course: here it has more sense to have the submit option both at both ends because it is some mechanical job, the pages are long, and perhaps you know by heart the default configuration so what you want is 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 of settings, grade preferences, edit course, backup and override permissions in course. C) Administration of a course with short pages: there are some pages which are short and does not have sense to have all buttons duplicated. This is for example the case of the 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): A) 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. B) 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: A) Nested view: Left the posts correspondingly shifted in each page setting a maximum number of post per page or have several pages. B) 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) C) Optional: Collapse parts of a forum perhaps using AJAX functionality Solution: A) Nested view: posts correspondingly shifted in each page. It is set a maximum number of posts per page having a default of 30 B) Threaded view: There isn't a limit of pages Reason for adopting this solution: Nested view: as there are several posts there is a maximum number of post per page. Threaded view: 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): This pages have been changed: mod/forum/discuss.php mod/forum/lib.php At discuss.php several new parameters are declared: Discussion ID: If set, then display this post and all children. Mode: If set, changes the layout of the thread Move: If set, moves this discussion to another forum Mark: Used for tracking read posts if user initiated. Postid: Used for tracking read posts if user initiated. Perpage: Maximum number of posts per page. Page: Page to display. Then the discussion is printed At lib.php is printed the first post of the discussion
Site-Administration Link: MDL-12753 Possible solutions: 1a) 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. 1b) Use the same get_string function 2a) Add in advance the last parameter to all calls, so that only language files need be modified whenever one needs to add an abbreviation 2b) This will only be done in the languages that they are needed. Solution: To prefix every menu entry that needs a short name with the word "short_". 1b) It is used the same get_string function 2b) Just be able to call the constructor like new admin_settingpage('gradecategorysettings') and have it look for the appropiate strings and their abbreviations. Reason for adopting this solution: 1b) There is no advantage nor need to create a separate function which I think would just cause more confusion. 2b) This would make the code both more compact, easier to read/write and less error prone (no duplication of string labels). The only disadvantage is that this would not be consistent with the usage in other parts of the code base. How the problem has been solved (code): Files that have been changed: blocks/admin_tree/block_admin_tree.php (se añade function create_item) 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" was of a different color or shape the usability would be better
Link: MDL-10182 Possible solutions: 1) Change of the color: the yellow colour would catch the atention 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 better 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. 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 labeled pushbutton? What would be the logic for determining when to use an icon or a text labeled pushbutton? When the icon is understandable for the major of people, is considered that can be used. 7) 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 be consistent with them 8) Adding a help icon at the right side of "turn editing on": this button must be explained because perhaps the user don't know what he/she can do with the button. Moreover, it will catch user's attention on this button. Solution: Duplication of "turn editing on" and an addition of a help icon. Reason for adopting this solution: Adding an icon would confuse folks and colour has a meaning in Moodle in order to preserve consistency. How the problem has been solved (code):
Wiki: error message too small (not noticeable) when upload file exceed file size limit (usability)
Link: MDL-14294 Possible solutions: 1) Study the places within Moodle where there is an option to upload files and compare it with the wiki (why is it different?) Solution: Reason for adopting this solution: How the problem has been solved (code):
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 the 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 username, file size, and modified date. Solution: After studying the Moodle File Management System the solution of this issue was: Reason for adopting this solution: How the problem has been solved (code): files/index.php: change two echoes and one print_cell
Create a Bulk User Action to Force Password Change
Link: MDL-13557 Possible solutions: 1) How users are added and removed from lists with in Moodle. 2) Consistence (for example, available users on the left, selected members on the right, etc.) 3) Location of the pushbuttons so that they have a consistent and look, feel, and function. Solution: Reason for adopting this solution: How the problem has been solved (code): files/index.php: change two echoes and one print_cell
Increase use of tabs on all mod activities
Link: MDL-14632 Possible solutions: 1) Implement it with Javascript 2) Implement it with AJAX 3) Some previous study about tabs has been done Solution: Reason for adopting this solution: How the problem has been solved (code):
Ability to hide and activity or resource but still make it usable if I link to it
Link: MDL-14444 Possible solutions: 1) Some previous study about hiding has been done Solution: Reason for adopting this solution: How the problem has been solved (code):
Usability issue: send in ratings
Link: MDL-2572 Possible solutions: 1) in ratings Some previous study about send in ratings has been done Solution: Reason for adopting this solution: How the problem has been solved (code):
