Conduct website UX review and develop action plan for specific website changes

[ninavizz]

The problem you're addressing (if any)

1. Qubes website does not currently present a clearly discoverable option for paid support for enterprise users.

2. Likewise, the website does not clearly enough manage everyday user expectations for what community-managed "support" looks like. Core team members regularly get questions emailed to us. Abuse is occasionally lodged at folks on GH and in forums, too—which for our generous volunteers, is not acceptable.

n°1 and n°2 can both be easily done with clearer positioning in content, and some IA tweeks.

Per offline discussion, creating this issue to document need to address this as time permits.

Describe the solution you'd like

I've researched and worked on these problems with previous gigs, so have some ideas for simple(ish) website updates. After I've wrapped work on the Policies stuff, I'll do some wireframes.

I'd like to also potentially add a level of sub-navigation to our existing website theme. Some dev help executing that, would be great, if the rest of the core team is on board with a proposal via wireframes.

Where is the value to a user, and who might that user be?

• Enterprise users with money: Find a clearly discoverable place to reach-out to chat about paying ITL to support you!
• Everyday users with imposter syndrome about engaging with the community: We're nice, come say hi! We also have a CoC, and hold folks to it.
• Everyday users looking for good customer service: (cough) being reminded what "Community Support" is, and that we'd all love to have a properly funded customer support department. And millions of dollars for other things, too.

Describe any alternative solutions you've considered

Today all of the above is written into the website's content. The problem, is that it's not written in a fashion that is readily discoverable—nor is it presented in a fashion that aligns with common patterns users may be looking for.

Additional context

nope!

---

Relevant documentation you've consulted

nada

Related, non-duplicate issues

negative!

[ninavizz]

@andrewdavidwong How scary would it be to just move a small amount of content from the Support page (only the "Support FAQ/steps to follow"), and the entire FAQ page, to the regular website(so, outside of the docs)? FAQ page, because .MD restrictions make it such a beast to usably consume in a web browser.

[ninavizz]

@andrewdavidwong Alternate thought: How possible would it be to not use MD on just the FAQ page's core page content (and instead use HTML/CSS), while keeping the rest of the docs in MD?

[andrewdavidwong]

@andrewdavidwong How scary would it be to just move a small amount of content from the Support page (only the "Support FAQ/steps to follow"), and the entire FAQ page, to the regular website(so, outside of the docs)? FAQ page, because .MD restrictions make it such a beast to usably consume in a web browser.

Would probably be fine.

@andrewdavidwong Alternate thought: How possible would it be to not use MD on just the FAQ page's core page content (and instead use HTML/CSS), while keeping the rest of the docs in MD?

Pretty undesirable but possible. The intro page is written in HTML rather than Markdown, so there's a precedent for an exception.

[ninavizz]

@andrewdavidwong Awesome!

I had already done mockup as a mitigation of today's confusing website-to-docs experience... by creating a stronger visual separation with a "real" breadcrumb in it (3-deep vs today's 1-deep). It is shown in the comment above (second image). Assuming that design change to the Docs header could be made, which would be the lesser of two evils for you: HTML/CSS/JS on the docs page (to enable to accordions), or a fully-separate webpage outside the docs?

Figma proto, for reference. No, accordions don't work in it, as Figma is not that fancy.

Also curious to get @unman and @svensemmler and @deeplow's feedback on this, too. As developers, developer users, multi-language-need peeps, and folks familiar with the community and end user needs. If any of y'all have questions around why any of this is being done, see Design Brief.

[SvenSemmler]

On 10/21/21 10:35, Nina Eleanor Alter wrote:

Also curious to get @unman and @svensemmler and @deeplow's feedback on this, too.

1) It is critical that the website is 100% functional WITHOUT cookies and JavaScript (with the exception of the forum). Many, including yours truly judge projects harshly by the way their websites are implemented: if I navigate to a site claiming to be about security or privacy and I cannot view it without JavaScript and/or enabling cookies, I know those people are not to be taken seriously. Optional and not externally hosted JavaScript is fine, while cookies are not under any circumstance other than me explicitly wanting to identify myself (e.g. to use the forum).

2) "About" should contain the Privacy Policy and CoC on second level. Unless I misunderstand what it links to, "Security Center" should either be under "News" or a top-level entry by itself, given that this is a security focused OS.

3) "Support" should contain the "Forum" as a second level entry. Yes, it's part of the community support, but it's the only option actually hosted by the project and it is arguably the main venue.

4) "Search" should be top level ... it's OK if it uses duckduckgo.com

On 10/9/21 19:47, Nina Eleanor Alter wrote:

Will need to adapt this with the help of a webdev, to "just show everything" as open, when no JS is present. Otherwise, Tor "Safest" users will be blocked from consuming content—which would suck.

This is an excellent test.

On 10/6/21 03:08, Andrew David Wong wrote:

It seems unusual to have "About" as the first item. Usually, it's the last, and it would typically have "about the project"-type content.

Fully agree.

On 10/11/21 19:45, Andrew David Wong wrote:

these things have been part of the branding for such a long time that I'm not sure what the ramifications of changing them would be. It might affect "brand recognition" and related things I won't pretend to know about.

My own first reaction to the prototype was that it looked "wrong". It didn't look like it belonged to Qubes OS. I cannot find any rational reasons other than that the capitalization and font. It also felt crowded, while at the same time showing less.

On 10/12/21 15:50, Nina Eleanor Alter wrote:

for translation—are languages then only triggered by IP location? Only confused, as I'd expect a languages picker/dropdown for when a thing is available in a different language.

Another pet peeve of mine: my IP doesn't mean anything at all (Tor, VPN, traveling ...) except where to send the answer to. Since the very start browsers have settings for the user to specify their preferred language. No guessing required... I told you which language I prefer.

-- public key: https://www.svensemmler.org/2A632C537D744BC7.asc fingerprint: DA59 75C9 ABC4 0C83 3B2F 620B 2A63 2C53 7D74 4BC7

[ninavizz]

Thx for all the rad feedback @sven! The main navigation updates (search + dropdowns) feel like a bit of a distant wish right now, unfortunately. :/

The three biggest priorities are getting the Contact Us and Help pages coded & added to the existing nav... potentially moving away from the font currently used on the website (Ostrich Sans) for legibility/accessibility/extend-ability reasons, and adding accordions to the FAQ.

The biggest things I need feedback on right now, are:

1. Which is the lesser of two evils for accordions: via HTML/CSS/JS on the Docs page, or removed from the docs and on the regular website? Caveat being that if it were to live in the docs, we'd need to change the Docs header (and IA somewhat) to something like the below, to more clearly distinguish to users that they're in a different experience.
2. Thoughts on the below proposed docs header/breadcrumb, below?
3. Thoughts on the replacement of Ostrich Sans, in the below?

Another pet peeve of mine: my IP doesn't mean anything at all (Tor, VPN, traveling ...) except where to send the answer to. Since the very start browsers have settings for the user to specify their preferred language. No guessing required... I told you which language I prefer.

Ehh? If I'm on a German VPN, I get websites in German. If I'm in Tor and my exit node is Germany, same. Maybe it's just that I'm a mono-lingual American and stuck in the mindset that the rest of the world accommodates my language, but I don't think I've ever experienced that browser setting.

Bigger picture tho, the question was more generally "Are languages served to users based on backend magic, without the picker?"

Like, it's a nit of my own when people refer to "Helvetica" as a font. It's not, it's a typeface. 12pt Helvetica 45 from Linotype is a "font," and all sizes/variations from a singular foundry are a "family." Gotta roll with one another's domain knowledge limitations, s'long as they don't produce erroneous byproducts.

[SvenSemmler]

On 10/21/21 14:59, Nina Eleanor Alter wrote:

1. Which is the lesser of two evils for accordions: via HTML/CSS/JS on the Docs page, or removed from the docs and on the regular website? Caveat being that if it were to live in the docs, we'd need to change the Docs header (and IA somewhat) to something like the below, to more clearly distinguish to users that they're in a different experience.

TBH, I hate accordions with a passion. The Whonix team uses a variation of them on their site to the point of making it nearly unusable. Accordions or "Details" views are fine to hide truly secondary / just for the record / going into extra depth kind of information. A characterization that hardly describes the answers on an FAQ page. It might also hinder searching over all answers with the browsers Ctrl+F feature.

What happens to the accordion when JS is disabled? Will it render like a normal page again with all the content visible? What do accordions do to people relying on screen readers?

I'd much prefer a design that has a TOC either at the top or on a separate page just containing the questions followed by or linking to a page much like the one we have today.

2. Thoughts on the below proposed docs header/breadcrumb, below?

You mean the "Docs Home / Using Qubes / Upgrade Guides / 4.0 to 4.1"? That looks OK, especially if clicking on e.g. "Using Qubes" brings me to that level.

Please excuse me -- I did read the whole thread multiple times and you probably have answered this before: Why is "Documentation" removed from the top nav????? That's literally THE MOST IMPORTANT PART of the entire website.

3. Thoughts on the replacement of Ostrich Sans, in the below?

It's OK, but I really like and got used to the current "branding". Why do we need to change it? You refer to "legibility/accessibility/extend-ability reasons"?

Ehh? If I'm on a German VPN, I get websites in German. If I'm in Tor and my exit node is Germany, same.

Here is the way it ought to be done: https://www.w3.org/International/getting-started/language

Unfortunately what you are describing is more and more the "de facto standard" and it's completely mindless. There are so many examples: people in the US more comfortable with Spanish, French speakers in Canada, Germans in the US getting a short English stub instead of the full German site ... my VPN gives me Swedish and Finnish IPs, so my English podcasts download with Swedish Ads inserted facepalm

These are all issues solved for decades and if anyone would actually bother reading the specs ...

(In case it has to be pointed out: NONE of that frustration is directed at you, you simply reminded me of it.)

-- public key: https://www.svensemmler.org/2A632C537D744BC7.asc fingerprint: DA59 75C9 ABC4 0C83 3B2F 620B 2A63 2C53 7D74 4BC7

[ninavizz]

Please excuse me -- I did read the whole thread multiple times and you probably have answered this before: Why is "Documentation" removed from the top nav????? That's literally THE MOST IMPORTANT PART of the entire website.

It is uncommon for "Documentation" to be at the top level in most analogous project website headers (cited in the Design Brief); and it is present in the fat footer. Technical users seek "Documentation." Non-technical users rarely know what to do with "Documentation." The docs are also at the top level of the "Help" page. If it's at the top level navigation, it needs to resonate with all users. Longer-term, I'd also like for there to be a sub-nav (probably as a menu) and the Docs would certainly be in that. When "Documentation" is at the first level, it can also be alienating to the users navigating imposter syndrome—and for how this project's community encourages and supports growth and learning, I feel it makes sense to move away from that.

The website is for a project overview; for everybody from individuals whom are Qubes-curious, business entities considering adoption of Qubes in an enterprise environment, potential large-sum donors, folks interested in learning about the project itself, to users looking for help and support. Again, all of this is summarized in the design brief, linked above.

(Ostrich Sans is) OK, but I really like and got used to the current "branding". Why do we need to change it? You refer to "legibility/accessibility/extend-ability reasons"?

One, a brand is a lot more than just a typeface—and I am in no way suggesting we change the colors, the "Q" icon, or the core presentation of the website. Brands also evolve over time, or become stale (and yes, as a curmudgeon this also annoys me, personally, but from a strategic perspective it is necessary for various reasons Capitalism has trained us into).

Ostrich Sans is an exceptionally narrow font, with an awkward x-height and counter sizes. The rounded terminal edges also contribute to obfuscating clear legibility—so all the aforementioned, compromise legibility. Legibility matters. Roboto Condensed is a much more legible but similar type family. Likewise, a type family's ability to be used in different ways a long page of content with hierarchies, is also important; and Ostrich is available in fewer weights and variations, making that harder—while also being outright illegible in all-caps at sizes smaller than ~18px.

Sven dislikes accordions.

1. When JS is disabled, yes, they'd all render as open.
2. A well-done accordion page will have "Open All" and "Close All" buttons at the top—as well as for each section—so folks put-off by accordions aren't forced into the pattern.
3. A well implemented accordion also works well for accessibility needs (screen readers, font sizes, contrast, discoverability, etc). I would never, ever suggest something be done to the website, that would go against A11y best practices. There are many reasons I'm not trying to hacksie these changes, myself, in a PR. This is high among them. I can "pull off" a lot of things, but have no idea how to do things well, to work with screen readers.
4. For users new to Qubes, and for folks unaccustomed to reading through hundreds of words to find an answer to a curiosity, the existing long-form format of the FAQ is untenable. Which is evidenced by people asking many questions here in GH and in the forums, and in direct emails, that are answered on the FAQ.
5. A majority of the human population will not read through thousands of words of content, to find answers for things. Many also don't even know the right questions to ask, so depending on a Search function is inadequate. We can continue to disparage those folks as lazy or unworthy of our special project, or we can help them with more consumable patterns.
6. When an FAQ is easier to scan and consume, it is a far more useful learning device.

L10 things

No disagreement from my end, that language selection should be more smart. Yes, a native Mandarin speaker in a primary-English country will likely know about the browser preferences thing and be set-up for that. Please also consider, that I have lived my entire live in an intentionally racist country that has resisted a bi-lingual society my entire life, despite the clear need for Spanish ubiquity. Much as my values desire different, my lived experiences of the world have been through a lens of what is normal, here, and knowing that most other countries are different—but having not ever lived in other countries, not knowing what that "different" is actually like. So, there is no need for hostility. I get and see that American society is a self-important and dumb-by-design mono-culture. Much of why I love this project, is because it is the opposite.

Anyway, pickers are still a good thing to have—if anything, to let folks know what languages an online resource is available in. Which is good information to have for many reasons: if you want another person to look at a website and you want to know if it can meet their language needs, if your preferred language is unavailable and you want to see what the easiest alternative is, or if you're trying to learn a new language and want to put your skills to the test.

Language pickers also present an organization's value of their global community in a fashion more technical users may consider "virtue signaling;" but I still find that declaration of an organization's values to be appealing. It's inclusive. Stating your intentions to be inclusive rather than exclusive, imho matters. To that end, accessibility matters a great deal, too—and I haven't even touched upon that (apart from wanting a more legible typeface). And as a nod to accessibility, I'm not proposing changing many of the .md pages to HTML, because I respect that developers want to read things in CLI terminals—and they are the primary consumers of those pages.

These are all issues solved for decades and if anyone would actually bother reading the specs ...

Yep. Same with gas mileage on IC engines. And non-coal energy creation. And yet, here we are. I raise you a toast, to humans behaving badly, and imposing the burden of adapting accordingly onto the rest of us, because selfishness is easier. And yet, people not RTFM is also in many ways my job security, and a never-ending point of intrigue for study.

[ninavizz]

This is a good accordion(USGov website). If we could use the multi-selectable accordion pattern shown here, without having to pull from a USGov library, I'd actually love that. Yep, it works w/o JS w/ all things open. Got the link from this website, which recommends it as a solid A11y compliant pattern.

[andrewdavidwong]

The biggest things I need feedback on right now, are:

1. Which is the lesser of two evils for accordions: via HTML/CSS/JS on the Docs page, or removed from the docs and on the regular website? Caveat being that if it were to live in the docs, we'd need to change the Docs header (and IA somewhat) to something like the below, to more clearly distinguish to users that they're in a different experience.
2. Thoughts on the below proposed docs header/breadcrumb, below?
3. Thoughts on the replacement of Ostrich Sans, in the below?

I think the discussion so far has surfaced the main pros and cons on both sides regarding these points. I don't have much to add. Regarding (1), without taking a stance on accordions, I'm guessing "removed from the docs" would be slightly easier, but it depends on how everything gets implemented.

[ninavizz]

I understand and respect that our most technical users won't like the accordions. What I feel needs to not be overlooked, however, is the fact that the accordions are not being recommended on pages those users frequent.

Even among technical users new to Qubes; the docs are beyond (beyond!) thorough, and technical users have more cognitive capacity & patience to wade through docs, than the less technical or quickly-curious users do. Which we know, partially because it's an established paradigm in UX, and partially because so many overlook today's FAQ to ask questions it answers in other channels.

Prioritization and inclusion both need to balance each other out. No solution(s) will be perfect. As the design brief states, the goal with this work is to help the project grow its userbase so that it can increase revenues*, to increase available resources to work on the project. Long term goals that will serve everyone. Our nerdiest users seeking a more versatile and stable Qubes, especially.

General ask to all in the continuation of this discussion: please read the design brief. I feel some questions and criticisms contradict its goals—and if the goals need to be changed, that is a different ask from requesting solutions tailored to its priorities be different. I appreciate that it's easier to just respond to the solutions, themselves. Solutions are all tailored to meet specific goals, however—so alignment on goals, will help facilitate alignment on solutions. Kind of like asking folks new to FOSS to read the docs. It's not the easiest path, but it will benefit all in the long run.

* Revenue increase goals ≠ making anyone rich; rather just getting more resources on the project to help it grow with integrity, and to better serve users.

[SvenSemmler]

folks unaccustomed / will not read through thousands of words of content

Which is why the collapsed accordion shows only the questions to ease scanning over them. Much like a separate TOC section or page that then links into the full page containing both, but without introducing the need for scripting. That way users without scripting enabled would benefit from the same design decision via a different (better?) implementation.

about living in the US

I feel this is somewhat inappropriate here. Sorry if I started without realizing it.

no need for hostility

???

-- public key: https://www.svensemmler.org/2A632C537D744BC7.asc fingerprint: DA59 75C9 ABC4 0C83 3B2F 620B 2A63 2C53 7D74 4BC7

[ninavizz]

Which is why the collapsed accordion shows only the questions to ease scanning over them. Much like a separate TOC section or page that then links into the full page containing both, but without introducing the need for scripting. That way users without scripting enabled would benefit from the same design decision via a different (better?) implementation.

Statistically, very few users are likely to have scripting disabled. Which I say having looked at Tor compatible design stuff A LOT for SecureDrop over the last several years, and user adoption of No Script. If fewer than 20% of users browse websites w/o Javascript I don't feel it's worth imposing a less user-friendly design that would have clear benefits for the other 80% of users, when graceful degradation is built in and that experience is still solid.

Qubes is also getting more and more "normie" users interested in privacy enhancing tech, because of things like the Facebook scandal(s) increasing normie awareness of privacy needs. Much as I dislike stereotyping, user profiles and "typing" users is helpful for making design decisions. The design brief clearly prioritizes expanding Qubes' userbase to support more normies, w/o alienating advanced users, as a goal. If that should be challenged, that is a separate topic than accordions.

With regards to the ToC pattern: It's a poor experience to see the answer separate from a question—and requiring questions to be repeated on "an answers" page would be a nightmare to maintain. With CSS and without scripts, the visual hierarchy of a page with H2 categories, styled accordion-headers, margin styles, linespacing styles, paragraph spacing styles, and text color styles, will all help ease consumption of the content and make it more inviting to browse, significantly.

I'm really not trying to shoot down your idea. I appreciate the idea a lot, and did give it thought! MD just offers inadequate page formatting options for establishing visual hierarchies on pages consumed in web browsers. Which, for long-form page consumption, is much less of a problem than for an FAQ. And, I'm also not proposing accordions that auto-close whatever was previously opened. The "yo-yo" experience sucks—and the specific pattern I'm recommending, is the "Borderless multi-select" pattern on this page—which nicely degrades w/o JS: https://designsystem.digital.gov/components/accordion/

Most FAQs are done with accordions. For the project's growth, I still feel rather strongly that a gracefully-degrading accordion outside of the docs (for general and "I don't yet have Qubes but am curious" users), is important to have. For inside the docs (contextual/topical FAQs) I agree with your recommendation on a ToC-style FAQ though.

I am going to add a "Do you disable scripting in browsers" question to the survey, tho, prompted by this discussion.

Below are some stats from the survey to-date, for reference against the concern of delivering a poor experience for users w/ scripting disabled.

[ninavizz]

...also, to just re-itterate an objective I don't want to see lost: I'm not wanting to change what Qubes is, or who Qubes OS serves at its core. Qubes' most hardcore developer/security/IT folk users, have been vocal about desiring more frequent releases, a more stable product, broader hardware compatibility, etc. All of that takes resources... and regrettably, resources cost money.

While I personally want to see Qubes improved for non-technical users, I also see it as a win-win to make the entire project more generally-accessible to a wider audience. More money is likely to come to the project, when at least a few of its touchpoints feel more in-line with mainstream consumer culture; and the website, is the most important of those.

The docs? Those are for end users, and also essential to be consumable on the command-line. At the same time, the entire core team—Marek, myself, everyone—is dead-set against accepting venture funding, or any funding that would compromise the core ethos and goals of Qubes. So, please know all of that.

The volunteers who do spend their time generously moderating the forum and GH, it pains me to see respond to redundant inquiries because n00b users couldn't find that information on their own. All of these things, have some happy-path common-ground solution opportunities I feel we're remis, to not at least try. In past positions, I've seen IA changes like this work wonderfully—and I'm cautiously optimistic, they can do the same, here.

[ninavizz]

FYI to those following this issue, I shared a prototype in #7005 that replaces the accordions on the main FAQ page with a TOC-patterned approach. Pls check it out and comment if so inclined!

[deeplow]

Gave some feedback on the prototype's home and overview pages here, on the help section here and here on the FAQ page.

Thanks so much @ninavizz for all your dedication!!! And do let me know if you need more feedback from me :)

[deeplow]

Just noticed something that may be important: discoverability of the documentation reduced significatly by not being shown on the nav. bar.

Prototype:

Current:

I know it's referred to in the "help section", but still. For such a large information resource it may need more visibility.

[unman]

If the proposed change to the navbar happens, Qubes will be closer to other distros, (Ubuntu, Arch, Suse). In the meantime it's a click away, like with Debian, and it's highlighted the paid support.

[ninavizz]

@deeplow Per @unman's comment, it aligns with other distros. Developers look for documentation; not many other folks. "Documentation" is against consumer mental models of "hand my answers to me on a silver platter with a fancy customer support team."

"Documentation" is a full column in the new footer, though, and the first section on the "Help" page.

The long goal for the nav, is for there to be a sub-nav with "Documentation" in the "Help" or "Support" primary; and only 3 or 4 primary tab items. Not wanting to venture down that specific IA rabbit-hole, in this issue.

But, to align with consumer-experience trained expectations of websites, I felt it made the most sense. Developers know to look for a thing in a footer if its not in a header, and its also the first H2 on the Help page.

The least-curious or willing to "do the work" folks, also take up moderation and email energy that design improvements like these can curb.

[ninavizz]

(the design brief in older comments, also covers more of the goals and intent with these things!)