[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [CONTRIBUTE] [DONATE]

New Qubes Website! New Whonix Website?

Do the colors have any significance? Will the Whonix brand include official colors?

Edit: Nevermind… Just saw posts on feedback thread.

hi,good job on the new site,and i’m liking elioqoshi image the best looks really neat and cool

Thanks guys!

@Ego maybe we can meet on IRC or another IM some time to work in real time?

Good day,

Sure, luckily I finished my entrance exame for university just now (literally 30 minutes ago), so I should have quite a bit of time in the near future.

Have a nice day,

Ego

Great! Hit me up on email: elioqoshI@ura.al when you want to work on it :slight_smile:

Good day,

So thanks to @elioqoshi, the site at egobits1.github.io is looking better with every day. The “lighter” font still needs to be added which will be done very “soonish”.

Adding to that, keeping this discussion in mind: splitting Whonix documentation into a short and long edition for better usability, I’ve added a small, Jekyll based Quick Start Guide to the site, which could be used to cover the essentials, you may look at it here: http://egobits1.github.io/wiki/ Does also somewhat play into this: mediawiki replacement

Both pictures and text are placeholders, obviously. For a simple introduction and to cover the most important aspects of Whonix such a design should suffice in my opinion.

Furthermore, I’m currently working on the translation solution for Jekyll. Should be presentable in the near future as well.

Have a nice day,

Ego

1 Like

I like it.

As for the Quick Start Guide, do you suggest to introduce a new sidebar that is visible on all Quick Start Guide sub pages or even the whole wiki?

Actually, the original reason to move from the default mediawiki skin to mediawiki skin strapping was to get rid of the mediawiki sidebar.

I still think those sidebars are wasting a lot space and are problematic especially on mobile devices. Unless I am wrong on that usability experience wise, I think these should be avoided.

Good day,

I can see where you are coming from and am able to agree on the space aspect, however the alternative would be to force users to click through dozens of sites before finding what they need. Was somewhat inspired by this: https://jekyllrb.com/docs/home/

Maybe a drop-down menu or a which may be called when needed could be a solution here.

Have a nice day,

Ego

I think I might understand where you are coming from and I guess you have a valid point.

Assumption: When users click the quick start guide they may wish to click through it page by page.

Now, when we had a quickstart documentation overview (similar to our current one, but much, much smaller)… People would click a page, read it. And then be stranded. Bad. They would have to use their browser’s back button to click the next page. This may not be good UX. With a sidebar, this might be better. Impossible for me to answer, I hope there is a clear UX designer answer somewhere.

Does that nail it?


What I find interesting is the backwards / forwards button feature of the Tails documentation. (example)

←System requirements | Features and included software→

It’s at the top and button of each and every of their documentation pages. I dunno if it is great at the top, but at the bottom I guess it is great. Happy to be corrected.

Good day,

If you look at the current draft, you may notice that I already included “Next >” and “< Back” buttons. The idea of that was, like you suggested, to allow a constant stream of information, letting users read the most important things in one go.

So maybe keeping these buttons, but replacing the bar with a drop-down menu may be a solution…

Have a nice day,

Ego

Hey guys, I’m catching up on this just now. I did some research on this and am still doing so.

First thoughts, this is a big no go:

I think Mozilla Developer Network does it really well here:

As you can see, it features a sidebar (which appear also on mobile). Mozilla has a great UX team and I believe they are doing their homework. This is some good material to use as a base.

I also like the getting started guide from Elementary OS. Very basic but perfect for people like me:

Maybe we can do both? I still believe we shouldn’t be scared of sidebars (better than hamburger menus definitely).
Also, the active section can be highlighted in the sidebar, like this:
http://zurb.com/patterntap/pattern/getting-most-out-footnote-0

Let’s discuss these and we can go on from there.

1 Like

Good day,

First of all, I have to say that I feel like, while the list used by Qubes on their documentation would be detrimental for something like a Quick-Start-Guide, I also feel that it does make at least some sense and serves a purpose when it comes to a “real/complete/long” documentation. It gives you the ability to quickly scan over every available article, to find what you need. It isn’t that pretty and shouldn’t be the default/first thing a user sees, but as an optional addition to make a wiki more accessible, gets the job done. What we actually use as the front page for our documentation currently (https://www.whonix.org/wiki/Documentation), should probably not be the first thing a newcomer sees/reads, but shouldn’t be removed for that reason alone.

Now, the Mozilla approach is interesting. Just like myself, with the Quick-Start-Guide, they move the bar with the main topic below the text, when in “mobile mode”. Works and preserves screen-estate.

The implementation Elementary used looks good as well. Making subtopics in a site “clickable” to link to them directly is a nice way of keeping a long page manageable. A combination, like you suggest would definitely have benefits. Making “Isolation”, “Safety”, etc on the first page, for example, clickable makes the whole thing appear more rounded.

I can agree that “hamburger menus” should be avoided, as they’d just make looking for a certain topic even more tedious, than such a task already is.

Now, I’d love using a side-bar like “zurb”, blending in and out once someone hovers over it with a curser. This though seems to be only possible with JS, according to my research. Now, as for making the current page highlighted, that will be implemented by me. Shouldn’t be to hard. Either by changing the color of the current topic or using pictures instead of text. Should have gotten that idea myself…

Have a nice day,

Ego

1 Like

I agree.

(Btw Qubes has a separate tour and getting started.)

Good day,

That actually brings up another thing I had in mind: Video guides

However, I feel like we should do it distinctively different to what the Qubes team did.

For one, the fact that “Getting started” and “Tour” are different entities despite the obvious similarities and overlap, reflects bad desing in my opinion. Adding to that, the length (over 30min) is far to great, to be easily digestible for a newcomer.

My idea would be, to create one video for every page of the Quick-Start-Guide, which contains no more, nor less information then the text, making no method superior or inferior and giving the user the feeling that, no matter how he likes his information, he’ll receive it. These should be under 5min, as to not overwhelm users. And they shouldn’t, like that’s the case with Qubes, be placed in a way that makes the average user think that the video is the only thing on the site. Because of the bar below it, I initially thought there wouldn’t be any information under said bar, just the normal header. A “Watch this as a Video” button on the site, which doesn’t obstruct the rest of the page, would be my solution for this.

Either way, having two so similar, yet different sections, that the average user might feel confused is a bad idea.

Have a nice day,

Ego

1 Like

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.

1 Like

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?
http://www.mobile-patterns.com/custom-navigation

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,

Ego

1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]