* Replacement for Dokuwiki
@ 2015-02-17 9:24 R. W. Rodolico
2015-02-17 15:49 ` Michael Tremer
0 siblings, 1 reply; 4+ messages in thread
From: R. W. Rodolico @ 2015-02-17 9:24 UTC (permalink / raw)
To: documentation
[-- Attachment #1: Type: text/plain, Size: 912 bytes --]
I have a tech who is wanting additional hours, and she is a fairly good
researcher. I'd like to put her on the project of finding a replacement
for Dokuwiki. However, before I do, I'd really like to know what we want
it to do.
Here are my thoughts. Please feel free to say "yes" or "no" to anything.
My feelings will not be hurt. But, I do want Brandy (the tech) to have a
clear cut set of requirements before she puts in the time.
Requirements:
* HTML
* Multilevel tree menu
* Keyword searchable
* Full text searchable
* User management
* Multi-language capable
Nice to have
* WYSIWYG editor
* Export all or part to PDF or HTML
* Comments on articles (similar to php.net)
Anyway, anyone want to add/remove/modify the above? Also, does anyone
have a favorite package I should have her look into?
Rod
--
"Rod" Rodolico
Daily Data, Inc.
POB 140465
Dallas TX 75214-0465
214.827.2170
http://www.dailydata.net
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Replacement for Dokuwiki
2015-02-17 9:24 Replacement for Dokuwiki R. W. Rodolico
@ 2015-02-17 15:49 ` Michael Tremer
2015-02-17 21:26 ` R. W. Rodolico
0 siblings, 1 reply; 4+ messages in thread
From: Michael Tremer @ 2015-02-17 15:49 UTC (permalink / raw)
To: documentation
[-- Attachment #1: Type: text/plain, Size: 4136 bytes --]
Hi Rod,
thanks for offering to work on this.
On Tue, 2015-02-17 at 03:24 -0600, R. W. Rodolico wrote:
> I have a tech who is wanting additional hours, and she is a fairly good
> researcher. I'd like to put her on the project of finding a replacement
> for Dokuwiki. However, before I do, I'd really like to know what we want
> it to do.
>
> Here are my thoughts. Please feel free to say "yes" or "no" to anything.
> My feelings will not be hurt. But, I do want Brandy (the tech) to have a
> clear cut set of requirements before she puts in the time.
I am not too sure if there is any other good alternative that is
suitable for our needs but I am sure that we should have a look every
once in a while to see what else is out there.
Years ago we use Mediawiki which is great if you have many single pages
with one topic on them. We changed to dokuwiki back then because it
comes with a sort of directory structure which is very very great for
documentation. I have not found any other wiki software that has some
similar thing and I guess that this is the main feature that we need:
structure.
As mentioned Mediawiki doesn't have that and some other popular wiki
softwares that I checked out very more similar to the Mediawiki concept
than to the dokuwiki concept.
Maybe it is the best solution to stick with dokuwiki but enhance its
functionality with many plugins. There are lots of them but I didn't
have the time to check them out.
> Requirements:
> * HTML
yes :)
> * Multilevel tree menu
Yes. Structure is very important for us.
> * Keyword searchable
Dokuwiki's search is not the best. If you know the right keyword for
what you are searching for you will find everything. This does simply
not work in practice because if you are searching for something you
don't always know what you are exactly searching for.
Dokuwiki can be extended by using a software called Sphinx to improve
search results. Maybe it is worth trying that.
> * Full text searchable
Yes.
> * User management
We are using the forum's database to authenticate users. Dokuwiki itself
only comes with some very basic user management and we don't need
anything special here. Just authenticate users against a database and
have some groups to grant rights to some internal pages.
We decided using the forum's database so that users don't need to create
many accounts.
> * Multi-language capable
Yes.
> Nice to have
> * WYSIWYG editor
I personally prefer writing the wiki language directly.
> * Export all or part to PDF or HTML
Printing wiki pages is very common (apparently). I don't know why people
do this but having some option to export to PDF would be nice. It is
just a very low priority kind of thing.
> * Comments on articles (similar to php.net)
Nice idea. I am usually against the commenting thing on the Internet.
Mostly because this always leads to endless discussions about the least
important things. Maybe it is better to encourage users to edit an
article right away instead of getting lots of comments saying "this is
wrong/broken. please someone fix this paragraph".
We have the mailing list for discussions. Nobody uses it though.
> Anyway, anyone want to add/remove/modify the above? Also, does anyone
> have a favorite package I should have her look into?
I would like to add that the software should be easy to host. A huge
rails application that consumes loads of RAM won't work. I also want
really good performance from the wiki. Loading an article should not
take a second.
And last of all I wanted to state that Dokuwiki is not that bad. It
works very well for us. It is just some stripped-down software that
maybe be need to customize a bit. There are so many plugins that could
help us with that. It is also written in PHP and enhancing it with own
plugins is really easy.
If you want to create an installation to play with I could zip you the
data directory and send it to you. So you will have all the data and
maybe that is a great point to start with...
Enhancing the current wiki would also save us lots of work instead of
migrating the whole thing. History needs to be kept.
-Michael
>
> Rod
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Replacement for Dokuwiki
2015-02-17 15:49 ` Michael Tremer
@ 2015-02-17 21:26 ` R. W. Rodolico
2015-02-20 0:52 ` Michael Tremer
0 siblings, 1 reply; 4+ messages in thread
From: R. W. Rodolico @ 2015-02-17 21:26 UTC (permalink / raw)
To: documentation
[-- Attachment #1: Type: text/plain, Size: 6832 bytes --]
On 02/17/2015 09:49 AM, Michael Tremer wrote:
> Hi Rod,
>
> thanks for offering to work on this.
>
> On Tue, 2015-02-17 at 03:24 -0600, R. W. Rodolico wrote:
>> I have a tech who is wanting additional hours, and she is a fairly good
>> researcher. I'd like to put her on the project of finding a replacement
>> for Dokuwiki. However, before I do, I'd really like to know what we want
>> it to do.
>>
>> Here are my thoughts. Please feel free to say "yes" or "no" to anything.
>> My feelings will not be hurt. But, I do want Brandy (the tech) to have a
>> clear cut set of requirements before she puts in the time.
>
> I am not too sure if there is any other good alternative that is
> suitable for our needs but I am sure that we should have a look every
> once in a while to see what else is out there.
>
> Years ago we use Mediawiki which is great if you have many single pages
> with one topic on them. We changed to dokuwiki back then because it
> comes with a sort of directory structure which is very very great for
> documentation. I have not found any other wiki software that has some
> similar thing and I guess that this is the main feature that we need:
> structure.
>
> As mentioned Mediawiki doesn't have that and some other popular wiki
> softwares that I checked out very more similar to the Mediawiki concept
> than to the dokuwiki concept.
>
> Maybe it is the best solution to stick with dokuwiki but enhance its
> functionality with many plugins. There are lots of them but I didn't
> have the time to check them out.
I'd rather find something else simply because I want more people to be
comfortable with using the tool (writing/editing). Requiring that
someone use the markup language used by DokuWiki reduces the comfort
level many people have with writing anything. I know that I was
initially put off by this.
What we do not need is more articles written by Michael or Arne. You
guys need to be focusing on the Next Big Release. I want Brandy (my
tech) or even my sister (who has no ideas about it) to be able to edit
without feeling they have to spend time learning a new system.
>
>> Requirements:
>> * HTML
>
> yes :)
>
>> * Multilevel tree menu
>
> Yes. Structure is very important for us.
>
>> * Keyword searchable
>
> Dokuwiki's search is not the best. If you know the right keyword for
> what you are searching for you will find everything. This does simply
> not work in practice because if you are searching for something you
> don't always know what you are exactly searching for.
>
> Dokuwiki can be extended by using a software called Sphinx to improve
> search results. Maybe it is worth trying that.
>
>> * Full text searchable
>
> Yes.
>
>> * User management
>
> We are using the forum's database to authenticate users. Dokuwiki itself
> only comes with some very basic user management and we don't need
> anything special here. Just authenticate users against a database and
> have some groups to grant rights to some internal pages.
>
> We decided using the forum's database so that users don't need to create
> many accounts.
Ok, let's add "integration with outside database for authentication" to
the list. I'm thinking we could just export a simple view if the package
we use does not have the ability to authenticate against a different API.
>
>> * Multi-language capable
>
> Yes.
>
>> Nice to have
>> * WYSIWYG editor
>
> I personally prefer writing the wiki language directly.
I disagree. Yes, I generally hit the "Edit Source" button when I'm in a
WYSIWYG and write in HTML. However, we want documenters, and the fewer
limits we put on who can write/edit documents, the more people we can
get involved.
Actually, many times I write a document for our wiki
(wiki.linuxservertech.com) as plain text, then put my HTML markup on it,
then import it directly into the wiki as HTML. However, some of the
articles are written by my employees who are technically competent but
really not comfortable with HTML.
I am afraid that without a WYSIWYG, we are decreasing the number of
people who are willing to write their notes. I have 3-4 articles I have
written, but not put into the system due to the fact that I'll need to
translate them to the DokuWiki markup language. It is not intuitive to me.
>
>> * Export all or part to PDF or HTML
>
> Printing wiki pages is very common (apparently). I don't know why people
> do this but having some option to export to PDF would be nice. It is
> just a very low priority kind of thing.
>
With a printed document, PDF or epub, you can make notes, put in book
marks, and read when you have no internet connection. PLUS, a lot of old
guys like me have a few decades of reading "dead trees" (English slang
for paper books), and only a couple of decades of reading online, unlike
you younger ones who probably were using tablets in grade school.
I use ISPConfig and Zabbix, and in both cases, have downloaded (and paid
for in one case) the document so I can read it whenever I please.
>> * Comments on articles (similar to php.net)
>
> Nice idea. I am usually against the commenting thing on the Internet.
> Mostly because this always leads to endless discussions about the least
> important things. Maybe it is better to encourage users to edit an
> article right away instead of getting lots of comments saying "this is
> wrong/broken. please someone fix this paragraph".
>
> We have the mailing list for discussions. Nobody uses it though.
>
>> Anyway, anyone want to add/remove/modify the above? Also, does anyone
>> have a favorite package I should have her look into?
>
> I would like to add that the software should be easy to host. A huge
> rails application that consumes loads of RAM won't work. I also want
> really good performance from the wiki. Loading an article should not
> take a second.
>
> And last of all I wanted to state that Dokuwiki is not that bad. It
> works very well for us. It is just some stripped-down software that
> maybe be need to customize a bit. There are so many plugins that could
> help us with that. It is also written in PHP and enhancing it with own
> plugins is really easy.
>
> If you want to create an installation to play with I could zip you the
> data directory and send it to you. So you will have all the data and
> maybe that is a great point to start with...
>
> Enhancing the current wiki would also save us lots of work instead of
> migrating the whole thing. History needs to be kept.
I agree. If you want to ship me a copy of the current wiki, I'll put it
someplace and either play with it myself or put Brandy and Cait on it.
Who knows, all of my objections to it may disappear once we get them
working on it.
>
> -Michael
>
>>
>> Rod
>>
--
"Rod" Rodolico
Daily Data, Inc.
POB 140465
Dallas TX 75214-0465
214.827.2170
http://www.dailydata.net
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Replacement for Dokuwiki
2015-02-17 21:26 ` R. W. Rodolico
@ 2015-02-20 0:52 ` Michael Tremer
0 siblings, 0 replies; 4+ messages in thread
From: Michael Tremer @ 2015-02-20 0:52 UTC (permalink / raw)
To: documentation
[-- Attachment #1: Type: text/plain, Size: 9090 bytes --]
Hi,
On Tue, 2015-02-17 at 15:26 -0600, R. W. Rodolico wrote:
>
> On 02/17/2015 09:49 AM, Michael Tremer wrote:
> > Hi Rod,
> >
> > thanks for offering to work on this.
> >
> > On Tue, 2015-02-17 at 03:24 -0600, R. W. Rodolico wrote:
> >> I have a tech who is wanting additional hours, and she is a fairly good
> >> researcher. I'd like to put her on the project of finding a replacement
> >> for Dokuwiki. However, before I do, I'd really like to know what we want
> >> it to do.
> >>
> >> Here are my thoughts. Please feel free to say "yes" or "no" to anything.
> >> My feelings will not be hurt. But, I do want Brandy (the tech) to have a
> >> clear cut set of requirements before she puts in the time.
> >
> > I am not too sure if there is any other good alternative that is
> > suitable for our needs but I am sure that we should have a look every
> > once in a while to see what else is out there.
> >
> > Years ago we use Mediawiki which is great if you have many single pages
> > with one topic on them. We changed to dokuwiki back then because it
> > comes with a sort of directory structure which is very very great for
> > documentation. I have not found any other wiki software that has some
> > similar thing and I guess that this is the main feature that we need:
> > structure.
> >
> > As mentioned Mediawiki doesn't have that and some other popular wiki
> > softwares that I checked out very more similar to the Mediawiki concept
> > than to the dokuwiki concept.
> >
> > Maybe it is the best solution to stick with dokuwiki but enhance its
> > functionality with many plugins. There are lots of them but I didn't
> > have the time to check them out.
>
>
> I'd rather find something else simply because I want more people to be
> comfortable with using the tool (writing/editing). Requiring that
> someone use the markup language used by DokuWiki reduces the comfort
> level many people have with writing anything. I know that I was
> initially put off by this.
>
> What we do not need is more articles written by Michael or Arne. You
> guys need to be focusing on the Next Big Release. I want Brandy (my
> tech) or even my sister (who has no ideas about it) to be able to edit
> without feeling they have to spend time learning a new system.
First of all we intentionally avoid editing many things on the wiki. We
are hoping that the community is taking care of this which is not
working out that well. On top of that it is that we wouldn't have much
time even if we wanted to.
Secondly, this is a really good point. Editing the wiki should not
require any learning about the wiki system as well. I personally am much
concerned about the styling of the markup. This should work almost
automatically.
I have never seen a WYSIWYG editor that was any good so I personally
chose to edit the plain text files.
>
>
> >
> >> Requirements:
> >> * HTML
> >
> > yes :)
> >
> >> * Multilevel tree menu
> >
> > Yes. Structure is very important for us.
> >
> >> * Keyword searchable
> >
> > Dokuwiki's search is not the best. If you know the right keyword for
> > what you are searching for you will find everything. This does simply
> > not work in practice because if you are searching for something you
> > don't always know what you are exactly searching for.
> >
> > Dokuwiki can be extended by using a software called Sphinx to improve
> > search results. Maybe it is worth trying that.
> >
> >> * Full text searchable
> >
> > Yes.
> >
> >> * User management
> >
> > We are using the forum's database to authenticate users. Dokuwiki itself
> > only comes with some very basic user management and we don't need
> > anything special here. Just authenticate users against a database and
> > have some groups to grant rights to some internal pages.
> >
> > We decided using the forum's database so that users don't need to create
> > many accounts.
>
> Ok, let's add "integration with outside database for authentication" to
> the list. I'm thinking we could just export a simple view if the package
> we use does not have the ability to authenticate against a different API.
I wrote a plugin for dokuwiki myself a couple of weeks ago. The process
was simple but I wouldn't want to do it again for some other software.
> >
> >> * Multi-language capable
> >
> > Yes.
> >
> >> Nice to have
> >> * WYSIWYG editor
> >
> > I personally prefer writing the wiki language directly.
>
> I disagree. Yes, I generally hit the "Edit Source" button when I'm in a
> WYSIWYG and write in HTML. However, we want documenters, and the fewer
> limits we put on who can write/edit documents, the more people we can
> get involved.
>
> Actually, many times I write a document for our wiki
> (wiki.linuxservertech.com) as plain text, then put my HTML markup on it,
> then import it directly into the wiki as HTML. However, some of the
> articles are written by my employees who are technically competent but
> really not comfortable with HTML.
>
> I am afraid that without a WYSIWYG, we are decreasing the number of
> people who are willing to write their notes. I have 3-4 articles I have
> written, but not put into the system due to the fact that I'll need to
> translate them to the DokuWiki markup language. It is not intuitive to me.
>
I kinda of think differently about the dokuwiki language. It is not
designed to replace the HTML tags and make the articles easier to write.
It is about marking parts of the text as headlines, links and so on.
So instead of thinking <h1></h1> the better way is to think "this is the
main headline". Some people use bold text instead of headlines. This is
not really the same. It happens just very often that headlines are bold
but that is not a must.
There is some javascript working in the dokuwiki editor which work just
fine for me. I highlight the headline and then click the button. Done.
This does nothing to this discussion whether WYSIWYG is needed or not.
This is just how I use it.
> >> * Export all or part to PDF or HTML
> >
> > Printing wiki pages is very common (apparently). I don't know why people
> > do this but having some option to export to PDF would be nice. It is
> > just a very low priority kind of thing.
> >
>
> With a printed document, PDF or epub, you can make notes, put in book
> marks, and read when you have no internet connection. PLUS, a lot of old
> guys like me have a few decades of reading "dead trees" (English slang
> for paper books), and only a couple of decades of reading online, unlike
> you younger ones who probably were using tablets in grade school.
I prefer reading books on paper than on a tablet. Archiving the wiki
does not make too much sense as the documentation should change every
once in a while. I can think of many other use-cases for downloading
articles. It is nice to have the installation guide on the tablet when
you are installation IPFire for the first time. A PDF document would be
great for that don't you think?
> I use ISPConfig and Zabbix, and in both cases, have downloaded (and paid
> for in one case) the document so I can read it whenever I please.
>
> >> * Comments on articles (similar to php.net)
> >
> > Nice idea. I am usually against the commenting thing on the Internet.
> > Mostly because this always leads to endless discussions about the least
> > important things. Maybe it is better to encourage users to edit an
> > article right away instead of getting lots of comments saying "this is
> > wrong/broken. please someone fix this paragraph".
> >
> > We have the mailing list for discussions. Nobody uses it though.
> >
> >> Anyway, anyone want to add/remove/modify the above? Also, does anyone
> >> have a favorite package I should have her look into?
> >
> > I would like to add that the software should be easy to host. A huge
> > rails application that consumes loads of RAM won't work. I also want
> > really good performance from the wiki. Loading an article should not
> > take a second.
> >
> > And last of all I wanted to state that Dokuwiki is not that bad. It
> > works very well for us. It is just some stripped-down software that
> > maybe be need to customize a bit. There are so many plugins that could
> > help us with that. It is also written in PHP and enhancing it with own
> > plugins is really easy.
> >
> > If you want to create an installation to play with I could zip you the
> > data directory and send it to you. So you will have all the data and
> > maybe that is a great point to start with...
> >
> > Enhancing the current wiki would also save us lots of work instead of
> > migrating the whole thing. History needs to be kept.
>
> I agree. If you want to ship me a copy of the current wiki, I'll put it
> someplace and either play with it myself or put Brandy and Cait on it.
> Who knows, all of my objections to it may disappear once we get them
> working on it.
Great. I think starting with what we have and figuring out what is wrong
with that and if and how we can improve should be the best option. If we
cannot fix that with dokuwiki we should search for something else.
-Michael
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2015-02-20 0:52 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-02-17 9:24 Replacement for Dokuwiki R. W. Rodolico
2015-02-17 15:49 ` Michael Tremer
2015-02-17 21:26 ` R. W. Rodolico
2015-02-20 0:52 ` Michael Tremer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox