Author Topic: Word processor or wiki exporting?  (Read 15147 times)

admin

  • Administrator
  • Newbie
  • *****
  • Posts: 11
    • View Profile
    • Email
Word processor or wiki exporting?
« on: May 27, 2007, 07:37:30 pm »
A Word processor is one of the first and obvious features of a Web Office. Ignacio and Marcos have been working on a "state of the art" analysis of the subject, since there is no obvious Open Source project standing out.

One idea that came out of the sessions at www.fing.edu.uy was to use a Wiki as a Word Processor, and add some sort of plug-in to enable ODF exporting. What are your thoughts on that idea?

admin

  • Administrator
  • Newbie
  • *****
  • Posts: 11
    • View Profile
    • Email
Re: Word processor or wiki exporting?
« Reply #1 on: May 27, 2007, 09:09:51 pm »
Just found this article very related to the subject. It's a good read, I promise.

webworkerdaily.com/2007/05/12/open-thread-what-word-processor-or-text-editor-do-you-use/

conrado

  • Administrator
  • Hero Member
  • *****
  • Posts: 998
  • Conrado
    • View Profile
    • Feng Office
    • Email
Re: Word processor or wiki exporting?
« Reply #2 on: June 05, 2007, 12:08:29 pm »
Mario was asking in this post why should we use a wiki instead of a word processor (WP), and I realized we didn't give too many reasons for the suggested approach.

To be honest, FCKeditor would be my candidate for the Word Processing app, by two main reasons:
  • Features set
  • Recent announcements of Adobe and Oracle support

But then I think reality dictates...

Create content, not design
When working on a company, most of the time you should follow the company guidelines for Document formatting. Font family, style, header size, alignment, etc., should be dictated by the company, and workers should simply adhere to that, and not waste time 'crafting' a document each time they work on it.

If you use a wiki, then you already know it is much faster to create a document than to use a Word processor.

Collaborating needs versioning
The Web Office is about collaborating. And when a single document is the work of a team, you need revision and version history. Most popular Open Source Web (OSW) wikis already deal with that. Word processors don't.

Maturity
Wikis are, at this stage, more mature than OSW Word processors.

You can embed a WP in a Wiki
Finally, I think that you could embed a Word Processor in a Wiki. Just like adobe is probably doing. Kind of what google does when you are writing an e-mail in gmail. That, I think, is the trend.

Wouldn't it be great to always use the same word processing toolbar, be you writing a blog post, a forum post, an e-mail, or a document? And, depending on the circumstances, you could chose between the complex or the simplified version.

And more
And, as usual, what I am missing. That's why your opinion is important. What arguments have not been discussed?
Get Official Support for your Feng Office. Support the development team. Sign up for a Free Trial here.

mario

  • Newbie
  • *
  • Posts: 5
    • View Profile
Re: Word processor or wiki exporting?
« Reply #3 on: June 05, 2007, 07:36:23 pm »
Good enough for me, at last in  fist instance, i think that the possibility of extending the WP functionality by changing it and leaving the wiki "container", add grate amount of flexibility to the project.

yed

  • Newbie
  • *
  • Posts: 16
    • View Profile
Re: Word processor or wiki exporting?
« Reply #4 on: June 06, 2007, 11:01:59 am »
My idea of a web based word processor would be a WYSIWYG editor on a Wiki.

Now we can have any wiki under it but the editor should be something familiar.
I agree with conrado that a web based document would basically mean collaboration and if collaboration is to be done we must have the history of changes in it. And the best way to track the user changes across a document is a Wiki.

Even the writey/google doc has something very similar. Just that they have hidden the wiki completely out of picture. Any change made to the document can be tracked back like a wiki and the entire document is editable using the WYSIWYG editor. A little more of ajax is sprinkled to the document to make it more realtime than a text based wiki, lie- auto saves, simultaneous edits tracking etc etc...

As for exporting and importing the document to word we already have the famous OpenOffice open document format.

conrado

  • Administrator
  • Hero Member
  • *****
  • Posts: 998
  • Conrado
    • View Profile
    • Feng Office
    • Email
Re: Word processor or wiki exporting?
« Reply #5 on: June 06, 2007, 02:35:35 pm »
Hi yed. Welcome aboard!

It seems you back the idea then. Which OS Wiki and text editor do you think would be best for the merger?

It is true we have OpenOffice that comes handy quite often (It's been over a year now since I last used MS Office). But there is no Wiki->ODF translator. That should be a priority feature for OpenGoo.
Get Official Support for your Feng Office. Support the development team. Sign up for a Free Trial here.

yed

  • Newbie
  • *
  • Posts: 16
    • View Profile
Re: Word processor or wiki exporting?
« Reply #6 on: June 07, 2007, 11:14:39 am »
I have worked on PmWiki which is pretty simple yet with lot of features.
And someone had provided a FCKEditor on it to give us a WYSIWYG editor on PmWiki.
I have it on my intranet and though the WYSIWYG editor on PmWiki is not the best, it shows that it can be achieved easily.

But I would suggest that we don't get too much drawn into the wiki thing.
The idea here would be to give the user a view with a transparent wiki component to it. Give them the familiar word like view. The only interesting thing would be to make sure that the user gets the to know when and what changes were made and if the document is being use collaboratively then if any simultaneous edits happen the user is dynamically shown the changes being made and a way to recover the edits (with the overwritten)  incase the user would like to keep them.

I know the above lines can be broken up more neatly. Let me know in case I am not clear above. I am able to give only a small idea with what I have setup, used and observed with the 3 years with PmWiki. And compared it with Google Docs since writely came in. I have received comments from so many that they would prefer a google doc like application than a wiki (which is far more feature rich and extensible). I have been recently toying on an idea of implementing spreadsheets on PmWiki.

We can reuse a wiki but in its simplest form with only the following features:
1. History tracking
2. Authentication
3. Simultaneous edits tracking

The trick I have found about the web based office suites is mostly on the user experience end of it. As long as the user finds himself on familiar grounds it is a success.

conrado

  • Administrator
  • Hero Member
  • *****
  • Posts: 998
  • Conrado
    • View Profile
    • Feng Office
    • Email
Re: Word processor or wiki exporting?
« Reply #7 on: June 07, 2007, 04:44:22 pm »
The trick I have found about the web based office suites is mostly on the user experience end of it. As long as the user finds himself on familiar grounds it is a success.

Agreed. Absolutely.

We can reuse a wiki but in its simplest form with only the following features:
1. History tracking
2. Authentication
3. Simultaneous edits tracking

Excellent. But what do you suggest? Do we use a wiki as "the engine", use FCKEditor and work from there, or start something new from the ground?

This is actually the analysis that have taken us longer, and we still didn't decide which way to go.

One thing I do know: It would be great to always use the same WYSIWYG toolbars. As you said, it would provide a familiar ground in every part of the system.

But I would suggest that we don't get too much drawn into the wiki thing.
The idea here would be to give the user a view with a transparent wiki component to it. Give them the familiar word like view. The only interesting thing would be to make sure that the user gets the to know when and what changes were made and if the document is being use collaboratively then if any simultaneous edits happen the user is dynamically shown the changes being made and a way to recover the edits (with the overwritten)  in case the user would like to keep them.

I think I get the idea, and I agree. I am all for hiding the "Edit as Wiki" mode if that is what you mean (just enable the WYSIWYG). Programmers and Web Designers learn to write in Wiki language very fast, but I am sure it is a tedious task for Joe Average.

I know the above lines can be broken up more neatly. Let me know in case I am not clear above. I am able to give only a small idea with what I have setup, used and observed with the 3 years with PmWiki. And compared it with Google Docs since writely came in. I have received comments from so many that they would prefer a google doc like application than a wiki (which is far more feature rich and extensible). I have been recently toying on an idea of implementing spreadsheets on PmWiki.

That would be neat! But have you tried WikiCalc? Maybe it is a good starting point with many functions already in place. Just a thought. I haven't dug much in this area.
Get Official Support for your Feng Office. Support the development team. Sign up for a Free Trial here.

yed

  • Newbie
  • *
  • Posts: 16
    • View Profile
Re: Word processor or wiki exporting?
« Reply #8 on: June 07, 2007, 05:29:28 pm »
Quote
Excellent. But what do you suggest? Do we use a wiki as "the engine", use FCKEditor and work from there, or start something new from the ground?
Like I said I would prefer if we have a more plugin based architecture. Something which will be common across all the applications running on top of the engine. Wiki as engine is an example, we can choose to rewrite it completely as our own. As for using FCKEditor we should be able to reuse it (mashup up -  ::) I know...) if not completely in its existing form.

Quote
That would be neat! But have you tried WikiCalc?
I have tried WikiCalc but its standalone version and not the hosted one.
Yes I would say say that I was thinking in those lines. But frankly I have not been very impressed with it. I found the others like the one from tikiwiki and twiki to be better addressing the needs.
http://doc.tikiwiki.org/tiki-index.php?page=Spreadsheet
http://twiki.org/cgi-bin/view/TWiki/SpreadSheetPlugin

I think it is OK if you would like to mash up at the application level, but lets try and keep the underlying engine(wiki or whatever) separate from them. This will be better because we can always go back and mashup something else at the application layer than at the platform layer. Also this gives us more options and a safer environment to play with.

I will try and explain with an example which is just a very simple one:
    Lets say we take a wiki engine as the base layer/core of the system : a simple (or complex depending on what we need) wiki
    • Next we plugin FckEditor on it as a rich text editor
    • Next we plugin the Twiki spreadsheet on it as a spreadsheet editor
    • We include a blog as a plugin again like what we have one on PmWiki or Twiki
    • We include a way to load a ppt for showing slides (maybe on a flash based front end)
    • Again we include a single signon for all of them using a plugin
    And all along the user never knows that he or she is actually working on top of a wiki or wiki like engine!

    So its fine if we mash things up at the higher level of abstraction but would suggest we have a common, uniform and strong platform to hold together all of them. Because this will glue together and also be the backbone for the rest of the applications. Yet be separate enough not to impact each other.



conrado

  • Administrator
  • Hero Member
  • *****
  • Posts: 998
  • Conrado
    • View Profile
    • Feng Office
    • Email
Re: Word processor or wiki exporting?
« Reply #9 on: June 07, 2007, 05:46:46 pm »
Yes. I get the points and they make a lot of sense. Specially for the same "family" of apps. In this case, we are talking about the "Composing" or "Document creation and edition" applications. Those would include:
  • Word processor
  • Spreadsheet
  • Presentation Program
  • Flowchart
  • Raster image processor

*Taken from the Wikipedia Web Office definition.

Now we have to find that engine... or build it?

I still would like to experiment with an integration at a higher layer. For instance, I think it would be cool to have a blog, and maybe have a "post in blog" button in the menu where you create a document. Then why put a blog on top of the wiki-like engine if we have cool frameworks like WordPress?
Get Official Support for your Feng Office. Support the development team. Sign up for a Free Trial here.

jeremyclarke

  • Newbie
  • *
  • Posts: 2
    • View Profile
Re: Word processor or wiki exporting?
« Reply #10 on: August 17, 2007, 03:07:39 am »
I still would like to experiment with an integration at a higher layer. For instance, I think it would be cool to have a blog, and maybe have a "post in blog" button in the menu where you create a document. Then why put a blog on top of the wiki-like engine if we have cool frameworks like WordPress?

It kind of seems like in the organizational scheme from activeCollab messages to everyone in the system would take the for of memos to the 'projects' or something. A block listing recent memos from your project manager (basically a very specific blog) could show on the summary page. But as internal messages it would kind of make sense that they are written with the "word processor", as that's usually how memos come in a big organization. Besides, most blogging software now is just using WYSIWYG editors like FCK and TinyMCE anyway, so opengoo might as well just have a consistent WYSIWYG throughout.

If anything, the great thing about the WordPress editor is that it lets you use both formats (XHTML and WYSIWYG) quickly and interchangeably, allowing everyone to look at the code as often as they wanted but didn't force them (textpattern also had this, but they had a third tab for their own markup system). I think it's valuable to have tabs or something to let people access any raw markup that might exist.

I know I personally often get mad when dealing with WYSIWYG javascript editors because I know enough about markup that it's easier to use html or wiki scripting. If you offer both formats then no one has to get frustrated, and targeting web designers/developpers who know markup is a really good idea because they're the ones deciding what software will be used by entire organizations.


conrado

  • Administrator
  • Hero Member
  • *****
  • Posts: 998
  • Conrado
    • View Profile
    • Feng Office
    • Email
Re: Word processor or wiki exporting?
« Reply #11 on: August 20, 2007, 04:45:24 am »
Totally agreed.

Wordpress approach is the best I have seen. It may be improved, but it is the best so far. Additionally, I think it is a good idea to have only the WYSIWYG as default, and enable the code view only for those users that request it. "Start simple", and "complicate on demand".
« Last Edit: August 20, 2007, 04:48:08 am by conrado »
Get Official Support for your Feng Office. Support the development team. Sign up for a Free Trial here.