I'm building a church community site that is "two sided"...one side is 'public' (ie. it's where new people would go to find out about church beliefs, worship styles, etc) and the other side is 'community driven' (not private, but the church community interacts here, posts events, has online groups, etc). Both 'sides' of this site have their own main navigation menu...they reside on a single database.
This is fine and dandy until you have to write URL paths for content (which, by the way, will be shown on both sides of the site). Most content (events etc) should 'reside' on the community-side of the site (event listings, etc) but much of this stuff will display on the 'public' side. So, imagine going to the public site and you see an event listing...you click on it to view the details. Two things happen:
1. You're directed to the 'community' side of the site (which maybe you didn't even know existed)
2. Your main navigation menu changes and you have no idea why (because you don't understand the '2-sided site' concept is happening.
How do I remedy this horrible usability issue? If content is listed on the public side and to visit that content means visiting that community side (thereby having your main nav change without explanation)...how do I keep from confusing the visitors?
- Is it as simple as putting up a short message telling them what happened
- Do you just have a huge back button?
- For this one reason do you not 'host' that content on the community side?
- Do you do some kind of script-fu that keeps the menu the same if they're coming from the public side?
Share with me your genius solutions....
I think that if you have to
I think that if you have to display a message to the user explaining to them your site's architecture, it's probably not very good architecture. :) Seems like something you'd see in Windows ("We're hiding your toolbar items, but defeating the purpose of it by showing this annoying dialog box instead").
Will community members be logging in? If they do, then you could use the $user variable to decide if they're visitors or not. If they're a visitor, they always get the visitor styles / menus, but if they're logged in they'll get the 'community' styles.
I think this is a winner!
First off, let me say you're dead on with "if you have to show a message, your architecture sucks" comment...almost. It's not really a problem with the architecture, it's a problem with siteflow/usability (which is what I'm trying to work out here). But, I totally agree...I sorta thew that in there as an extreme option.
Second, I think testing for the community users is a good start...mostly. I think there's issues here that are hard to explain such as the need for a community nav whether you're logged in or not...but this got me thinking in a good direction.
Thanks for the input Daniel!
-Rob Feature
Geeks and God Co-Host
www.mustardseedmedia.com
Question too hard for a Friday afternoon
That's just unfair. ;-)
Some thoughts. If I'm understanding you correctly, the menu changes based on your location in the site. So you have a menu set up, and a view that is showing the user some events, but when they click for details, they're taken to the event node, which resides in the context of the other menu.
My first thought is to make the click target another view, and never actually show the node to the user. Or maybe I'm over-complicating and it can be the same view, and just changing node arguments gets you to the details. Either way, if they never leave the view(s) designed for external users, they never leave the menus for that part of the site, either.
On the other hand, if you're doing the normal setup where your menu is displaying as a block, then why not have one menu block that's visible only to anonymous users and one visible only to authenticated users? In other words, base the menu on the user, not their location navigating the site.
That's the best I got this late in the day, but hopefully it'll trigger something for ya.
Micah
RE: Site Architecture Quandry
I would put the content on two pages. One on the public side and one on the community side. Design the page on one "site" and copy the page and give it a url on the other site.
Too many nodes
I briefly considered duplicating content, since it seems better than directing them to a confusing part of the site...but that's just going to yeild too many nodes, so I think that's not really an option on an active site like this.
-Rob Feature
Geeks and God Co-Host
www.mustardseedmedia.com
a new window
Create a list view. When additional details are required, present them in a new window. -NP
Start With A Storyboard
I'd start by forgetting that you're building a drupal site. Start with a story board of the path users will take through the site. Don't think of URLs or any of that thing first. Create a storyboard starting from the homepage.
Lead you visitors through the site but give them options. Think of it like a choose your own adventure novel. They choose a path but the next part of the adventure is laid out for them.
For members you may want to have it automatically redirect to the community area if they are logged in. In this area make it like a little village. The community homepage is like the town square that leads you to the different parts of the site.
As for the menu, have one for the community side and one for the visitor side. That's 2 menus to run the site on.
If a computer of an account first comes to the community part of the site have a block with a message telling them what's going on. Once they dismiss the block (some kind of button) it's gone for good.
When it comes to events and general things like that consider having a URL structure that's something like /event/[year]/event-name. This is generic enough that people will understand what's going on and yet still usable as a link on the visitor side of the site. Keeping with this convention would be URLs that are [type]/[some info like year]/[name].
Thoughts?
Matt Farina
Geeks and God Co-Host
www.innovatingtomorrow.net
www.mattfarina.com
It's the URLS that are the issue...
I think maybe you're not understanding the issue...let me try again:
Site flow and user flow isn't really the issue here. I know exactly how users will navigate the site, and by analyzing that is why I came to this issue. When you boil it down, the issue is 100% urls. Why?
So, these are all path related...so there's no use thinking anywhere else. All nodes must reside under a path in the architecture..so either they'll be on the main site (at the / path) or the community site (at the /community) path. This means that they WILL have a menu associated with them (either community menu or main menu)....and THIS means that we much choose where they reside. It makes the most sense that they'll reside on the community side since that's where all the more interactive style nodes are appropriate.
So, maybe all this takes me to one thing: how we determine which menu shows. I still think testing for something other than URL may be the case. Is it possible to test where they came from with php?
-Rob Feature
Geeks and God Co-Host
www.mustardseedmedia.com
In D6
In drupal 6 you can tell where it came from.
Also, if you use breadcrumbs well (some custom setup) the url doesn't necessarily need to reflect where they are in the site because the breadcrumb can tell them that. It's a different visual aid for the same purpose.
Matt Farina
Geeks and God Co-Host
www.innovatingtomorrow.net
www.mattfarina.com
How would that be done?
This sounds like the ultimate solution to me....if I could say "if they come from anywhere except /community/* then give them the main nav, not the community nav.
How is this done? Is there a hook that handles it? Would it be done in a module or in template.php? Hook a brotha' up with some additional info on how this happens in D6...
*edit: just realized this would ideally be done in the block visibiilty box using PHP....is there a variable I could test there to see where they came from?
-Rob Feature
Geeks and God Co-Host
www.mustardseedmedia.com
No Variable
There isn't a native variable to check. Just the hooks into the system. You could install eatons clickpath module. and then get the most recently visited locations from that using the function clickpath_get_paths().
Matt Farina
Geeks and God Co-Host
www.innovatingtomorrow.net
www.mattfarina.com
How about referer_uri()?
Could you use referer_uri()? This returns the $_SERVER['HTTP_REFERER'] variable which should be the fully qualified url of the page from which you came (i.e. http://...). It should always be populated as long as you followed a link and didn't come from a bookmark or manually type in the url.
Guess you could code something similar to:
if (preg_match('/\/community\//', referer_uri()) {[community nav]
} else {
[main nav]
}
(Note that this should be less sloppy since it looks for /community/ anywhere in the url and not immediately following the hostname.)
Another Good Suggestion
This is another way to do the same thing. Good suggestion.
Matt Farina
Geeks and God Co-Host
www.innovatingtomorrow.net
www.mattfarina.com