GSOC 2013/Student Application Charlesx/GlitterGallery
Fedora Summer of Code Proposal
Email: charlesx AT berkeley DOT edu
GlitterGallery as a concept is great. Having a form of git-like version control enhances a designer’s ability to collaborate not only with a team, but also with the rest of the world. Having designers work with each other through GlitterGallery will improve quality of design, increase productivity, and be a great platform for designers to share designs, all from the comfort of their computers. Who doesn’t want that?
However, at its current state, GlitterGallery is not ready to be deployed. There are many bugs that have yet to fixed. Pull requests (at the time of this proposal) have not been repaired. Pictures cannot be deleted. But most of all, there are so many features that can be implemented and fleshed out.
This project will not only fix and repair these bugs, but will also implement these features to improve the functionality of the growing GlitteryGallery project.
Here's a list of proposed features that I will implement this summer.
Fix various bugs.
Implement additional login abilities.
Allow users to “friend” other users.
Along with implementing feature/fixes, for each proposed idea I will also include basic integration testing using capybara, rspec, and cucumber.
Benefits to GlitterGallery
Among other things, this project will primarily further enhance the ability of GlitterGallery to promote and stimulate contribution and collaboration within the community of designers. By allowing users to friend others, they will be able to keep track of the needs of the people they follow, and possibly contribute. Allowing people to view projects that are not their own will promote users to chip in to open source projects. Issue trackers will help designers post design problems and ask questions.
GlitterGallery has so much room to grow as a site. There are still so many features that can be implemented. With this project, the website will be able to do so much more.
One of the first tasks that needs to be implemented is the design of a more comprehensive test suite. As the codebase continues to grow, it will be increasingly difficult for collaborators to test and retest features to make sure new changes to the code won’t break already existing implementations. The first week or so of this project will be dedicated to revamping the existing test suite, creating comprehensive test cases to check for even the most extreme use cases. This can be discussed with other collaborators of the project to make sure all cases are covered. This part of the project will be written using rspec and capybara to do the actual testing. I will design and work out a system so that each model and controller will have its own set of tests.
The other part of this task will be fixing up bugs that still exists, even before new features are implemented. This will help streamline the process and prevent long periods of debugging.
This is the login page as it is right now:
Could use a facelift.
The problem with this login page is that it isn’t very user friendly. GlitterGallery was originally meant to be used only in conjunction with Fedora id users, but as GlitterGallery expands, it should include other login options as well. OpenID can be used with other sites such as WordPress, but users don’t know that. Using Devise, which also supports OpenID, we can make this signin process much more convenient for users, allowing them not only to signin with traditional username/password combinations but also sign in with Facebook, Google, and other outside information. I would also redesign the login page so that logging in will be simple and easy to understand.
Of course, the GlitterGallery admins should have the highest input when it comes to the various methods of authentication. This issue will be throughly discussed with the mentor before implementation to ensure that each authentication method is approved and safe.
Here’s a proposed low-fi mockup:
A great feature that GlitterGallery can implement is the ability for users to find and follow other users and their projects. This would require a searching function, a show users page, and a user profile page where you can follow projects (ajax to be implemented when you unfollow projects from this list). With the ability to search, users can filter out those that they are interesting in helping, and contribute their ideas to the project. Users can also follow projects that they like from their friends. Ideally, this feature wouldn’t be of much use if you didn’t also have a notification based system. The search function can be implemented with simple database queries, and presented in a list. The user profile page would include their nickname, actual name, and projects that they have created.
Here’s a mockup of the proposed change:
Searching for a user.
Being able to follow/friend users/projects is quite pointless unless there was a way to track the things that a user follows. Fortunately, the next part of the project calls for the implementation of a notification bar (which can be turned on/off) by a user. This feature allows for users to really know what is happening to a project they like, and will make it more convenient to catch up. As it is, there might not be enough time to make notifications live (notify without refreshing), but if there is more time, that can be implemented.
Currently, the only way for users to fork/view projects is by directly manipulating the url (ex: changing to /projects/3 to access the project with id 3). The user has no idea what project they are looking up, who the project owner is, or even if they’re looking up the correct one, until they actually visit the page.
This feature will include a page where users will be able to see projects under various filters, such as “popular” and “trending”. This will require me to implement a popularity feature in which a project will be moved higher on the list as more and more people fork their project. There are several methods to implement this “reputation” system. I can either create a like/popularity system where users can upvote projects that they like, or use a gem such as activerecord-reputation-system, which includes a “karma” rating for each project.
A GitHub comparison would be the “explore” feature that they currently have, which allows users to discover projects that many people have been contributing to.
Look for projects you like!
The issue tracker will be used much like how people use it on Git - to propose changes, notify contributors of bugs/other problems, and ask questions. This is an extremely useful feature to add to GlitterGallery, seeing as it is another channel of communication between designers. Issues will be able to be opened and closed by all users of the website, and will be commentable. To implement this will be quite tricky, but it is worth the effort.
If Time Allows
The following section is dedicated to list the features I will implement if I finish any of these projects earlier than expected. However, the priority lies in completing the main tasks. (Not that these additions aren’t important)
Adding a like system to comments (not necessary, but would be good).
Built-in chat applications (using services such as Pubnub and Faye).
Adding a help page for new users explaining what GlitteryGallery does.
Adding ability to convert svg files into everyday PNG/jpeg files.
Adding ability to download pictures.
Each feature (except for the test suite) will have its own cycle of 2.5 weeks, in which I will plan, code, and write a test suite for the idea. No tests will be written for test suite, for obvious reasons.
Meetings with Mentor
This is by far the most vital part of the project if it is to succeed. Communication, though not face to face, will help my mentor and I discuss plans and problems before I begin coding. I plan on meeting with my mentor at least twice a week via web chat or phone call during iterations of code, and at least once before starting the next part of the project. Questions and smaller discussions can also be done through email, Facebook chat, and any other forms of written communication.
Here’s my plan for the summer (and before):
(Now - May 19): Get to know the codebase. Gain knowledge about associations within models, what routes where, what renders what, what each gem does. Also begin to test gems that could be used in coding period on test applications and study documentation related to each one. Brush up on basic HTML/CSS for simple redesigns, and read up on bootstrap docs (assuming that’s what GlitterGallery is switching to).
(May 19 - May 26): Start working test suite. Write edge case tests and attempt to break code (not permanently) to see what bugs have to be fixed. Attempt to simulate regulate user interaction with the website and see if anything seems out of place/choppy.
(May 26 - June 12): Begin revamping authentication systems, using gems such as Devise to make the job easier. Allow authentication from third party services such as Facebook, Google, and OpenID providers to provide options to the user. I feel that this job may not need to take 2 weeks, so if I finish early, I’ll start working on the additional features list.
(June 12 - June 29): Following/“friending” users/projects: implement a system in which users can search for projects and users and follow them. This will be done live, so that the user can see results with each keystroke.
(June 29 - July 16): Implement notification system on projects that users follow, such that they can keep track on the entire design process. Begin work on “exploring” projects feature.
(July 16 - August 2): Finish “exploring” projects feature, and implement issue tracker so that users can open/close issues.
(August 2 - Aug 11): These last days will primarily be used in case something goes wrong, and a feature cannot be implemented in time (a “fallback” time period). The unexpected must always be expected. If a miracle occurs and nothing goes wrong, this week will be used to implement as many of the additional features list posted above.
(Aug 11 - Aug 18:) Last minute testing, fixing up any last bugs that may pop up.
When Things Blow Up
There is no guarantee that everything will run smoothly when the time comes to start coding. Bugs will rear their ugly heads; things will run, but not correctly. Here’s a list of things that could possibly go wrong.
Features that change existing code could screw up other code that have dependencies.
Features may be more difficult to implement than previously believed.
Tests are not comprehensive enough.
GlitterGallery may become too awesome after GSoC 2014.
Most of these problems can be solved with prior planning, testing, and collaboration. When writing test suites, the collaborators on the project should gather and discuss edge cases that may possibly break the site, and code test cases to verify that the website won’t break. I’ve given myself extra time to implement each stage of the process to account for potential bottlenecks in the project.
I believe with a little collaboration between team members, there is no problem that will be too hard to solve. Everything else can be googled. The last problem, however, may be impossible to prevent from happening.
To anyone reading this proposal: Hello! I’m Charles Xue, a freshman EECS major studying at UC Berkeley (Go Bears!). I started coding rather late (most people start as soon as they’re born), learning python on eDX during my senior year. It was a great beginning - so much so that I decided to switch majors during my first semester. This past semester I’ve been studying Ruby on Rails, finishing both 169.1/2 (Software as a Service, using Ruby on Rails - Check it out!- on eDX, and other online tutorials. I’m excited to learn so much more about what Rails has to offer. This semester, I’m currently in the process of getting into Node.js and mobile development with Android.
I’m a programmer by day, but a piano jammer, manga lover, racket sports player, video gamer, yearbook designer, guitar strummer, and board game enthusiast by night.
Why Choose Me?
So after reading up to this point, the question becomes this - why should you choose me out of all the other candidates that are also just as bright, if not brighter, than me? Simple.
I’m persistent. I’m not afraid ask questions, whether it be to google, stack overflow, or other contributors to GlitterGallery. I’m willing to stay up as long as it takes to get things done. I pride myself on my ability to complete tasks earlier than I plan to (or at least on time). Most of the work I will be doing will be before the summer even starts, prepping and testing out gems/designs on test applications before they are implemented into the GlitterGallery project. Railscasts will be my new youtube. No Rails tutorial will be left unread. By the summer hits and the program begins, the only thing will be implementing the features that I list on my proposal and bringing them into fruition.
In addition, I also have experience working on projects involving Ruby on Rails. After finishing Michael Hartl’s tutorial on Ruby on Rails, I proceeded to experience with Rails on my own, recreating the twitter application again to fully understand the basic mechanics on rails. I then built my own voting application from the ground up, modeled after a high school’s student body voting process. This semester, I’m also working on two separate Rails projects for Berkeley. The first is Beehive, a website that matches students with professors to collaborate on research projects. The second is a quiz portal for 61AS, the introductory computer science course taught at Berkeley. This project involves creating a platform in which students can take quizzes and staff can grade them, saving overall paper usage. These projects have helped me understand the full scope of Rails (which takes more than a semester to fully grasp), as well as teach me things I never knew existed.
A link to my GitHub: Check it out!
Experience with GlitterGallery
Over the past month I’ve been diving into the codebase for GlitterGallery, seeing how everything fits together in the bigger picture. I’ve also been coding smaller features in the website, adding pagination to comments, implementing comments to use ajax, and fixing smaller bugs during my journey to understand what everything does. I’ve also been active on the issues page, posting bugs and errors that need to be fixed and taking up repair tasks myself.
I have never contributed to open source projects before, but as a FOSS user and designer myself, I’m excited for what GlitterGallery has to offer the world.
I've been in contact with the project's mentor, Emily Dirsh, and she would be my mentor if my proposal is accepted.