Google Summer of Code 2012

About GSoC

Google's summer of code is now in its 8th year, funding student positions over the summer, working with various open source development projects producing code that benefits everyone. GSoC will put up $5000 US to cover the wage of a student during the period between the end of May and the end of August. 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.

IDI GSoC Home Page
Google Summer of Code
Google Summer of Code FAQs
Advice for Students Applying for GSoC
Students: Google Summer of Code Student Guide
Students DOs and DON'Ts

Students applying to work with the IDI must submit a resume, along with a 1 or 2 page proposal mentioning the project they wish to participate in, with a plan describing how they would go about developing or coding the software, and send it to info at atutor dot ca. We will on one occasion 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 quesitons.

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

Mentoring Organisation Applications February 27 to March 9
Student Application Period March 26 to April 6
Accepted Students Announced April 23
Community Bonding Period April 23 to May 21
Start Coding May 21
Mid-term Evaluation July 13
Pencils Down August 13
Final Evaluation August 24

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 go 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

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. AContent to ATutor Live Content Link

Difficulty: difficult
Mentor: Greg Gay (IDRC, ATutor Lead)
(Positions available: 1)

Description:
The aim in this project is to extend ATutor’s content integration capabilities to present content that exists in AContent. This will allow instructors to search through the AContent elearning content repository, and instead of downloading or importing content for their courses, they can simply create a link within their ATutor content, and have AContent content display as if it were part of ATutor content. This will allow content to be updated in AContent, and propagate through all courses in ATutor that have that content linked in.

The candidate for this project should have a strong background in PHP development, understand REST Web services, and have an understanding of Javascript and AJAX. The candidate should also demonstrate knowledge of ATutor and AContent content authoring. Familiarity with IMS content interoperability standards will be an asset, as will knowledge of Web content accessibility.

Outcomes
On successful completion of the project, the code generated in this project may be added to the ATutor and/or AContent core source code, and the student will be recognized as an ATutor contributor.

AContent CMS
ATutor Developer Guidelines
IMS Standards
ATutor Common Cartridge Video
AContent Installation and Integration with ATutor LMS Video

2. ATutor Mobile Skins

Difficulty: Medium
Mentor: Alison Benjamin (IDRC, mobile theme developer)
(Positions available: 1)

Description:
 During last year’s Google Summer of Code the ATutor mobile theme was introduced, and early versions of a Tablet theme, and of a Simplified Desktop theme were developed. The Tablet theme is based on the mobile theme, and is designed to work on a variety of tablet technologies. The Simplified Desktop theme is an adaptation of the Tablet theme intended to work with a typical desktop browsers to minimize features of the ATutor interface. The Simplified Desktop theme will be designed to support those who want a simplified desktop interface, for example, because of their learning style, or because they use technologies such as screen readers.

This is a project that could include design and research/documentation deliverables:

On the design side, the student could continue to work on mobile themes, creating one or more additional new mobile skins. The student could also continue to refine the Tablet and Simplified Desktop themes and get them ready to add to the ATutor public distribution.
On the research/documentation side, the student could provide some documentation of their work to act as a resource for future ATutor designers and developers. Some things for candidates to consider include how to incorporate WCAG guidelines for accessibility (http://www.w3.org/TR/WCAG20/) and Mobile Web Best Practices (http://www.w3.org/TR/mobile-bp/) into design, and whether some quality assurance testing with a limited set of browsers and/or assistive technologies could be performed.

The candidate must have good understanding of Web accessibility, HTML and CSS3/CCS2, and have a minimum basic knowledge of PHP, Javascript and jQuery. Knowledge of mobile browser features and limitations (iPhone, Android, and Blackberry), and knowledge of smartphone accessibility features will also be an asset. Knowledge and strategies for dealing with variations in CSS support across browsers is a definite asset.

Outcome: 
On successful completion of the project, the new mobile themes will be considered for addition to the ATutor public distribution.

ATutor Theme Designer Documentation
ATutor Mobile Theme
ATutor Tablet Theme
ATutor Simplified Desktop

3. Google Apps Module for ATutor

Difficulty: Medium
Mentor: Greg Gay (IDRC, ATutor Lead)
(Positions available: 1)

Description:
Tools such as Google Docs, Google Calendar, Google Spreadsheets, YouTube, and others, are becoming more widely used in educational settings. The aim of this project is to make these and other Google applications available from within ATutor as additional learning tools that instructors and student can utilize in their online learning activities. In this project the student will design a module that will make use of a number of Google apps that will open in the ATutor environment. The module should allow users to associate their ATutor accounts with their Google IDs so they can access these tools via a single sign-on in ATutor (and potentially visa versa)

The candidate for this project must have a good understanding PHP, be familiar with ATutor module development, and with various Google APIs and the OAuth API.

Outcome:
Upon successful completion of this project, the Google Apps module will be made available to the ATutor community.

Google Docs API Documentation
Google Calendar API Documentation
Youtube API Documentation
Google OAuth API Documentation
Google OpenID API
ATutor Module Developer Documentation

4. ATutor Calendar Module Extension

Difficulty: Medium
Mentor: Cindy Li (IDRC, ATutor Lead Programmer)
(Positions available: 1)

Description:
In last years Google Summer of Code development started on the ATutor Calendar module. The initial structure for the module, and its linking into other ATutor modules to collect dates (e.g tests dates, assignments due, course start dates) were setup to automatically generate content for the calendar. The aim of this project is to build on these features, making it possible for students and instructors to create personal calendar entries, to share entries, and to integrate other calendar data (e.g. Google Calendar, Outlook) into their calendars.

Features to be developed include:

1. A module_date.php file for each module that requires its dates to be exposed to the calendar. (Tests & Surveys, Assignments, Content)
2. A side menu block that presents a typical numerical calendar layout, with the current day highlighted, and dates with content clickable. Clicking an active date will generate the events for that day below via .
3. A month view, accessed by a main navigation tab, or course tool icon.
4. A week view access by clicking "week view" in the monthly of day view.
5. A day view, accessed by clicking a date in the month or day views.
6. An event view, accessed by clicking an event in calendar to display event details.

A challenging aspect of this project will be developing a calendar interface that is both accessible and usable by screen reader users. The candidate should be able to describe strategies that might used to improve the usability of each screen within the calendar, so it is navigable without the use of a mouse, and understandable when output as audio from a screen reader.

This first implementation of the calendar will focus on gathering dates from within ATutor. The candidate should develop the calendar with foresight of extending the module in future versions, adding in such features as a personal calendar component for recording personal events, a calendar integration feature for combining information from the ATutor calendar with other calendars via iCal for example, and an export component so calendar information can be packaged and imported into other systems.

The candidate student should have good PHP programming skills, preferably with good Javascript/Ajax programming skills. Familiarity with jQuery libraries would also be an asset.

The candidate for this project should have a good understanding of PHP, and be familiar with iCalendar file format, and Google and Outlook Calendar APIs.

Outcome
Upon successful completion of this project the ATutor Calendar module will be made available as an addon module, and considered for integration in a future release as a standard module.

Calandar Module from GSoC 2011
ATutor Module Developer Documentation

5. Collaborative editing for AContent

Difficulty: Difficult
Mentor: Silvia Mirri (U of Bologna, AContent Developer, Italy Lead)
(Positions available: 1)

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.

Outcome:
The final work may be included in AContent distributions.

Ajax: A New Approach to Web Applications
WAI-ARIA Introduction
AContent CMS
ATutor Developer Guidelines

6. Templating for AContent

Difficulty: medium
Mentor: Catia Prandi (U of Bologna, AContent Developer)
(Positions available: 1)

Description:
The aim of this project is to provide AContent with a set of templating features to support the author in content creation.

The idea is to integrate AContent with an already existing system which has been designed and developed to support the use of templates during authoring and editing of e-learning content, by using existing data structures and e-learning standards.

The system will provide 3 layers of templates:

Layout template: to select and apply a graphic design to display the content.
Page template, to support the author in composing pages (inspired by slide models).
Structure template, to provide the author with some predefined learning object structures (with/without assessment, overview, goals, etc.).

By using this new feature of AContent, the following scenarios will be possible:

each lesson can be created on the basis of a structure template that provides a predefined organization of the lesson into goals, content, assessments, tools, references and so on.
Each page of the structure is associated to a page template that schematizes the page content by split-ting it into sub-parts. Page templates have been de-signed on the basis of the well known “slide layout” used by main presentation programs.
Each page is associated to a page layout for the graphic aspects of the page.

Outcome
The final work may be included in AContent distributions.

AContent CMS
ATutor Developer Guidelines

7. AChecker Interactive Interface

Difficulty: Medium
Mentor: Silvia Mirri (U of Bologna, AChecker Developer, Italy Lead))
(Positions available: 1)

Description
In this project the candidate will re-design and develop the AChecker interface.

The new interface will be based on AJAX technologies and it should be compliant with W3C WAI‑ARIA specification.

The candidate students must have a good knowledge of HTML and CSS and also be familiar with PHP, AJAX and W3C WAI-ARIA specifications. The AChecker interface and layout will be renovated with new AJAX technologies. Compliance with W3C WAI-ARIA specifications will guarantee system accessibility.

Outcome
The final work may be included in AChecker distributions.

Ajax: A New Approach to Web Applications
AChecker
AChecker Development Site
WAI-ARIA Introduction

8. AChecker manual evaluations

Difficulty: Medium
Mentor Paola Salomoni (U of Bologna, AChecker Developer))
(Positions available: 1)

*Description: *
In this project the candidate will design and develop a new AChecker feature with the aim of adding manual evaluation results to the AChecker report after a URL validation activity. Such a feature will be related to the export functions, so as to let users download a complete report, related to automatic and manual control results.

AChecker evaluates the accessibility of an URL according to a specified set of guidelines or requirements (derived from international standards or national laws and acts). Such a validation activity produces a report with certain errors (derived from automatic controls) and warnings (named "Likely errors" and "Potential errors"), which the users should evaluate on their own. This new feature will support users in declaring if a warning is a real error or not. After this phase the users will be able to export the final report with results about certain errors and manually evaluated likely and potential errors.

The candidate students must have a good knowledge of XML and PHP. Familiarity with HTML, CSS and MySQL is also required.

Outcome
The final work may be included in AChecker distributions.

AChecker
AChecker Development Site

9. Media Player Update for ATutor

Difficulty: Medium.
Mentor: Harris Wong (IDRC, ATutor Developer)
(Positions available: 1)

Description:
ATutor recently adopted the Flowplayer media player as its default player when video is included in ATutor content. With accessibility as a high priority for ATutor, there is room to improve Flowplayer and its accessibility support. The aim of this project is to update media support in ATutor with improved accessibility. This may include adding the Flowplayer caption addon or other addons, addressing potential keyboard accessibility issues with the player, and potentially adopting the Fluid HTML5 media player as the default player. Other possibilities might include integration with Universal Subtitles, to add a captioning tool that will integrate with the ATutor content editor.

The candidate for this project should have a good understanding of multimedia development, as well as javascript, and potentially Flash development. A basic understanding of PHP will also help with this project.

Outcome:
Upon successful completion of this project, the updated media player will be considered for a replacement for the current basic Flowplayer.

ATutor Module Developer Documentation
Flowplayer
Flowplayer Plugins
Fluid Player Roadmap
Universal Subtitles Documentation

10. AContent module for Moodle

Difficulty: Medium.
Mentor: Lachlan Blackhall (Australian National University. AContent/Moodle Developer)
(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

11. ATutor Chat Redesign

Difficulty: Medium
Mentor: Harris Wong (IDRC, ATutor Developer)
(Positions available: 1)

Description
ATutor currently uses the AChat chat application for synchronous text chats within courses. AChat was originally added to ATutor back in the early 2000s, filling the need for an accessible chat application that could be used by anyone, including students who are blind and might be using a screen reader to participate in ATutor courses. No other accessible chats existed at the time, and the technology to create such a chat was just emerging.

Since the original AChat was introduced, the WAI-ARIA standard was made public. It can be used to address the accessibility of live dynamically updating content such as a chat dialog. With the addition of ARIA live regions for instance, it is now possible to access chat dialogs with a screen reader, for instance, making synchronous communication more accessible to blind students.

Another possibility for a chat redesign would be to create a small popup chat, much like you might find on Facebook, or in Google+ or Gmail. There are many possibilities.

In this project the candidate will design a new chat for ATutor, or potentially use the current AChat application as a starting point and build on it, perhaps using WAI-ARIA, perhaps extending it to include a Gmail like chat. The student can decide. Whatever path is selected, accessibility needs to be a key consideration.

The candidate for this project may rely on various programming skills depending on the type of chat chosen for the project. PHP and Javascript will likely be part of those skills, though there should be some familiarity with accessibility requirements (e.g. WCAG 2), familiarity with WAI-ARIA, and potentially familiarity with assistive technology such as screen readers, and the difficulties users of these technologies face when accessing live updating content.

Outcome
Upon completion of this project, the chat module created will be considered as a possible replacement for the aging AChat application currently used in ATutor.

ATutor AChat module
ATutor Developer Guidelines

12. Improve accessibility of BigBlueButton

Difficulty: Medium
Mentor: Richard Alam (BigBlueButton Developer)
(Positions available: 1)

Description:
For it's real-time sessions ATutor uses BigBlueButton, an open source web conferencing system for distance education. This project involves analyzing the accessibility requirements for BigBlueButton (from the student's perspective), researching the technical options for extending the Flex-based BigBlueButton client to support accessibility, and prototyping and implementing the changes to enable a student with disabilities to participate in a real-time ATutor session.

Students should have prior knowledge of development in ActionScript and Flex (please indicate specific examples of your Flex development experience if you are applying for this project). This project will involve research and analysis as well as implementation, so students should be comfortable with prototyping various approaches and analyzing the strengths/weakness of each approach, and then focusing on the implementation of the recommend solution

Outcomes:
Based on the quality of the work, candidate's work will be reviewed and merged back into the BigBlueButton client by the core developers of BigBlueButton.

BigBlueButton
BigBlueButton Source Code
BigBlueButton Developer Documentation

13. Enhance Integration of ATutor with Apache OpenMeetings Web-Conferencing

Difficulty: Medium
Mentor: Sebastian Wagner (OpenMeetings Developer)
(Positions available: 1)

Description:
Apache OpenMeetings provides Video-Conferencing with Chat, Whiteboard, file sharing, screen sharing, and recording of whole meetings. There is currently a basic integration of ATutor with OpenMeetings. The project's aim is to rework this integration so that recordings made within OpenMeetings are available in ATutor (1), further that files uploaded to ATutor can be made accessible within OpenMeetings conference rooms (2) and to bring the existing integration in line with OpenMeetings latest API functions (3). OpenMeetings already provides a Web-Service to do that, the candidate's task would be to integrate those service calls at the right places in ATutor.

As OpenMeetings future versions will be Apache licensed it would be recommended to have the Plugin under ASL as well so it can be maintained by the Apache OpenMeetings team.

The candidate for this project should have basic knowledge of PHP and the willing to learn how to trigger SOAP / REST Web-Services via PHP using examples that will be provided. The candidate should have knowledge of ATutor module development.

Outcomes:
Have a ready release of the plugin including gathering feedback from potential users. The project should cover a whole small software development cycle from analysis, implementation, to verification of the results with end users.

OpenMeetings
Current Source Code for OM Module for ATutor
ATutor Module Developer Documentation

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 2012 program. Working with Fluid gives you a chance to learn more about accessibility and usability while writing code with cutting-edge open web technologies like HTML5 Canvas and Video. Create cool stuff and make a real impact on users at the same time!

To communicate directly with the Fluid development team, open an IRC session at irc://irc.freenode.net and join the #fluid-work 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 developers get to know, are the ones chosen to fill the limited number of spots available.

1. Visualization of declaratively-structured programs using Fluid IoC

Create a visual representation of the component structure as seen by the Framework/IoC

1 position available
Difficulty: medium
Mentor: Michelle D'Souza, Antranig Basman

This project is an opportunity to combine your technical and design skills. The Fluid Infusion Inversion of Control (IoC) system has grown a lot in the past year. It has become a robust way of building JavaScript applications where the pieces of the system do not know about each other and can be swapped out for different implementations based on the context they find themselves in. The system relies on JSON specifications (called defaults and demands blocks) to signify what components use in particular contexts. Being based on JSON rather than raw JavaScript code, the system has been aimed at smoothing the path towards creating powerful visualization and design tools. Currently, the IoC system is lacking in developer supports. This is where you come in. You will use HTML5 Canvas , WebGL and/or traditional HTML widgets to create a visualization of an application that has been written using Infusion IoC. The goal of this project is to assist developers in understanding and debugging their applications.

2. Towards non-visual/accessible programming

1 position available
Difficulty: hard
Mentor: Antranig Basman, Michelle D'Souza, Clayton Lewis

Today, for almost every purpose, programming an application implies editing some kind of text file. This is a limiting model, which shuts out a huge community who might otherwise be making applications for their own needs and those of others. The form factors of computers are changing - this year, the majority of computers online are tablets and phones, making these inappropriate devices for a person in the role of a programmer. Liberating programming from the text file model is a great opportunity to broaden access as well as to a different class of device, to a different class of user - those with visual impairments, or those who are in an environment (perhaps a crowded/noisy bus, bar or otherwise "on the move") where whipping out a traditional class laptop with high-res screen and keyboard would be inappropriate. An important idiom in moving towards the "non-visual" model is to reformulate operations which are traditionally performed by "visual scanning" or "skimming" into a population of "non-visual query operations" which the user can adjust and improve to match their favorite style of working. This project may be synergistic with, but independent of, the Fluid GSOC project on IoC visualisation. Creating a model where a program structure is "topologised" is a crucial element of both projects - whereas in the visual project this graph structure will be laid out in visual space, for this non-visual project it will be treated abstractly as pure topology (graph connectivity).

This project will explore this currently completely unvisited frontier of programming idioms, drawing on the wisdom of the ages, including dataflow programming, functional programming and/or functional reactive programming (FRP), context-oriented programming, declarative and state-oriented programming to liberate coding from the era of the typewriter.

3. HTML5 Image Editor

Create a component for accessible image editing with HTML5 Canvas and Infusion.

1 position available
Difficulty: medium
Mentor: Jon Hung & Justin Obara

This project is an opportunity to create an image editing tool entirely with open web technologies, especially HTML5 Canvas. The goal for this component is to provide familiar image processing features such as rotation, skew correction, brightness/contrast, and threshold, all within a standard web page. The contributor is free to experiment with other, more complex image processing algorithms and implement them as desired. The component should be able to export the settings in an easily consumable format (e.g. JSON). The component will support accessibility features such as use of the keyboard instead of the mouse.

Students should have a firm knowledge of open web technologies: HTML, CSS, and JavaScript. A desire to learn emerging technologies such as HTML5 is essential. Familiarity with Fluid Infusion is not required; we'll show you the ropes.

4. Highly customizable and accessible web based ePub reader.

1 position available
Difficulty: medium
Mentor: Yura Zenevich

This project will focus on implementing a web based ePub reading (possibly, editing) component based on open web technologies (and infusion framework). The result implementation must be screen reader accessible. It also needs to utilize tools for customizing user experience (through UI Options or other means). Having a highly customizable reading experience on the web will contribute to a growing number of new learning tools in the educational domain.

Students should have a firm knowledge of open web technologies: HTML, CSS, and JavaScript. Familiarity with Fluid Infusion framework is not required; we'll show you the ropes.

Feel free to research more about javascript epub technologies available as open source.

5. Inclusive, Web-based Musical Instruments

1 position available
Difficult: medium
Mentor: Colin Clark

The Inclusive Musical Instrument project provides an opportunity to design simple, novel, 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 may wish to use Fluid Infusion and the Flocking web-based music synthesis framework to implement their designs.

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.