Conduct website UX review and develop action plan for specific website changes #6835
Comments
ninavizz
added
T: enhancement
|
Related: #2324 |
andrewdavidwong
changed the title
ninavizz
changed the title
This comment has been minimized.
This comment has been minimized.
|
...oh, and also, research.qubes-os.org should become a proper thing. |
This comment has been minimized.
This comment has been minimized.
andrewdavidwong
changed the title
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
andrewdavidwong
changed the title
andrewdavidwong
added
T: task
This comment has been minimized.
This comment has been minimized.
|
Ok, first stab at this! Figma prototype here. If folks cannot access Figma, see bottom for ASCII version. Guiding Principles:
Why a sub-nav?A number of problems have been anecdotally observed over the past several months, that surfacing secondary-level navigation options could easily address.
Yep, a lot of what the above suggests, would involve architectural changes to how the website is structured. Between that, and @andrewdavidwong being the Community Manager (aka bad behavior corrector), his feedback feels most essential to guide this. (yes, Marek and others, too—but have pinged outside of GH to keep this out of usual GH workflows) @SaptakS I'd previously pinged you about thoughts on how to work within Bootstrap/Jeckyl to change the Qubes' website nav to include a sub-nav, as implied in the above Figma—executed as a new row of items below the primary row, and that remains visible when an item in the sub-nav or the main nav are selected... but not visible when the home page is what's visible. And, would obvs collapse nicely with the rest of the site's responsiveness, to a menu in mobile. Would also love to hear what @SvenSemmler, @holger, @deeplow, @unman and others whom are active with new users in the forums, think this. ASCII SketchBolded items would be in a row as primary nav items. Descending items would appear in a horizontal row just below the main navigation, not as a menu. In a mobile experience, they'd collapse to become a menu. About News Downloads Documentation Get Support Donate |
|
@ninavizz The navbar an homepage looks like a very nice improvement. Once issue I've always found with Qubes it's still a technical system. As such one likely will want to learn more about it, rather than simply download. However, the emphasized button is on download and install. I would argue that place should be for the "Intro page" (or a de-technicalized version of it) and then from the bottom (or side) of that page link to the downloads. Either way, the "Downloads" are in the navbar, so it's not like it's going to be extremely missed if not shown on the big blue button (:wink:) of the home page. |
|
Another small note, on the suggested prototype the Qubes logo changes from QUBES to Qubes. The logo change is likely unintended, no? (although I have to say your version looks more readable). |
Based on the prototype shared, I would say that it would need certain amount of custom CSS (and probably some JS) code, and won't work by adding few bootstrap classes. Also, even thought a non-JS fallback can be created for the above hover prototype, it won't be the best. Though, I think non-JS users can still visit the individual pages and have the navbar there (which won't involve any JS)
I am guessing you are thinking of an accordion-type collapse-expand behaviour in mobile? That should be straight forward to implement. |
|
@deeplow Yes, the "Intro" page that currently is there, seems more intuitive to move into "Overview" under an "About" menu... and also what would show should the user simply click "About" |
|
@SaptakS Oof. Yeah, as with SecureDrop, I'd prefer to not have any JS dependencies—and to do everything purely with CSS. All opened pages should have the sub-nav bar showing as a static asset, but then when hovering over primary-navigation tabs, show the respective sub-nav bars for those tabs. While I can see fiddling that up with hide/show Divs in CSS, how to do it to navigate well with a keyboard and screen readers, I don't know how to do. I found this, but the codepen is only for the sub-nav, not the full nav: https://getuikit.com/docs/subnav#divider-modifier |
|
I found a Jekyll "How To" page, and it explains how to do menus here: https://mycyberuniverse.com/jekyll-bootstrap-dynamic-navigation-highlighting-active-element.html With a 2-level Navigation (what they're calling what I have) here: https://jekyllrb.com/tutorials/navigation/#scenario-3-two-level-navigation-list I'm ok doing it as a menu vs as a bar, if that's the only options Bootstrap offers, fwiw. The bar would make things a tad more discoverable, but if kids today only use menus, so be it! |
|
Just created this alternate version w/ proper Bootstrap style menus: |
Yes! |
|
On Tue, Oct 12, 2021 at 01:49:02PM -0700, Nina Eleanor Alter wrote:
Would support.qubes-os.org be more inline with standards, or docs.qubes-os.org?
Whatever you like.
|
There already is one, but it's not live yet. Search issues with the "localization" label to read more about it. |
Ok, sounds fine to me. |
|
@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. |
|
@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? |
Would probably be fine.
Pretty undesirable but possible. The intro page is written in HTML rather than Markdown, so there's a precedent for an exception. |
|
@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. |
|
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
|
|
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:
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. |
|
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](https://en.wikipedia.org/wiki/Accordion_(GUI)) 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*
<rant>These are all issues solved for decades and if anyone would actually bother reading the specs ...</rant>
(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
|
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.
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.
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
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. |
|
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. |
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. |
|
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. |
|
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
|
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.
|
|
...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. |
|
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! |
|
Just noticed something that may be important: discoverability of the documentation reduced significatly by not being shown on the nav. bar.
Current:
I know it's referred to in the "help section", but still. For such a large information resource it may need more visibility. |
|
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.
|
|
@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. |
|
(the design brief in older comments, also covers more of the goals and intent with these things!) |
andrewdavidwong
added
T: enhancement
The problem you're addressing (if any)
Qubes website does not currently present a clearly discoverable option for paid support for enterprise users.
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?
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!
The text was updated successfully, but these errors were encountered: