I did understand that earlier. 
I however discarded that option, because you said…
Well, if it was only as bad as auto expanded by default, that would be a compromise we could make. (Similar to the one with our existing mediawiki solution.)
I understood this as a deal breaker.
That seems very buggy indeed. A deal breaker?
Which could be super annoying if someone wants to copy something from an expanded area, no?
It’s looking great! I assume it would be trivial for you to make it hidden by default and expand upon click? Could you modify that example please to make two boxes hidden by default so we can test this?
Good day,
Ah, I see. Well, I can see why you see these things as issues, though let me clarify a bit which engines are problematic with such a set-up. The more severe issues, like messing up the base layout or collapsing at any click regardless of where it is made, should only be expected to happen on browsers like the Internet Explorer 8, due to its rather obscure implementation of CSS.
The persitence issue is however one which indeed happens regardless of browser, as shown in these small examples: javascript - Show hide divs on click in HTML and CSS without jQuery - Stack Overflow As you can see, most of the shown examples are plagued with this problem. The top one seems to work on Blink at least without fault. Adding to that, there seem to be other, more advanced approaches which, at least from what I can tell, seem to work much more reliable like this one: http://jsfiddle.net/thurstanh/emtAm/2/
Yes, would be possible easily as well, though this approach suffers from the “persitence issues”, whereas the last example I linked doesn’t making it a much better choice as a base.
Have a nice day,
Ego
Good day,
Regarding the previous request to show the two different, basic concepts for the Quick-Start-Guide:
The advantage of going this route is, as I’ve previously explained, that users get gradually thought everything neceassary to operate Whonix, rather than in one session, making the whole “ordeal” easier to digest. Arguments against it have been that this approach isn’t really of use considering users likely click" through the whole thing in one go eitherway since they want to use Whonix to its fullest immediately. Adding to that, finding what you are looking for might be harder than with an “one-page-solution”. However, I personally feel that a chapter based approach makes a project look better, though that is likely just me.
The advantages of a “one-page-concept” with click- and linkable subcategories is rather obvious. It’s easier to maintain, let’s users find information more quickly and efficiently and all in all is very similar to what we currently have on MediaWiki on sites like “DoNot”. Different to those however, to save screenspace, it was (at least at the time) decided against having the chapters on top or the site of the page. This might make finding your way arround as a newcomer harder. However, since newcomers should be reading the entire thing anyways, this shouldn’t be a deal breaker. Having one long, ongoing page also means that we should try to keep the information as focused, short and simple as is humanly possible, otherwise we (as I’ve mentioned in detail before) may overwhelm users with so much information that they wouldn’t want to use Whonix in the first place or (even worse) underwhelm them so much that they immediately presume all that information isn’t necessary and is already something they know. Both states we should avoid, as far as I’m concerned.
Have a nice day,
Ego
Ego:
The advantage of going this route is, as I’ve previously explained, that users get gradually thought everything neceassary to operate Whonix, rather than in one session, making the whole “ordeal” easier to digest. Arguments against it have been that this approach isn’t really of use considering users likely click" through the whole thing in one go eitherway since they want to use Whonix to its fullest immediately. Adding to that, finding what you are looking for might be harder than with an “one-page-solution”. However, I personally feel that a chapter based approach makes a project look better, though that is likely just me.
Since there weren’t any other opinions… And since we previously agreed
that sidebar is okay… Let’s go for that route.
Good day,
Ok, will copy it into the stable branch together with the new changes for the newsletter as soon as possible. Should I integrate the list’s headings and subheadings as well?
Have a nice day,
Ego
Ego:
Should I integrate the list’s headings and subheadings as well?
What do you mean by that?
Good day,
The small list which was create by @entr0py and can be found in post #31.
Have a nice day,
Ego
Post #31 for sure? There is no list in that post.
That is #31 btw.
splitting Whonix documentation into a short and long edition for better usability - #31 by Patrick
That list is fine for the sidebar, I guess?
Not sure about the sub headings. Any opinions?
Hi Patrick (and everyone else),
I think the headings and sub-headings are fine for now, if we want to imitate a ‘Tor Browser’ manual style short guide. Sweet and simple (the KISS principle).
As @entr0py progresses, it will become clear whether anything else is needed. I think the Qubes-Whonix vs Whonix separation I originally did may or may not need to be imitated, even in a short version.
I’m happy to edit this as entr0py nuts it out. I also agree this thread is far too long. So, I’ve started a new thread for the short version where only entries and suggested edits should happen. I’ve cut and pasted entr0py’s suggested ToC.
If we get our shit together, this might even get done for Christmas! 
For purposes of closing ticket ⚓ T521 simplify https://www.whonix.org/wiki/Documentation…
Is this subject considered done or is there something else to do?
Over 3 years old - just kill it off. It can be resuscitated later on if needs be.
Not exactly this but big progress was made.
