some improvements to menu

Ticket

+commit
 

 

edit:
 
view:
  • √ make refresh first
  • √ add type: Foo (under page) but not under page.  see comment.
advanced:
  • √refs -> references, and make it two items, one for references from and one for references to
  • √kin -> related
  • √ add ancestors - same submenu as view...page, except no self or type
  • √ rules - add submenu with possible sets. (On Cardtype cards, uncertain if top one always self or cards of that type)
    couldn't quickly do this without adding too much processing; I suspect I can find a way.  ticket separately: add rules submenu
account - add a submenu with:
  • √ "edit account" (going to account password, roles etc., what "account" currently goes to) - used "details"
  • √ "cards edited/created" did these separately
 

 

 

This comes from a phone conversation that Ethan and I just had. Two things that we did not get agreement on:

  • view...page - I'd like it to be easier to get to the trunk card (the primary thing I use page for), so I'd put the trunk first. If not first, could reverse the order after the first item (which is to the card itself.
  • add "what links here" or "backlinks" to the view menu - or if not, find another more discoverable way to get to that list (it's three-deep currently).

And two we wanted to track separately:

--John Abbe


I'm now thinking we should get rid of the "page" submenu and put all that functionality under advanced > related. This means that no menu other than advanced goes more than one level deep.

  --Ethan McCutchen.....2013-03-20 20:35:23 +0000


So then the first item for most Readers is either discuss, or edit if they have that permission. That's nice. Conversely, Editors and Wagneers have significantly further to go to get at those functions. I'm maybe mostly okay with that if page is top level under advanced rather than further down under related. Will percolate. Or maybe you could implement it on some test server for us to get a hands-on reality-check?

 

One thing I would miss most is some easy-to-access way to get the URL for the card in question. This is of value even for readers - it's like the permalink on blog entries (that use case - or any use case - could solve the problem via Wagneering, but I think having a default method of accessing the URL which will be the same or similar across most Wagns is of significant value). I'm open to the solution to that being something other than it being in the menu.

  --John Abbe.....2013-03-21 23:09:31 +0000


getting rid of page submenu items. view still exists, as does view > page.

  --Ethan McCutchen.....2013-03-22 03:10:52 +0000


the latest is now up on dev server.

 

There seems to be some recurring confusion about language here. When I refer to a menu, it means a bunch of items, not a single item. (Same goes for "submenu", which just a menu that doesn't happen to be root). And I'm identifying the menu by the item that opens it.

 

So:

1. root menu, gear menu, and card menu basically all mean the same thing

2. the view menu refers to anything opened by "view" (but not to view itself).

3. the thing I talked about removing above is the links underneath page. The page item itself remains.

4. similarly, in another discussion you were confused about removing the refresh menu. that was your idea -- getting rid of links to titled, open, etc.

  --Ethan McCutchen.....2013-03-22 17:34:44 +0000


I like it! And if you don't have edit permission, the gear pretty much is the permalink for included cards. Hover, menu pops, right-click and copy URL.

 

Is there somewhere listing the servers and which Wagns are on each? Does dev=dwagn ?

 

Thanks for the clarification on language. I realize I've never been involved in collective development of a menu before (which as well as being a shorthand for "root menu" can also mean the entire thing including all items and submenus, but hopefully context clarifies which we mean in any given instance :-), so I hadn't even thought about the need for specific nomenclature for the various parts.

  --John Abbe.....2013-03-22 18:30:04 +0000


dev = dwagn, staging = swagn. everything else, the listing is DNS (but most of the ones we work with are on our production server).

 

Yeah, you're right, there's some theoretical ambiguity as to whether a given menu includes its submenus, but for whatever reason, that bit rarely comes up, even in code.

  --Ethan McCutchen.....2013-03-22 18:57:34 +0000


view...type: Foo currently shows the Cardtype card Foo in the context of open view of the relevant card. I'd be inclined to have it instead load Foo as _main. Whaddya think?

  --John Abbe.....2013-03-26 17:59:17 +0000


rationale?

  --Ethan McCutchen.....2013-03-26 18:05:21 +0000


Less noise - in particular, it often slows me down looking for the right menu when there are two gears right near each other. Since we're trying to make Wagneering more friendly/discoverable...

  --John Abbe.....2013-03-26 18:15:01 +0000


So the way this works is that there is a "related" view that we use to show most of the in-place stuff. (references, structure, etc) -- basically anything where the content is already in a card, so there's no need to create new views. I think you're making the case for cleaning that up, but to me the more relevant question here is whether this is more often useful in context or as a context shift. And what are the criteria for these decisions?

 

Eg, for now it kind of looks like we're preferring to stay in context for searches, sets, and forms but context shifts for most other cards.

 

I made this change and a couple of others (including always showing the arrow when there is a new page load). Will deploy soon. btw, test and en should be more reliable now; ported to new server.

 

  --Ethan McCutchen.....2013-03-26 18:37:25 +0000


cool re new server. everything else makes sense, thx, though i can't say i've exhaustively thought out all of the cases that aren't searches sets or forms :-).

  --John Abbe.....2013-03-27 06:12:49 +0000