Topic on Talk:Flow Portal/Archive2

I posted a comment regarding this already here but I'm afraid it was overlooked. However I think this could be a very important design decision, so I think it deserves it's own thread.

I was asking if there will be only one unstructured edit section per talk page or if there will be multiple (e.g. per thread). Actually I think it would be useful to have

1. one large unstructured edit section on the top of the page for design purposes (e.g. to put inproject page headers or to customize user talk pages)
2. one unstructured section per thread into which thread specific examples go that require Wikitext and templates to be working.

I'd even go further and not have a completely unstructured design of 2), but allow some sort form of dividing the edit section into distinct "test cases" that can easily be reference from within the discussion and a common section. For example:

• The common section can contain an example of what is discussed in the section, e.g. an existing template, some images, whatever.
• User 1 creates "test case 1" in the unstructured section (that gets a nice border around it, and a label, e.g. "Figure 1" beneath it)
• User 1 writes something like "see [[fig:1]]" (I'm still thinking in Wikitext here, it should be easy to implement something similar in the VisualEditor) in a comment, which get's rendered as a section link with the testcases name as link text.
• User 2 can create a second testcase, independently of what user 1 created, which will get a nice box and label in the not-so -unstructured section, too, which he can easily link to and explain to user 1 why his design might be better.
• Those sections should still be editable by everyone, but I'm quite sure It will be necessary to reference different examples and distinguish between them when there is no possibility to put Wikitext directly into comments.

I only read this after making my comment above. This is a good way of presenting feedback, and I like the idea.

Maybe it would be simple enough to just use subpages of the talk page (on which Flow is not enabled), which could then be linked to from the main talk page.

It would be a good thing for each thread to have a "community area" , which structured discussions is anchored to.

Your #1 is already planned; see all the stuff about "metadata" in the use cases.

Approximately three ideas have been seriously considered for #2:

1. One anyone-can-edit-just-like-an-article kind of unstructured space per thread.
2. One per comment.
3. A separate 'scratchpad' area, which might not be truly part of the thread (but could be associated with it).

I don't believe that a decision has been made, but since these are the ideas that keep coming up, I assume that it will end up looking like these ideas, or like some combination of these ideas.

I only gave #1 for the sake of completeness, I already knew it was planned.

It was #2 that I actually wanted to point out.

1. Sounds like a good idea in terms of clarity (Wikitext samples neatly arranged at one place in the thread). It would definitely need some sort of sophisticated referencing system, though as I proposed in my initial post (which could easily get too complex in the end, I'm afraid). Otherwise it probably gets impossible to keep track of which Wikitext sample was posted by which editor.
   Completely separating comments and Wikitext samples isn't a good idea for sure.
2. Could quickly get crowded when many Wikitext samples are posted and would therefore need some very well thought-out integration into the thread structure. However this is what gets closest to the current discussion system and might fit our needs best. At the very end I'd prefer Wikitext directly in comments anyway (as many other authors do) but from the statements by Brandon and others I'm afraid that will not happen, so this is possibly our best opportunity.
3. Sounds like a very bad idea. Wikitext samples are needed directly alongside the comments. Further scattering contents of a talk page should be avoided at all cost.

What about offering both, #1 and #2? There would be nice usage scenarios for both of them!

I support #2. It looks like the most flexible in terms of reusing existing Wikipedia content in order to discuss it, given the constraints of the architecture that was already decided by Brandon.

The most flexible is probably the scratchpad system, which could be a plain old page rather than anything "inside" Flow.

Sorry, but how is having to visit another page every time I want to look at a Wikitext sample flexible? I hope this is not the way it will be implemented.

Just to make sure: I'm not against scratch-pads. They might have their uses (although I'm not sure if a simple subpage did not do the job as good as dedicated "scratch-pad"). But a discussion needs Wikitext examples directly (or at least nearly directly) in the comment that is referring to them! And on the same page for sure...

The best solution would be "one scratchpad per comment", shown right above or below it. That model would be the one that best suits our needs, and definitely the most flexible (it subsumes everything that can be done with #3 above, since a separate scratchpad can be created as a separate thread with only one comment).

Of course, if you create one scratchpad per comment, there's no real need to have one comment at all; everything could be done by placing each comment directly at one the nested scratchpads. For some reason, I don't think this is what they have in mind, although it is exactly what we need.

As long as the list of examples I added at the bottom of the w:Wikipedia_talk:Flow#Supported_Wikitext thread, are supported in either the VisualEditor or the fallback editor, then the whole notion of requiring-scratchpads will be vastly less important. Hopefully a dev (from either VE or Flow) will reply to that listing, after Wikimania.

Who said that you'd have to "visit another page every time I want to look at a Wikitext sample"? It could be displayed on the same page, right there with the comments that it's connected to.

Sorry, maybe we're talking past each other, but in your comment above you mentioned a scratchpad (#3) as a separate thing which "could be associated" (whatever that means, I imagined a link). This would not be a workable solution in my opinion, see my immediate answer on this comment.

As soon as you show the scratchpad directly in the thread this would basically be (#1) from my understanding (e.g. one scratchpad per thread). This would be a possibility, although limited (again see my answer on your original post).

I don't think multiple scratchpads per thread could be shown directly, as this would quickly get very unclear.

Edit: The fact that we're again discussing the exact same things than at the start of the thread is the reason I think the threaded style that is currently intended for Flow (and which will be similar to what Liquid Threads offers us here) is not working well for our discussions. If we had this conversation on a conventional talk page, we'd have all the information in view and I would not have to repeat myself over and over again!

1. You could associate multiple scratchpads with a single conversation. I was thinking about using the tag structure, but there are probably other ways to do it. Imagine not "we are limited to one scratchpad, and it will always be in this fixed position" but "hey, I just added a scratchpad between these two comments".
2. I have to repeat myself over and over in the existing talk-page structure, too, and information isn't always visible on screen. In fact, this conversation, pasted into my sandbox, is three screenfuls of moderately small type for me.

1. So basically we'd reach (#2) of your comment above (up to one scratchpad "per comment"). Do you think "scratchpads" are really helpful then?
   • I mean, how probable will it be that a single sctatchpad is shared between multiple comments (e.g. the tagging feature)? Will this even be possible technically with reasonable effort?
   • How should those scratchpads be stored in a way to be able to ever find them again to even be able to reuse them? They can't be saved as simple subpages as on current talk pages I assume? Therefore the only place those are accessible will probably be the comment they were posted on?
   • Would it not be much more convenient to have an "add Wikitext area to comment" action directly choosable from the file menu that adds something similar to a scratchpad which is automatically associated with the corresponding comment (but not necessarily reusable)?
2. I better do not ask how much space this thread is taking up for you in Liquid threads then (e.g. this page) and how many pages it would use in the current Flow prototype (which wastes even more space then LQT)...
   Plus I don't know your settings of LQT, but it tends to hide comments, making it even harder to follow the discussion. Something Flow might suffer from, too.

Actually, "up to one scratchpad per comment" was not what I said. I see no particular reason why you couldn't have a dozen scratchpads associated with a single comment, if that's what you wanted.

Database storage is not something I'd want to speculate on, but the primary difference between a Flow comment and a scratchpad is the storage difference: one is written directly in HTML5, and the other is written in exactly the same wikitext markup that articles are currently stored in. So even if the wikitext area is "inside" the comment, it seems to me that you would still have the Flow comment and the "wikitext area" stored separately, with exactly the same limitations that you hypothesize about being able to find it later (or even greater ones, because if you can tag it separately, then you ought to be able to view it, and therefore to see the URL just for it).

"Actually, "up to one scratchpad per comment" was not what I said. I see no particular reason why you couldn't have a dozen scratchpads associated with a single comment, if that's what you wanted."

Well, then add it to the list of things I said! I don't think this would be a good idea. In fact i think this would be a hell of a mess! I can't imagine a single reason one would need more than (at most) one scratchpad per comment (many comments might need none at all). It will definitely increase clutter to have separate scratchpads in the first place, instead of typing Wikitext directly into the comment. Having even multiple scratchpads will increase clutter exponentially (and render the whole idea of not having Wikitext inside comments useless).

For the second part: You're exactly right (and that's what I said): It will be hard to find a scratchpad for reuse. Therefore I think this is an unnecessarily complicated "feature" that will only be useful in some very rare edge cases.
Therefore my suggestion: Don't add such a tagging feature. Irrevocably attach scratchpads to the comments they were created for. This will a) simplify the user experience; b) won't seriously limit functionality; c) will almost certainly simplify the implementation in the backend.

I'm wondering a little bit what you try to achieve with such a tagging feature for scratchpads in the first place? First you state that Wikitext won't be available inside Flow comments as a design constraint. Then you try to implement some incredibly complicated tagging for some "mysterious" scratchpads, nobody asked for and even I (whom I'm one of the most enthusiastic advocates of the need for Wikitext inside Flow) would not now a single really useful usage scenario for.
Why don't go the simple way and simply allow one Wikitext area at a fixed place per page, thread, and comment?

I agree with Patrick87. There are potential reasons why one might want more than one wikitext area per comment, but it would only be important if the wikitext was flawed (unclosed tags), so it shouldn't be rendered, anyway. One wikitext area per page (board?), thread, and comment seems the way to go.