Skip to content

GsoC 2014 Application Karan Grover: Developing an advanced user interface for browsing and viewing tutorials.

Karan Grover edited this page Mar 16, 2014 · 1 revision

STUDENT INFORMATION

Name Karan Grover
EMail karan13048@iiitd.ac.in, krngrvr09@gmail.com
Telephone +919818148131
Time Zone GMT+0530 (IST)
Github Username krngrvr09
IRC Handle krngrvr09
Blog http://karangsoc14.wordpress.com/

Short-Bio: I like programming, playing guitar and sketching( http://instagram.com/krngrvr09 ). I think of programming as an art form, and I really believe that one can do anything using programming. I like to keep an ideas list and I love to strike things off it. I am a free software enthusiast and a member of my college's software development club. I am also an Open Source advocate, and I try, whenever possible, to create awareness in and around my college about Free and Open Source - Software, Hardware and Design.

UNIVERSITY INFORMATION

University Indraprastha Institute of Information Technology
Major Computer Science
Current Year 1st
Expected Graduation 2017
Degree Btech.

PROGRAMMING BACKGROUND

I have been a full time Ubuntu user for the past 6 months. I use Gedit as the primary editor. I have been programming for almost a year. I am proficient in C, C++ and Python. I love to create things, and the feeling which I get after creating them is indescribable.

Besides that, I keep playing with python, as it is very easy to test ideas on it.

  • I once used python to plot an image to test whether the randint() function really generates random numbers. Also on github( https://github.com/krngrvr09/random-check ). It turned out that it really was ‘random’(Mind you, rand() function in php is not random. Interesting, right?).

  • I recently created a webpage, named magic-text, which makes 'typing text' seem beautiful. On github( https://github.com/krngrvr09/magic-text ).

  • I have participated in various hack-a-thons in my college and have tried to implement various ideas into web apps.

Python was the first programming language I had learnt. I have been using it since then. I loved it and decided to stick with it, as it focuses on readability, it has a great community and the fact that it acknowledges the importance of development speed.

I have been using git for the past 3-4 months, and now I think I am very comfortable with it. I’d like to mention, that half of what I have learned about git, is the result of contributing to Astropy. So, I’d like to thank the community for that.

I find fixing bugs addictive. It is like clearing different levels of a game. Although, I didnt go past the 'easy' level, with Astropy, but I learned a lot.

I, currently have four pull requests, out of which 3 have been merged. They are:

#THE PROJECT

Proposal Title: Developing an advanced user-interface for browsing and viewing tutorials.

##Abstract The idea of writing and providing Astropy tutorials, has been around for about an year. Astropy 0.3.1 has been released, and now seems to be the right time to make them publicly available for users and developers. The advantages and benefits are 3 fold.

  1. For Experienced/Professional users - “They're for people who say 'All I want to do is X, I don't want to have to read through all this documentation!', where X is 'read a text file', 'read a fits table', 'convert pixels coords to RA/Dec' or something similar. ” - Neil Crighton. As Neil pointed out, going over the whole documentation, when you have to do something specific with Astropy, is very time-consuming. And tutorials will definitely save this time.

  2. For Newbies – They'll provide practical and conceptual coverage of tools at an introductory level. Also, people who are just getting started with Astropy, will quickly get to see its cool features and how useful it is. And then, as they wish, they can delve into the main docs, or get started right away.

  3. Increasing User-base – No doubt, the above points will come together and play a significant role in increasing the user-base of Astropy.

My project aims to bridge the gap between users and Astropy, and bring the tutorials to the world, in an organized manner. It aims to improve both the user-facing interface and developer-facing backend of the tutorials. Therefore, I plan to include content search, tagging, a feedback system and allow for different versions of the tutorials that correspond to different releases of Astropy. I also plan to make the deployment process as easy and as fool-proof as possible.

##Detailed Description

As our tutorials grow in number, so will the time required for visitors to locate specific information on it. Hence, I plan to extend the site with a search functionality, so that users can filter tutorials via a particular keyword, or a particular tutorial.

Adding tags to tutorials is a natural and convenient way for us to organize our collection of tutorials so the users can filter via different tags(topics, difficulty etc.) and quickly find the ones they want for the specific task.

Soliciting feedback from the community is critical to the long-term success of the tutorials. I propose to implement an easy-to-use comment system at the bottom of the tutorials for exactly this purpose. Users will be able to post and edit comments on the individual tutorials without having to go through the GitHub issue system. Developers will be encouraged to supply their feedback via GitHub.

The tutorials are closely related to the docs. Hence I plan to connect the Astropy documentation with the tutorials, by implementing an automatic linking feature using sphinx.

The goals that I want to achieve are divided into 2 categories:

Critical

  • I propose to develop a web interface to organize the tutorials, for astropy and its affiliated packages.
  • Make them searchable and taggable.
  • Link tutorials automatically to the documentation.
  • Streamline their deployment.

Optional

  • Allow for different versions of tutorials that correspond to different releases of Astropy.
  • Implementing a feedback system.

My mentor, Adrian, has already implemented a publishing system for the tutorials, which I think is great. I really liked the idea of having 3 branches. The web interface however, is not in place.

##Pre-Requisites and Requirements I fulfill all the requirements(in terms of pre-requisites) for implementing the project. I am proficient in HTML, CSS and JavaScript. I am also good in Python, and have a fairly good knowledge of and experience with nbconvert.

##My Involvement There are many reasons, as to why I am excited about being a part of the project:

  1. I wanted to contribute to Astropy. Since I have little astronomy knowledge, this is one more way, other than bug fixing, that I can contribute to the community.

  2. When I got started with Astropy, even I felt a need for tutorials. Not because the documentation was not enough, but because going through it was time-consuming. Tutorials, and short HOW-TOs, would be great for anybody wanting to get started, or even for experienced users, who want to get a particular thing done, but don’t want to go over the docs again.

  3. Because this will be my first big contribution to Astropy, and because it will be used by a lot of people, the experience and feeling that I'll get after the completion of the project, is inexplicable.

###Before The Summer I have spent quite some time learning how to use nbconvert, and Pelican. I also plan to look at the Sphinx extension tutorial, available on the sphinx website, to get an idea of how Sphinx extensions work.

###During The Summer During the summer, I plan to spend 7 hours for 6 days every week, and I’ll make up for less hours(if any) on sunday. I also plan to schedule biweekly meetings(twice a week), with my mentor, to update him regarding the progress(through, IRC, mail, or google chat).

###After The Summer Well, if I am not able to achieve the optional targets, I would definitely want to do them first. After the tutorials' website will go live, we’ll definitely get feedback. If there is something to be done, I’ll be more than happy to do it. Regarding Astropy, I plan to keep fixing bugs, and keep learning during the process. I have also planned to improve the test coverage, in case nobody takes it as a GSoC project.

##Project Timeline My project makes use of 4 technologies. They are, Sphinx, Pelican, web technologies and shell scripts to automate the process.

Timeline
22 April – 6 May (2 weeks)
An in-depth check of code and documentation of Pelican, nbconvert and Sphinx, will be the first thing I will do. I will also familiarize myself with the current deployment system. During this period, I would like to get in touch with my fellow peers who have been approved for GSoC. I'll get in touch with the senior developers, I will make sure that they know me and know what idea I am working on. Also important to get in touch with, are developers who are working on Pelican, nbconvert and Sphinx.
6 May – 17 May (1.5 Weeks)
Modify the current deploy script (or write server-side githooks – a possible enhancement) to first serve .rst files using Pelican. After it is successful, I will include nbconvert in it, and try to serve ipython(.ipynb) files. I plan to test it using existing tutorials. And after every incorporation, I will test with them. I plan to follow the test driven development path, to save myself from the horrific process of debugging at the end, and so that, at any moment, if I mess up, I'll not be too far, from the righteous path of correctness.
18 May – 28 May (1.5 Weeks)
Design the template, and configure it only for displaying the list of tutorials(which will be the page, on which users and developers, first land on), and the tutorials(HTML version of IPython notebooks). I will then, test it using, Pelican and the deploy script(or the githook) and make further changes, to ensure that the notebooks are wrapped perfectly.Designing the website would involve setting up pelican environment, and working with HTML and CSS (and JavaScript, in future, if required).
29 May – June 5 (1 Week)
Configure the template, designed in the previous week(which was only for displaying the tutorials-list and the tutorials), to include search. This would involve, implementing the plugin, designing the results page, and the search box. Since this is my first time with Pelican, things might go wrong, or might not work. I have worked with ajax search in the past, so, if I am not able to make the plugin work, I have a back-up plan. Here, the testing will be focussed on the search-results page, and I'll fix if anything is broken.
June 6 – June 20(2 Weeks)
Tags, I believe will be more useful for newbies, while content search, for a little more experienced users. Hence, the tag system should be made as helpful as possible. Pelican has a tag cloud feature. First I would implement this tag-cloud feature. This would involve, configuring the plugin, and the template. Also, a feature, for letting users search for multiple tags at once, is equally necessary(say, I need tutorials, for manipulating tables, but they should also not be very difficult.). For this, I would write a Pelican plugin, for 'filter-by-tags' feature, which is not yet available in the plugins repository.
June 21 – July 5 (2 Weeks)
Enter Sphinx. Now, I plan to use sphinx, to implement the automatic linking feature. It is very important to let users get to the docs, from the tutorials, if they plan to delve deep into the code. Lets zoom out for a minute, and see how things would work. Nbconvert will convert the ipython notebooks to .rst files. These .rst files will now be handled by sphinx, and it will convert then to HTML and will also take care of the linking. Now, it is important to note that the template(or the theme) will not be Sphinx's. These html files, will now be handled by Pelican(themes, search, tags and feedback), and will then be put up.
July 5 – July 14(1.5 Weeks)
In this period, I plan to implement the comments plugin on the page where the tutorial will be displayed. Since we are not using a server framework, it is not possible to include comments without using an external service. Hence, for the comments, I will either be using Google+ or Disqus as the external service.
July 15 – July 24(1.5 Weeks)
In these 1.5 Weeks, I plan to allow for different versions of tutorials, that correspond to different releases of Astropy. Now this would involve, tweaking with the deploy script, and reconfiguring the template to include tabs, for different releases. Things, might get a little tricky here, since, the task is manually trivial, but one has to be careful while automating it.
July 25 – August 10(2 Weeks)
Buffer period.
August 10 – August 22
Bug hunting, cleaning up code, beautification, collecting community feedback, reviewing comments and writing documentation.
Clone this wiki locally