You simply don't force volunteers to use tools. We're trying that now with RST.People use guiguts because it's the only thing available (other than your
preferred editor and personal html sense, which is not a common resource.)
I am developing tools that people will only use if a) they're easier than the alternative,
b) they are more productive than the alternative and c) they increase the likelihood
of success when facing the whitewashers and the PG software filters.
But why would I want to develop tools that didn't? Unlike some, I'm not committed
to any technology in the workflow, I'm only committed to the people without
whom the workflow wouldn't flow. Hence my insistence that the only markup
options worth considering are the ones that have the possibility of being used
by DP volunteers with minimal objection.
You'll see one example when I get the
eb.tbicl.org clone up (probably within
a week - I've got to ship the database files over and transplanted as the most
tedious step.) It's by default an html editor but with some helper abstractions
added to simplify some common markup patterns to enable non-techs to
write successful html.
Interesting fact - there are really only three contexts that provide html editing tools
that non-technical people seem to tolerate. One is email editors; and their
output is so dumbed-down as to be I think useless. The other two are wikis
and blog engines. Wikis have developed a comprehensive markup of their
own that no one seems to be interesting in discussing. Nor blog engines,
which have a larger variety of options.
Most of the discussion here centers around how technically well some
markup will represent the text, while capturing the data, unambiguously
enough to be mined for alternative outputs. I think this is a futile exercise
base on incorrect priorities. I think the only path to success is to provide
a user interface that as much as possible hides the markup so people don't
need to deal with it directly. Then as long as the information is there, it
can be extracted into any format you want. That's what software is for -
to adapt to what people need to do. Not vice versa (yes I'm repeating
myself.)
That's the main point of one of those wikisource papers - they have decided
that the most important inhibitor to their ability to grow and succeed is
an inadequate editing interface.
I can't think of a single successful word processing product that exposes
its underlying text representation to the user.
So I have one project that's built on the blogger software that has the
reputation for the least intimidating user interface (wordpress). And
I picked it pretty much solely for that reason. It's a lot easier to get
the text into whatever markup I want, serialized any way I need to,
once I get people to edit it into some unambiguously structured format,
whatever way they find easiest. (And very few people can get it into
unambiguously structured form of any kind using just notepad.) Guiguts
has unstructured ambiguity as one of its biggest weaknesses.
Wordpress by default provides the user with a TinyMCE interface,
which looks like any rich text editor and produces html. I find it
personally unusable. The backup editor is a customizable html
editor that doesn't inhibit the complexity of the html or other
markup you enter so that's what I'm building on. The also have
editor modules for markdown, FCKeditor, textile, and RST
(although the RST editor appears to have been abandoned.)
I think it had the potential to be morphed into a variety of contexts,
but it has never caught on and is now primarily a python
documentation tool, and applied to other purposes by
pythonisti.
Eclipse is quite commonly used as an easier-to-use ui shell in front of
editors (mainly of the programmer type, but the target audience of the
preferred toolset provided by PG is unquestionably programmer-types.)
It comes with pretty good tools for highlighting html, javascript, or any
other syntax you can name.
On Sun, Feb 5, 2012 at 10:31 PM, Jim Adcock
<jimad@msn.com> wrote:
Don>I'd like to see someone consider using one of the many UI frameworks
available these days rather than coming up with another - I guess to try to
avoid another guiguts situation. One-man software tools have such obvious
shortcomings no matter what their technical merit.
Sorry, I'm sure I get what you are suggesting based on looking at these
websites, but it seems like you are going beyond requiring volunteers to
submit to a "master" source format to now also "master" them when it comes
to the choice of tools they are allowed to use to develop books in that
"master" source format?
I can see how this might work if they were well paid employees, not
volunteers.
Or are you saying that you are volunteering to make a new set of tools that
the volunteers can *choose* to use -- either the tools you provide, or
guiguts, or Notepad++ -- or whatever the heck the volunteer wants to use
which *they* feel is the most efficient, and/or the most fun, to help them
get *their* book effort done?