refactor card menus

Ticket

+commit
 

We need a more compact way to get to all of wagn's functionality.

 

The core idea is that there will be a single, unobtrusive "doorway" to the worlds of editing and wagneering that can optionally appear in any "wrapped" view (that is, any slot that's prepped for javascript actions).

 

The doorway will be customizable; the default will look something like this icon from connectipedia.org:

connectipedia edit icon

Mousing over that icon will open up a menu that looks something like: 

refactor card menus+mockup

Clarifications:

  • all of this will be done in packs; can be rewritten / modified
  • you will originally see only the five items on the upper right (edit, view...)
  • every item -- even those that have sub-items -- will be clickable
  • "manage" takes you to the set / rules stuff (currently under options).  this will likely be a javascript popup so that you can see changes take effect as you make them.  you will only see this if you have permission to view the set.
  • "talk" is analagous to MediaWiki's talk pages.  it will be a "+*talk" card, probably similar interface to "manage".  you will only see the link if you have permission to view the discussion.
  • "follow" is what is currently "watch".  Will change to "unfollow" on mouseover
  • "view", "refresh", and "*(viewname)" will all do the same thing -> refresh the home view
  • "related names" includes parts and plus cards.
  • link builder is new functionality.  basically lets you select various options that can be set in GET requests (layout, view, format, etc)  more on that soon...
  • the arrows on the "related names" dropdown indicate that those items take you to a new page.

 

 

The image is only viewable by administrators, is that on purpose?

 

I this related to make simple edit-alternative to double click?

 

--John

 


Is titled view "wrapped"?

  --John Abbe.....Sat Jun 09 00:27:26 +0000 2012


re admin: sorta on purpose. we were using this in the demo and found a bug there (fixed but not deployed). I took that rule away.

re simple alternative: yes, related. sort of a reframe, because it's not so much a one-or-the-other thing. you can actually turn double click off now, but that's in a trial phase. not documented.

re wrapped: Yes. all the views in the upper left are wrapped.

  --Ethan McCutchen.....Sat Jun 09 03:15:59 +0000 2012


Presumable this will all need to be themable and packable, so we need to do some API design in all of this. The look and UI needs to be nice for base Wagn, but it also needs to be built in such a way that a pack-builder could take and extend the settings and rules in the core Wagn, and build packs to replace any part of it.

 

I'm thinking we need to first spec the Views API more completely. I'm sure there are other cards that already cover parts of this.

 

The the question for this ticket is about what view names will be used for all the parts of a card that will implement the card menus. This is the view API for card menus. Maybe just one view name :menu, and each pack could define component views but it wouldn't need to.

  --Gerry Gleason.....2012-10-12 14:31:05 +0000


I would list this as pretty urgent, so I wouldn't want to hold off on a final api to get something working, but otherwise I agree. My thought is that we will want one view (something like :menu) that handles all of this, but it will use a set manipulable menu object. I don't know how all that works yet...

  --Ethan McCutchen.....2012-10-12 15:59:54 +0000


In any case, I do hear your key concern that this needs to be configurable. Definitely agree!

  --Ethan McCutchen.....2012-10-12 18:30:20 +0000


Yes, I also hear you about wanting to implement a basic working something first. Spec it in tests, make a prototype work, ...

 

We should also think about using wagn data structures and core types in creative ways for this. The setting (rule card) for codename :menu might give a pointer card that might represent the component views. Or maybe this is a new core types to represent not an array of cards, but an array of codes. Oh wait those are still cards (a pointer card type array), just the options sets are special enumerations of codenamed cards.

 

As you said, we spec and write something first, then talk API.

  --Gerry Gleason.....2012-10-21 13:57:37 +0000


we are still refining the menu and still need to handle the "related" stuff, but this is basically implemented (mostly as designed)

  --Ethan McCutchen.....2012-12-20 22:10:10 +0000