sharks

get started

concepts

features

syntax

 

monkeys

intro

mods

REST API

 

platypuses

github

blueprints

tickets

 

everyone

support

ideas

contact

license

 

 
 

disentangle admin cards from coded cards

help edit space_dashboard

Idea

 

+issues

help edit space_dashboard

Currently, star cards conflate two purposes:

  1. Letting coders know which cards are referenced in code.
  2. Keeping administrative/Wagneering cards from muddying up the main namespace. (a third, perhaps conflation-ok purpose is to let Wagn administrators and users know when they might be editing a card that could break things. Even in cases where it's okay if they edit the content of the card, it could mess WQL up if they rename it.)

Note that Wagn's design principles can lead things that were in code to no longer be - e.g., *sidebar. And any definition of what cards count as content vs. administrative/Wagneering is going to be subjective (it's part of what Wagn's about to fuzz that line!), but i think we can help people with this a lot by making some good choices about this in the default card set.

 

Design-wise, any solution should make it easy to move cards among these categories with as little pain as possible.

 

+solution

help edit space_dashboard

Ethan and i talked about this some; here's my sense of what we came up with, fleshed out a bit:

 

"*in code+*right+*default" is a Toggle, restricted to editing by Administrator. (We maintain the +*in code settings on English.) On cards where +*in code = yes, a small graphical indicator shows up  in the card header of cards in code. (perhaps only visible to people with a given Role?)

 

Stars are used only for administrative/Wagneering cards.

 

 

 

 

These lists may not be complete; please help fill them out. Not listed are star cards that are in code. Are there any of them that it would make sense to remove the star from

 

Current star cards that are not in code:

  • *sidebar - keep as star card
  • Related subtabs: *incoming, *outgoing, *plusses, *community - keep as star cards
  • See the discussion below about the cards used in those tabs:
    • *linkers, *links, *includers, *inclusions, *plus cards, *plus parts
    • *tagged (tags is not a star card)
    • *editors, *edited by
    • *roles, *members
    • *watching (*watchers is in code)
  • ?


Admin cards that are not star cards:

  • Default Layout -> star card
  • email config -> star card
  • by name, by create, by update - non-star; see discussion
  • Administrator links - keep as non-star card
  • ?

 

Cards we'd like to add that raise the questions, star or no star?:

  • radio, checkbox, select, multiselect, list (to switch to a menu for +*input) -> star cards; see discussion below
  • ?

 

 

 

help edit space_dashboard

Cards close to the fuzzy line re admin/non-admin are "by name", etc. and

*linkers, *plus cards, *tagged, etc.

 

I see these as one path for end users getting under the hood into Wagn. Also, i've realized that even seeing a "+" in a card name is going to clue them in that there's something a bit geeky going on here. So, i'm inclined to have names that pretty much make sense in plus card names as English not be star cards. Note that in the future i expect this to develop very far, in really interesting directions, like "Wiki+linkers+just Events+in Eugene+on Wednesdays+by name"

 

"by name" and the other bys fit, perhaps with a little renaming so that they make sense as natural language:

  • by create -> by date added
  • by update -> by date edited

Relatedness cards are harder. Some are clearly more content-ish; i'd be inclined drop the star from:

  • *tagged (certainly; to be consistent with tags not having a star)
  • *editors, *cards edited
  • *watching, *watchers
  • *roles

However, "editor" is a term that some Wagns definitely want to use. This might come up for watching or watchers as well; and we already have a Role card, although in this case there's no functionalty collision, and they are actually referring to the same thing. Ideas?

 

These are the generic card relationships, which i could go either way on:

  • *plus cards -> ??
  • *plus parts
  • *linkers, *links
  • *includers, *inclusions

--John Abbe

 

There's a pattern where when some star card names show up in the interface we want to drop the star. E.g., the *community Related subtab, and *list, *radio, etc. if we want those as *input+*right+*options. The former is handled by code so it can customly remove the star, but the latter is pure Wagneering, so, hrm. Ideas?

--John Abbe

 

 

+relevant user stories

help edit space_dashboard