|
|
|
Home » Developing U++ » U++ Developers corner » Documentation and Topic++
| Documentation and Topic++ [message #12713] |
Tue, 13 November 2007 19:41  |
 |
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
| Mindtraveller wrote on Tue, 13 November 2007 08:33 |
OK. I started making new articles.
For now, two things impedes the most:
1) Unnatural division of package docs by "src" and "srcdoc". After some learning it seems like one stands for index while other stands for manual.
I would refuse such a division because index must be one for all packages (smth. like MSDN where I type first letters and got functions starting with them). So all we need in the package docs tree is articles (I would refuse treeview of structure too - as described in forum messages).
|
Well, first of all, the idea behind Topic++ is that it should serve as tool for documenting both the program structure (sources), but also the application being developed (help, application manual).
That is the original idea behind documentation groups.
Now "predefined" groups are
src - this should contain a straight *reference* to the code *interface*. Note that theide is able to bind documents to the code. We have big plans on improving on this. (think "reference" part of MSDN API documents).
srcdoc - this should be for other programming documents - guides, explanations etc...
srcimp - this is intended to contain the comments about code implementation.
app - application documents - help, manuals etc...
| Quote: |
2) Inexistence of first common page. I think there must be root page, and this page must be default (but when we click some package` article, it shows in help window).
For now this root article is finished and I started writing inner articles, which were linked from root.
|
"index" page is considered "first common". Obviously, there is a little problem as this really works well only for single group in single package...
Mirek
|
|
|
|
| Re: Documentation and Topic++ [message #12720 is a reply to message #12713] |
Wed, 14 November 2007 04:32  |
Mindtraveller
Messages: 917
Registered: August 2007
Location: Russia, Moscow rgn.
|
Experienced Contributor |
|
|
I think this is of course great to have one help engine for development docs and user (not programmer) documentation on application developed. So I vote for the original idea.
Next, from the design point of view, treeview-control guiding system as well as "predefined groups" seems to me not very optimal.
I`ll try to make suggestions how to increase usability. Of course, everything below is my point of view and a subject for discussion:
1) Leving behind any "magical words" line "srcdocs","srcimp". We simply don`t need that kind of magic. We need simple things to concentrate attention to the help text itself - without user`s brain guiding through magical labyrinths.
2) Information on package must be concentrated in one articles-tree. Each article has index-tags. So user has 3 ways to look at docs: manual view mode, index and full-text-search modes. Last two modes I`d like to be as MSDN ones.
This approach seems to me little more general. General enough to handle with programmers` manual as easy as user help.
3) src* groups are presented as:
src - number of articles, generated by TheIDE (and linked from some other articles if necessary). I`d prefer some package article to have these links listed by logical or functional groups (alphabetic access is available through Index mode).
srcimp and srcdoc articles are represented as links from (or part of) articles about respective subjects.
The general approach is the same: different kinds of information about subject must be in easy reach from parent article about subject. It seems very obvious way of making things user-oriented.
4) Fimally, general view of help system with approach suggested will be something like this:
5) Thoughts about root article I`ll try to write later, as all ideas about it come in order.
[Updated on: Wed, 14 November 2007 04:35] Report message to a moderator |
|
|
|
| Re: Documentation and Topic++ [message #12724 is a reply to message #12720] |
Wed, 14 November 2007 11:46 |
|
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
| Mindtraveller wrote on Tue, 13 November 2007 22:32 |
I think this is of course great to have one help engine for development docs and user (not programmer) documentation on application developed. So I vote for the original idea.
Next, from the design point of view, treeview-control guiding system as well as "predefined groups" seems to me not very optimal.
|
Yep, I agree. The help page definitely needsd an improvement.
| Quote: |
I`ll try to make suggestions how to increase usability. Of course, everything below is my point of view and a subject for discussion:
1) Leving behind any "magical words" line "srcdocs","srcimp". We simply don`t need that kind of magic. We need simple things to concentrate attention to the help text itself - without user`s brain guiding through magical labyrinths.
|
Mostly agree, but I think medium advanced user will need to know those magic words too, so that he can use Topic++ to write docs...
Considering other points, the only thing I would like to add is the vision that the future ide will provide much better code/documentation integration.
One of ideas is that browsing the .h file, you will have small icons in left bar (when breakpoints usually are) for each code element (e.g. method declaration); moving the mouse over that icon will popup documentation for the item.
If documentation is not available for item, icon will look differently and clicking it will move you to topic++, generating the text template to document the method.
Similar capabilities should be available in new class browser too.
In .cpp, the idea is that instead of "src", these will lead to "srcimp".
Mirek
|
|
|
|
| Re: Documentation and Topic++ [message #12727 is a reply to message #12724] |
Wed, 14 November 2007 13:24 |
Mindtraveller
Messages: 917
Registered: August 2007
Location: Russia, Moscow rgn.
|
Experienced Contributor |
|
|
| Quote: |
Mostly agree, but I think medium advanced user will need to know those magic words too, so that he can use Topic++ to write docs...
One of ideas is that browsing the .h file, you will have small icons in left bar (when breakpoints usually are) for each code element (e.g. method declaration); moving the mouse over that icon will popup documentation for the item.
If documentation is not available for item, icon will look differently and clicking it will move you to topic++, generating the text template to document the method.
Similar capabilities should be available in new class browser too.
In .cpp, the idea is that instead of "src", these will lead to "srcimp".
|
Could you please describe why exactly is it needed to use these words? I think it is way too hard for understanding "by default". Yes, user may learn manual on that subject, but what for?
It`s nothing prevents us from adding these comments simply by clicking left icon and typing docs in the same window, without any additional identifiers. For me it is so natural, that I have to think of arguments to make this thought clear.
[Updated on: Wed, 14 November 2007 13:33] Report message to a moderator |
|
|
|
| Re: Documentation and Topic++ [message #12728 is a reply to message #12727] |
Wed, 14 November 2007 13:41 |
|
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
| Mindtraveller wrote on Wed, 14 November 2007 07:24 |
| Quote: |
Mostly agree, but I think medium advanced user will need to know those magic words too, so that he can use Topic++ to write docs...
One of ideas is that browsing the .h file, you will have small icons in left bar (when breakpoints usually are) for each code element (e.g. method declaration); moving the mouse over that icon will popup documentation for the item.
If documentation is not available for item, icon will look differently and clicking it will move you to topic++, generating the text template to document the method.
Similar capabilities should be available in new class browser too.
In .cpp, the idea is that instead of "src", these will lead to "srcimp".
|
Could you please describe why exactly is it needed to use these words? I think it is way too hard for understanding "by default". Yes, user may learn manual on that subject, but what for?
It`s nothing prevents us from adding these comments simply by clicking left icon and typing docs in the same window, without any additional identifiers. For me it is so natural, that I have to think of arguments to make this thought clear.
|
Well, if nothing else, groups are important if you are importing Topic++ into your code - you do so by package-group quantities.
So perhaps for documenting the code, you could do without it, but for using Topic++ as application document resources, understanding of groups is unavoidable.
Mirek
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Documentation and Topic++ [message #13025 is a reply to message #12713] |
Wed, 05 December 2007 18:19 |
Mindtraveller
Messages: 917
Registered: August 2007
Location: Russia, Moscow rgn.
|
Experienced Contributor |
|
|
Ok.
I suggest having 2 types of docs: autogenerated from sources and manual. Manual articles may hypelink to source-autogenerated articles. All these docs are accessible by 3 tabs:
1. Index
indexed source-autogenerated articles;
2. Manual
manual docs, something like site with hyperlinks;
3. Search
full-text search within source and manual docs;
user may check areas for search: source, manual, or both.
Only tabs, no magic words. Plain and simple.
Is it OK, any corrections?
[Updated on: Wed, 05 December 2007 18:19] Report message to a moderator |
|
|
|
| Re: Documentation and Topic++ [message #13027 is a reply to message #13025] |
Wed, 05 December 2007 19:18 |
|
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
| Mindtraveller wrote on Wed, 05 December 2007 12:19 |
Ok.
I suggest having 2 types of docs: autogenerated from sources and manual. Manual articles may hypelink to source-autogenerated articles. All these docs are accessible by 3 tabs:
1. Index
indexed source-autogenerated articles;
2. Manual
manual docs, something like site with hyperlinks;
3. Search
full-text search within source and manual docs;
user may check areas for search: source, manual, or both.
Only tabs, no magic words. Plain and simple.
Is it OK, any corrections?
|
Sure, but I am not sure whether something like such plan is very important right now.
I mean, yes, we plan to produce more docs. We plan to implement better ways how to access it.
IMO, both 1. and 3. are already "initiated".
Mirek
|
|
|
|
|
|
| Re: Documentation and Topic++ [message #13041 is a reply to message #13038] |
Thu, 06 December 2007 21:05 |
zsolt
Messages: 696
Registered: December 2005
Location: Budapest, Hungary
|
Contributor |
|
|
| Novo wrote on Thu, 06 December 2007 20:05 |
| Mindtraveller wrote on Wed, 05 December 2007 12:19 |
Is it OK, any corrections?
|
Documentation in source code would be very handy.
One line per method (at least).
|
Current (separated) type of reference docs is very useful, I think. Some time ago I prefered doxygen docs of sources, but now, I don't care about it. The only problem is this tabbed help. Previous (windowed) version was better for me (using Alt+TAB is more easy, than clicking mouse). So I'm using online HTML docs currently.
Maybe it would be useful, to create a separate help viewer window or application with an "Edit" button, to allow editing topics, like in a wiki.
|
|
|
|
|
|
Goto Forum:
Current Time: Fri Apr 19 02:02:28 CEST 2024
Total time taken to generate the page: 0.02972 seconds
|
|
|
Members
Pages
Help
Register
Login
Home
Just need time to collect arguments for the thing I feel subconciously. )
