create a simple Bullet List plugin so we need less html

[SvenDowideit]

very simple plugin for now.

however, it does need the plugin discovery feature you're working on :)

several related ideas:

• it'd be nice to be able to convert from one type to another
• if the plugin's js contained the description and other data, simple plugins would be entirely self contained
• plugin dependencies and incompatibilites probably need to be considered some time in the future.

[SvenDowideit]

see http://youtu.be/lBUhYCHvCcE

[interstar]

@SvenDowideit I have simple nested bullet-lists in my Wikish plugin : https://github.com/interstar/ThoughtStorms/tree/master/plugins (Also italics, bold, horizontal lines etc.)

I'd really like to get this into the official distro if possible. Or at least into the official catalogue of available plugins.

[SvenDowideit]

your plugin is essentially the opposite of what I'm thinking :)

a really nice thing about fed-wiki, is that paragraphs are a basic building block - so from my perspective, it'd be good to have a new paragraph for each type of information -

a bullet-list is a different type of information from a prose block.

I'm also thinking that headings are a separate element - though I realise that there is going to need to be a way to tie sections together.

There are a number of (twiki/foswiki related) reasons for my idea -

sections, and groups of sections can lend themselves to both structured (data-typed) querying and transclusion, and can push towards giving different views into the wiki - Table of Contents for eg would be a filtering to show only the header typed data, list pargraphs can have much clever-er widgets to allow manipulation and aggregation

In this way, importing from other wiki's means detecting these type transitions though.

out of interest - what wiki engines do you use? (I'm rather too heavily invested in the data-wiki/structured data area)

[WardCunningham]

Do we want to encourage the use of bullet lists? I understand their appeal on the printed page, but maybe we should leave some of those conventions behind.

We've made the paragraph (story item, actually) the unit of mobility, not lines or characters. Admittedly they look a little big compared to a bullet item, but that makes them finger-sized for touch-based editing. And, of course, there is the unicode • for those who like the look.

[interstar]

@SvenDowideit I agree with the SFW model of putting things into separate paragraphs to make it easier to manipulate them. And also with using paragraph types to capture the logical structure. With a couple of provisos : I'm pretty sure we're going to find the existing model of one paragraph, one type becomes a bottle-neck very soon.

1. We are going to want to give multiple types to individual paragraphs. That's true whether we think of paragraph types as conferring logical meaning or styling / visualisation hints. I can think of two ways to do that : either like CSS where you just add a number of classes to the same object. Or through a more formal class-inheritance model where we can define specialist subtypes that inherit or mixin functionality from more general types.

2. The great joy of wiki was how it made marking-up a document so much easier than either raw HTML or using a GUI. While the SFW may need less visual markup (given that it has more tightly constrained layouts) we surely don't want to lose that fluency of expression. And if paragraph types are our way of marking up documents then we need an equivalently flexible and fluent way of applying types to paragraphs.

At the moment, in SFW, selecting a paragraph type is fairly clunky, ie. we do it from a single unstructured list in the factory. And it's impossible to change or modify a type after the paragraph has been created.

I don't have the right solution, but I think the original wiki intuition of using lightweight text markup is still a good one. Ie. an asterisk in the first character of a line can MAKE the paragraph become a bullet-point in a list. We can parse the paragraph at save time and turn the markup into explicit type. Similarly, have == markup create a heading, which is itself a logical type (and available for TOC creation etc.)

For the record, my initial use-case of SFW was that I wanted to port a large number of pages from UseMod and its derivatives. Hence it made sense to adopt the UseMod markup language. I'm happily evolving onwards from that, while wanting to keep that import channel open. (I'm hoping to encourage other UseMod users to make the same jump.)

[SvenDowideit]

well. this is interesting.

@interstar I hope we manage to avoid mixing types. thats an issue we butt up against constantly in foswiki - though I think we currently have a kind of mashup in the link rendering - who knows, maybe we'll find a way out of that too.

Ward is (imo) challenging us to cast of the wiki-fu and find new ways to achieve simplicity.

@WardCunningham I really don't like the idea of mashing rendering into content - so I'm going to try to find a way not to force hardcoded unicode bullets / html or whatever into the source :)

so - what about this slightly different tack:

if I want an ordered list to mean something like bullets, rather than sequential paragraphs of prose, I create a list type paragraph that I can drag several paragraphs into? is nesting paragraphs a good or useful idea?

@interstar we need to separate some of the issues tho:
1 want to be able to change or select paragraph types in a 'nicer' way
2 I'd like a more natrul way to start a new paragraph (i'll expand later.)

[WardCunningham]

Our goal should be to have a positive influence on how people write, not just to admit every style of writing. It might be interesting to compare federated wiki to twitter, another influential system. Analogous elements:

Markup == Abbreviations (contextual, evolving)
Paragraph == Tweet (the mobile entity)
Page == Hash Tag (the named organizing structure, shared)
Site == Account (reference to authority, not shared)

Of course our goal isn't to be twitter, but to recognize that the world is happy to adopt new writing styles when there is utility to be had in doing so.

[SvenDowideit]

In the first Sunday Hangout, Ward added that he thinks of the Site as like a PDF - which gives us a touchstone wrt the sizing of data, topics and focus of a Site.

for example, rather than hosting all of wikipedia on one site, we'd have Waki-Wiki style (sorry, reference to thought experiment dating back to 2005's wikimania) distributed sites that focus on their local topic area / interest.

as an example, a Chemistry department might have a site that contains mostly local research and learning topics, some of which refer to shared articles like wikipedia, and might have forks of some of those topics.

[creatinglake]

As I not a programmer, I hope you all don't mind me chiming in. I am very excited to see this project underway and hope to integrate it into a social networking platform in the future.

So, from my perspective, Wikipedia is an inspiration and should be considered closely when determining what features will exist in Smallest-Federated Wiki. I love the innovations you are bringing to the wiki, in fact I think they have profound implications. That being said, I think having different types of blocks/entities besides paragraphs would only expand possibilities of expression through the wiki. I am not suggesting having too many, but think allowing bullet lists, for example, just makes use more flexible and useful. I see bullet lists in Ward's videos so maybe i am missing something here.

Also, why not integrate a standard editor that allows many types of word document type modifications within each block/entity? Also, about the editor, and this is very important from the layman's perspective, I suggest having a WYSIWYG editor. Mark-up languages are a barrier to entry for many people. It may seem simple to you all, but it is not the language most people write in. Although I think this model has worked for Wikipediai because it is a type of quality censorship, it seems that a federated wiki should be all about people to people sharing of anything with anyone.

I guess what I am suggesting is a federated MediaWiki with an integrated WYSIWYG editor like http://ckeditor.com/.

Now that I am thinking about it, if there was a federated protocol written for MediaWiki, could all existing MediaWiki installations be upgraded and immediately able to operate as a federation? Or is JSON allowing this drag and drop magic and not able to work with MediaWiki code?

I would really appreciate any feedback on these comments/ideas. Thanks you all for your work on this project and am thankful to see that it is being develop. I hope I can help spread the word once it is ready for the masses.

[WardCunningham]

@interstar mentions pulling content from a UseMod wiki. I'm currently feeding my original wiki into the federation through one page of perl that generates json instead of html. It's read only, but it serves the most recent content on the fly and makes it available to sites that might choose to improve it the federated way. Let me know if you'd like to try running this yourself. It's an experiment.

[SvenDowideit]

ancient, so closing.

[WardCunningham]

These are all good suggestions. I'm sorry we have left them hanging here so long.

We do now accept a wiki flavored markdown inspired by github flavored markdown.
http://ward.asia.wiki.org/view/about-markdown-plugin

We don't do deep bullets or headings. But we do accept task lists which depend on having a mutable memory behind the markdown. (Github does in some cases but not all.)

Thank you all, and especially @SvenDowideit who offered much good advice early in this project, some of which took me years to appreciate.