Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Standalone wiki-client page #169

Open
clemsos opened this issue Jun 20, 2016 · 4 comments
Open

Standalone wiki-client page #169

clemsos opened this issue Jun 20, 2016 · 4 comments

Comments

@clemsos
Copy link

clemsos commented Jun 20, 2016

While doing a bit of work about fedwiki design for mobile on #163 and #167 , it made me think it will be great to have a wiki-client that can handle a standalone page. Then the navbar and the handling of the lineup could all become optional - in the form of npm plugins as in other fedwiki plugins.

One particular achievement of this will be the creation of a standalone writer that can be integrated in virtually any software, but will have a common content and authorship structure. That means that instead of being a complete software, fedwiki could become a core part for differents websites and apps. For instance, I could drag the text from my app or another webpage into my wiki and start editing it. That also means that this standalone fedwiki page component will have minimum styling guidelines, so it can integrate in other graphic environment easily.

The general approach of developing this standalone page fedwiki-client will also be a good way to start to build a solid page component that will work on mobile and all - maybe as a react component as discussed in #167 . It requires to dissociate some of the logic of wiki-client like the auth system, that could by a 3rd part (like Meteor in the case of Topogram), the lineup or the menu (that can become plugins).

I don't know if anybody is interested to work on this, but I will be eager to start to experiment with ideas and code in that direction.


An example with Topogram

The idea comes from the fact that I have been working on the development of a software for collaborative creation and visualization of network called Topogram http://topogram.io . I would love to integrate it with fedwiki so people can describe anything using network representation dynamically only by writing content.

Here is a screenshot of the UI. I would like to replace the part with the red circle with fedwiki

selection_138

Which should give sth like this

topo-fedwiki

Where each node will be a single wiki page.

The software (topogram) is written in JS so it should be fairly easy to integrate. My idea is that if I could have only a single standalone page that will allow drag & drop and all the basic features of fedwiki. it will also allow me to integrate the many existing plugins and to rely on the authorship structure of fedwiki. Well, it will be absolutely great.

@opn
Copy link

opn commented Jun 21, 2016

We see things the same :)

Here are a few notes and designs I suggested:

And yes I think this is a step towards an alternative way of showing wiki
content, and would be best pursued as an external single page app. The
second way round is to put small graphs inside wiki (with the option of
full screen) - the latter full screen action could instead link to the
single page app view. So we are talking inside-out type views - or wood /
tree views of the federation content.

On 20 June 2016 at 16:23, Clément Renaud notifications@github.com wrote:

While doing a bit of work about fedwiki design for mobile on #163
#163 and #167
#167 , it made me think it
will be great to have a wiki-client that can handle a standalone page. Then
the navbar and the handling of the lineup could all become optional - in
the form of npm plugins as in other fedwiki plugins.

The idea comes from the fact that I have been working on the development
of a software for collaborative creation and visualization of network
called Topogram http://topogram.io . I would love to integrate it with
fedwiki so people can describe anything using network representation
dynamically only by writing content.

Here is a screenshot of the UI. I would like to replace the part with the
red circle with fedwiki

[image: selection_138]
https://cloud.githubusercontent.com/assets/743246/16199438/d10e3cde-3709-11e6-87c6-8502be2ad60a.png

Which should give sth like this

[image: topo-fedwiki]
https://cloud.githubusercontent.com/assets/743246/16199532/2bb65d38-370a-11e6-9c83-6b50d2a100e8.png

Where each node will be a single wiki page.

The software (topogram) is written in JS so it should be fairly easy to
integrate. My idea is that if I could have only a single standalone page
that will allow drag & drop and all the basic features of fedwiki. it will
also allow me to integrate the many existing plugins and to rely on the
authorship structure of fedwiki. Well, it will be absolutely great.

The general approach of developing this standalone page fedwiki-client
will also be a good way to start to build a solid page component that will
work on mobile and all - maybe as a react component as discussed in #167
#167 . It requires to
dissociate some of the logic of wiki-client like the auth system, that
could by a 3rd part (like Meteor in the case of Topogram), the lineup or
the menu (that can become plugins).

One particular achievement of this will be the creation of a standalone
writer that can be integrated in virtually any software, but will have a
common content and authorship structure.
That means that instead of
being a complete software, fedwiki could become a core part for differents
websites and apps. For instance, I could drag the text from my app or
another webpage into my wiki and start editing it. That also means that
this standalone fedwiki page component will have minimum styling
guidelines, so it can integrate in other graphic environment easily.

I don't know if anybody is interested to work on this, but I will be eager
to start to experiment with ideas and code in that direction.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#169, or mute the thread
https://github.com/notifications/unsubscribe/AAE71t44HC1yEPXXCAwfVsVg65obJZ3dks5qNrCAgaJpZM4I50K5
.

@clemsos
Copy link
Author

clemsos commented Jun 21, 2016

interesting. We could just continue what we started here https://github.com/clemsos/wiki-plugin-single-page . this is all very basic feature, but the rep is here already. we can also move that to another organization

@opn
Copy link

opn commented Jun 21, 2016

Good idea!

On 21 June 2016 at 20:20, Clément Renaud notifications@github.com wrote:

interesting. We could just continue what we started here
https://github.com/clemsos/wiki-plugin-single-page . this is all very
basic feature, but the rep is here already. we can also move that to
another organization


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#169 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAE71nWOGL6bM2_4KPwQpFSGBjeVwLs8ks5qODmEgaJpZM4I50K5
.

@WardCunningham
Copy link
Member

I look forward to see what you do with this.
I'm watching the clemsos repo and encourage others here to do likewise.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants