Hi, the documentation was written with a first time user in mind. That's why the topics start with the "first start" experience and move on to installing/handling maps. Next it explains the general idea behind projects and the 4 elements a project can contain. I recommend to read the wiki up to this point for everyone. The database is not a must. And devices only of interest if you got one that is supported.
Most of these topics I wrote while developing the software and occasionally updated it. Thus it's not always up-to-date. And it's more a documentation about what is available. Less a documentation about work flow. Many of Wolfgang's FAQ articles compensate that lack of work flow documentation. These parts would fit better right into the real documentation. Maybe in a different font to mark them as work flow documentation vs what's available documentation. I am not sure if we can squeeze that out of the Markdown tags. The FAQ probably should contain answers to questions that will not be documented e.g. why there are not a trillion digits behind the colon. There is no sense to explain that in the documentation. But it's quite frequently asked and has to be answered. But always keep in mind that the docs are for new users in the first place. Thus keep it short, keep it simple. Place the important stuff in the first paragraph rather than in between a lot of side information. The strong reader will find the details while reading the complete article. And for the weak one I am happy if he/she gets the basic idea without reading everything. One thing I personally dislike in the Wiki are the images. Images are important but they are a pain in the ass to keep them up-to-date and to organize them. Plus I think I made a real bad start with the naming scheme. If you guys have a better idea go for it. Oliver Am 21.11.2016 um 20:33 schrieb [email protected]: > Hallo Rainer, > > you raised this problem at the right time. I already started thinking > about the future of the FAQ in the same direction as you did. There > are certainly quite a few topics that belong to the "basic" part of > the documentation. > > Up to now it was relatively easy for me to insert information into the > FAQ part of the Wiki. Here topics are and can be isolated. There is > more or less no need to think about the right place in the > documentation, the interference with other parts and so on. > > My intention was to share with other users insight into QMS that I got > while working with QMS (following Olivers call for contributions). > And, of course, I played with QMS triggered by various discussions in > the newsgroup and elsewhere. Thus, my QMS information comes from a > users point of view and not from the designers/coders view (but I know > that Oliver reads the contributions quite carefully and if there is a > need he comments on them). > > With regard to your proposal I see at least 2 questions which should > be discussed before somehow re-arranging the Wiki: > > * The list of contents of the Wiki in DocMain is relatively short and > should certainly be extended due to the fact that QMS has plenty of > useful features not yet described (some are now in the FAQ). Otherwise > the Wiki pages are getting too long. And above of this: The structure > of the list of contents should reflect the philosophy of the software > designer! > > * What is the best structure for the QMS Wiki? Is the linear structure > proposed in connection with your toolset the best way to describe QMS > or would a tree structure as normally used in Wikis to be preferred? I > don't know how to answer this question. Both approaches have their > pros and cons. Think what happens with the DocMain page when having > there a much longer linear list of contents required by your tools! > > Thank you for raising this discussion! > > WolfgangTh > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > Qlandkartegt-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qlandkartegt-users ------------------------------------------------------------------------------ _______________________________________________ Qlandkartegt-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qlandkartegt-users
