(Moved all of the early conversation designing input for tagging, etc. to implement textbox for Pointer input. --John)

---

we've implemented select & radio. started on multiselect but there's some trickiness to clear up there. still need to verify that things work in multi-edit

  --Lewis Hoffman.....Sat Aug 29 12:33:57 -0700 2009

---

Kewl!

  --John Abbe.....Sat Aug 29 12:41:45 -0700 2009

---

Ticket: make+*input work as a Pointer

  --John Abbe.....Tue Sep 08 16:15:34 -0700 2009

---

testing at http://test.dwagn.org/wagn/fun_with_pointers

  --John Abbe.....Tue Sep 08 16:16:39 -0700 2009

---

documenting at Pointer+input options

  --John Abbe.....Tue Sep 08 16:21:52 -0700 2009

---

fixed in multi-edit scenarios, fixed multiselect.

 

full is not yet implemented, I think we want a new ticket for that. (Done: implement full for Pointer input)

also changed to use 'max' instead of 'limit'

  --Lewis Hoffman.....Fri Sep 11 13:20:59 -0700 2009

---

First off, this is supercool to see and play with!

 

So far i tested multi-edit by just editing inclusions on http://test.dwagn.org/wagn/fun_with_pointers and it seemed fine.

 

And now, some bugs/issues (expanded http://test.dwagn.org/wagn/fun_with_pointers a lot to test more):

 

select:

• √1. If you don't select anything, you should get blank content, instead you get "" http://test.dwagn.org/wagn/bar%2Bselectfun
• √2. The "--Select--" item in the menu seems odd after you've selected something. If we want people to be able to reset the content to be empty, maybe the first item in the menu should be blank? (Once we do *min, presumably we let the menu default to the first item returned by +*options. When inclusions can specify default content, that can determine what the menu defaults to.) See replace Pointer menu --Select-- with a blank choice

radio and checkbox:

• √3. On long lists, multiple columns would help out a lot. Ticketed: multiple columns for radios and checkboxes  changed to Idea -efm

multiselect (not urgent):

• √4. When you edit an existing pointer, the items are selected but gray. http://test.dwagn.org/card/edit/Lewis_Hoffman+multifun Unless you're in multi-edit, they should be highlighted (i think this means the control needs to be selected in the browser? I think doing this now would be nice. If we don't, i'll add it to Put focus where expected.)  - let's add it there
• √5. It seems like it might be easy for someone to click on an item and 'lose' items that are already selected. I guess if that happens, hopefully they realize they can cancel and edit again. They have to know to command/control-click. I guess this is standard behavior. It might help a bit if the background color were more distinct from the gray item-selected-but-control-isn't color. -probably goes with #4
  The proposed color change (heighten multiselect vs multi-edit-background contrast) doesn't seem to go with #4; is there an implicit to-do that i'm missing in my whining about possible confusion with the standard behavior?.

√6. moved to add ability to limit number of Pointer items

 

7. http://test.dwagn.org/new/committee?_radiofun=Lewis%20Hoffman - the radio button isn't selected. (Perhaps related: If you start with +*input as select, choose an item, save, and then change +*input to radio, then when you edit nothing is selected. http://test.dwagn.org/wagn/bar+radiofun I found this first, knew it was a bizarre edge case, but that it might stem from something that would have other undesireable behavior. Same thing in reverse, if you start with radio, pick something, then switch to select, it comes up with "--Select--" in the menu.)

 

√8. http://test.dwagn.org/new/committee?_checkboxfun=Moo works, but if you try to save it you get an application error.

 

√9. radio and select are implicitly +*max=1, so if there is one item in the card, it would make sense for the edit link to say "edit" rather than "add/edit". Idea'd: change link on max=1 Pointers to just "edit"

---

√10. On checkboxes, the card names are links, pretty sure we want them to be plain text.

  --John Abbe.....Sat Sep 12 02:38:03 -0700 2009

---

I know it's mostly developed now, but what's the added value of multiselect (given that we have checkbox)?

  --John Abbe.....Sun Sep 13 07:42:06 -0700 2009

multiselect is useful when there is large number of choices, takes up lots less screen space than checkboxes.

  --James Thompson.....Mon Sep 14 17:05:38 -0700 2009

---

deployed fixes to #1, first part of #7, #8, #10

  --Lewis Hoffman.....Mon Sep 14 20:59:24 -0700 2009

---

re #9. this requires getting a bunch of information that we don't already have on a view screen so needs to be done with performance implications in mind. my inclination is to punt on this one.

 

status: I think this is close to ready. (we'll of course want to improve limit (other ticket) before release.)

  --Lewis Hoffman.....Tue Sep 15 07:44:44 -0700 2009

---

11. did you do the cleanup of *option text that we discussed? As in: (1) first looks for tag+*option text, then just *option text, (2) works if user doesn't have permission to read option text card (System.setting), and (3) works with radio buttons?

  --Ethan McCutchen.....Thu Sep 17 08:14:37 -0700 2009

---

As far as i can tell, #8 and #10 are all fixed now. So everything is fixed or ticketed/idea'd, except for #7 and #11 (Ethan - i commented on #5).

 

Regarding #11, i get wanting it to work with radio, and shifting from "+description" (which works currently) to a star card; how about "+*option label" rather than "+*option text"? (Even if images don't work now, we'll probably want to do that eventually.)

 

Also, what is meant by "then just *option text", and why would you want to ignore permissions?

 

FYI, right now if you put something in tag+*option text you get strange results (the label for every item is Committee+*tform). See http://test.dwagn.org/wagn/Moon+*option_text and http://test.dwagn.org/card/edit/Lewis_Hoffman+checkboxfun

  --John Abbe.....Thu Sep 24 00:11:33 -0700 2009

---

And actually, it looks like we can already create *input+*options and set *input+*rform to Pointer and it will work. See:

http://test.dwagn.org/wagn/you+add

http://test.dwagn.org/wagn/add+*input (make sure to edit this)

http://test.dwagn.org/wagn/*input+*options

 

Unless someone tells me otherwise, i will update English to do this.

  --John Abbe.....Thu Sep 24 02:40:31 -0700 2009

---

I coded #11 last night. Pushed to staging branch on pinz but not yet deployed anywhere.

 

Here's how it now determines what plus card to use: 1) content of "tag+*option label" card. if there's not one, 2) value of "*option label" card. if there's not one, then 3) "description".

 

so if I'm looking at checkbox or radio pointer "Fix pipes+assigned to" and one of the options is Lew, then to get the label first I have to figure out: Ethan+what? if there's a Phrase card "assigned to+*option label" that has "about" as its content, then I should look for the label at Ethan+about.

 

re #4 and #5, they're pretty narrow appearance fixes for multiselect (which is not yet used anywhere) so I thought they could go in one ticket. also, if the focus issue is fixed, the background issue is much less significant.

 

re permissions, this is not about the permission of the label itself, but of the setting card that determines what plus cards should be used as the label.  That piece should work even if the user doesn't have permission to read the setting.

 

re setting *input+*rform to Pointer, yep Lew added code to make that work. cool with putting in on english.

  --Ethan McCutchen.....Thu Sep 24 08:37:37 -0700 2009

---

Cool!

 

Got it re "+*option label" - i was missing the extra layer of redirection. Now "+*option label" is a geeky pun, yugh ;-). Updated the documentation, and added "*option label" stuff to English.

 

re #4/5, the background issue is less significant when someone is single-editing Pointers via multiselect, but Pointers are often used in multi-edit. I assumed the focus issue chunked well with the existing ticket which is why i put it there, while the CSS fix is totally different work. Figure?

  --John Abbe.....Thu Sep 24 13:37:11 -0700 2009

---

I started to implement menus (select) for +*input on English, and realized this could mean reserving a bunch of card names (select, radio, checkbox, multiselect, list), which definitely doesn't feel right. Make it *select, *radio etc.? Kinda fugly, but this issue will probably arise again, and this may be the right solution. Any other clever ideas?

 

http://test.dwagn.org/wagn/*input+*options (for my own use later)

  --John Abbe.....Thu Sep 24 13:38:34 -0700 2009

---

re permissions, seems like an edge case. guessing there may be other cards that will wreak havoc if permissions are set wrong; a more robust solution might be a way to lock card permissions on such cards?

  --John Abbe.....Thu Sep 24 13:40:58 -0700 2009

---

it doesn't really exactly mean reserving card names -- those cards don't do anything. they can be any type, any content. doesn't really matter.

 

I don't want to do any more coding on this before 1.2 unless something is pretty badly broken, so the * idea is probably a no go for now. (plus, that feels very wrong to me)

 

Guessing this is going to be a common problem that needs a deeper solution. some other time :)

  --Ethan McCutchen.....Thu Sep 24 13:42:48 -0700 2009

---

Don't want to push too hard, but could lead to headaches. E.g. if someone renames the "list" card it will disappear from the menu of options.

  --John Abbe.....Thu Sep 24 14:34:42 -0700 2009

---

Phrase card?

  --Ethan McCutchen.....Thu Sep 24 14:41:12 -0700 2009

---

Not getting what you're suggesting.

 

√12. Just discovered that the select menu only shows 50 items if there is no +*options, or its WQL is "{}". Looks like it's coming from WQL returning 50 cards at a time by default (the menu had 100 items with WQL of {"limit": "100"}). Ticket: default to showing all *options in *input menu

  --John Abbe.....Thu Sep 24 17:12:57 -0700 2009

---

nope. that will be disastrous. we can choose another limit, but we can't do unlimited.

 

By phrase card, I mean let's drop the idea of making *input+*rform a pointer for now.

  --Ethan McCutchen.....Wed Sep 30 14:44:34 -0700 2009

---

Lew says he thinks this has gotten deployed, so I'm changing this to "testing" (particularly for #11)

  --Ethan McCutchen.....Wed Sep 30 14:58:30 -0700 2009

---

documented on Pointer card

  --Ethan McCutchen.....Mon Oct 19 11:21:58 -0700 2009