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.

 

Pattern_cards+interface+image-large-66514

 

Here are some things to notice:

  1. Each line represents a plus card.  Pattern+Setting = Value.
  2. 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)
  3. 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.
  4. 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.
  5. 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. 
  6. 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?
  7. 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.
  8. 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:
  1. Ideally any interface widgets that we get for this interface are available generally for cards
  2. Therefore, these tabs would be implemented similarly to *related tabs?
  3. Should we define this as a design element of Wagn 2.0?  Something about rendering actions and generalizing how they are handled?

try it

 

wagneers

intro

videos

features

syntax

weekly calls

ideas

 

twitter

mailing list

 

developers

roadmap

next release

tickets

pack API

REST API

one-pager

 

github

mailing list

 

wagn.org

recent

todo