build link and inclusion editors+ticket line view
Link editor is straightforward and will look like a typical (eg gmail) link popup window. We only have two fields: link and text. TinyMCE already has one that we may be able to alter to produce Wagn markup.
Inclusion editor is a bit more involved, of course. It will obviously need to have fields for card and view. Some other thoughts:
- first field may be a relative (contextual? plus? child?) checkbox that will default on and will generate the plus
- do want size on images. would be awesome if it were smart enough to know that view actually showed card content (so that this was relevant)
- will certainly want show/hide eventually but probably not in first iteration. may only appear after view is chosen?
- will want something like an "items" button that will add the next level indented (view, size...)
links and inclusions are not discoverable. a GUI editor -- particular as an extension to tinyMCE (our current wysiwyg tool) would go a long way.
There may be some parallel opportunities, design issues, etc. with add menu item(s) to build link.
--John Abbe.....2013-03-22 09:01:57 +0000
We were considering shifting away from TinyMCE before doing this, but have decided to stick with it for now.
--John Abbe.....2013-03-22 22:58:12 +0000
Drag and drop a card into an edit box to add a link to it, hold down shift to make it an inclusion? (from the original Idea for this)
--John Abbe.....2013-03-27 08:31:34 +0000
hmm, drag and drop seems totally separate. the priority here is form building; that wouldn't help. Sorry if I renamed that. It's neat but sounds like candy that would never be used.
If we could come up with a case for it, then behavior would probably be to open the editor.
--Ethan McCutchen.....2013-03-27 15:14:15 +0000
btw, I think I want to push skins ahead of this. One key reason is that I think we need to add n-depth inclusion syntax first. the editor is basically going to produce the markup, so doing it before the syntax change is going to mean doing a lot twice.
Also, I've looked and can't find an old mock-ups. But I think I remember the key bits...
--Ethan McCutchen.....2013-03-27 15:19:37 +0000
so, this 1.12, skins 1.13?
imho drag & drop would be a major plus for form building - not so much for this (where I'll accept "candy" :-) but for build layout tool for Wagn (where i see it's already mentioned...). I expected it would be out of scope for this go round, but wanted to at least mention it.
--John Abbe.....2013-03-27 16:18:42 +0000
Unclear what this was in reference to: "If we could come up with a case for it, then behavior would probably be to open the editor."
--John Abbe.....2013-03-27 16:24:30 +0000
I'm saying this now needs to be behind skins. skins 1.12, this 1.13 (what you described is current situation).
agree re drag and drop within structure (not candy).
Re immediately above question, I was saying that if eventually came up with a use case for dragging cards into a card editor (eg tinyMCE) to create an inclusion, my expectation would be that the "drop" would trigger the inclusion editor to open with the card name pre-populated. Fun, but candy imo because I rarely have the experience that I'm building a form and the cards I want to include are somewhere on the page. Perhaps at some point we'll make a "palette" or something to change that, but that ain't close :)
--Ethan McCutchen.....2013-03-27 16:34:43 +0000
Ethan mentioned somewhere that this would probably build inclusions with views explicitly named in the markup. Just wanted to pipe up one reason this is not so great - one of the design principles that I think made wiki great was as little markup as possible, ideally none (hence WikiNames to make links). In this sense, unneeded explicit view-naming adds a bit more noise and makes the editor->Wagneer jump a bit more difficult. May seem minor, but these things add up.
Good inquiry. There's value in both routes (WikiNames are a great example of how things can get ugly when you take syntax aversion too far), but I'm inclined to say I was wrong about this one. Let's plan to do as you suggest and have the inclusion editor have a "default" view option that does not explicitly show a view.
Perhaps there's a better solution to the issue that prompted this. Currently Wagn uses different default views in different situations: and I'm now thinking that is a bad idea. (Specifically it uses core in most layout situations to avoid extra wrapping, open for main, content for other, and closed for items.) As I think we've tracked elsewhere, we've been wanting to move to "link" as the default item view and "titled" as the default in every other situation. To make this work, we will probably want to migrate a lot of old layouts to explicitly use "core", but that would be a valuable form of explicitness (showing exceptions) rather than the more heavy handed approach I mentioned.
Sounds great.