I may have answered this myself.

---

Hmm. I do think menus should be a bit more wagneerable, but I'm not sure we've got a great solution yet.

 

Really, the main place the menu is organized right now is in this javascript file: https://github.com/wagn/wagn/blob/master/card/mod/03_machines/lib/javascript/wagn_menu.js

 

If a mod developer wanted to re-arrange a menu while preserving its basic functionality , then it would make sense to reorganize that file.

 

If he/she wanted a whole different look, the way to go would be to redo the :menu view.

 

I can imagine fairly quickly making it so that there are alternate menus that can be selected with a menu directive in the nest syntax.

 

But making the menus more deeply wagneerable will require a good bit more design. My suspicion is that this kind of change would mostly be about reorganizing a predetermined list rather than creating any new logic. new logic = mod development.

---

But, I can create a real card with the same contents as the 'script: card menu' card, and then replace it in the *script rule? Or don't we allow JS stored in cards yet?  I'll have to play with it on gerry.wagn.org.

---

Oh, if you want to go hard core, yeah, you can do that. You kind of have full control over HTML, Javascript, and CSS now (though of course, the less Wagny you get, the harder it is).

 

I guess I've been thinking of CSS editing as advanced wagneering and JS editing as moving into development. But that's all just semantics; yes you can control the js by editing cards!

---

Yes, we've finally given wagneers the power to hang themselves good. I know you have some rescue methods, but we'll likely need more.

 

I think you're right this is edging towards development, but I suspect we'll develop a few formulaic ways of extending things like menus. They may sometimes need additional data in the menu hash, which may again require actual module work for more complex additions. I'd hope to pretty much stick to the wagny pattern so the standard JS can pretty much still work with customized json stuff.

---

Ok, I think this is probably the wrong place for this. The design area that I would like to explore before getting too deep into actual solutions is about how we want to handle a more general ability to put widgets, including menu-ish widgets, into cards. I suspect the right area to look at for the core design elements is views and the related concept (only in code for devs) of modes. In the beginning, there were open and closed view/modes and there has always been edit.

 

I think there are two core ideas here, and there should be an idea card for each of them. Rather than go ahead and create, I thought I'd ask if the appropriate cards are there and we would jump this discussion to those places. One issue (for me at least) is moving towards modeless UX where there is no hard distinction of edit mode. Just click on the element you want to edit and change it. Visual indicators for dirty, validation errors, etc. Click the checkmark to make permanent, x to cancel, and so on. The other I would call extending the view/interaction modes.

 

The use cases I'm interested are related to very common UX elements for site navigation and more. It would be natural, and I think some recent features do some of this, to use pointers and searches for say a list of categories for site navigation. If I want each target card to represent both a page to navigate too, and a pop-up widget with more links and text/images, I think that difference is a view. I.e. one for the widgets as in the nav bar (use 'memu' or 'widget' or ? for the item view).

 

I suspect you have already been thinking of such things.