Persistent navigation when navigating to parts of the site

rhines61 commented 9 months ago

Hi, The best practice for navigation is that it persists when users go from one part of the site to another. In the new iteration of the listening section of the site the navigation goes away except for a couple items. I'd be interested to know the thought process on the intent related to this implementation.

rhines61 commented 8 months ago

Is there a way to prioritize this one? It's a heuristic issue for users to help keep them oriented within the experience. Thanks!

paulcretu commented 8 months ago

Thanks for opening this issue, I agree that consistency is key. It's a bit extra complicated because the two screenshots you posted are two separate sites/projects hosted on different tech stacks.

The first is a Wordpress (PHP) site that @scottveirs manages. The second is the code in this repo (orcasite), running as a Next.js site.

The code/content for the Wordpress site isn't open source or publicly accessible. It can be modified but we'd have to work with @scottveirs to figure it out. I've never touched it so I'm not sure how it would go. This is one of the main motivations behind orcahome, which at some point will replace the Wordpress site, but there's plenty of work left before orcahome is ready to go.

However, we can easily make changes on the orcasite side. So, should we:

Modify the orcasite navigation to look like the Wordpress (quick but may require future adjustments)
Modify Wordpress to look more like orcasite
Modify both to something different/better (slower depending on how quickly we can decide and how easily we can modify Wordpress)
Leave as is until orcahome is released and replaces the Wordpress navigation (slowest, but less work long-term since we'll just do nav once)

Option 1 is quickest, but I know @UXBrendan has put quite a bit of effort into re-thinking navigation, which means we may want to modify both sites (option 3). These tasks aren't that complex, so not worth spending too much time discussing, but they do involve uncertainty. We could end up re-doing navigation a few times, but sometimes that's just how it is. So @rhines61 (and others) how do you feel between these options?

rhines61 commented 8 months ago

Thanks for letting me know. Maybe we can have a sync on this one - I think it's a good example for us to discuss regarding process and how we think about implementation so we're able to update or pivot as needed without things being super difficult to manage. I do think this is an important heuristic issue that could confuse users as described in the issue. Would love to sync maybe after the new year. Thanks Paul!

rhines61 commented 8 months ago

Hi Paul, hope you had a great holiday. I realized I hadn't responded specifically to your comments above. So I have more clarity on how things are currently set up - we have different code bases for different parts of the site? Or different code bases for different versions of the site? Let me know if we can have a meeting to discuss so I can have a better understanding of how things are set up currently, and how that might change moving forward.

rhines61 commented 7 months ago

Let's figure out who should be involved in this discussion... My recommendation is that we address this issue as a high priority since it's a fundamental heuristic issue from a UX perspective. I entered a question in the orcasite channel on slack to see if we can make some progress on this.

paulcretu commented 7 months ago

Thanks for following up @rhines61, I missed your last reply.

we have different code bases for different parts of the site? Or different code bases for different versions of the site?

Both actually (to make it confusing). There are two parts of the site:

1) Live listening site (https://live.orcasound.net)

Uses the code in the main branch of orcasite (this repo)

2) Landing/home page (https://orcasound.net)

Currently running on Wordpress (which we haven't written any code for, just content + customization, but we can consider it a "codebase" for this purpose).
In the future, Orcahome (orca + homepage) is supposed to replace the Wordpress site, so you could consider Orcahome to be "orcasound.net v2". Orcahome isn't ready yet, so for now there's a dev version currently running at https://orcahome.netlify.app/ using the code found in the main branch of the orcahome repo.

UXBrendan commented 7 months ago

@paulcretu @rhines61

To add to the discussion, I formed a global navigation UX team, and am finishing up the final design and research work before sending it to production for Release 2 of Orcahome. #ux-navigation

In the interim, I have had a global navigation designed for Release 1 of Orcahome, and have that sent to production. Resolves #127: Nav bar & Footer Release 1 Desktop Updates Completed

scottveirs commented 7 months ago

The best practice for navigation is that it persists when users go from one part of the site to another. In the new iteration of the listening section of the site the navigation goes away except for a couple items.

Hey @rhines61 it's possible that this whole discussion should happen higher up in the Orcasound organization on Github, rather than here within an orcasite issue, but I think it's worth offering a brief history that I hope will slightly adjust the terminology you use in the issue description -- "the site" and "the listening section" (quoted above). Perhaps along the way you can teach me, as a marine scientist -- not a UX expert or coder! -- what best practice might look like for Orcasound software more generally than how you've framed it here.

This history is a distillation that excludes many other valuable efforts that are more fully acknowledged in the Orcasound Hacker Hall of Fame:

2003: Orcasound.net is registered as a domain & we start a Wordpress based web site for Orcasound. This is what you call "the site" I think. (Live-listening happens with Winamp plugin creating the stream and various apps on phones and other devices playing it, especially iTunes.)
2018: Kickstarter funds are used to pay Paul and Skander to create version 1 of a new web app that makes it easy to listen on any device/OS/browser and inexpensively scale to 100s of simultaneous listeners. This is what you call the "listening section" of Orcasound.net (-- possibly because it is deployed via the subdomains live/beta/dev within the orcasound.net domain?)
2020: Mike Castor codes v2 of the live-listening web app
2021: Isabella, a Google Summer of Code student mentored by Paul, takes on challenge of creating a static site generator within Github to replace the ~20-year-old Wordpress site. She chooses to deploy her prototype via Netlify and documents her work in the orcagsoc wiki.
2022-3: Paul and Skander lead development of v3 of the live-listening web app

Throughout this history, I have been wondering if these three parts would grow into a single site (as I think you are suspecting) or evolve into two or more applications: e.g. a static web site to help organize and serve all Orcasound community members and a dynamic event-driven web app optimized for helping a single persona like "concerned community scientists" make an acoustic observation or take a conservation action as they listen to a natural event. I am still wondering if we'll have "one app to rule them all" -- possibly with a UI that is customized by user persona -- or an "ecosystem of applications" exchanging information -- each designed with a single specific user persona front and center.

What does best practice suggest in the latter scenario?

Related graphics to consider:

a 2022 "roadmap" that shows even more apps emerging in relation to the live-listening web app
Paul's schematic of a proposed new architecture for Orcasound's open source software, especially the concept of "presentation layers" --

rhines61 commented 7 months ago

Hi Scott,Yes, I’d like to have a discussion about this so we’re all on the same page. Let’s try to set something up.

rhines61 commented 7 months ago

Hey all... I'll give a more detailed response. But I think we'd benefit from a live discussion about this issue since it deals with information architecture of all the orcasound entities moving forward. It affects how we structure them (internally, and externally), and how we present them to users in a way that's intuitive, and explanatory.

Best practices should apply to the experience as a whole. The nav in this particular issue is a manifestation of a few best practices that generally apply to UX/UI - listed below.

As a user I want to be able to: • Know where I am (without having to guess or struggle) • Know where I can go (without having to guess or struggle) • Know how I can get back to where I was (without having to guess or struggle)

Intuitive UI helps achieve the above best practices related to users Consistency also helps achieve this...

A question I have is... What's the benefit (to us, or to users) of separating out the entities you've described above (rather than the entities living in an ecosystem like a website?)

This essentially is an information architecture issue: How are we structuring all the entities that make up our offerings so users can participate, and consume information in a way meets the needs of orcasound and our users.

Let me know if any of this needs more clarification... But I think it would help the discussion to get together on a video call. ;)

rhines61 commented 7 months ago

Let me know if we want to schedule a video call to discuss...

scottveirs commented 7 months ago

What's the benefit (to us, or to users) of separating out the entities you've described above (rather than the entities living in an ecosystem like a website?)

Good question, @rhines61 . Happy to have a call, but I'm also enthusiastic about recording this discussion in Github for others to ponder...

A similar over-arching question I'm asking myself is "Could a global navigation UI make the live-listening web app less effective?"

Here's why I'm asking that and how I'm starting to think about two potentially distinct types of web sites:

static sites like orcahome that present and archive content pages
web app that present dynamic content, like the increasingly event-driven live.orcasound.net

Web apps: -- designed ideally for a single persona (we have 3: new user, concerned community scientist, professional conservation scientist) -- in the long run, if live.orcasound.net becomes even more event-driven that it already is, then the ideal user experience might look quite different to what you described, e.g.:

As a user having arrived due to a live event notification I want to be able to: -- Listen to the live-streamed audio without performance issues or distractions -- Engage as a community scientist by selecting the REPORT SOUND button and describing what I'm hearing -- Interact with the app to build my empathy for the species making sounds underwater -- take a customized action through the app to conserve that species, If my engagement and empathy is high enough

Maybe @UXBrendan can confirm/deny, but I'm imagining that a similar "custom" user story may be in order for other "applications," like the OrcaLearn product.

Static sites: -- serving information to (and ideally designed for) the full suite of Orcasound user personas (probably greater than 10, including: volunteers and NGO hosts from 5-7 physical hydrophone sites; Kickstarter backers; funding Foundation managers; founders; open source software designers/developers/UXers; and web app users [all 3 personas]) -- For this type of site, the more general user story you provided may be more applicable:

As a user I want to be able to: • Know where I am (without having to guess or struggle) • Know where I can go (without having to guess or struggle) • Know how I can get back to where I was (without having to guess or struggle)

Maybe with static sites it's about intuiting how to navigate content to achieve your goal as a user (possibly very different from the goal of another user from a different persona) whereas with web apps its about intuiting how to interact or act to achieve the goal(s) the app was designed and built to achieve?

rhines61 commented 7 months ago

It's common that sites contain static content pages along with dynamic web app experiences within an ecosystem. To me the content and app experiences are connected within the ecosystem of orcasound. And various personas can, and will use different parts of the site. And people who come to the site may learn things they didn't know, may be interested in other offerings from orcasound as well. This is an established mental model for users based on existing sites we all use. So in that model there would be a global nav visitors would use to navigate the offerings within the ecosystem of orcasound (which is common practice).

I guess I don't understand how a global nav would detract from a user's experience in the listening app for instance. They would also be exposed to other educational information, and other information that they'd likely be interested in since they've already shown interest in orcasound and it's mission.

The experience that's live is contrary to best practices for the reasons I cited. • The UI doesn't offer information that helps users get back to where they were • The UI doesn't offer information that helps orient them in the experience • The UI doesn't offer information that would help them explore other content if they so desired

These apply to all personas, and all experiences, they orient a user within a given experience. As a user I want to be able to: • Know where I am (without having to guess or struggle) • Know where I can go (without having to guess or struggle) • Know how I can get back to where I was (without having to guess or struggle)_

rhines61 commented 7 months ago

The main point I'm trying to make is that whatever experience we serve users should be intuitive, and use best practices with regard to wayfinding. Let me know if that makes sense.

paulcretu commented 7 months ago

Just want to point out that there are two discussions here:

What are the boundaries between each "app" or "site"? Is http://live.orcasound.net a separate site/app from http://orcasound.net, or just a continuation of the same site?
Practical concerns of how to actually implement consistent nav/header (if we do decide they are the same site and want to have consistency)

I was addressing 2, but there's definitely a valid discussion to be had about the first point and it's probably larger than this thread

rhines61 commented 7 months ago

This is great Paul. Yes, I think it’s worth talking about how the experience works as a whole. Also getting us to think about these experiences from our perspective (the product team), and how users think about them. Looking forward to the chat. ;)

On Jan 21, 2024, at 1:46 PM, Paul Cretu @.***> wrote:

Just want to point out that there are two discussions here:

What are the boundaries between each "app" or "site"? Is http://live.orcasound.net http://live.orcasound.net/ a separate site/app from http://orcasound.net http://orcasound.net/, or just a continuation of the same site? Practical concerns of how to actually implement consistent nav/header (if we do decide they are the same site and want to have consistency) I was addressing 2, but there's definitely a valid discussion to be had about the first point and it's probably larger than this thread

— Reply to this email directly, view it on GitHub https://github.com/orcasound/orcasite/issues/285#issuecomment-1902776612, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGWQWBPJVLYXMFMHQZY3T2LYPWEEJAVCNFSM6AAAAAA76KLNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBSG43TMNRRGI. You are receiving this because you were mentioned.

orcasound / orcasite