Introduction
This page will track progress of the GSoC 2011 project, GUI Overhaul (Fronted and Administration Interfaces).
Details
The first tasks will be gathering some requirements from Melange administration. We have gathered following requirements from Carol:
- Enhance administration dashboard
- Withdraw/accept students from administration dashboard, even after the students with projects has been announced.
- Make the regular dashboard more usable both in how the list requested and rendered
I also came up with following additional ideas to enhance Melange:
- Adding breadcrumb. See Jacob Nielsen's article on how breadcrumb navigation increasingly useful.
- Adding Cluster Map for program administrator. With this feature, program administrator can see all participants location in a single map or even get information/profile for a participant by clicking at the marker.
- Upload handler for organization‘s logo. Currently, organizations need to provide a link to theirs logo’s url.
Iconic Dashboard Architecture
Iconic dashboard basically is a chunk of template, or a Django view that will be rendered as a partial HTML. Specifically, the view will be rendered as a collection of links that either nested (link to another block/div in the same page) or linked to another page. Iconic dashboard consists of:
- Django view (app/soc/views/dashboard.py). Classes in this view are not supposed to be instantiated directly, where each class acts as a base class. To implement iconic dashboard at least one derived class must be created.
- Django template (app/soc/templates/v2/soc/dashboard/)
Don‘t be confused with a dashboard page (participant dashboard and admin dashboard) and the iconic dashboard itself. To avoid the confusion, let’s say iconic dashboard is a helper in form of view and template that used by dashboard page, such as participant dashboard and admin dashboard in gsoc module.
It will be easy if we have an example of implementation. Lets say we want a GSoC view named dummy_dashboard (which is in app/soc/modules/gsoc/views/dummy_dashboard.py) implements iconic dashboard with following requirements of links:
- “A”, with description “This is the first link” and has two children:
- “A-1” with description “Lookup profile page” and links to lookup page
- “A-2” with desctiption “This is actually a link to another dashboard containing two links that appear at the bottom of this description if you set the dashboard in the view correctly” and has two children:
- “A-2-1” with description “bla bla bla” and links to lookup page
- “A-2-1” with description “bla bla bla” and links to lookup page
- “B”, with description “This is the second link” and has two children:
- “B-1” with description “List of my todos” and links to a dashboard where my todos will be listed in.
- “B-2” with description “List of my todos” and links to a dashboard where my todos will be listed in.
In iconic dashboard implementation, both “A” and “B” are considered as link and dashboard (because “A” and “B” have children, hence it acts as dashboard/container for their children). The root/main dashboard must be defined in the view to act as a container for both “A” and “B”, let's name it MainDashboard. This is not a must, but it will make life easier later if we name a dashboard class with “Dashboard” suffix. From our requirements aboove, there are five dashboards, eh six with the MainDashboard:
- MainDashboard
- DashboardA(Dashboard)
- DashboardA2(Dashboard)
- DashboardB(Dashboard)
- DashboardB1(Dashboard)
- DashboardB1(Dashboard)
“B-1” and “B-1” have no child, but they contain list. So either it has children or list, declare it as a dashboard. All classes must be derived from Dashboard. To import the base class of dashboard:
...
from soc.views.dashboard import Dashboard
from soc.views.dashboard import DashboardUserActions
...
If the dummy_dashboard needs to render list component (such as in the participant dashboard), then Component class must be imported too.
...
from soc.views.dashboard import Component
from soc.views.dashboard import Dashboard
from soc.views.dashboard import DashboardUserActions
...
blabla
Given use cases of GSoC program below on how to alter the dashboard will give you an understanding how the dashboard works.
Iconic Dashboard Use Case in Admin Dashboard (GSoC)
Iconic Dashboard Use Case in Participant Dashboard (GSoC)
Meetings and Agendas
May 10, 2011
My result reported in this meeting:
Not yet
Meeting notes, copying from Leo's note:
- Set up and run an online GAE instance before Thursday with your “View” from the first week.
- Write a blog post about it (and other work you've done) before next Monday so it can be reviewed before our conference call.
- Create a wiki page on Melange wiki for recording the progress of your project.
- Plan a meeting with your mentor and add notes to your OWN project wiki page.
My plan for next week:
- I've set a live instance at http://akeda-melange.appspot.com
- Started writing wiki page to track my project's progress
- I'm planning to refactor melange.map.js to be more generic. As Mario has said the current status of melange.map.js functionalities is not supposed to be. It only provides map to organization home page. Other pages, such as profile and read only profile, have their own js files which, basically, have common usage of Google Maps API. The refactored melange.map.js should handle all maps functionalities, including my proposed function for MarkerClusterer.
- Upload and crop features for org logo.
May 16, 2011
My result reported in this meeting:
- I am working to make melange.map.js more generic, so it can be used by profile page as well, or maybe other pages that need to render maps.
- I am also working to add breadcrumb and highlighted mainmenu in currently visited page
Meeting notes:
Copying from Lennie's note: Daniel and Akeda will meet with Carol on Wednesday using Skype to brainstorm about their project.
My plan for next week:
- Submit my code for breadcrumb functionalities to get any feedback
- Prepare talking with Carols about her needs
May 18, 2011 (Requirement gathering)
My result reported in this meeting:
Not yet
Meeting notes:
- If we're login as a host and view the dashboard (My Dashboard), we will see the page overloaded by Jqgrid list. Carol wants the list is grouped. Akeda has suggestion to group the list by tabs.
- When students with project announced, there might be a student consider himself ineligible to participate. If Carol rejects that student, there will be available slot to accept another student that already rejected. Carol needs this feature to withdraw / accept student in her dashboard.
- Carol needs the Admin dashboard to be enhanced.
My plan for next week:
- Create mockups for the Dashbord page with tabs to group the list
- Create mockups for the withdraw/accept students manually after students announced period
- I'm planning to give the mockups by Saturday so everyone can give feedbacks
- I will implement this feature after everyone agree with the mockups.
May 26, 2011 (Requirement gathering)
My result reported in this meeting:
Not yet
Meeting notes:
- Akeda is working on redesigning dashboard. Lennie reminded him that there are two dashboards that Carol is faced with. One allows administrative functionality like sending out reminder emails while the other represents not only Carol's role as a Organization Admin for GOSPO but also gives more information than the regular dashboards for other users. The focus should be on improving the usability and functionalities that are exposed to Carol in her daily job as Program Administrator.
My plan for next week:
- Contact Carol and Daniel to discuss the requirements briefly
May 30, 2011 (Requirement gathering)
My result reported in this meeting:
See the notes at Google Wave, https://wave.google.com/wave/waveref/googlewave.com/w+mdcpD6vmC
Meeting notes:
My plan for next week:
- Give updated mockup and if possible with the implementation.
Jun 06, 2011 (Toggleable list)
My result reported in this meeting:
See the notes at Google Wave, https://wave.google.com/wave/waveref/googlewave.com/w+P8uYzs7_C
Meeting notes:
My plan for next week:
- Implement toggleable list and start working on admin dashboard.
Jun 13, 2011 (Toggleable list)
My result reported in this meeting:
I‘ve posted the toggleable list patch to melange-soc-dev. The toggleable list is works by set the context of toggleable and collapse on component based class in app/soc/modules/gsoc/views/dashboard.py. If we set both toggleable and collapse to True, then the list wouldn’t requested by the JS, but it updates the list_configurations variable with idx as its key. We still can make the list requested on the first load by ignoring toggleable and collapse context. With this approach, other list such as accecpted_orgs wouldn't affected.
Meeting notes:
My plan for next week: