Idea

Should this be an idea card? I'd like some feedback on the basic ideas and suggestions for best approach. Not sure when I might try to do this, but I'd like to be using this in my wagn.

---

So a non-wagneer goes to a page and you want to add some sort of field to it that isn't already there?

 

Actually, that's kind of how Wagn worked at the beginning.

 

I don't see adding it to the core without some well-thought-out user scenarios where people would actually discover and use it. So it seems like a self-standing mod for now.

---

I think perhaps you should consider a new approach. Here's how we normally do stuff like this:

 

Eg, Imagine that we want a page with stories about dogs. We can create our "Dog" card., and then we create Stories with +tag or +about or whatever, and that's a pointer that refers to Dog.

 

You can then easily create a link for this like add Story.

 

See Campaigns on Wikirate.org for a simple example. Or, for that matter, "add a user story" lower down on this ticket page.

 

Basically, the above approach is conflating wagneering (creating new plus patterns) with content addition (naming new cards). At this point we're pretty committed to the "plus card as field" approach.

---

(I think I finally understood what you were going for when I clicked to the page you were working on. Real examples work much better than A, B, foo, bar, etc for communicating ideas!)

---

I know I can get the effect in other ways, but I want something a bit more specific, and I do think it is generalizable. I'm asking you to make sure it is general, and maybe even usable in other ways to expand the scope of the wagneerable.

 

I want the ability to have a bunch of children whose names are generated as they are added. It isn't even necessary (in the general case) that they end up being children. Given a context card, I want to use (optional) user input and the context (plus relevant rules) to generate the cardname. The same code should be able to implement a much more general autoname feature. Done right we can do new name validation as we do with names when the use is typing.

 

Say what you would want in the long run without considering when and how. That's what we want to do with an Idea card, no? Then if part of it looks doable and useful it might get done even if not scheduled.

---

I think the need is to articulate good use cases for this. So far it sounds like a wacky mod to me.

---

I don't think you are really appreciating the ask. It doesn't have to work any particular way, but you have not proposed a better solution to the need. I'm open to finding a real solution with current features, and/or clarifying a better syntax for the solution.

You're just saying "we don't need that" (generally), when, I'm not really seeing your response to the request. I don't want to do a wacky mod, I want to do a change the enables a whole class of possibilities including a particular one. How can I complete a new card name in ways between having no name (any I have to fill it all in) and having a complete name. Autoname is in a sense one such way (no name and no filling in, auto generation instead), but the current feature is pretty limited.

 

A better autoname feature might be enough for me. You have any ideas about that?

---

You haven't articulated a need, you've articulated a solution. If you could figure out how to articulate a need, then we could get somewhere.

 

I'm just having to guess about your need at this point. For that need, see the Dog / Story proposal above. Just add an autoname rule to story cards. done. Then you have AutoStory1, AutoStory2, etc, and the relationship to Dog1 and Dog2 is handled in pointers.

 

If you're wanting RegularName+Autoname1, RegularName+Autoname2, etc, I'm saying that's not a naming pattern we should support unless there's a well-articulated need for it. As of yet there is not.

---

Dog/Story doesn't really answer it. That is a kind of solution that is fitting the solution to the tool (wagn), but I think if we are to be a platform you have to think more in terms of having general capabilities. I want to be able to add arbitrary plus cards to a context card. I don't want to alway be creating cardtypes because there aren't other good ways to do common things. I'm not saying this is a priority, and more than anything, I'm interested in thinking about the best approaches to a general class of things.

 

I'm not tied to any solution as to how to implement it or syntax or rules or whatever.

---

"I want to add arbitratry plus cards to a context card". That's a solution, not a need. (and it's a poor solution, imo, because it bastardizes what name trees are supposed to be).  What's your need?

---

You don't necessarily need to create a new cardtype, in theory. The link could provide an instruction to create Autonamed1+mytag or something.

 

---

You're narrowly defining need. As a developer I want to be able to use the feature of 'a set of children of a card' in various ways. I need a UI that can add to that set of children in a natural way. To say that it is a solution because I don't specify the user story where it comes up.

 

You haven't even said what's wrong with what I'm trying to do. As a designer of the card architecture who occasionally wants to wagneer things for myself, one of my biggest frustrations with Wagn is that it is often hard, or counter-intuitive to find ways of doing common, simple things that are pretty trivial in other platforms. I can see addressing this by documenting wagny solutions and creating tools that hide the tricky bits.

 

I want to be clear that I think what wagn can do is great, and it may even hold a decent solution already. What Wagn doesn't do well is to support alternative UI paths. You can do stuff with modules, but I don't want to encourage a pattern of creating lots of UI mods because I expect many will by wacky as you describe this one. I wan't a way to wagneer stuff like this. To be able to take input and incorporate the input into some action. In this case, the action is just a view or a redirect, so it will not be intrusive or dangerous for wagneers. I would say that comments are an example of an alternative UI path, but the cases I'm talking about are simpler because they are read action (new action as the case in point).

 

I'm asking how you would want to do this kind of thing, and if there might be general design, say by adding a rule card that specifies a template to modify the handling of some input parameters. I'm trying to avoid working on dumb ideas, and likely my current conception of possible solutions has a bunch of these. Maybe there already are view options to do this, or maybe there is a solution with view options that is least intrusive and the best design. I'm just not buying the response of "why would you want to do that?", and even if I did, I'm not sure what part of my solution you think is so dumb.

 

I'm not looking for a specific solution and I'm not tied to any solution-like ideas in the ticket. What I want is a reasonable response to a developer inquiry. Pretend for a second that I'm some unknown (to you) developer playing with wagn to find out if I can really use it for my application.

---

You have any idea to eventually to move some events to the wagneering space? I'm hesitant to put ruby code into cards as would be needed to actually add or modify events, but you could just add code-cards for some events and just control which ones are in/out with rules. We already have moved some code-like stuff (js and css) into editable cards, but the main pattern there is to list read-only cards to include.

 

We could have a very restricted DSL to allow site-admins to add different event flows as needed. I'm thinking that some admins already would like this to modify account handling events.

---

I really don't know what you want, Gerry.

---

Ask somebody else to read this stuff and see if they can translate, maybe?

---

I'm not saying what you're suggesting is useless; I'm saying to prove the use to somebody who's not living in your head, you need to articulate a user story. Presumably this came from a concrete user story for you, then you abstracted the need into and only communicated your abstraction.

 

Maybe I can pick this up again sometime when I'm not super stressed or you've made an effort to articulate a need.

---

Ok, I'll give you a break based on stress. Like I've said, there isn't anything critical here, and really my inquiry is more architectural than being based on a specific feature.

 

As I reflect on this and what the need is, it really harks back more to the original meaning of plus. I think there may have been a tendency to think of the plus operator as commutative, because it often is used for more symmetric relationship, but it never was. The idea was always that any card could be tagged with a simple card, which sets the asymmetry.

 

Now as we conceptualize the namespaced usage of the cardname space, the analogy to a hierarchic store is also brought to the fore. Either way, the pattern of adding a tag to a card is important, but we don't have any way to prompt the user for the name of a new tag to add. We can prompt them for a name or a type, but only for the whole name, there is now feature to initiate a new card page with part of the filename established in the link. I can't even edit the name in the link. Sure, it isn't a big hurdle for me, I know that I can just add a tag or change the tag in the URL box to add a new child, but how do I prompt a regular user to do that?

 

Like I said, take your time and try to answer when you are not stressed. You can critique my solutions or partial solutions, but I'd rather have suggestions about how you might address this problem, or discussions about what solutions are ok or not ok architecturally. Maybe it is a special case module. Calling it wacky is a pejorative which you can get away with with me, but shouldn't be that quick to use. It's not problematic with me, I know I sometimes articulate wacky ideas, maybe often. On the other hand, you know that you've called some of my ideas wacky that you later came to like very much.

 

I've had trouble clarifying the need because I don't think you've been specific enough. I've written several times that I'm not tied to anything that is a solution. I've attempted to ask clarifying questions that might help me describe the need better (as I just did above with "but how do I prompt a regular user do do that?"), but your comments haven't been that helpful in that dimension.

---

I've not been saying this well, but I think you're asking me how to help a regular user do something that I don't think a regular user should do. Creating new fields (children) is wagneering. Regular users shouldn't be asked to wagneer. New fields = new structure. Regular users should create content, not structure. This is why I proposed a solution that involves no new structure, only new content.

 

This is not whimsical. We've worked extremely hard to avoid confusing these roles.

 

I can believe that there are cases where the plus card is not truly structural, and I'm asking you to give a real example. A real example, by the way, does not have "A" or "B" or "foo" or "bar". It explores some real world scenario. Yes, we would want to generalize. At this point I think my generalization credentials are sound ;). But we wouldn't want to generalize what is generally a bad idea.

 

I will say that Wikirate provides one example of using plus cards for non-structural reasons, eg where we have made it that Company+Topic = Analysis. In this case it's fine for a regular user create a new Topic. That makes sense. The plus is not a field here but a combination.

 

Perhaps there is a concrete case that can make sense of what you're asking for: a box to make a new child. The limited examples we've seen so far really shouldn't be children but linked cards, imo.

 

I agree, by the way, that there's a good chance that there's something of value here. I just don't have the energy to do all the digging for it right now. Part of the reason it takes so long for people to see value in your ideas sometimes is that you can be extremely reluctant to offer a concrete example of why it would be useful. Not for nothing, but if you could actually try to make a practice of figuring out how to use examples in your communication, I suspect you'd find it very fruitful. It seems like you feel like you're sacrificing some ultimate purity by giving an example, but hey, it's nice to be understood.

---

In the +example card: In this page, I want to have a link to create new cards that will be shown with: {{+*children||titled}} (Currently one page is found by this search).

 

The use case is that Debbie wrote "What Democracy Means to Me" and we wanted to invite others to tell their story around this question. I renamed her hard to "what democracy means to me+Debbie". It happens to be her user card, and I was going to make +Gerry and we would want to invite others to do the same. I'm just noticing that it would certainly work for the tag to be the users card, and that would be fairly trivial to implement. It might even be wagneerable now. We have the user in contextual names, and so the card +_u (I think) would be +gerry for me and +debbie for Debbie. I can link (or show) my tag on the current card. If it doesn't exists, the missing link would be a perfectly fine way to show it. If there isn't a way to change the 'missing text' I might want that.

 

I actually do have another use case. I have a Book type, and I would like the chapters to be named with the book's name, globally. It is ok as it is, I just make a pointer card, BookName+chapters and type the chapter names into the pointer list. Then I can create them as I go. In this case, what I want is an implied 'BookName+' pre-pended to the pointer items. I guess it is just the + needed, so the editor can just type it (if/when we do the +->/ and namespace thing, the '/' would only be needed to make it a global name (or // for namespaced global if I recall). So maybe I don't have a case.

 

I get the point that you don't plus for random structure. I have to make that sink in better somehow.

---

these are great, Gerry. can't dig in now but will when I get back.

---

Closing this one, tagged it with a new ticket I will create now that will be more general.