Top-down design looks at the entire project and breaks it into high-level components; those components are then subprojects and can be further handled in the same way.

Bottom-up design looks at the resources available and sees likely things that can be done with them; the idea is to provide generalized components to be used in any project.

A healthy software design ecology has a lot of bottom-up components at varying stages of maturity; those components then inform the top-down requirements of the current project, giving those designs something to work with. In the absense of complex components, we're forced to write everything from scratch, and it all turns into ad-hockery of the worst kind.

Anyway, that item of philosophy out of the way, I wanted to talk about the design of this week's project, the drop tagger. There are three main components of the drop tagger, as follows:

• The drop handler
  The drop handler is the component which interacts with the shell and provides something you can drop files onto or otherwise tag them. It calls the file manager. However, the notion of a general drop handler is a much more interesting one than a special-purpose drop handler just for this project, and one which can be a valuable addition to many different file-oriented projects.
• The file manager
  The file manager shows us what files have been dropped, allows us to add and delete them and modify their tags, and for fresh drops it will actively ask for tags. It also calls the tag cloud formatter and provides a convenient place to display the cloud.
• The cloud formatter
  This is likely to be the least general and thus the least interesting of these components, but it formats the file cloud upon request based on information compiled about the tags in the system.

Each of these components can be designed and used in isolation, and reused in other projects. Alternatively, once we've defined the components we need to meet our goal, we may well be able to find ready-made components already available (or at least something we can adapt instead of starting from scratch). There is then a maturity effect over the course of multiple projects, as our codebase allows us to be faster and faster responding to the need for a project.

I'd like to formalize this design process over the course of several mini-projects. Stay tuned for further progress.