Skip to end of metadata
Go to start of metadata


GSOC 2014 has been announced. The page that follows is a list of project ideas coming together for this year. Other project ideas will be added here over the coming weeks, before the 2 week student application period starts March 10. In the meantime, get involved with the ATutor and Fluid communities to show your interest, and suggest potential projects if you have a good idea. Students who participate in the communities are more likely to be rewarded when the GSoC student selection period comes.

About GSoC

Google's summer of code is now in its 10th year, funding student positions over the summer, working with various open source development projects producing code that benefits everyone. GSoC will put up $5500 US to cover the wage of a student during the period between the end of May and the end of August. A stipend of $500 US goes to mentors. Students who are interested in participating should scan through the GSoC FAQ  for information about the program and how to apply, and scan through the "Project Ideas" listed below for potential projects they might participate in. Or, propose a project of your own and attach it to your application ( be sure there's a mentor who will oversee the project).

Google Summer of Code
Google Summer of Code FAQs
Students: Google Summer of Code Student Guide
Students DOs and DON'Ts

Students applying to work with the IDI must download the application template, and send it completed to jobara at ocadu dot ca. Mentors will on one occasion only offer suggestions you can use to enhance the proposal you submit when you register with GSoC. Be sure your proposal is as close to finished as possible before submitting it for feedback.

Contact

The best way to contact IDI if you have questions is through our IRC channels. Use the ATutor channel for ATutor project related questions, and the Fluid channel if you have Fluid project related questions.

ATutor IRC Channel: irc://irc.oftc.net and join the #atutor channel
FLUID IRC Channel: irc://irc.freenode.net and join the #fluid-work channel http://webchat.freenode.net/

Important Dates

February 14 Mentor organizations applications due
March 10 to March 21 student application period
April 21 Accepted student proposals announced

Selection Criteria

Google Summer of Code is a very competitive process at IDI. Many more students apply than we have spots available to offer. Students should keep this in mind and plan accordingly. Students can apply for up to two projects at the IDI.

When selecting students there are a number of qualities we look for:

  • Students need to be independent, curious, and resourceful and self-directed. Mentors will help steer students in the right direction through encouragement, feedback, and critique, but will not direct or dictate what a student should do.
  • Students need to be able to communicate effectively. All of the IDI work is collaborative and community-based. Students should get to know the community and learn how to communicate effectively using IRC. The IDI works in an open, transparent manner, so students will be expected to contribute work openly on IRC, mailing lists, and wikis etc..
  • Students are expected to design their own projects based on the descriptions provided in the ideas presented below, or based on their own ideas. Mentors will give feedback and point out useful resources to further develop plans.
  • Students should not begin doing any more than basic coding that might be required for research, before being selected for a project.
  • Students may submit a project plan for feedback once. The plan should be close to done when submitted for feedback.
  • Students should demonstrate good time management skills. Making contact with mentors early, being able to judge how much time is required to complete a project, being able to organise tasks in a logical order along a timeline, and being able to accommodate complications if things don't go quite as planned, are all qualities of good time management.
  • To pass the midterm and final evaluations, students are expected to work on their GSoC project as if it were a full time job, and be in regular communication with the project mentor. That is, working Monday to Friday, 9:00AM to 5:00PM, or the equivalent. Some leeway will be allowed for exams, holiday plans, and unforeseen circumstances. Student need to let their mentor know in such cases.
  • Students need to be able to document their progress on a weekly basis. This can be done in a variety of different ways, perhaps setting up blog or wiki of their own, and keeping an ongoing timeline for their project that mentors can refer to to monitor a student's progress.
  • Students should also be familiar with the Git version control system, and have an account setup on GitHub. All project code must be available on GitHub for the duration of the project period.

About the Inclusive Design Institute

The overarching goal of the Inclusive Design Institute is to help ensure that emerging information technology and practices are designed inclusively from the very beginning. We define inclusive design as design that enables and supports the participation of individuals and groups representing the full range of human diversity. We see disability as a mismatch between the needs of the individual and the service, education, tools or environment provided and accessibility as the adaptability of the system to the needs of each individual. Our research, development, education and services are all grounded in this principle.

The IDI supports open standards - as well as open access and open source wherever possible - to distribute our work as widely as possible and to encourage broad participation in our initiatives. All our work is collaborative.

We are strong advocates of the overlooked principle that people with disabilities should be producers and not only consumers of information, knowledge and culture. Society as a whole is impoverished and deprived if we exclude through action or omission. Inclusion benefits everyone, it should be everyone's concern and, in this digitally transformed reality that we live and work in - where consumption does not consume and space has no limits - there is no downside to inclusion and it is possible to make room for us all.

Jutta Treviranus
IDRC Director

Project Ideas for GSoC 2014

ATutor Project Ideas

The following is a list of potential GSoC projects for students. These are only suggested projects, outlining the types of things the ATutor community has been asking for. Students are welcome to suggest their own projects, or suggest variations on the ones listed here if they have other ideas.

To communicate directly with the ATutor development team, open an IRC session at irc://irc.oftc.net and join the #atutor channel. The core developers are generally around 9:00 to 5:00 Monday to Friday Eastern Standard Time (UTC-5). Though not a requirement, students are advised to login to IRC and interact with the developers. Generally students that developers get to know, are the ones chosen to fill the limited number of spots available.

Students should note that mentors working with IDI work as a team, so you may interact with several mentors over the course of your project. The mentor listed with each project is the primary contact for the project, but he or she may direct you to other mentors where they are better able to answer questions or provide guidance.

 

1. ATutor TinyMCE/CKEditor Update

Difficulty: Medium.
Mentor: Greg Gay
(Positions available: 1)

Description

Shortly after ATutor was launched in 2000, the ATutor team worked with the developers at Moxiecode to bring their TinyMCE editor in conformance with WCAG and ATAG accessibility guidelines. TinyMCE has since been integrated with ATutor as its "Visual Editor." Recently TinyMCE 4.0 was released, one of the more attractive features being its support for HTML5. However, some of the accessibility features added in previous versions did not make it into this release, so we have been holding off on upgrading ATutor's Visual Editor.

In this project, the candidate will first work with Moxiecode to reintroduce the lost accessibility features, then update ATutor to use the latest version of TinyMCE. The integration of TinyMCE 4 will also involve reworking the the older TinyMCE 3.* addons, particularly the AChecker addon, as well as the math, video, glossary, and LaTeX editor addons. In addition, time permitting, a current version of CKEditor will be integrated and made available in ATutor as a second WYSIWG editor option. This will also involve extending current preference settings to include CKEditor as an option.

The candidate should be proficient programming with PHP and Javascript, understand REST Web services,  and be familiar with HTML5 and WAI-ARIA.

Outcome:
Updated TinyMCE, make it accessible, and add CKEditor to ATutor.

TinyMCE Accessibility
ATutor Developer Guidelines
CKEditor

2. ATutor Public API / REST Webservice

Difficulty: Medium

Mentor: Alex Novak

(Positions available: 1)

Description:

The aim of this project is to introduce ATutor JSON/REST Webservices. This work will help developers, and users, build their own tools, websites, webservices or mobile applications based on the ATutor architecture and data, and open up ATutor for data mining. This project is a starter project, which might touch on one or multiple subjects related to webservice problems such as: API Specifications, User Authentication, User Authorization, Logging, API Structure and other topics. Some data that could be exposed via the API might include System Properties, Courses Details, Course Content, Usage Tracking, Tests and Test Statistics, Class Schedules, and others.

The candidate for this project should have excellent PHP coding skills, have a strong grasp of modern web standards such (JSON, REST, HTTP(s)), understand Web security, write advanced-level JavaScript knowledge as well as having a solid understanding of the HTTP protocol. The candidate should propose possible API calls, with some ideas on how to implement them, in their GSoC application. Previous experience with ATutor would be an asset.

Outcome:

On successful completion of the project, ATutor should have few working basic REST APIs available, detailed documentation, and one, or a few, model implementations that users and developers can build on.

ATutor Developer Guidelines

3. ATutor Usage Module

Difficulty: Medium

Mentor: Harris Wong

(Positions available: 1)

Description:

This project will create an addon module for ATutor that generates a variety of ATutor usage statistics. ATutor currently collects usage information when students are navigating through content pages in a course, like the path through pages, time spent on each page, as well as cumulative time spent on pages, as well as summary statistics for individual content pages. This information helps students keep track of what they've completed, and helps instructors understand how the course content is being used.

What's needed is a way to extend this content usage information with information about other activities, such as when, how, where forums, blogs, chats are accessed, or any other feature that might be turned on in a course. The module should gathering information about tool usage, paths from content to tools, tool to tool, when and where login sessions start and finish, etc. along with visualizations of the information to help administrators understand how the system is being used, help instructors understand how courses are being used, and help students understand how they use courses.

Candidates should have strong PHP and Javascript skills, have some experience with data visualization, and should be familiar with the current statistics generated by ATutor. This project may work well as a collaboration with the student working on Idea #2 above, working together to design a stats API, Idea #2 creating the API, and Idea #3 implementing it.

Outcome:

On successful completion of the project, the module will be released to the ATutor community. In time the module may be consider for addition to the ATutor code.

ATutor Developer Guidelines

4. ATutor Chat Improvements 

Difficulty: Medium/Difficult
Mentor: Olga Casian
(Positions available: 1)

Description

During GSoC 2012 a new version of chat based on XMPP protocol was developed for the ATutor. The chat already has the basic functionality and some more advanced features. This project focuses mostly on the usability and performance improvements to the chat.

In this project, the candidate will create a notification area in the ATutor header, will launch a proxy server that will use all ATutor instances to convert tcp to http for the web implementation of XMPP protocol, will implement a minimized gtalk or facebook style chat window that is displayed on all the pages and will consider another ways of storing chat history (possibly by using XMPP features). All the interface related changes should be made taking into account accessibility standards.

The candidate should be proficient with JavaScript, jQuery, CSS, HTML and network programming, understand accessibility issues and know how to solve them (WAI-ARIA) and be familiar with PHP.

Outcome:
On successful completion of the project, a new version of the module will be released and used in ATutor

ATutor Developer Guidelines

ATutor Chat Github Repository

Module Development Documentation

Documentation from the chat module [[see doc inside of the module archive]]

About proxy server

WAI-ARIA FAQ

WAI-ARIA authoring practices

5. ATutor Testing/Assessments Enhancements

Difficulty: Medium
Mentor: Cindy Li
(Positions available: 1)

Description
While timed tests in ATutor would be a relatively easy feature to add, they do present a particular challenge when it comes to implementing them in an accessible way. For some people with disabilities time tests can be a barrier if for example it takes a longer time to read and answer questions than most people. For those with reading difficulties, or for those using assistive technologies to access ATutor, more time is often needed to complete a test. For those who are blind, presenting a timer can also be a challenge, ensuring they know how much time they have remaining. The primary goal of this project is to introduce accessible timed test in ATutor.

In addition to developing a timed tests feature, a tool will be needed to allow instructors to add time to a test on a student by student basis, so those who require more time can be accommodated. Or, a test duplication utility could be created that would allow tests to be replicated, their timing modified, and using the existing groups feature, assign tests to group that might include students who need more time, or perhaps a group of students doing a make-up test..

Another feature that could be created along with timed tests, is partial marks for multiple answer and matching questions within ATutor assessments. Currently test takers must answer all items in matching or mutliple answer test questions inorder to get the question correct. This part of the project will rework these question types to allow test takers to get part marks for questions answered partially correct.

Outcome:
Upon successful completion of this project, the modifications made to the ATutor testing module to allow timed test, and to accommodate extra time for students, will be considered for merging with the public distribution.

6. AContent Module for Moodle

Difficulty: Medium.
Mentor: Matteo Ricci
(Positions available: 1)

Description
AContent is an open source tool for developing rich learning and educational content using a variety of content types including images, video, mathematical equations, and text. The ability to rapidly develop content in AContent and then export it in a standards based form is particularly powerful for content authors and developers who need to rapidly develop and deploy content. The authoring capabilities of AContent are superior to many other tools that are included within learning management systems (LMS).

In many universities around the world the Moodle LMS has been deployed. However, the content development tools within Moodle not as well developed as those in AContent, nor can the content be exported from Moodle. Moodle does however support the inclusion of content developed within AContent through being able to import IMS Content Packages exported from AContent. While being able to import content into Moodle is a useful capability it would be better to be able to easily develop content within AContent and deploy it into Moodle in a single step, something currently not possible.

In this project we will look to more tightly integrate AContent and Moodle so that people using Moodle for online course management can easily develop content in the AContent environment and then deploy it into Moodle directly.

The candidate should be proficient programming with PHP, understand Web services and have some familiarity with HTML and CSS.

Outcome:
AContent will be turned into a content authoring tool and repository for Moodle.

AContent CMS
ATutor Developer Guidelines
Moodle Developer Documentation

7. Collaborative Editing for AContent

Difficulty: Difficult

Mentor: Catia Prandi

Description:

In this project the candidate will integrate wiki-like editing features into the AContent editing system. This will allow multiple authors to collaboratively create, write, add, and edit e-learning content to be packaged in conformance to well-known standards. This feature can be added by implementing it as a new AContent module or by integrating an existing open source wiki engine. The idea is to choose an already existing open source wiki (e.g. Dokuwiki, Mediawiki), integrating AContent and wiki users' management, adapting wiki features according to users' permission and learning objects structure, integrating the wiki versioning system into the content management.

The candidate for this project should have excellent PHP coding skills, have strong familiarity with wiki engines and some HTML, CSS and Javascript expertise.

Outcome:

On successful completion of the project, the final work will be released to the AContent community. In time the module may be consider for addition to the AContent code.

8. AChecker HTML/DOM Review

Difficulty: Medium
Mentor: Silvia Mirri
(Positions available: 1)

Description:

One feature that has been needed in AChecker for some time, is the ability to generate dynamic, interactive components within Web content so the generated markup can be reviewed by AChecker. AChecker currently only reviews static HTML. As part of this project the candidate will research, along with the mentor, available open source libraries that will generate an extended DOM with interactive elements in Web content activated. Once a suitable library is found, it will be added to AChecker to extend the current static reviews to include dynamically generated Web content.

The candidate should have strong PHP and Javascript programming skills, and understand DOM manipulation.

Outcome:

Upon successful completion of the project, DOM level accessibility reviews will be considered for addition to the public AChecker distribution.

Resources:

AChecker

9. AChecker Spider and Summary Reports

Difficulty: Medium

Mentor: Matteo Battistelli

(Positions available: 1)

Description:

AChecker was originally created to review single Web pages for their conformance with various international accessibility guidelines. There have been many requests to have AChecker spider through Web sites to review multiple pages, such as analysing the accessibility of a whole Web site, or review pages across multiple Web sites, such as analysing pages across a collection sub domains. The candidate will develop a utility that can be loaded with URLs to review, the depth of the review set (e.g. 2 or 3 or 4 levels deep), select review levels (A, AA, AAA), and other potential options for generating data across a range of Web content. Output from a spidered review might be arranged in a hierarchy, with summary results for all sites at the top level, summary results for individual sub sites at the second level, detailed result for pages with a sub site at the third level, and so on. The candidate should look at options for developing a standalone applications that makes use of AChecker's REST API for generating accessibility reports, or consider the potential of extending the current functionlity in AChecker, developing a series of new tools and options that will be integrated into the AChecker pubic distribution.

The candidate should have strong PHP and Javascript skills, have a working understanding WCAG accessibility specifications,

Outcome:

Upon successfully completing the project, the accessibility review spider will be made available as a complimentary tools for AChecker, or it may be integrated to become part of AChecker depending of the development path taken.

 

Resources:

FAE Reports Example

Vamola Monitor

 

 

Fluid Project Ideas

Fluid is an open source community of designers and developers who help improve the usability and accessibility of the open web. We contribute to a variety of open source projects (such as jQuery UI), and we work on a few projects of our own: the Design Handbook, a guidebook of techniques for improving usability, and Infusion, a JavaScript application framework for developing flexible user interfaces.

Fluid Infusion is built on top of jQuery, providing all the stuff you need to create user interfaces that are incredibly flexible, accessible, and easy-to-use. Infusion is an application framework and a suite of user interface components built with HTML, CSS, and JavaScript. In contrast to many other user interface toolkits, Infusion components aren't black boxes--they're built to be modified, adapted, and changed to suit your application or context. Taking a "one size fits one" approach, Infusion even lets end-users customize their experience with the UI Options component.

We're looking for students to collaborate with us on the Google Summer of Code 2014 program. Working with Fluid gives you a chance to learn more about accessibility and usability while writing code with cutting-edge open web technologies. Create cool stuff and make a real impact on users at the same time!

For information about the various ways we communicate with each other, see our Google Summer of Code 2014 wiki page.

1. Web-based instruments for inclusive musical performances

1 position available
Difficulty: medium
Mentor: Colin Clark

The web-based instruments for inclusive musical performances project provides an opportunity to design simple, expressive, and accessible ways to play and perform electronic music using entirely Web-based technology. Most current music-making software is complex, inaccessible to assistive technologies, and requires the use of a mouse. This project involves designing and implementing musical keyboard-navigable and assistive technology-friendly instruments on the web for playing music. Students will use Fluid Infusion and the Flocking web-based music synthesis framework to implement their designs. Students are strongly encouraged to explore novel interaction methods to allow people who might not otherwise be able to play an instrument to participate in the music-making process. How can a musician who needs extra time, or who has limited mobility, or who can't see the screen, engage in expressive music-making?

Students should have knowledge of open web technologies, including HTML, CSS, and JavaScript. More importantly, they should have a desire to experiment with novel user interactions and understand some electronic music and Digital Signal Processing techniques.

2. Picture Dictionary

1 position available
Difficulty: easy
Mentor: 

Like a traditional dictionary, a Picture Dictionary will allow a user to search for the meaning of a given word or term. However, rather than returning a text based description, an image representing the meaning will be returned instead. For example if a user were to look up "dinosaur", an images of a dinosaur would be returned. A Picture Dictionary would have many applications including assisting users who are learning a new language, are better visual learners, have trouble with perceiving or understanding text, and etc. This project will involve working with and expanding on existing designs, while implementing with the latest web based technologies (HTML, CSS, JavaScript). The student will be expected to make use of Fluid Infusion, and ensure that all work is implemented with inclusivity in mind.

3. In Browser Text-To-Speech

1 position available
Difficulty: hard
Mentor: 

There are many OS based screen readers (NVDA, JAWS, ORCA, VoiceOver) available. However, not all users require, need, or want the full screen reader experience. More and more sites are starting to look at providing a text-to-speech feature on their site, allowing users the option to have the contents of the page read to them. This is only one of many preferences that a user may wish to change on a site. Our Preferences Framework has been developed to allow a user to customize their own experience, allowing the interface to adapt to their needs and preferences. This project will focus on enhancing our early implementation of text-to-speech (interface options demo, preferences exploration tool demo) based on our existing designs. Students will be expected to use Fluid Infusion, in particular the Preferences Framework , to integrate with a text-to-speech engine to implement the designs. Students should have knowledge of open web technologies, including HTML, CSS, and JavaScript.

4. CMS Plugins for Infusion Components

1 position available
Difficulty: medium

Mentor:

For this project, you will create a plugin, module or theme that incorporates one of the following Infusion tools into a Content Management System (CMS):

UI Options will enable users to easily customize the appearance and layout of the CMS site. For example, UI Options provides high contrast, large print, and simplified layouts that help improve usability with assistive technologies such as a screen magnifier or mobile device. The Video Player is fully accessible, and designed to work with UI Options.

We have already created a UI Options theme and a Video Player plugin for Wordpress; Now we want your help to expand and improve on these, or incorporate them into another CMS.

You should have a firm knowledge of open web technologies: HTML, CSS, and JavaScript, as well as experience with one or more CMSs. Familiarity the Infusion Framework is not required; we'll show you the ropes.

See also:

Infusion Documentation

Most of the work we do here either uses or directly involves the Infusion Framework and Component Library. These links should get you started learning about Infusion, and should lead you to many more pages.

Contributing Code To Infusion
Infusion Documentation
How Infusion Works
Tutorial - Getting started with Infusion
Infusion Framework Best Practices

  • No labels