Tutorials

Start with the tutorials on concept design, including the tutorial on concept modularity.

Advice

  • Don’t give concepts cute names that obscure the fact that they are familiar, existing concepts. For example, if you have a ChatRooms concept in your app, don’t call it Chatterbox: this might be a great name to use in the user interface, but that doesn’t mean you should use that name in the design. Thinking about the underlying behavior of the app, you want to make it clear that you’re adopting a standard concept.

  • Don’t reference one concept inside the description of another! Remember that there are no intrinsic dependencies between concepts. Concepts often have polymorphic type parameters: for example, we might have Posting [Author] for the concept of posts with authors. The name “Author” is a placeholder for an actual type we will choose when the concept is instantiated in an app; perhaps a User type that comes from our Authenticating concept. But Posting will not refer to the Authenticating concept and will not refer to type User.

    (When it comes time to implement your app in Node/Express/MongoDB, these generic parameters unfortunately don’t appear in the code. We will use Mongo ObjectIDs when one object points to another object.)

  • Don’t describe the value of the concept, in its purpose or operational principle (OP), in app-specific terms, and make sure that the OP doesn’t mention anything about the UI or how the app as a whole is designed.

    For example, if you were defining the ContentReporting concept in Facebook, you shouldn’t write a purpose that says “helps users of Facebook report status updates that include offensive content” because this mentions the app (Facebook) and another concept (StatusUpdates). A better purpose would say something like “manage offensive content by crowd-sourced reporting,” which is more precise, application independent, and more generic (since it can be applied to any kind of content, not just status updates).

  • Don’t hide the purpose in the OP or vice versa, for example with a principle that starts “Because the user wants to have offensive content taken down, they report an item…”

  • DRY: don’t repeat yourself. Avoid, for example, using a concept’s own name inside its definition, although of course you will often mention similarly-named data managed by the concept (the Labeling concept has Labels, ShoppingCarts has Carts, and so on).

Our goal is to achieve separation of concerns:

  • separating individual concepts
  • separating concept functionality from the user interface
  • separating concept behavior from the motivation for including the concept