> I do not really get the difference you make here. Wiki as > means of discussion doesn't work, IMHO, and points that come > up in discussion as they are not clear in the help (or do > not even exist there) should make it into the docs. Maybe I > see to close a relation. I'll leave this point to the doc > people however ;)
There are many differences : if it is backed up by an on-line help facility, it does not have to be the complete Scid manual. A simple description is enough. > This was the reason of my question. Is this possible, if so > wouldn't that be the best way to get a really user centred > help? The problem will come when the wiki will want to integrate tricks, tips, bugs, user cases, etc. Consider for instance the last discussion about working with multiple files. This fits well with the wiki, but not the F1 help. I fear that it will be hard to separate automagically description of a functionality with everything else. > Besides: there are some projects that do not have any F1 > help locally, but always link to a certain wiki page online. > I'm not sure that I like this, but one could think in this > direction. Yes, that is a possibility. We would have to consider it if we can't improve the help.tcl file. I would like to give it another chance, though. In any case, we need to improve what we have now as a help.tcl file. And you know I am starting to work on it. That said, that's my impression. If we can automatize the work from wiki to help.tcl, I would reconsider, since there is much to gain. Maybe we could then markup what makes the F1 help cut and what does not. That could be admin related business. If this is easier than maintaining help.tcl by itself, then your idea might be interesting. > I had two parts in mind, a bit like Wikipedia: one page > containing the destillate and an additional "discussion > page" behind it. The destilled information being the > offical help that could probably be used to update the local > files. > > The only point I'd not have like wikipedia is this senseless > discussions going on there about relevance of an article. > IMHO if someone took the time to write an article it made > sense for him to have it and one is done with this > discussion. Doesn't eat any bread in the database. Agreed. In fact, since we have a mailing list, we do not even have to discuss anything in the wiki itself. (Besides, if we have a flat file system, we do not even have that database problem ;-) > I'm not sure that the online help should not contain such > things. IMHO the most helpful docs always contain real world > examples: not trivial but also not absolutely unearthy to > show all features by construction. The problem is that there is one F1 file and many Scid versions, with all their own idiosyncrasies. > I fear we don't have for the docs. If we have wiki contributors for the 14 languages we are maintaining, I would certainly consider maintaining all the docs in a wiki. I just got this idea : we can have a type for the F1 help topics, e.g. Nutshell or Description. It can be a page title, a section title, a category, etc. So we may be able to have both the cake and eat it ;-) ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Scid-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/scid-users
