GSoC 2017 Ideas - nteract/nteract GitHub Wiki
Project Ideas
Important Note:
This project list is not exhaustive. If you have an idea for a project not listed here, please tell us! We can work with you to create a proposal.
Suggested projects, include:
Improved Completion
Summary: We want Jupyter frontends (notebooks, IDE plugins, etc.) to have richer autocomplete information.
This work will span three projects:
- IPython or another well supported kernel like Julia, R, node.js, or Scala
- A frontend (nteract notebook and/or Hydrogen)
jupyter_client- updates to the spec
Motivation
With introspection in the kernels, we can create completions that are even more informative than the best static analysis tools in compiled languages. autocomplete-plus in Atom with Facebook's ObjectiveC tools provides a good bar:
These tools are important because they allow our users to see and understand exactly what is going on without guesswork. Instead of requiring the user write some text and ask for an action to be performed on it, the interface should surface information when it is relevant. The user should never have to take an action blind or search for the information they need.
As an example, this is an experimental prototype using Hydrogen and IJulia:
Note the live values in the right column of the variable completions.
This work has been started in the past in jupyter/jupyter_client#51.
Expected skills
General programming background is expected. Javascript knowledge is a benefit in a strong application, but not required.
Difficulty level
Difficulty is subjective, but this is probably a medium to hard difficulty level project.
Available Mentors
John Detlefs
External Displays
Sidecar
Ipython is an interactive Read-Eval-Print Loop, it helps a user save, execute, and display the results of computer code. After some time existing as a language-specific tool, the tech in IPython was abstracted to create Project Jupyter and the idea of the Jupyter kernel. The messages sent by a frontend to the Jupyter kernel responsible for evaluation of code were designed to be independent of any programming language. As a core technology underlying Project Jupyter, the messaging specifications are thoroughly documented and maintained http://jupyter-client.readthedocs.io/en/latest/messaging.html by Jupyter developers.
One common result of the evaluation of code by a Jupyter kernel is the display of data. This displayed data should have a mimetype that determines how the data is displayed. Charts, tables, and data of any other mimetype is often found rendered in the output area of the classic Jupyter notebook as the result of execution of a code cell.
Some time ago team members at nteract built a tool merging the interactive REPL elements of IPython with an electron browser window --- similar to the browser windows that display nteract --- designated for rendering data. The tool, named Sidecar, should be rewritten to work with advancements that have been made in the jupyter messaging specification and other relevant packages.
Sidecar relies on jmp and zeromq for communication with the Jupyter kernel being interacted with via a command-line-based REPL. As part of this project, the applicant would rewrite Sidecar from scratch. This work should use nteract's more recently maintained packages including enchannel-zmq-backend and react-jupyter-display-area.
This part of the project is expected to take a month or longer, and it will be expected that the student learns and blogs on the details for how a frontend and Jupyter kernels communicate. Upon completion of this portion of the project, work should be done to facilitate similar functionality in the nteract app.
Browser Window Display Area for Individual Cell Output
Similar to sidecar, it would be desirable to have the ability to send the output of a cell to a remote browser window separate from the window rendering the initial notebook document itself. For users with multiple monitors, they could then have one monitor containing the dedicated display area, and another with the actual notebook itself.
A relatively new feature to the messaging specification is the update_display message that can be used to update a display existing in multiple output areas. Some work can be done in nteract can be done to pass the result of a cell execution to a remote display window.
This part of the project is meant to take approximately the second half of the summer coding period. A project proposal should contain relevant information for how to create the UI for creating a separate display window. Relevant info for learning how to implement this feature can be found here: https://github.com/nteract/nteract/pull/1162 and in the Electron API.
Expected skills
General programming background is expected. Javascript knowledge is a benefit in a strong application, but not required.
Difficulty level
Difficulty is subjective, but this is probably a medium difficulty level project with respect to programming background.
Available Mentors
John Detlefs
WCAG Accessibility for nteract
nteract was created with the mission statement:
The nteract organization explores what is possible (and impossible) in interactive computing experiences. We investigate cutting edge technology to build small components that others can combine to create the next big thing. nteract is all about learning together and learning from each other.
From the Web Accessibility initiative website:
The Web Content Accessibility Guidelines (WCAG) documents explain how to make web content more accessible to people with disabilities. Web "content" generally refers to the information in a web page or web application, including:
- natural information such as text, images, and sounds
- code or markup that defines structure, presentation, etc.
Currently, nteract does not satisfy all the standards set by WCAG 2.0. This means that potential users who use tools including but not limited to screen-readers, magnifying tools, dictation devices and more are left unable to interact with nteract reliably, in conflict with our mission statement.
In order to satisfy the WCAG standards, nteract is looking for a student to go through the criteria set by the WCAG website and create a project proposal to enhance nteract's accessibility. This proposal should focus on iteratively making fixes towards an eventual conformance to the four criterion outlined in the quick reference.
In order to be deemed accessible, nteract must be:
- Perceivable
- Operable
- Understandable
- Robust
Absolute mastery and/or comprehensive knowledge of the WCAG standard is not expected from the proposal. The most pressing issues are likely making nteract accesible to the visually impaired by ensuring the efficacy of screenreaders and a high contrast mode. A proposal for this project should contain a nearly complete checklist of nteract's features to be tested and a clear demonstration of the WCAG details that must be holistically understood during the Summer coding period.
In addition to a written proposal, an applicant must create a realistic and thorough timeline for how accessibility-related shortcomings will be discovered and their corresponding fixes will be made. The timeline should contain a realistic amount of time allotted for research into the small details of the various accessibility criteria, weekly blogging about work and research being done, and actual coding. This may also involve time dedicated to learning react, electron, and details of the Jupyter notebook.
Expected skills
A background in accessibility issues is a benefit but not required. Basic programming knowledge is expected, Javascript knowledge is not required.
Difficulty level
The difficulty with respect to this project lies in the organization and thoroughness to go through each aspect of the app. Solving bugs and making changes with respect to code will likely be medium difficulty.
Available Mentors
John Detlefs
Relevant issues: https://github.com/nteract/nteract/issues/852