Digital Education team blog
  • We support Staff and Students using technology to enhance education at UCL.

    Here you'll find updates on institutional developments, projects we're involved in, updates on educational technology, events, case studies and personal experiences (or views!).

    Subscribe to our elearning newsletters.

  • Subscribe to this blog

  • Meta

  • Tags

  • A A A

    Archive for the 'Digital Education' Category

    Jisc student digital tracker 2017 and BLE consortium

    By Moira Wright, on 10 August 2017

    computer-767776_1920UCL participated in the 2017 Jisc Digital Student Tracker Survey as part of a consortium with the Bloomsbury Learning Environment (BLE) made up of SOAS, Birkbeck, LSHTM and RVC. 74 UK institutions ran the tracker with their students collecting 22,593 student responses, while 10 international universities collected an additional 5,000 student responses

    We were the only consortium to participate in the survey and had come together as a result of institutional surveys, such as the National Student Survey, meaning that the time available to run it independently was short (a month) and we therefore felt that our individual sample sizes would be too small. We treated the survey as a pilot and advertised a link to it on each College’s Moodle landing page as well as some promotion via social media and the Student Unions. The survey generated 330 responses, which given our constraints was much more than we expected.

    The survey comprises five broad areas: Digital access, digital support and digital learning. Most questions were quantitatively recorded, but there were four open questions, which produced qualitative data. We were also able to choose two additional questions to the survey and we selected e-assessment, since that was a previous shared enhancement project (see www.bloomsbury.ac.uk/assessment) and Moodle, since all members of the consortium use the platform for their Virtual Learning Environment (VLE).

    Once the survey closed and we had access to the benchmarking report we ran a workshop for representatives from each of the Colleges in July 2017 whereby the results corresponding to the survey’s open questions were analysed in institutional groups, which facilitated interesting discussions over commonalities and potential implications.

    Sarah Sherman, the BLE Manager and myself, have been working to produce a report which will examine our collective responses to the survey in comparison with the national survey population with a recommendation that individual Colleges independently analyse their own results in more detail. For confidentiality, each College will be presented with a version of this document, which contains the relevant data for their institution only and not the complete BLE data set. A disadvantage of the consortium approach was that we were not able to benchmark individual Colleges to the survey population as the resources would not allow for this. In the future, the participating Colleges may wish to run the survey individually rather than as part of a collective as it was not possible to conduct deep analysis with this data set. 

    markus-spiske-221494

    Although the sample size collected by the Bloomsbury Colleges was small and not statistically viable, there is much we can extract and learn from this exercise. For the most part, our collective responses tended to fall within the margins set by the national survey population, which means we are all at a similar phase in our student’s digital capability and development.

    You will have to wait for the full report for more information on the UCL data collected but just to whet the appetite you can see the key findings from Jisc in this 2 page report: Student digital experience tracker at a glance .

    Finally, you can see this collection of case studies, which features the Bloomsbury Colleges consortium, here.

    Please get in touch with me if you would like to get involved (moira.wright @ ucl.ac.uk)

    Sarah Sherman and Moira Wright

    Jisc/ NUS student digital experience benchmarking tool 

    Jisc guide to enhancing the digital student experience: a strategic approach

     

    Cloud services enable How to Change the World student programme to go global

    By Alan Y Seatwo, on 14 July 2017

    For the last four years, the Department of Science, Technology, Engineering and Public Policy (STEaPP) has been running a two-week programme called ‘How to Change the World’ (HtCtW) for undergraduate engineering students in the Faculty as part of the Integrated Engineering Programme. The aim of HtCtW is to enable students to work in multi-disciplinary teams and collaborate to create engineering solutions to an open-ended problem linked to a particular global challenge.

    Due to the success of this format, the programme is being rolled out externally. It was piloted with members of the Royal Academy of Engineering (RAEng) in London in 2016, and now STEaPP is partnering with the RAEng and National Academy of Engineering to run a student programme for a cohort of 150 students (from China, UK and US) at the Global Grand Challenges Summit 2017 in Washington DC on 18–20 July.

    Students will generate their own audio or video podcasts exploring how solving one or more of the Grand Challenges could impact real peoples’ lives for the better. These podcasts will be reviewed and a selection will be promoted across a range of professional networks and media channels, with career-enhancing benefits for participants.

    Five members of STEaPP staff will travel to Washington DC and offer face-to-face facilitation at the Summit. In additional, the department is also offering online learning consultancy to the RAEng that enables us to develop, produce and release online learning materials to support the programme. Based on a ‘flipped classroom’ approach, we are use a combination of the Microsoft Office 365 tool and online cloud storage to set up a password-protected online portal where students can access information and reading materials to prepare for the programme. Using Dropbox’s “File Request” allows students at the Summit without an account to submit their deliverables.

    We are also working with experts in media to give the students some unique insights into how best to communicate their message. Alok Jha (ITV News Science correspondent), Dr Kevin Fong (STEaPP Honorary Lecture and BBC science programme presenter) and Oliver Morton (the Economist) have been tasked with producing an online guide on how to produce a good podcast.

    The use of a range of cloud services enable the partnership of UCL STEaPP, RAEng, British broadcast professionals and US-based organisations to work effectively together to design, develop and deliver this student programme. It is hoped that the experience of this collaborative work will help STEaPP to further develop our expertise in the use of learning technologies in both formal and informal learning curricula.

     

    Alan Seatwo

    Learning Technologist and E-Learning Champion at STEaPP

    Comparison of websites to inform the design of accessible online learning environments

    By Jessica Gramp, on 20 June 2017

    The Accessible Moodle project is looking at how UCL Moodle can be made more accessible for those with disabilities, with input from disabled students and staff. A number of recommendations have been developed to guide work on the project and address the concerns of the focus group participants.

    In order for e-learning to be accessible to all students and staff, including those with disabilities, the pages and resources contained in the Virtual Learning Environment (VLE) need to be constructed in a way that is accessible. The rules for doing this are not always straight forward to implement, so I set out to determine how others are developing their websites to meet the needs of disabled users.

    I analysed the websites of a number of leading UK government, charity and public broadcasting websites to obtain a clearer idea of how web accessibility standards can be applied in practice. These websites aspire to meet the needs of a large range of users, including those with disabilities. The websites I analysed are:

    I used the built in Chrome web page inspection functionality, and a number of browser plugins to help me determine how the web pages were constructed, including:

    The four main types of disability are:

    • hearing loss;
    • visual;
    • cognitive and neurological; and
    • mobility.

    Each of the four main types of disability are considered by at least one charity website (most of which focus on supporting that particular disability). Five of the websites aim to be accessible to people with a range of disabilities more generally, in order not to exclude members of the public, and this is also true of the websites for specific disabilities, already mentioned.

    At UCL, the majority of our disabled students have cognitive and mental health conditions (Dyslexia, Dyspraxia, Autism, long term depression etc.). However, it is important we consider all types of disability when looking at improving accessibility.

    Meeting web accessibility standards

    The World Wide Web Consortium (W3C) is an international community, led by Tim Berners Lee (father of the world wide web). The W3C runs the Web Accessibility Initiative (WAI) to develop “strategies, guidelines, and resources to help make the Web accessible to people with disabilities” (W3C).

    Part of the WAI includes the Web Content Accessibility Guidelines (WCAG) 2.0, for making web content more accessible. These recommendations are split into three levels from A to AAA. Most websites attempt to adhere to WCAG Level AA standard, “because it is not possible to satisfy all Level AAA Success Criteria for some content” (W3C).

    Another WAI guideline is known as Accessible Rich Internet Applications Suite (ARIA) and defines how to construct HTML and scripting languages that aid users of assistive technologies, like screen readers. Screen readers read websites aloud for those who are visually impaired or who have difficulty reading, such as people with dyslexia.

    Finally, the WAI Authoring Tool Accessibility Guidelines (ATAG) documents how to make accessible content editors that produce accessible content.

    Five of the eight websites analysed mentioned they aimed to adhere to W3C WCAG in their Accessibility statements. Most also specified meeting level AA, which aligns with the aims of the UCL Accessible Moodle project.

    Many of the WCAG guidelines are written very broadly, recognising the ability for accessibility to be addressed in different ways. However, there are common practices which make it easier to adhere to these. WebAIM (Web Accessibility In Mind), which is a non-profit organisation connected to Utah State University’s Centre for Persons with Disabilities provides practical advice on how to apply W3C standards when developing websites.

    My analysis of websites was led by questions I had around how to apply the WCAG 2.0 guidelines to develop a more accessible Moodle. This blog post summarises common practices used by UK websites interested in being accessible to a broad range of people with various disabilities.

    The analysis is broken into the following key areas:

    • Design
    • Headings
    • Skip links
    • Access keys
    • Accessibility toolbar
    • Accessibility statement
    • Paragraph v div tags
    • Alternative text
    • Site maps

    Design

    “Avoiding anything that draws a person’s attention away from the main content and using good design, such as color, white space, and simple presentation can help users focus on important content and functionality.” (WebAim). The designs on these eight websites are simple, with bright colours and plenty of white space around key elements, such as the main content and lists of news items.

    Colours

    Blue and white is a common colour scheme. Some websites, particularly those aimed at users with dyslexia and hearing loss, use a lot of bright, primary colours for different menus and areas of the page. This helps people distinguish between different areas of the website and make links between the menu items and the corresponding section they are in. The St Martin in the Field’s website allows users to override the coloured boxes with a simple dark grey background by choosing the ‘High contrast’ option in the accessibility toolbar at the top of the page.

    Every website examined, except Scope, has an off-white background, to help reduce glare for those with dyslexia and certain visual impairments. Scope does, however, explain to users how to change text and background colours within their web browsers from their Accessibility statement.

    Disability Rights UK also provides a toolbar that changes the default colour scheme (dark blue on an off-white background) with a choice of dark text on a light blue background, or a high contrast option, with light green and yellow text on a dark grey background.

    Logo

    All eight websites link from their logo to the homepage of the site. To confirm this is also common practice for UK Higher Education institutions’ Moodle installations, I also checked some of these (Bath, Cranfield and SOAS) and they too follow this protocol. Therefore, I suggest the UCL logo on UCL Moodle should link to the UCL Moodle homepage. This was raised by a student in one of the project focus groups, who expected this behaviour and were surprised that, in the current UCL Moodle, the logo does not link anywhere.

    Links

    Links were either underlined when there weren’t many links on the page; or coloured and usually bold, with an underlined hover state. Only the UK Government website underlined links in the menus. For most sites they did not, as this would have been overwhleming.

    The links that were underlined normally, had a hover state with no underline. A few were coloured with no hover states, which may prove problematic for people with colour blindness.

    In Moodle, there are links in close proximity to each other, both in the main content region and in side menus, so I suggest an approach where linked text has a unique colour and is bold, but only appears with an underline when someone hovers their mouse over it, to avoid visual clutter. However, it still needs to be clear to those who are colour blind that it is indeed a link, so it may be that links within textual content are underlined and links in blocks and alongside icons (such as the resources and activities), where it is more clear they are links, are not underlined. This causes inconsistency to the visual appearance of links, which may cause confusion, so it’s likely the project will need to go back to the disabled community to check what is best for most people.

    Text

    Most of the websites examined showed large text, at a minimum of 16px with line heights between 1.25 and 1.6. Although line-height is only included in the AAA level of the WCAG 2.0 standard and the Acessible Moodle project is aiming to adhere to AA level, the line height and paragraph spacing is a current issue that has been identified within UCL Moodle.

    WCAG 2.0 AAA expects a way to set “line spacing (leading) [to] at least space-and-a-half within paragraphs, and paragraph spacing [to] at least 1.5 times larger than the line spacing.” (W3C). Therefore, the project will aim for the visual design to meet this requirement.

    Icons

    One UCL student mentioned they find it easier to recognise icons than links that are purely text. The British Dyslexia Association website makes extensive use of icons to supplement menu item text. Action on Hearing Loss also uses icons to highlight key areas of the page and to supplement call to action buttons. Icons are also common in popular social media websites like Facebook and LinkedIn, so it is likely a large number of UCL students will be familiar with using them to help them navigate. I suggest we use icons to supplement text links, and in some cases, such as the search, replace the text link entirely, taking care to provide adequate alternative text for people using screen readers. In addition, the icons that supplement text should be hidden from screen readers entirely, using techniques defined in the WAI-ARIA guidelines.

    Headings

    WebAim states that websites should generally only have one <h1> heading tag per page to describe the page title, followed for a <h2> tag the describe the section title.  Moodle already follows this convention.

    Most of the websites widely use 3 or 4 heading tags, and have only 1 heading 1 (<h1>) tag to describe the title of the page. It is important these headings occur in order, to help blind users understand the navigation structure. Therefore the Atto text editor only allows Moodle course editors to add heading 3 to 5, as headings 1 and 2 already exist on a Moodle course page to describe the course name and section heading. If possible, the TinyMCE text editor should be configured to do likewise, otherwise content will jump incorrectly from one level to the next, as shown below:

    • H1: page title
    • H2: section title
    • H1: content section (added by Moodle course editor who sees heading 1 as the obvious option for a “first” heading and is unaware of the existing heading 1 and 2 on the webpage).

    The WAI ATAG guidelines for improving the accessibility of rich text editors are a useful reference here.

    Skip links

    Skip links are a common way “to bypass blocks of content that are repeated on multiple Web pages.” (W3C).

    All but two of the websites use skip links to enable screen reader users to skip straight to the main content area. Most of these are hidden to sighted users, but two of the websites provide visible skip links at the top of the page. These same two websites also provide a skip to navigation or footer links, and one of them also enables users to skip to the accessibility statement.  Webaim suggests limiting the number of skip links in most cases, to avoid adding to the problem of too many links on a page. The skip links on Moodle only appear when a user presses the tab key. Webaim suggests this as a good way to avoid affecting the visual design of a website, while still catering to sighted keyboard users. The new theme provides a ‘skip to content’ link, which is warranted given the complexity of the pages.

    Access keys

    The majority of the websites analysed do not use access keys.

    The Action on Hearing Loss website defines access keys on their accessibility page. These are based on the UK Government standard  and they describe how to use them (alt on Windows;  Ctrl on Mac, although each web browser may differ). Strangely, the UK gov website does not offer any access keys and the standard document on their website has now been archived, even though it seems a number of websites still refer to it and it appears to offer a default consistent schema for UK websites that still use access keys.

    S – Skip to content

    1 – Return to homepage

    2 – News & events

    3 – Sitemap

    4 – Search site (at the top of the page)

    6 – Help / contact

    8 – Terms & conditions

    9 – Feedback / contact us

    0 – Access keys details

    WebAim summarises that due to conflicts with browser and screen reader shortcuts, many web developers avoid the use of accesskeys, which explains the low number of websites I analysed that use them. This approach is now outdated and was removed from the WCAG standard when it was revised to version 2.0.

    The Adaptable theme, which we will base the new UCL Moodle theme on, uses accesskey=”6″ for search (ALT+6 for Chrome), which does not match the UK government standard.  In most cases WebAim explains that browser accesskeys will be ignored and the shortcuts for assistive technologies like JAWS and web browsers will take precedence, so there does not seem much harm in leaving the accesskey in Moodle. Additionally, there is no impetus to create any further accesskeys for quick access to common features. Instead we should concentrate on upskilling screen reader users, and other users of assistive technologies, to better use the native features of their software and hardware.

    Accessibility toolbar

    Four of the websites provide some form of accessibility toolbar at the top of the page. Three of these provide a variety of 3 text sizes, which seems redundant given that people can simply zoom in and out directly from the browser using the menus or common shortcut keys (Ctrl/Cmd+ and Ctrl/Cmd-).

    The British Dyslexia Society provides Recite.me access at the top of the screen if the user chooses to enable it, which reads aloud text, enables background and foreground colours to be changed and enables OpenDyslexi font amongst others to be displayed on the website, amongst other features.There is an open-source Assistive Technology bar (ATbar) that can eaaily be installed on websites, or by end-users, but I have found it problematic, as there seems to be no way to stop the speech once it has started. Even closing the toolbar does not stop the text being spoken aloud.

    At UCL, the Disability Services teams work with individuals to install and configure software that performs many of these tasks, so I do not suggest we implement an accessibility toolbar within Moodle itself.

    Accessibility statement

    All of the website analysed have an accessibility statement of some kind which explains how the organisation attempts to meet the needs of those with disabilities and in most cases provides a way to raise accessibility concerns a user may have with the website.

    Most of these are directly accessible at the top of the page (3), or in the footer links (3). The British Dyslexia Association requires users to search for their Accessible Communications statement, and the UK government website expects users to know their Accessibility information is in the help section, which is available from a link in the footer. The scope accessibility statement is the most comprehensive and I suggest we use this as a template for our own Moodle Accessibility statement.

    Paragraph v div tags

    All the websites analysed use <p> tags for paragraphs, rather than <div> tags, which is the correct way to use this semantic element according to the W3C. Moodle also uses <p> tags correctly, rather than <div> tags, in both the Atto and TinyMCE text editors.

    Alternative text

    According to W3C WCAG 2.0, images should include alternative (alt) text for any image that is not purely for decoration, so visually impaired users can understand what the image is for. A similar feature is the title tag, which is text that is often applied to links, to explain to sighted users where the link will take them if they click on it. Title tags can also supplement the alt tag on an image where you want that text to appear as a tool tip for sighted users (Penn State).

    Five of the websites provided only an alt tag for their images, with no title tag that appears when you hover over the image.

    The Action for Blind People website provide captions directly below the images in a paragraph tag and a blank alt tag for their images. Although the example on the W3C website suggests indicating in the alt text that the following paragraph contains text to explain the image, WebAim claim it is fine to use an empty alt tag and include text directly after the image instead. WebAim also suggest using blank alt tags for purely decorative images, so screen readers skip over them entirely. This practice is supported by the W3C amongst others (Penn State; AbilityNet; Oregon State University).

    Site maps

    One feature requested by a focus group participant during the Accessible Moodle project was to provide a site map of the course. There is a course format that offers this, but currently Moodle does not allow students to choose their own course formats, this can only be changed by the course editor.

    Half of the websites analysed provide sitemaps and all but one spelt it as a single word. Since it is such a large site, the BBC website provides a separate site map for each area of the website. I suggest the project team raise the idea of allowing students to choose their own course formats and if this happens then investigate the sitemap course format. In addition, I suggest raising the idea of providing a site map to users to help them navigate each Moodle course.

    Summary

    So what does this mean for the development of a more Accessible UCL Moodle?

    From my investigation of common practice across eight UK websites, I would suggest the following for the development of a more accessible UCL Moodle:

    • UCL Moodle should use an off-white background in its content and menu areas.
    • The UCL logo should link to the UCL Moodle homepage.
    • Links should underline on hover to avoid visual clutter in Moodle courses, most of which contain many links.. The potentially exception to this is for the content areas, where it may be useful to indicate links with an underline to supplement the coloured text for those who can’t distinguish this colour difference. This is providing the inconsistency in behaviour between the list of links and the links within content does not prove confusing for the majority of users. This therefore, needs further thought and consultation.
    • Text should be 16px for paragraphs, with a line height of 1.5 (times the normal spacing) and paragraphs another 1.5 times larger than the line spacing.
      • Icons should supplement text links and in some cases replace the text entirely where the icon easily recognised as performing a particular function (such as the search icon). Icons need alternative text where replacing text and need to use ARIA tags to hide them from screen readers, where supplementing text.
    • The TinyMCE editor should be configured to only show headings 3-5, to ensure a clear page structure for screen-reader users.
    • Access keys should not be used as this is an outdated accessibility feature that is mostly overwritten by browser and assistive technology shortcut keys.
    • We should teach assistive technology users to use the shortcuts native to the software.
    • An Accessibility toolbar (like ATBar) is not required due to the availability of assistive technologies for those who need it, especially since it does not allow text to speech to be paused and resumed.
    • An Accessiblity statement should be available, either in the header or footer, containing similar information to what is provided on the Scope Accessibility webpage.
    • Alternative text should be used for all images portraying information, or that are used as a link.  Any images where a tooltip would be useful, such as icons to explain their meaning, should also include a title tag. Purely decorative images should have an empty alt tag, so screen readers skip over them, which simplifies navigation of the page.
    • The project should raise the idea of making a sitemap available for each Moodle course to the Moodle development community, to enable students to easily locate resources and activities on the page.

    Read the top 10 easy accessibility tips from WebAim for further tips on making your website more accessible.

    Accessibility of e-learning – 10 key points from the free OU course

    By Jessica Gramp, on 13 June 2017

    The UK Open University (2006) provide a useful introductory course, called Accessibility of eLearning, that will help you understand how to create accessible e-learning experiences that provide access for all. The course can be completed online, or downloaded in a number of common file formats, including for e-readers and as a PDF.

    I would strongly suggest either completing the course, or reading the course materials, but if you don’t have time I’m going to summarise the key points in this post:

    1. In 2006, disability affected 10-20% of every country’s population, and this number is growing.
    2. In 2006, 15% of the UK population, over 16 years old, self-declared a disability.
    3. A disabled person is one who has a mental or physical disability that has a substantial, long term (12 months or more), adverse effect on their ability to carry out normal day-to-day activities.
    4. Around 1 in 10 men and 1 in 200 women have red-green colour blindness.
    5. UK Universities are legally obligated to make reasonable, anticipatory adjustments to ensure those with disabilities are not discriminated against.
    6. There are two views of disability. The medical model describes the problem of disability as stemming from the person’s physical or mental limitation. The social model sees disability as society restricting those with impairments in the form of prejudice, inaccessible design, policies of exclusion, etc.
    7. Accessibility is about both technical and usable access for people with disabilities. For example, although a table of data may be technically accessible by a blind person using a screen reader, they may not be able to relate the data in each cell to its column or row heading, so the meaning of the data is lost in the process, rendering the table unusable for that person.
    8. Computers enable even severely disabled people to communicate unaided, giving them independence and privacy that is not possible when they need to rely on human assistants.
    9. When communicating online, a disability may not be visible, removing barriers caused by people’s reactions to the disability.
    10. Creating accessible learning environments helps everyone, not just those with disabilities. For example, products that can be used by blind people are also useful for people whose eyes are busy*.

    *This last point reflects my own preference for listening to academic papers while running or walking to work, when I would be otherwise unable to “read” the paper. As a student and full-time employee, being able to use this time to study enables me to manage my time effectively and merge my fitness routine, with study time. This is only possible because my lecturers, and many journals these days too, provide accessible documents that can be read out loud using my mobile smartphone.

    This list brifly summarises the key points I drew from the OU’s Accessibility of eLearning course and demonstrates some of the ways we, as developers of online courses, can make better online learning experiences for all our students, including those with disabilities.

    References

    Open University (2016) Accessibility of E-Learning. [Online]. Available from: http://www.open.edu/openlearn/education/professional-development-education/accessibility-elearning/content-section-0 [Accessed: 13 June 2017].

    Moving to Turnitin Feedback Studio

    By Janice Kiugu, on 5 June 2017

    A few months ago we alerted you to the fact that Turnitin will be moving all users to its new grading interface known as Feedback Studio.

    At present, users can toggle between using Turnitin’s old interface – Turnitin Classic and its latest version Feedback Studio. From 1st August 2017, all users will have to use Feedback Studio to view originality reports, grade work and provide feedback.

    Though a number of you have already moved to using Feedback Studio as it is the default version available on UCL Moodle, some staff have chosen to revert back to the Classic version. In preparation for the switch off of the ‘Classic’ version, we recommend that all Moodle users have a go at using Feedback Studio.

    The 2-minute video below is a brief walkthrough of Turnitin Feedback Studio.


    Learn more about Feedback Studio

    • Quick Tips for mastering Feedback Studio
    • Trial Feedback Studio: Please note that not all functionality is enabled on this demo version. You can however enable feedback studio on assignments that you may currently be in the process of marking by clicking on the ‘Try Turnitin feedback Studio’ link located at the top of an open assignment.
    • For additional guidance on using Feedback studio see our user guides
    • Watch this video comparison between Feedback Studio and Turnitin Classic
    • View our past communication regarding the move to Feedback Studio

    Review: Automate the Boring Stuff with Python

    By Jim R Tyson, on 4 April 2017

    Author: Al Sweigart
    Materials:
    Book  $29.95 print, $23.95 e-book or from Amazon £15.54 print, £11.39 Kindle.
    Website
    Youtube fifteen free videos from the Udemy course
    Udemy: £50 (Discounted to £10 as at 4/4/2017 ) fifty one lectures following the book

    Python is often said to be a fun language to learn. Programming is sometimes said to be fun to learn. The combination ought to be fun too.  My lasting impression of these materials is that they are fun.

    Learners often find that resources for beginners self-tuition in programming are either daunting, or badly designed, or too simple minded to be of real help. This set of resources scores highly on all of these.

    Automate the Boring Stuff with Python is a book that is accompanied by a website, some youtube videos, and (for pay) a Udemy online course. There are eighteen reasonable length chapters and three appendices. The first ten chapters cover the absolute basics of procedural programming starting with simple interaction with the interpreter (do some sums!) through variables and assignment, flow control, writing functions, complex data structures, strings, input and output and debugging. There are one or two other topics that it was interesting to see dealt with relatively early such as searching with regular expressions and file manipulation – including compression, bulk filename routines – but they are simply explained and they make sense given the intention of the material (automating stuff). The book is well designed and clearly written. The website has the same material but includes an in-line interpreter so that you can type code as you go, make mistakes and correct them, and see the results when, finally, you get it right. I watched the free youtube videos and they were well made with clear explanations as were the other free tasters of the Udemy course.  The youtube videos get a big thumbs up in their comments sections.

    Overall, I think these materials are a good start for a beginning programmer who isn’t intending to become a software engineer. It would suit a learner whose aim is to write programs intended mainly for their own use. It doesn’t cover some topics that are increasingly included in early training for programmers, for example version control or test driven development, but for many learners overcoming the initial barrier to writing some effective code is more important than these aspects of best practice. The use of object methods, defensive programming and more can be tackled later.

    The second part of the book and course introduces the use of python libraries for some common and useful tasks. This section includes a variety of projects including web scraping, working with spreadsheets and word processor documents, integrating email in programs. In a higher education context you might want to include numpy, scipy, matplotlib but there are good tutorials for these – good at least for someone who already has basic coding skills and is familiar with the use of libraries – exactly where someone would be after finishing this course.  They are good choices if you want to learn scripting to automate the boring stuff, maybe periodically grabbing data from a website or a spreadsheet and transforming it before writing to a new file for example.

    It’s particularly nice that the website has an embedded interpreter, but I think you would want learners to move onto an IDE eventually and perhaps in some contexts you might want to replace the use of the in-line interpreter with iPython notebooks.

    Overall this is one of the best resources for beginning programmers I have seen and as a suite of resources it could be easily supplemented and adapted to meet an expanded or amended set of objectives.