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?
_______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d