BlueBrinting Fridge Magnet Kit

Software developers and system architects love to draw boxes for servers, environments, classes, or to explain the system/software development life cycle. For Tridion functionality, the BluePrint design is a crucial step and prerequisite to implementation.

Feel free to use or improve on the following in your next Tridion BluePrinting session, workshop, or discussion.

Update (8-Dec-2011): I loaded a picture of the first prototype. Pros: visual and movable pieces. Cons: magnets are too strong to easily move the parts, labels are paper (not re-usable), and the background is too small for larger arrangements. Next version should have smaller magnets or a bigger board along with re-usable, more sturdy labels (or magnets you can write on).


College student version:
  • 3x5 cards and pencil
  • Markers or colored string (optional)
Small-medium Business/Consultant version:
  • Business Card Non-Glossy Kit
  • Business Card Fridge Magnet Backing
  • Portable Magnetic Dry Erase Board (optional)
  • Markers, if using color consider different sizes or line styles for participants with colorblindness


Step zero:
Draw in permanent marker or carve into your board/desk the following:
00 Empty Parent. Optionally make a note about "scalability." This will be at the very top of your Tridion BluePrint diagram.
1) Label cards with publication names if known or leave blank for the workshop.

2) Add magnetic backings! Velcro, Post-it's, or gravity can be used in lieu of magnets. If you favor magnetic-based hard drives, consider one of these safer alternatives!

3) Create at least 3 types of publication "cards," using colors or icons as desired:
  • Schema
  • Content
  • Design
(see note on empty parent above)

4) Optionally draw out levels on your board or paper with lines or tape. Publication cards will fit into levels for better visualization and organization of the heirarchy.


You're now ready for your BluePrint workshop or brainstorming session! If your boss, consultant or Tridion Professional Services (PS) asks, take full credit for the idea (especially if you get quizzical looks).

You have your basic pieces, just use string or markers to connect parent and child publications!

Some general guidelines...
  • Separate design from content from functionality with perhaps content publications on the left, functionality-related publications (schemas, categories/keywords) toward the top, and design-related publications toward the left. 
  • The empty parent is a must, unless you enjoy starting things from scratch at the next major change.
  • Your actual site publications that publish to your specific URLs will be lower in the BluePrint.
  • Consider the distinctions and relationship between authorization, folders, and publication. For example, a large library of content could go in a single publication or in a folder, based on business need. I recommend considering folders first for flexibility and simplicity.
  • Additionally folders could represent either 1) sites and intended use (ok) or 2) logical groupings relevant to content editors (better).


When in doubt, keep in mind the impact of future changes: Published status (publish or unpublished) is trivially managed by end users. Content and Folders (name and location) are also easily handled. Keywords and their Categories could be harder to change, while Template Items, Schemas, and Publications have more serious consequences for later updates.

This all depends on how the items are used and related to each other and the specific implementation. Schema names may matter more for "dynamic component presentations" (think databased published content) for example.

Enjoy your fridge magnets. For extra credit be creative for the Enterprise Package (high-gloss, pre-printed magnets), Developer Version (touch screen mobile app or Visio plugin), or a Lego Blocks alternative.

The take-away point is the tool isn't as important as the process of creating a solution that meets real business needs. As long as it's easy-to-use and communicates the design to all (business and tehnical) groups involved, anything from twigs and leaves to UML would work just as well.

No comments:

Post a Comment

Feel free to share your thoughts below.

Some HTML allowed including links such as: <a href="link">link text</a>.