New Qubes Website! New Whonix Website?


Very interesting discussion going on here. I personally believe that we should let the user decide what they want as early as possible, so offering 3 options (like MDN kind of does) should be a good idea. I have designed a mockup here of how I envision it. The beginner option could be a page similar to the Elementary OS page I linked earlier, the FAQ one could lead to an relatively extensive FAQ and the last one would be the fully fledged documentation for power users (which doesnt mean it doesnt need to have good UX, we can improve that too there):

Let me know what you think. I believe we are on a good path here.


I like all ideas so far.

A quick start guide on a single page sounds good. Is this suggestion supposed to replace the sidebar?

I am open to replace our existing FAQ. To rewrite it from scratch. It got crowded and outdated over the years. It could become the old or wiki FAQ for historical purposes. The new FAQ would start fresh and only contain up to date frequently asked questions.

Videos are great! I imagine producing these would be a lot work.


Hey Patrick,

Yeah, it would replace the sidebar here. It might be needed in the full documentation though, but we can avoid the sidebar in the FAQ and Beginners guide too (althought it could be useful in the FAQ one).
Important is however to have an easy and accessible resource for Beginners and that should be covered well here I think.

I might help with videos if someone can record the screen and I can add my voice to it (I used to do tutorials at SitePoint.com)


Good day,

While I very much like the draft you’ve uploaded, I have to say that I maybe miscommunicated what I meant when I wrote about having a “Quick-Start-Guide”.

Obviously, a “normal” QSG is supposed to contain every information necessary to initially get a program/thing/whatever to work properly, not more and not less. This kind of information could easily be communicated on just one page, potentially even while staying under 500 words, making it easily digestible.

However and you are free to correct me here, I feel like something like Whonix needs more than just “how to run it” so a user is properly informed. After all, we are talking about software, which even people skilled in technology and with an extended background in Linux, sometimes don’t understand completely. If you look at my current draft, you may see (under “Chapters”) what I personally consider to be the topics any newcomer to Whonix should have a rudimentary knowledge of. “What is Tor, how do I verify images and which software can I use with Whonix?”, should be addressed in small, bite sized junks (maybe under 500 words and with only three sub-chapters?). A FAQ could serve this purpose obviously, though it would thus be quite long, which in some cases might lead to users not reading it at all and in others, might confuse/frighten them. Both states we should probably try to avoid. Having these topics split in small, bite sized junks will make them automatically appear less complex.

That a long FAQ, even when perfectly written, can be problematic can best be seen with “TheTorProject” itself. Their FAQ (https://www.torproject.org/docs/faq.html.en) answers most questions anyone can have, yet these questions are still asked (even on here), because people don’t like reading such long text, even when looking for specific information.

Now, you’ve said, a side-bar might be useful in the FAQ, though I would say that if we go “this route”, which would be fine by me, some way of quickly navigating to any point in it will be necessary. It mustn’t be a bar, though something needs to be there as, like I’ve suggested before, it would probably be rather long. The Elementary method works, because their pages are short, our FAQ, even when updated, will very likely be a bit longer.

So, here is what I’d suggest and you are free to critize it if you think it isn’t a good idea: The “Quick-Start-Guide” or whatever it will be called in the end, should employ a front page similar to what your sketch shows. To some extend it would look like the “Download-page”, currently found here: http://egobits1.github.io/download/ Now, on the left we have, as you suggested, a guide for people who just want to set-up Whonix via any way they like. It should be short, mention “Verification” and point to additional info. Nothing more though. Now the middle button though, instead of leading to a normal FAQ, which has “all the info” on one page, could be a step-by-step based approach, similar to what I initially proposed.

The advantage would be that people would be less overwhelmed with information at once.

The disadvantage? We still have the navigation problem. Placing the chapters over the text on mobile would force users to have to scroll furiously until they get to the text they want. Having it below would lead to people searching a long time before finding it. Having non at all would give us indirect control over their learning process, though finding what you want will be a chore. Using a drop down menu, like I suggested before, would work, though it wouldn’t look that good. Having a hamburger-menu is also not possible, as it again, forces people to search and as this menu would only be used for this one section of the website, would throw of users again. And, like I’ve said before, having everything on one site would force mobile users to scroll like crazy, make the whole thing seem more complex than it is and leaves the question for where to place navigation unanswered yet again. Quite the predicament to be honest.

One possible solution, if we settle on the “single page” FAQ, would be to do something similar to this: http://yanderesimulator.com/about/ Especially the fact that the search bar serves both to search, as well as a drop-down menu (when you click on it) and the fact that it autocompletes are aspects I like. However, as so many other nice things, this approach is based on JavaScript. Whether this is recreatable for me is thus the main question.

Either way, finding a way to navigate a long FAQ or this “split FAQ” is a necessity.

Now, to get back to my proposal, making the right hand button for an extended documentation is a neat and elegant solution to a problem/quandary I had, about how to link to the “long/proper” documentation. I wanted to simply have to buttons, one for the “Quick-Start-Guide”, one for the “proper documentation” in the top bar, but your solution is much cleaner and more efficient in that regard.

Now, regarding the question whether we will need a side-bar in the full documentation, that fully depends on whether we’ll continue using Mediawiki or going for an alternative. The Jekyll based drafts I had created all employ side-bars after all… For that reason, I’m still working on getting Dokuwiki to work as a Jekyll-sub-page. It’s playing a bit coy in that regard. Which is a shame, as customizing and translating it works like a charm and it doesn’t employ side-bars in the standard configuration.


Wow, Ego’s last post is quite overwhelming, still digesting it :slight_smile:

I agree with you on the approach as it was what I envisioned (FAQ was an example, but step by step might work just as well).
Can we implement a slidable sidebar like here?

What we could do is to implement a floating button on the site which would quickly bring the viewer to the top of the page upon clicking it. That’s the best solution here.

In the full documentation we can easily have a sidebar as we wouldn’t have all the content in a single page, right? The (sub)chapters would all be on single pages as I understand.


Good day,

Well, what would be possible without JavaScript would be something like this: https://designshack.net/tutorialexamples/sliding-content-box/index.html However, this carries the same problems a hamburger menu does, it doesn’t give the user necessary information upfront, means that users have to adjust to multiple control schemes in a short time and this kind of implementation wouldn’t work on phones, as it depends on hovering over the bar with the mouse.

Having a button which can “bring you to the top” is probably a good idea if the whole thing ends of being rather long and shouldn’t be hard to implement. That however doesn’t solve the question of how we are going to give users the ability to quickly navigate the topics at hand. It will however reduce the amount of scrolling after having read an entire page, which is why I feel like it should (if possible) be included.

I feel like the question of how we will handle the “long” documentation in the future should be answered after we have figured these key issues with the short one out, as a lot of factors will influence it.

Have a nice day,



Hey Ego

As for navigating through the “shorter” documentation, we could have the sidebar which would bring the page to the appropriate section. On mobile this can be on top of the page, so people can easily click it to get there. In combination with the hovering “get to the top” button, the viewer could easily navigate with minimal manual scrolling.


Good day,

That would be possible and one of the solutions I’ve written about a few posts ago, including the more negative aspects of this solution.

Obviously, the perfect solution doesn’t exist. So the question will have to be on which compromise we’ll settle. Personally, I’m fine with whatever is decided in the end (as long as it’s possible of course) and would appreciate any input we can get.

Have a nice day,



Good day,

Another question, we need to ask ourselves is how we should handle the “Installation-Guide” in conjunction with the “Download-Page”. What I mean by this is, whether clicking the “How to Install” button should lead to the “Download-Page”, which after choosing an OS starts a download and directs the user to the step-by-step procedure for said OS, or whether it should rather lead directly to the “Installation-Guide” and the “Download-Page” is a separate entity all together. Also, would clicking on the OS on the “Download-Page” then only start a download or link/direct to the “How to install” guide? And should we rather link from one page to another or automatically redirect? Both approaches have advantages and disadvantages…

To put it simply, questions upon questions…

Another question would be whether I’m putting to much thought into the way this whole thing is supposed to play out… Like written before, the perfect solution sadly can’t exist, so maybe settling on one which isn’t ideal but functional might be better…

Have a nice day,




I think that “How to install” should link to that very section in the Step by Step guide.

Let’s not mull too much over this and move a bit quicker and implement the mockups. I will continue work on them so we can implement them right away.


Good day,

You are definitely right. Got a little carried away. Am currently working on getting the front page you’ve designed online. The same goes for the font modifications and social media logos.

Have a nice day,



Good day,

So the front-page you’ve proposed is now viewable in a rudimentary state here: http://egobits1.github.io/wiki/ The pictures and the text are of course place holders as always. Also created a draft for the FAQ you may find here: http://egobits1.github.io/faq/# with a “Get back to the top” button and page jumps for easy usage.

Sadly, said button doesn’t seem to stick to the right hand site when using a mobile device. Will have to look into that issue. Also, I feel like the button should rather be a picture, than text. Maybe an arrow pointing upwards?

The next updates will mainly focus on me optimizing, improving and fixing my CSS, as it contains a lot of things which aren’t used anymore, but do in fact lead to me having problems with implementing the font-weight @elioqoshi proposed. On that end, a question would be whether every page should have such “light fonts” or just the homepage.

Have a nice day,



Ego - that website is looking great! Thumbs up to all involved :+1:


Hey Ego,

The website still needs lots of changes which I already proposed in my mockups. Let me know when you can implement then so I can suggest new updates. It would kind of not make sense to suggest new things now when the initial design elements are not implemented yet. Let me know how your schedule is :slight_smile:


Good day,

You are of course right there. I’m currently simply strugeling a bit with fixing certain issues I myself created in style.css… Is also why my last commits on Github where massive changes on that front. As I was unable to really iron out what keeps my design changes from being applied when using the original file, I’ve spent the last few days rewriting it from scratch which is quite a tedious task. Anyways, should be finished by wednesday if I don’t missjudge my abilities (as I usually do).

After that, like you’ve said, we can continue working on the improved documentation, translation, etc.

Have a nice day,



Perfect, just let me know when you need my input :slight_smile:


Good day,

So finally found time to include the proposed changes, had some stuff (both health and otherwise) going on, which is why it took me a little longer than anticipated. Luckily, the stylesheet shouldn’t be bothering us any longer, as it seems to have been cleansed of any mistakes, which (could) have lead to issues down the line.

However, I’m still not completely fine with how the site looks now, especially in regards to readability. Even with font-color black, some of the text is barely readable at this font-weight/thickness. Tried multiple solutions, non of them improved readability other than massively increasing the thickness (to the point we started out from). Maybe using a different font might be an option… Will look into some.

Will now start optimizing/fixing the html part of the site, as, if this is going to be used as I’m pressuming that isn’t going to be flawless either.

Have a nice day,


Whonix newsletter



Good day,

In that regard, what can be accomplished without JS is to create a php based solution, which simply sent each new mail address to a “receiver address”. From there, it would then have to be automatically added to a list containing every subscriber. Whether this is a viable solution would have to be discussed.

Edit: Just tried, isn’t possible with Github Pages, as they don’t allow php, only HTML and JS. Source: https://www.reddit.com/r/github/comments/2zhgbu/can_i_run_a_php_script_on_gh_pages/ Sadly, without either JS or php, I don’t see a way to “take” any user inputs and reuse them in any way…

Have a nice day,



Php and mailer is available on the whonix.org server anyhow.

We need also a verification mail before sign up (to prevent abuse). As
well as an opt-out blacklist. Not a super small project when inventing
it from scratch. I’d say, therefore low priority, follow-up task.
Hopefully we could reuse some existing code. But let’s discuss that in
the Whonix newsletter thread.