Pattern Cards+interface
I've done a little work on a first stab at how it might look to interact with patterns on a per-card basis. The following is an exploration of what might appear on the options tab of a Ticket.
Here are some things to notice:
- Each line represents a plus card. Pattern+Setting = Value.
- When a setting is "closed" (as all but *edit are in this image), you see only the current value (and the relevant pattern) for this card. If there are no settings on any matching patterns, the pattern is blank (as in *new)
- When a setting is open, you see all applicable patterns. I was trying to make it visually obvious which pattern was current -- the white one! You also see a description of what that setting does. Which, naturally, comes from another card.
- Clicking on a setting will take you to the setting card. Clicking on a pattern will take you to the pattern card. I'm now thinking both should be cardtypes.
- A card's patterns are ranked, with the order being roughly from specific (just this card) to general (all cards). The most specific setting is used. We expect this to be a fixed ranking in the initial release.
- I didn't really work out a good edit interface for changing the value. Presumably this is where we would want to change the values. How should we do this?
- The name of the pattern isn't necessarily what we would display in the pattern card column. For example, the Pattern Card that actually represents "All Tickets" might be named "Ticket+*type cards", but it would be great to have a way to make prettier names for those patterns.
- Don't know if we'll actually do all this, but the idea of the "patterns" subtab was that we'd make that an easy place to add applicable patterns. The "links" subtab was about some sort of cool way to click to see different views and layouts of the same card. Seems like both would be good additions for discoverability.
How might this type of interface be defined:
- Ideally any interface widgets that we get for this interface are available generally for cards
- Therefore, these tabs would be implemented similarly to *related tabs?
- Should we define this as a design element of Wagn 2.0? Something about rendering actions and generalizing how they are handled?