So you're working on a web page and you're making some adjustments to the CSS files, and you want to see what those changes look like.  You click reload, but it reloads the whole page, undoing all of the changes that have been applied to the DOM via javascript.  There's got to be a way just to update the CSS without refreshing the whole page, right right?

CSS Reloader is a [Chrome] browser extension that allows you to reload CSS without reloading the page itself.

From Chrome Web Store - CSS Reloader.

There's a similar tool for reloading CSS in Firefox, too!

I had a much longer post written about the kind of project management software I would like to use, but it assumed that I wanted to work a certain way -- a way I really didn't want to work.

The problem is this: Project management is made hard.

It's not that project management is hard. It's sometimes challenging, but it's not hard. I believe, completely without evidence, that following basic procedures and using tools that fit will most often result in a positive outcome. A tool that would help me manage a project would be more than a bug tracker alone, but that should be a component of the system.

So what does this thing include? Primarily, it should be simple to use. It shouldn't do anything extra than what it minimally needs to get the job done. That's not to say that it should be inflexible, just that these additional traits shouldn't be user-configurable. You should be able to just turn the system on and have it work.

Minimally, the system needs to track a few separate things:

  • Projects - Projects are larger tasks that have a well-defined begin and end condition that involve achieving one or more goals. Projects are made up of the definition of starting and goal states, and also list the stakeholders of the project, the communication plan for the project (including who to call when a decision needs made, and how often communication should happen), and other miscellaneous details that don't have specific tracking components.
  • Deliverables - Deliverables are the fruits of the project that you deliver to the client. A project can have multiple deliverables, although simpler projects might have just one. Projects should include a deliverable when and only when something should be given to the client, and it should be reasonable to associate delivery dates to these deliverables. A deliverable could be a report on progress, or it could be an actual component of the system.
  • Tasks - Tasks are the things that need to be done to produce a deliverable. The deliverable would have one or more high-level tasks associated to it by a project manager (which might be one person, if they're just a freelancer), and all of the tasks usually should be complete before the delivery to the client is made. Tasks should have some loose times/difficulty ratings associated to them so that they can be used for estimates, and each task should have someone who is specifically accountable for its completion, even if they're not responsible for completing it.
  • Issues - Issues are discrete unit of a task. Some tasks are simple enough by themselves. Others have multiple pieces. A developer might like to break down tasks into these smaller units to better handle larger tasks. If someone is accountable for a task, then they might assign multiple issues under that task to different people, delegating the work. Issues may also enter the queue externally, usually submitted by clients, and would be associated automatically to a generic task under the current deliverable, then reassigned by the project manager.

So that's the, um, small feature set for the project manager/developer user. There's also a client actor that needs to have a dashboard to keep track of progress, meetings, deliverables, etc. They should also be able to submit the aforementioned issues there to enter an incoming queue that is later sorted by the project manager or lead developer.

There should also be a place to manage project files. Inevitably, you've got a designer working on the project who's producing photoshop images. These things need to live somewhere central, where the participants can find them. There should be a place to put documents, too. I think this is separate from project notes recorded by the developers.

Projects notes are also important, since at the end of the project, you want to be able to deliver not just the project, but the documentation for the project. There should be a way to document project notes that can be either public to the client or solely for internal use. For example, you might want to note for the client's end deliverable the name and contact info for the host of their live server, but you would not want to include the steps of the import process for their data, which might be useful to other developers working on the project.

Some additional features that qualify in the "might be nice" category include svn integration, so that you can specify a repo or two for the project and associate commits to specific project issues in the system. I know some people that would like to incorporate time-tracking into the system for hourly billing. It might also be nice to include a CRM component so that you could keep contacts separately from the project itself. This wouldn't be interesting to me personally, but it might interest others because it could make the system useful for industries outside of IT/development.

Eventually, it might be nice to track things that are not projects, but ongoing, like maintenance. After you deploy a project, you might want to keep regular tabs on the client and the project to make sure it's up to date. While this is partially a CRM feature, it would also be somewhat project-related, since you'd have specific tasks you'd need to accomplish on every periodic check of the deployed project - like "update server" and "check for HTML compliance", or whatever.

The above is a lot of stuff, but I think a truly integrated package that makes it easy to access all of this information can be simple and effective as a project management tool.