There are millions of tools available on the internet for millions of different, specialized purposes. For any given mission, there are probably dozens of competing products with different focuses, user interfaces, etc. The most successful product is not always (or even normally) the most efficient or effective product; it's the one that has the largest community buy-in.
In order for a project--especially one that's based in collaboration or social media--to be successful, community buy-in is as important as the product design. Since our project--TroyNexus--is so community focused, I've been focusing a lot over the past several week on ensuring that the major stakeholders in the Troy community are aware of and excited about the development of this project. This also provides a valuable opportunity to collect feedback and get an idea of how each set of stakeholders will actually use the product; it's easy for the designers to come up with a theoretical set of needs for each group, but it doesn't necessarily coincide with reality.
Although these meetings haven't led us to change anything major in the site design, they have helped us assess our audience, underlined our priorities (usability, project guidance, archives, etc.), and led us to form relationships that will be crucial in the release of this product.
I've gotta admit, I'm not typically a Helvetica person. The "hallmark" of a Reilly Hamilton designed site is Gotham. Gotham everywhere. Gotham Black logo, Gotham Medium navbar, etc. The other "tell" is the gradient. Oh my, do I love gradients. Just take a look at current "working" Nexus logo. It just screams "Reilly".
But I'm trying to take a step back from my typically "busy" layouts of yesteryear and do a nice, clean simple "Web 3.0" layout. This means large white spaces, not-black blacks, thin dividers, and Helvetica. I've been using Google+ and the new Gmail theme as my inspiration.
One of my foibles is that I have a hard time coming up with the "spark" to start off a project, which is part of the reason I gravitated toward this project. It has a massive vision; one which I didn't help to create. I didn't come up with the idea, I didn't spec out the requirements, I didn't initially communicate with the client to determine their interests, and I'm quite pleased. My goal is to realize this vision. I'll make plenty of decisions along the way, but these decisions affect how the product is designed internally rather than what features it'll support.
The first action I took on this project was to condense the huge mind map created by Lee and the Client in to an Object Diagram. I used an online service called Gliffy for the UML constructs. The relationships between objects would serve as the basis for my Rails relationships later down the line. I gradually shaped the Object Diagram in to a Database Schema of sorts, carefully considering what kinds of joins to use for each relationship.
It's this sort of planning that really helps down the line. With the database schema/object diagram in hand, I began scaffolding out each of the objects in Rails. Scaffolding creates a rudimentary model, view, and controller for each object as well as a table in the database with all the columns specified during the scaffolding process. The newly scaffolded object contains four basic views/actions: index, show, edit, and new as well as three additional actions: create, update, and destroy. The scaffolding process really help throw down a lot of base code quite quickly.
Once enough objects are scaffolded, associations between the objects are established in the model. Most associations are readable in English: A User has many Projects. A Project belongs to a Category. A Project has and belongs to many Tags. The type of association determines which table the foreign key is located in. Simply adding an association creates helper method. Calling user.projects returns an array of projects; calling project.category returns a singular category. Rails does a lot of pluralization magic behind the scenes: it knows the plural of category is categories, for instance.
With the associations figured out, the next step is to start linking together the objects on each others views. This creates a sort of hierarchy. Ideally, I want to be able to reach any instance of an object through a series of links.
Next, it's time to start defining how objects actually interact with each other. What does each association mean for the user, and how should individual relationships between instance be created and managed? This stage typically means a lot of UI design, and for this project we're using jQuery as a library.
This step is where Nexus is now. All the fundamental models and associations are established, now it's time to smooth together each relationship.
Once that's done (which will be quite a while, this is perhaps the longest phase), we'll integrate the design elements of the layout, round out any remaining problems, and deploy.
Next time I'll talk a bit about some of the "trick" polymorphic associations I'm using and dive into some of the Ruby behind certain aspects.
It's a week into RCOS, and we're working hard to lay the groundwork for the weeks to come. There are a few different angles that we've been working over the past few days, but most of it has been focused on the feature sets and user interface.
Because our project is being implemented for a very specific community, Troy, we're working closely with the Business Improvement District (BID) in determining the needs of different community groups, neighborhood associations, government officials, active citizens, and other key stakeholders in this product. This Wednesday, Reilly Hamilton, Anasha Cummings (who's helping us on the project), and I met with the head of Troy BID, Elizabeth Young, to talk about what sort of features and user interface the community needs. Much of the discussion was reiterating things that had been said before (Anasha, Elizabeth, and I along with several others had met a few times last semester discussing the logistics behind and requirements for this project), and the conclusion of the meeting was basically affirming our previous priorities and Elizabeth volunteering to survey community groups about their needs.
As for our previous priorities, this project has been in development for a lot longer than this summer. I'd been discussing the idea of a project management site with Anasha that works in a college environment, where there are a fixed number of students, but the actual membership of "teams" and project participation varied wildly (at the time I was mostly concerned with accountability in projects); we brainstormed different ideas on how to increase accessibility to institutional knowledge and collaboration/awareness of similar project as well as how to empower students to make change. After our strong run for the Pepsi Refresh grant, Anasha started to look into how we could implement such a system in Troy for the Downtown Collaborative (which Elizabeth was, at the time, leading) and even did his work for Public Service Internship brainstorming requirements.
The product of these previous discussions, old work, and the meetings with Elizabeth, Anasha, some local RPI alumni, and I was a very detailed user interface and feature requirements for a wide-reaching web application. Although this iteration would be impossible to complete in three weeks, having something concrete gave us a base. We did a lot of our brainstorming from that point using FreeMind, an incredibly useful mind-mapping software. From there, we mapped the project goals, the potential users (in Troy) and their interests/needs, and the different types of projects and ideas that the application would need to accommodate as well as the basic website flow (user interface) and the system design, describing the different features of the application and their interactions with each other. By the end of this week, we'll have the initial mind map narrowed down to something that can be completed in 10 weeks but also retains the initial purpose of the project.
Over the next week, we're going to define exactly what users need to get from this application and, more directly, what features we need to implement to facilitate that user experience. From there, we'll plan through diagrams and whiteboards how these features will interact with each other and how they'll be implemented, and likely next week we will begin our coding. Personally, although I've been very involved in this project since its inception and was an avid programmer and tinkerer several years ago, my skills are rusty now. Besides working on the foundation work for this project, I will also be spending this coming week brushing up on my skills through some simple Rails side projects, hopefully putting me in a good place by the time our coding starts.
Problem: Troy, like many other localities, suffers from a disengaged citizenry and unresponsive political system. Currently there is no infrastructure in place for an online project management system which is capable of dealing with the real world constraints found in grassroots efforts. Constraints such as flexible membership, variable commitment, and grassroots project proposals.
We are proposing the creation of a social project management system, supported by the Troy Downtown Business Improvement District, which would allow streamlined project management and development in a uniquely inviting and open way. The goals of this project are five fold:
Provide a system for existing groups to organize projects, get people involved, and archive project states for future development.
Allow citizens of Troy (and/or any locality where this is deployed) to submit and develop project ideas online.
Facilitate the project actualization process through a guided web system as well as by connecting people with the necessary resources to solve problems.
Integrate with existing systems via APIs facilitate the growth of projects through social networking connections.
Openly allow affiliation with projects by new members to create an open-source model in the physical sphere.
Related Projects and Literature
A literature search returned no current open source projects currently filling this niche. There are many acclaimed online project management applications, such as Basecamp and No Kahuna; many problem- or goal-based social media sites, such as Stack Overflow or Kickstarter, but we were able to find no intersection between the two fields or any project management software focused on a community as opposed to a fixed team or business.
We believe that this hole exists because community-based action—with flexible teams, clear project archival, and multiple allegiances—is not is not something traditionally thought of as under the realm of project management. However, a centralized accountability source is clearly a need for the community. We hope that by integrating tested features of project management while focusing on the unique attributes of a community and building an accessible project memory we will be able to fill this current niche in the Troy community and beyond.
Schedule and Plan of Action
This project will follow a 10-week timeline; two weeks will be allocated to the elaboration and transition phases while the bulk of the work—8 weeks—will be the construction phase. During the elaboration phase, we will design the user interface for the site by completing the mockups and mapping out the functionalities and their technical specifications. The framework will be Ruby on Rails using SQLite for development; additionally, JQuery and AJAX will be used to enrich the user experience beyond static pages.
The construction phase will be broken up into four two-week iterations. The first iteration will focus on developing the project submission and progression mechanism, which would display inputted fields in different manners depending on the project’s stage of development (idea, review, feasibility, and implementation). Additionally, this step involves creating an algorithm to control project progression from idea to implementation. The second iteration will focus on the project archival and search features, during which time we will implement a problem-based map and introduce a tagging and verification system into the project submission and progression forms. The third iteration will focus on the creation of users and groups in the application and customizing the individual user experience through traditional project management tools (calendars, tasks, list of projects, updates, etc.) The fourth iteration is integrating more application features with Google or Facebook through use of wall posts, Facebook Applications, on-site commenting and foruming, and other current heavily-used features. The transition phase will encompass the final testing processes and project deployment
Each iteration within the construction phase has a base set of functionality requirements in order to make the web application accomplish its purpose. However, each of these iterations has potential to be expanded upon to make the final product more robust. This development plan gives us the flexibility we need to ensure that the end product will be functional and fulfill its purpose while ensuring that each feature is fully tested.. Frequent iterations allow us to meet often with the project stakeholders to ensure the project is carrying out their vision to its fullest potential.
The minimum deliverable will be a functional community-based project management web application with verified users, user/group pages with individually relevant information, project entering mechanism, project progression (rules that promote an idea to a work in progress to review to implementation with associated individual features), some basic project management tools including tasks, milestones, and discussion, and a search and archival mechanism. The maximum deliverable will include the core functionality of the minimum deliverable while further developing the social interaction through integrating with Google, Facebook, foruming, and other currently-used social media outlets and user interface through developing several different models of increasing complexity and control based on how a user ranks their technical skill/interest. Additionally, the maximum deliverable will include a problem-based searching mechanism by which a user may submit problems
Two students will be working in collaboration with the Troy Business Improvement District (and their liaison, Anasha Cummings) in order to complete this project: Lee Sharma (AERO, ‘12) and Reilly Hamilton (CSCI/ECON, ‘12).
Lee has been involved in several projects through her classes, but the most extensive of these was working on the development of a quad-directional neural-directed wheelchair, which processing the input of an EEG cap through MatLab, LabView, and a C++ program in order to control the motion of an electronic wheelchair. Lee has not been an active programmer for the past three years due to her involvement in Student Government and other community activities, and she looks forward to this opportunity to improve her skills while benefiting the community.
Reilly has participated in several WebTech projects such as Shuttle Tracking and Flagship Documents. He has developed internal titling and graphics software for RPI TV’s live production environment using PHP, GD, ImageMagick, and MySQL, created a detailed college hockey ranking and prediction program, and has developed and maintained several web applications in both PHP and Ruby on Rails.