hangout 140521

Regular Paul and Ward are there.

Next to me is also Mike Caulfield. Christian and Tom joined later.

MC thinks and works about education.

As they have accessibility requirements to meet, the JAWS screen reader has to be able to read the text.

And there's another image program for accesibility issues that only runs on Internet Explorer


The general idea is to provide Applications that take Data from Wiki and show it differently.

Ward has this dream of a Continuous Scrolling overview of federated wiki communities, their recent pages, synapsis, pictures on pages. That could resemble the Pinterest board UX.

It should be easy to implement by fetching of Sitemaps or Recent Changes as RSS.

In general my intuition states that Federated Wiki fits to creative, distributed process. But it's not understood yet, yet missing important features as PRs and fork notifications.

One has to think about security and privacy features from ground up. As notifications, WordPress'ish trackbacks, could invite similiar scenarios like DNS amplification attacks or E-Mail backscatter.

As he joined in during an ongoing discussion, he stood quite for a moment, but as he's asked for his opinion, Christian reminds the participants of the Federated Wiki Hangout about the difference between

  • a protocol and
  • an implementation

We might have to still down the mechanism of what federated wiki is itself. Either an abstract definition for interoperable servers and clients, or an implementation

There is an experiment of a wiki backbone implementation, that could precede full blown ECMA 6 or, before, Ember clients.

Different Wiki readers instead of editors would be more easy to implement in the beginning. After UI experiments one could start to think of new server and distributed storage implications.

Wards task is to keep the code clean, the community's to come up with ideas.

The other guy next to Ward added, that sometimes as knowledge about early prototypes evolved and led to clearer expectations, it's better to start again from scratch.

In regards of Internationalization and other metadata we might want to store with our Wiki (Farm) Instance, the status directory could hold more additional information than just authentication and a favicon.

The default data storage could have multiple language directories .en extension.

Basically there are the ideas of either different farms for different languages, or different languages in one farm/wiki.