My Google Summer of Code project was to improve the admin user interface for Review Board. For the past few months I worked on this open-source project building and adding new administration features.
Now I want to conclude this GSoC experience by writing my final progress report and mention some of the the challenges I had to face during this development process.
The new administration user interface consists of three elements. A totally new dashboard, an updated sidebar and a new header.
The new dashboard consists of a set of widgets, large and small ones. The large widgets take up the center of the dashboard and present the user with important activity information.
When the user logs into a brand new installation of Review Board, the widgets show informative link and text to start adding repositories and users. This component is important to user experience because it helps users get started with the product.
The widgets have a fluid layout and save the state if you collapse or expand them. I wanted to make sure the dashboard has a fluid layout, those with large screens would get a larger view of the dashboard, but for example someone a tablet would get a three column view. Some of the widgets have a set of action buttons. These action buttons allow fast access to adding and listing certain model entities. The action buttons are also easy accessible, especially on tablet devices.
The dashboard is optimized with daily caching and is updated when there’s an update to the database entities.
At first in my mock-ups the new admin sidebar felt like a small part of the project, but the more I worked on it the more important it became. The sidebar area transformed into a three-part area. Now administrators can access Review Board settings a lot faster by using the new System Settings sidebar block. The System Information block shows which settings are currently enabled or disabled.
Having the sidebar present on all admin pages makes it easier for users to jump between configuration pages. By moving all the settings items from the settings tab and into the sidebar, now admins are able to access feature settings faster, with a single click.
Right from the start, the goal of my project was move away from the default Django admin look. The challenge was to match the admin look with the existing application design, but still have a clear separation between these areas.
The design ideas for this section were to have a more ‘alerting’ view, as you can see in the yellow bar menu, and a blue “Back to Review Board” button, that helps you get out of the administration area.
The new branding header now shows that you are in the admin area with an additional title “Administration”. The navigation bar has only two items right now, but in the future it can be expended to add more tabs, such as Extensions and more.
I was able to complete the core ideas that I mentioned in my GSoC proposal. Following my project plan, it seems that I set the correct milestones, but I also added more milestones in the process. I spent a lot of time researching and working on optimizations such as caching and design improvements.
Even though my goal was to finalize the design in the early stages of the project, I still had to go back to the design tools to add a few bits here and there. I also had to spend a bit more time reading the Django admin source to be able to make it look like my goal design.
In my proposal I mentioned a lot of ideas for expanding the admin area, such as providing helpful tips to new admins, being able to fully customize the available widgets and manage extensions. I was able to add the main functionality to make these things possible. Adding new features and interface fixes should be really easy for any project contributor, because in most cases I tried to borrow the same code structures as the existing code and follow all existing code formatting guidelines.
In the future, I would like to learn more about code testing and therefore add some tests to this code. Also, fix more bugs from the issue tracker and of course push my admin interface changes into the master branch.
Here are some of the challenges that I had to deal with during this project.
UI Chart Library
Finding a chart library that can be used to create widgets in the dashboard. This component had to be open-source, with an easy API and work in a lot of browsers. In my case I chose to use Flot for this project. I could easily integrate Flot into my project, because it’s a jQuery plug-in. By adding canvas support to IE with excanas, Flot was an excellent choice for this project.
Supporting Python and other modules
Supporting different versions of Python was a fun challenge. Review Board currently supports Python 2.4, even though this will change in the future releases, I wanted to make sure my admin changes worked properly in all environments. Some of the Python modules such as datetime and time changed in the recent versions, this had to be addressed in my project.
Different Database environments
Some of the dashboard widgets required complex database queries. I had to make sure they would work in MySQL, SQLite and more.Thanks to Django and great Review Board debugging tools, database issues were easy to debug.
Getting into GIT branching without ever using them was an interesting experience. It was my first time working with branches, at first I could not grasp the concept. Now I can’t live without using branches and other GIT features that I learned during this project.
Dependencies and Project Helpers
Review Board has a lot of dependencies, one of them is the djblets project. It’s a collection of utilities for Django. Part of my project was to write a patch for that project and later use the new additions in my admin code. This was an interesting process and I hope I’ll get to use djblets in some other projects.
The project utilizes a lot of client-side technologies, such as HTML5 canvas and more. I had to perform a lot of browser testing to make sure everything worked properly. For example, dealing with Internet Explorer issues, I had to add fading effects when toggling widget text. This change made the widget behaviour a bit different, but helped it look better in all browsers. Another example, every time a collapsed widget is loaded the canvas elements do not render; the trick to fix these issue was to wait for canvas elements to render and then collapse the content view.
Working with dates and time.
I started off by using CSS3 Media Queries for early prototype versions of the dashboard and even blogged about it. However, the more I worked on the dashboard, I started to realize that a dashboard layout is a lot different from a responsive CSS site layout and regular CSS floats. Later in the project I switch to the amazing jQuery plug-in – jQuery Masonry. With this plug-in I was able to create a much more attractive fluid layout that CSS media queries and floats could not match.
I finally got to work on creating a fun dashboard user-interface, it was really exciting and full of challenges! This development experience will help me a lot in the future for sure. I thank my mentors – Christian, Mike, David – for helping me out and being patient with all my questions, and my fellow co-students Babak and Alexander.
Thank you again Review Board and Google for this amazing summer!