About Me:
Overview:
Description:
You could imagine that a company that uses BaseCamp or Highrise or Backpack not only uses 37 Signals' software, but probably other online software. Imagine, for example, that they also use Freshbooks (from FreshBooks.com) for managing their invoices, billing, payroll, etc.. You could imagine that the list goes on for different sites that they would use and their purposes. You can see that there is a problem here. The user has to go from site to site to complete all of the tasks that they may need done within a single day. However, most of the sites offer APIs so that they can be extended, used elsewhere (such as an iPhone for example) etc. My question is, if we have all of these APIs for interacting with all of these services that we use on a constant basis, why don't we implement a system in such a way that we can manage all of our data from one place. Why do you think rss feeds are so popular? One reason is that it allows us to use feed readers (such as Google reader) that allow us to read all of the news that we want to read in one place. I see this proposal as contributing to this idea that you only need to go to one place to manage all of your data whether it's PM information from BaseCamp or invoice information from FreashBooks.
I would like to integrate the APIs from 37 Signals into Drupal, essentially removing the need to log into BaseCamp, Highrise, etc. to manage your BaseCamp data.
In the future (beyond GSoC), I could see possibly extending the functionality of BaseCamp, if needed/wanted. I would also like to work with/on implementing other various (hopefully useful) APIs from other popular projects.
Mentors:
Contact Details:
- Email: murrayj5@nku.edu
- Phone: +1 502-442-6682
Difficulty:
By implementing various 37 Signals APIs, you help make Drupal the central place for managing data vital to internal operations. This promotes Drupal as a serious CMS that can be used for more than just blogging or sharing photos. I believe by making Drupal a serious CMS for internal operations, you increase the reputability of the system among developers and that, in turn, will help increase it's adoption. Adoption of the system for internal use is a new way to achieve the third goal:
To encourage people to improve their communities by supporting the free exchange of information and ideas.
This API integration allows companies the power to share their PM information with the public (or perhaps just the clients :-) ) and it also provides a way to share information internally in a company. For example, with this type of integration, a department of a company, say marketing, could easily (and unobtrusively) track the progress of a project being managed by a separate department, say the IT department.
The project would take the entire summer (GSoC). However, after the summer, I would like to continue work on the APIs, possibly extending the APIs to contain new capabilities and possibly implement new APIs for other various online services.
The project will be implemented as a module inside Drupal. Most likely, each product API will be implemented as a separate module, giving the site user/owner the ability to pick and choose what exactly they want to implement their perfect "content management portal" per say.
All funding would come from GSoC. :-)
Comments
Looking Back...
So, I read over this and realized that the Description section of the GSoC proposal sounded more like a persuasive argument that an actual description. So, let me elaborate on the subject.
This module, or set of modules as it may be, will not only allow the users of the site to manage thir information, but also share their informatoin. The user will be able to organize and catalog different projects/todo-lists/tasks/contacts/etc. into an easily searchable and maintainable layout. I would like to integrate fine grain permissions that allow the sharing and collaborative editing of projects/todo-lists/etc.
Users, or groups of users, will be associated with particular users in the BaseCamp, Highrise, etc. system. For example, a project manager for a company could create a user group called "Marry's Kitchen Site" within the Drupal system and that user group would be associated with user on the Basecamp site that has access to manage a project dedicated to working on "Marry's Kitched Site."
It would be more likely that each user in the Drupal system (that would be working on a project) would associate their user in the Drupal system with a user in the Basecamp/Hihgrise/etc. system. Allowing a group to operate under one user is a feature that would allow sharing of PM/Contacts/Taks/etc. information with users that are not associated within the Basecamp/Highrise/etc. system. This could be useful for sharing information with clients or upper management that is keeping tabs on a projects progress.
--
Thanks!
John Murray
I don't quite understand
What's the benefit of connecting it with a drupal site. Wouldn't that make it even more decentralized?