Monday 13 June 2016
Moodle 3.0 upgrade
It is time for our Summer Moodle upgrade again!
On June 27th we will be upgrading to Moodle 3.0.3 (from 2.8). While the number is a big jump the differences in the platform are not too large and so should have a minimal impact on students and staff. Most of the improvements, bug fixes and security updates are internal and will not be directly noticeable.
As with the previous upgrades there will be up to one day of read-only access while the upgrade proceeds (i.e. no Turnitin submissions, course editing, forum posting etc).
Read only access will be from 09:30 until completion, sometime before 17:30. There may be a brief (less than 15 minutes of outage while the final switch over is performed).
Moodle 3.x upgrade
On June 27th 2016 we will upgrade our live Moodle instance to version 3.0.3
This will bring stability, security and performance enhancements along with upgraded integrations and plugins.
Note: we will also have Mahara upgraded to 15.10 at the same time.
Upgrade plan
It will take between 4 and 7 hours to upgrade the platform. We will plan for the Moodle site to be in read only mode from 09.30 until 17.30.
Process carried out by ULCC
0. Internal upgrade test run two weeks before actual upgrade. Any external access (firewall, SFTP) configurations are updated.
1. On the day of the update the site is placed into read only mode at 09:30
2. A clone of the site is taken and copied to new infrastructure
3. Update is applied to the new site
4. Site is checked by ULCC Support team
5. DNS switch is performed by ULCC so that the current site is switched to the new upgraded site. I.e. moodle.brookes.ac.uk goes to new site
6. Admins are added back in and site is taken out of read only mode
Note: there may be a brief (<15 minutes) outage while DNS is switched over.
Backup out Plan
1. If an error is encountered during the update they will restore service from the backup (this is allowed for in the planned downtime)
2. Post analysis will be run and new update date will be arranged
What is new in Moodle 3?
Navigation Changes
Since 2.9 Moodle has improved the UI for user profiles and homepages
My home is now Dashboard
More information can be found here https://docs.moodle.org/29/en/Dashboard
New Grades page
Students can access an overview of their grades in all courses via a Grades link in the user menu (top right of each page). This lists courses they are students in under the heading ‘Courses I am taking’. If a student clicks on a course name, they will be taken to their user report for activities in that course.
Themes
Adaptable and Klass themes added
Atto Editor
Now includes math notation
Keyboard shortcut (ctrl+K) for hyperlinks
There have been improvements in adding and configuring tables when editing text, plus there are new equations in the equation editor
Under the hood
Improvements to web services, mobile services and administration of file resources.
Ref:
Tuesday 1 December 2015
Brookes apps in Moodle
This is an overview of how we are able to make some of our 'mobile' apps available to students directly from within Moodle.
The benefit to students is that they have an opportunity to utilise the rich functionality these apps have to offer even if they don't have a mobile device (or it is currently unavailable). This aligns with Brookes' drive to extend and improve accessibility.
Our mobile apps
The benefit to students is that they have an opportunity to utilise the rich functionality these apps have to offer even if they don't have a mobile device (or it is currently unavailable). This aligns with Brookes' drive to extend and improve accessibility.
Our mobile apps
Mobile apps are, generally, either:
- 'native' - written and built for a specific mobile platform (operating system), such as Apple's iOS
- 'hybrid' - written in a more generic way, these apps can be built for several different mobile platforms or
- 'web' - written for display in a mobile's web browser
Both 'native' and 'hybrid' apps require installation on the mobile device (downloaded from app stores) and can use features of the device that may be unavailable to 'web' apps.
To simplify development and maintenance, minimise multi-platform deployment effort and maximise functionality, we have chosen to make the majority of our apps 'hybrid' ones.
Hybrid apps
The program code files for these, like many web apps, are written using the standard web-based 'languages' of HTML, CSS and JavaScript. Additional functionality, such as the capability to receive notifications sent out by Brookes, is added by means of 'plugins' (of which there are different versions for each of the different platforms).
Unfortunately, limitations and differences still mean that the code files require some tailoring for each platform but this is far less effort than would be required to deploy separate native apps.
Brookes app 'BRISC' on Android
It is this similarity with web apps, and the limited tailoring required for each platform, that encouraged us to explore the possibility of also having 'browser-based' versions of those apps that could be modified to function without the features of mobile devices.
Browser-based apps
Whereas the code files for a hybrid mobile app are installed and 'hosted' on the device itself, the files for a browser-based version need to be hosted on a separate web server.
As OBIS didn't have a suitable public-facing web server for this it was decided - initially - to make use of our Moodle web server at ULCC. As a Moodle 'plugin' is simply a packaged set of files (normally executable scripts) that can be served-up to a browser, it was feasible (with negligible overhead in regard to either space or time) to include our code files within such a plugin.
'BRISC' in a browser
Although apps served in this way functioned perfectly, because the layouts had been designed for a small screen they were really unsuitable for use within a full-screen browser. As we didn't want to overhaul the designs to such a great extent, we tried apps both inside an HTML 'iframe' and a browser 'popup' window that were nearer to the proportions of a mobile screen.
'BRISC' in an iframe
'BRISC' in a popup
Having established that apps would display and function correctly within iframes, we needed to develop and host suitable web pages to 'embed' these iframes in. We chose to include these pages within a Moodle plugin because the overall page layout could be provided by Moodle and it would be a natural place for a student to find and use the apps.
'BRISC' in Moodle
Google App Engine
Due to the lead time to get our Moodle plugins updated it was decided to move the app code files themselves to another, more flexible, hosting solution.
Consequently, we developed a simple application on GAE that provides a 'front-end' to our app code files that are now hosted there instead of on Moodle. There has been no change to the Moodle pages themselves nor to the user experience.
The future...
Expect to see more great Brookes apps ported to Moodle/GAE!
Monday 30 November 2015
BRISC Quick Start Guide
Continuing the overviews of our apps, here is BRISC (the “BRookes Individual Skills Catcher” app).
This has been developed in conjunction with the Faculty of Business but it could be invaluable to any Brookes student.
The app is designed to allow students to simply and quickly capture personal reminders of employability skills they have gained, inside or outside of their course, enabling easy recall for later use in job or placement interviews. These skills, a valuable resource, could otherwise be overlooked or forgotten.
How it works
Students access the app either directly from within Moodle (Brookes Apps -> BRISC) or by logging-in to a mobile version using their usual Brookes credentials. The relevant skill heading can then be selected either from the 'Brookes Attribute' or 'CBI/NUS' categories or from a full alphabetical list.
Previous entries can be viewed or new entries can be added. New entries will have a title, a text body (what to remember) and, if required, a URL link to a further explanation or video. If relevant, a new entry can also be associated with one of the student's current modules.
Note: the app uses standard Moodle Blogs that can also be accessed from any PC, mobile device or Chromebook. Be aware that any entries made directly via Moodle itself would need to be flagged as 'draft' (private) to ensure confidentiality.
Note: the app uses standard Moodle Blogs that can also be accessed from any PC, mobile device or Chromebook. Be aware that any entries made directly via Moodle itself would need to be flagged as 'draft' (private) to ensure confidentiality.
The mobile app can be downloaded for free from Google Play, the Apple App Store or the Windows Store.
Logging-in
Login is done with Brookes staff or student credentials, as for Moodle (staff or student number).
Logging-in
Categories
Once logged in a user will see the possible selection methods. They may then choose a skill category or a list of all skills.Skills
Entries
At this point the user can either select a previous entry to view or opt to add a new entry.
New Entry
New entries will have a title, a text body (what to remember) and, if required, a URL link to a further explanation or video. If relevant, a new entry can also be associated with one of the student's current modules.
Please note: mobile users will remain logged into the app unless they use the Logout button.
Video - BRISC Trailer
Produced by the Faculty of Business
Video - BRISC Tutorial
Produced by the Faculty of Business
Friday 20 November 2015
Moodle notification block
Use case
Periodically we need to carry out maintenance or updates to our Moodle platform hosted at ULCC. We try to only do these, especially if they pose risk to the service, during our ‘at risk’ times on Tuesday mornings 07:00 - 09:00.
In the majority of cases any work carried out does not impact the service at all but occasionally some service interruption is unavoidable. This may be a restart of the web server or a significant outage.
We propose adding a notification block to all Moodlers homepages to ensure important messages are conveyed and absorbed.
Lose case
Service unavailability that was not communicated sufficiently well has inevitably caused issues for students and staff who need access to the platform at that time, e.g. to retrieve lecture presentations before a 9am class. This notification block is our response to alleviate those issues.
Whose case
The block will be visible, when there is one or more messages to display, on student and staff My Moodle pages. It is important that all Moodlers are aware of any potential downtime well ahead of the event. Asynchronous methods of communication, such as email, are problematic in that people have an inbox overload and it is easy to miss important messages in the noise. Posting on institutional services such as our Service Desk portal and our Message of the Day news pages may not be seen.
It was felt that placing the messages in Moodle, directly on the landing page following login, would get the most eyeballs. We do not want it to be intrusive but informative and, above all, noticeable.
Choose case
The idea is a block that we will add to the default My Moodle layout so all users will see it. They can ‘opt-out’ by hiding or deleting the block but this would be discouraged. We hope that by ensuring that only important, succinct and pertinent notifications are displayed it will encourage people to notice the block when it is visible.
News case
It is envisaged that the notifications will be constrained to content that is of high importance. If generic ‘news’ is added it is likely that the effect of seeing the block will be diluted and a localised information overload will lead to glazing over when presented with posts. The appearance of the block should be a triggered call to action.
Views case
We looked at currently available solutions and found none that quite fit our requirements. We have developed a custom block that will sit above the Course Overview block on the My Moodle page.
If there are no current notifications to display the block will not be visible.
Moodle Administrators can add messages through the back end. Messages can be configured to appear in red for high impact notifications.
Each notification should be on a new line. The format of each notification should be:
{notification text}|{start date/time}|{end date/time}|{type}. date/time should be YYYY-MM-DDThh:mm. date/times are UTC. type should be one of normal, important. Example: Test notification|2015-11-18T09:00|2015-11-18T17:00|normal
This allows the addition of messages that can have specific durations so that we can automate posts ahead of time or for recurring tasks.
Tues case
We will maintain Tuesday 07:00 - 09:00 as an ‘at risk’ window for scheduled changes to the live service and encourage people, where possible, to avoid having critical events during, or directly following, this period.
Moose case
If we moose, erm, miss any important notifications we would like to remind Moodlers to check the other information services such as Message of the Day or the Service Now portal and to report any incidents via the Service Desk.
image from http://rileyandco.blogspot.co.uk
Subscribe to:
Posts
(
Atom
)