June 1, 2004
"active" navigation
Recently, I utilized Tabulas to allow one of my clients to update their website ... they update their Tabulas and then it updates the website using the RSS feed.
The first time we tried it out, I watched the client try to add an entry. He logged in with no problem. But the moment he saw the first page (with the "Add an Entry" option) ... he sort of just froze there. He then proceeded to click "Add an Entry" (which takes you to the exact same page as when you first login) then he wrote out his test entry ...
It bothered me that he would have to click "Add an Entry." He did this not once, but twice. Apparently due to all the clutter, he didn't notice that going to "Add an Entry" takes you to the exact same page.
I came to the conclusion after some thinking that "links" in the navigation need to become disabled if you're on that page. It becomes far too confusing for the average use when they "think" they're on the 'Add an Entry' page but still see the link sitting there on top, daring them to click it.
The new control panel had no differentiation between "active" links and non-active links. None. The sub-navigational bars on the new CP were hard-coded into the HTML.... so they would always remain links regardless of if you were on the page or not.
So back to the drawing board for me. I needed a function that would: get the full request uri and compare it to the list of possible sub navigational elements. If the current URI and the URI of the subnavigational link matched, then it would display it. I originally thought there would be a problem because I have a penchant for using $_GET elements to separate PHP pages into chunks (like prefs.php?account and prefs.php?email) ... but luckily within the $_SERVER predefined superglobal ... there resides $_SERVER["REQUEST_URI"] which tells you exactly the requested URI ... so a simple string comparison was all that I needed.
But what if do something on a page? It'll redirect you to another URI which would "break" you out of the subnavigational consistency (e.g. you'd see the subnavigational link again!). Solution: Do a quick regular expression of the link that needs to be checked with the $_SERVER["REQUEST_URI"] and see if it exists within the requested URI. The problem here is that you'll need to keep your $_GET elements in order ... and I also need to go through and restructure my PHP files to take advantage of all this lovely stuff...
So what's the moral here? I've decided that if you're on a specific page, that link should become disabled on any navigational element.
It sounds so simple and obvious.. harumph. Feel like I've wasted time doing this.
But now it's another more small detail to add to the list of why the new CP is much better than the old one :)
The first time we tried it out, I watched the client try to add an entry. He logged in with no problem. But the moment he saw the first page (with the "Add an Entry" option) ... he sort of just froze there. He then proceeded to click "Add an Entry" (which takes you to the exact same page as when you first login) then he wrote out his test entry ...
It bothered me that he would have to click "Add an Entry." He did this not once, but twice. Apparently due to all the clutter, he didn't notice that going to "Add an Entry" takes you to the exact same page.
I came to the conclusion after some thinking that "links" in the navigation need to become disabled if you're on that page. It becomes far too confusing for the average use when they "think" they're on the 'Add an Entry' page but still see the link sitting there on top, daring them to click it.
The new control panel had no differentiation between "active" links and non-active links. None. The sub-navigational bars on the new CP were hard-coded into the HTML.... so they would always remain links regardless of if you were on the page or not.
So back to the drawing board for me. I needed a function that would: get the full request uri and compare it to the list of possible sub navigational elements. If the current URI and the URI of the subnavigational link matched, then it would display it. I originally thought there would be a problem because I have a penchant for using $_GET elements to separate PHP pages into chunks (like prefs.php?account and prefs.php?email) ... but luckily within the $_SERVER predefined superglobal ... there resides $_SERVER["REQUEST_URI"] which tells you exactly the requested URI ... so a simple string comparison was all that I needed.
But what if do something on a page? It'll redirect you to another URI which would "break" you out of the subnavigational consistency (e.g. you'd see the subnavigational link again!). Solution: Do a quick regular expression of the link that needs to be checked with the $_SERVER["REQUEST_URI"] and see if it exists within the requested URI. The problem here is that you'll need to keep your $_GET elements in order ... and I also need to go through and restructure my PHP files to take advantage of all this lovely stuff...
So what's the moral here? I've decided that if you're on a specific page, that link should become disabled on any navigational element.
It sounds so simple and obvious.. harumph. Feel like I've wasted time doing this.
But now it's another more small detail to add to the list of why the new CP is much better than the old one :)
Comment with Facebook
Want to comment with Tabulas?. Please login.
departed
roy