Okay, it looks shiny but I'm concerned about a few things :
hovering the highlighted item after leaving the menu makes the items wobble again
you should use a UL LI A #text for the markup of the menu/navigation. That what navigations are : a list of links.
I hope you'll overload the window.open( this.href, '_blank' ) by an "AJAX" call. People hate popups.
moot point, but speaking of "AJAX", the loadpage() event handler should also check for a status code 0 in case the content is cached ( I know it's no gonna happen in your case )
bad browsers such as IE6, will fire an HTTP request for each background image swap. Replace them by CSS sprites. Changing the background position is fine.
you should not attach a mouseout and mouseover event handler on each and every navigation item but just once on the div#menu . This is a bajillion times more efficient and elegant than creating an 2 anonymous functions and event handlers for each navigation item !!!
you should really stay away of setTimeout( "someCode", delay ) and similar calls. These create a new JavaScript context to parse "someCode". It costs memory and CPU time. Prefer setTimeout( aFunction, delay )
limit the number of setTimeout( foo, delay ). Browsers are not multithreaded and allocate time to the JS engine every X ms ( 10-20 on desktop ). Firing many setTimeout( foo, delay ) will produce a burst of CPU usage.
following what I just mentioned, I must say that the fadeIn( foo ) method is gonna kill any slow-ish machine/device. It's crazy, I count 98 !!!setTimeout( "someCode", delay ) + of course 2 more fired by fadeOut( foo ). This is crazy.
Animations should NEVER be done with a bajillion of setTimeout( "someCode", delay ) or setTimeout( aFunction, delay ). Firing many timers is gonna hurt the memory and performance. And using hardcoded delays makes the duration of the animations depend on a specific speed. This is doomed to ruin the user experience on any machine/device significantly slower/faster than that of the developer.
Always prefer having a single setInterval( updateAnimation, delay ) and define your animations' duration in ms. This way, they will run at the same speed on any machine/device.
I guess that's enough for now. I should really jump in the shower and head to work.
From what the code I saw, I think you'd benefit from reading things by John Resig, Chris Heilmann & co. These guys really know their sh*t.
I like except for one detail. When you mouse over a section that is already expanded, it shrinks a tiny bit and then expands again. Great, but if you happen to mouse over the very top or bottom of this section, the interface goes postal. That is, as the already expanded section shrinks, the surrounding sections expand and are thus triggered, but then the original section expands again, and it goes back and forth for a bit before reaching equilibrium (and when equilibrium is reached, it's not the section you originally moused over, it's the one adjacent). It's rather hard to explain, but it's simple enough to see. Just expand a section, move the mouse away from the menu, and then mouse over the expanded section toward the very top or the very bottom.
I would get rid of the shrink/expand when mousing over an already expanding section. The highlight is enough feedback, I think.
Firstly thank you for the pointers. And I love shocking poi this way
And I LOVE theory while we're at it :
quote:
following what I just mentioned, I must say that the fadeIn( foo ) method is gonna kill any slow-ish machine/device.
I am on a REALLY sluggish machine, trust me, and it works like a charm. But I will apply all the tips except one - for the time being, what mattered
was making it work at all costs, even if abusing the threading, even with ugly hard coded crap - yes of course the window open will go.
You should read the "origin of species" on adaptation
The only thing that I don't understand is :
quote:# you should use a UL LI A #text for the markup of the menu/navigation. That what navigations are : a list of links.
Why? Why would I - require - a list for a navigation?
---------------------
EDIT : fixed three of the issues, (mouseover/mouseout problems namely)
Regarding the general speed, animation and threading point : try your page on Wii, mobile phone, a PDA, a USD 10,000 computer ... I'm curious to see the memory and CPU usage on small devices ... well, that is, if they don't OOM.
Why should navigation use a LIST instead of a bunch of DIV ? Because navigations are a list of links. They are not abstract structure containers. It is more logical and semantically correct. The HTML 4.01 spec says:
quote:The DIV and SPAN elements, in conjunction with the id and class attributes, offer a generic mechanism for adding structure to documents.
quote:HTML offers authors several mechanisms for specifying lists of information. All lists must contain one or more list elements. Lists may contain:
Unordered information.
Ordered information.
Definitions.
Using a list or divs makes no difference for styling or authoring, so why not doing it right and use a list where a list is the logical and semantic option ?
Just to keep notes as I progress through optimisations :
quote:
FIXED :
# hovering the highlighted item after leaving the menu makes the items wobble again
# bad browsers such as IE6, will fire an HTTP request for each background image swap. Replace them by CSS sprites. Changing the background position is fine.
# you should not attach a mouseout and mouseover event handler on each and every navigation item but just once on the div#menu . This is a bajillion times more efficient and elegant than creating an 2 anonymous functions and event handlers for each navigation item !!!
MOOT :
# I hope you'll overload the window.open( this.href, '_blank' ) by an "AJAX" call. People hate popups.
# moot point, but speaking of "AJAX", the loadpage() event handler should also check for a status code 0 in case the content is cached ( I know it's no gonna happen in your case )
TO DO :
# you should use a UL LI A #text for the markup of the menu/navigation. That what navigations are : a list of links.
# you should really stay away of setTimeout( "someCode", delay ) and similar calls. These create a new JavaScript context to parse "someCode". It costs memory and CPU time. Prefer setTimeout( aFunction, delay )
# limit the number of setTimeout( foo, delay ). Browsers are not multithreaded and allocate time to the JS engine every X ms ( 10-20 on desktop ). Firing many setTimeout( foo, delay ) will produce a burst of CPU usage.
...Now how do I go about passing arguments to a function I call through setTimeout? I know the third parameter for setTimeout in Mozilla,
but how do I do that in IE?
One: You don't. Why would you anyway in the case of an animation since you obviously have an object managing the animation(s) that knows what to animate and when it started, etc ...
Two: You use closure / anonymous functions, or curried function. But I have NEVER needed to curry a function for a setTimeout.
Ok, it works a bit better now. I still need to use a timer to fix those setTimeout issues, and it turns out I want to identify
the index this way (instead of using LI).
In the future, I want to map rss documents to this interface, by converting news into index "pannels" -
and the channel header into a "welcome page" of sorts.
So, basically, if this interface is used against simple html to html/php links, it will load target pages by embedding them on the fly BUT
if it encounters html -> xml/rss links, it transforms the rss and respawns the interface with a new index & welcome page.
Don't worry if itsn't clear yet to you.
quote:I still need to use a timer to fix those setTimeout issues, and it turns out I want to identify the index this way (instead of using LI).
You don't. Trust me. The key thing is:
quote:Always prefer having a single setInterval( updateAnimation, delay ) and define your animations' duration in ms. This way, they will run at the same speed on any machine/device.
Make an animation manager or whatever to know what and when to animate. Then all your fadeIn() and fadeOut() functions have to do is poke a couple of variables in the animation manager and voila.
Thanks poi, but what I'd need much more is a hand in the site reviews - it is the Doc who first thaught me how to wrap my anims
in one single timer, and I wasn't talking about that bit in my latest post : I was talking about the UL/LI bit which I have tried.
Since I want to load whole rss articles in the menu panels, div seem to fit.
And yes, Jestah, completely inspired by that one : it is the color scheme I was using which reminded me of that page,
which in turn brought me to an "hey, why not" kind of epiphany.
Other than that, nothing I can add to this...well over my head at this point Except to reiterate that for a list of navigation links, a list most certainly the way to mark it up!
{{edit - Argo posted while I was...
For the record, a LI element can hold a div quite well, if additional content is needed. But it still ends up being a list
argo navis: Sorry I really thought you meant to show the RSS feed/items in the content panel, not in the nav. Then I wonder how much info you want to fit into that narrow panel. Tell me you yust want to show the headlines there, and the actual content on the right hand side.
Side note : the implementation I posted above could be tweaked to set and use an attribute on the A or LI to get the _highlightIndex instead of crawling the elements, but that's less generic and it gets dirty. Also, idealy I'd clean the UL of of any parasite #text surrounding the LI and use (_navigation.children||_navigation.childNodes).length to get the number of items so that the navigationThingy is completely live and LI elements can be added/removed at any time.
Well, I love the dedication to helping : but I am not going to tell you anything more For two good reasons -
(1) I have yet to figure out the best way to use rss to feed this interface, one can think of many different and reasonable
uses. And (2) you're way too fast to react indeed and I wouldn't want to use too much your time
For the record, it actually happened this way : see color scheme, think of an interface than could sit nicely on top of the xml layer,
cram script, fiddle, randomly, test, debug, come up with first "draft", post... the rest is history, right here in this thread
And of course, I am using Doc's page as a model : it is brilliant, might as well live in real world.
Glad to see many DO remember. On to some nightly debug.
For the record : spent roughly 8 hours on this thing so far, and I got rid of the parallel timeouts
- mostly. All is now embedded into one much nicer interval. One bug to fix and I am done with this part,
leaving 4 setTimeouts for the background anims AND the div instead of LI, which will be useful down the road.
Next scriptic part for this project : a good looking slider.
Just an observation ... every time I move the cursor from one tab to another the lowest tab (Contacts) rises a little bit and then lowers ... the problem seems to be that expanding is slower than contracting so many irrelevant tabs get moved around...
edit: Right now your menu just feels wrong While Doc's version feels right.
quote: poi said:
Animations should NEVER be done with a bajillion of setTimeout( "someCode", delay ) or setTimeout( aFunction, delay ). Firing many timers is gonna hurt the memory and performance. And using hardcoded delays makes the duration of the animations depend on a specific speed. This is doomed to ruin the user experience on any machine/device significantly slower/faster than that of the developer.
Always prefer having a single setInterval( updateAnimation, delay ) and define your animations' duration in ms. This way, they will run at the same speed on any machine/device.
Could you please explain why one setInterval beats multiple setTimeouts (each one fired after the other has stopped) a little more or were you talking about a situation slightly different than this?
Arthurio : don't take it bad, but comments like this..
quote:
Right now your menu just feels wrong
Are just as useful to me as how many noodles you've had for supper yesterday. Screencaps, for example, make such feedback MUCH more useful.
bottom line - giving feedback should be about "how the other guy can USE it" to be constructive. How can I use your feeling, if I don't understand it?
It's sad because with some proper phrasing, it would help a lot. (for example, since I have updated the page about 5 times and republished before you posted, I am NOT even sure which version your are talking about
- let alone understanding how you FEEL about it from this distance).
Understand also that Doc's approach is completely different (he uses px positioned layers and absolute positionning afaik, as opposed to % in my case, and relative positionning) also.
The trade is clear and simple : easier to maintain in my case, but I get to have to deal with liquid design challenges.
The similarity stops in that they both are brown elastic menus.
I also would like to point out that some advice can be negative even - like poi's desire to stroke a *right way* to do things as IF THERE WAS SUCH AN ABSOLUTE IDEAL.
The only "right" way, imho, is one that works as expected. Comments of that kind are both a helper, and a pain in the ass depending on how it is balanced :
I've been in IT for 10 years, poi is VERY FREQUENTLY recommending his way as the best.
Not only he makes me feel like he looks down on me - thank God I do not take it personal, but the above "quick sample" he whacked together is not exactly impressive,
nor is it getting the job done. It's clearly 5 miles away of a usable widget in the context where I need it.
That's why I always seem to be rejecting poi's feedback firsthand : all respect where it is due, but..
ALL I GIVE A DAMN ABOUT HERE ARE DESKTOP/LAPTOP BROWSERS, THE MAIN AND MOST RECENT ONES, AND HAVING THINGS WORK RAPIDLY SO I CAN BUILD UP THE REST.
LI has turned out to be the most obsolete thing in this case - 0 benefit for some wasted time.
And the single timer approach, while correct if I wanted to spare resources for display on a C64, is adding more constraints than it is helping SO FAR.
These are among the reasons why I didn't ask for poi's example when he offered it.
Now please, all of you who genuinely want to help me, concentrate your efforts on the site reviews where another important website for my business is getting
a lifting. And since I am done with updating the elastic part of my menu, feedback is relevant from now on - but make it clear, I don't have the time so sort
between "feelings", "impressions", "emotions", a thing for web standards, and all other things that I can't derive facts from.
Notice I didn't write a single a line of code until I saw Blaise's comment. If my example implementation is useful to at least one person, even if not you, well that's a welcome karma retribution.
Also the way I recommend is not mine. It's one shared by many front-end developers. Read people like John Resig, Chris Heilmann, Dustin Diaz, Douglas Crockford, ... It's a way that tries to address maintenability, accessibility, semantic, and performance. I have no problem with ditching any/some of these things for playground stuffs. But for anything supposedly "pro", nay ... it doesn't make sense to me, especially when/since there are simple and well known solutions to tackle them.
As for looking down on you. I'm not. However, I'm certainly more direct with you : because I know you can take it, and more importantly because I know you can do better.
[/slightlyofftopic]
Have you noticed that hovering the A tags fadeout navigation item ?
quote:LI has turned out to be the most obsolete thing in this case - 0 benefit for some wasted time.
And the single timer approach, while correct if I wanted to spare resources for display on a C64, is adding more constraints than it is helping SO FAR.
What didn't work with the LIs ? How does having a single timer add more constraints ?
Great way to alienate people who have been trying to help you argo navis.
You come across as an arrogant self absorbed person.
You have deceived or tried to deceive all of us from your very first post at the Asylum so I think you should be the LAST person to preach about the right and wrong way to post here.
I think you should tread very carefully, remember what problems you caused here in the past? They are not forgotten.
I don't see how this is supposed to be MY problem, for starters : it is YOUR memory that you want to hold on to.
I remember reporting clumsilly that an extra slash would open up doors to the back side of the Asylum - yes the way
to report it was clumsy, but I don't remember having done any actual harm in that regard. I remember other negative things,
coming from me, and ABSOLUTELY not relevant to anything you've just said.
I remember hundreds of people moronically picking up on the extra slash thing - without understanding any of the technical implications.
Wether you want to resurrect that trend or not is entirely NOT under my control,
and the above four lines are as much as you'll get from me here regarding the topic : like it? Don't like it? Don't threaten me.
And :
quote:
You have deceived or tried to deceive all of us from your very first post at the Asylum
A simple question, no judgement : are you on alcohol? Just to know if it's worth an extended discussion about THIS right now - I don't remember you around
at the time of my very first post. I remember I was a Mad Sci working my ass off to answer hundreds of questions on the other hand.
So how exactly have I "deceived" or "tried to deceive" you? I suggest you do two things about that :
wait until the vapors go, and open another thread where the flames you want to bring won't mix with tech talk.
Then, if the tone of my post sounds slightly agressive, it's because I know poi can take criticism as well - just as he took mine, without offenses
(so why do YOU feel offended). I absolutely see no point in using LI - and I wish I had received an explanation that makes more sense
in practical terms than simple conformism to standards : this is the tenth question where I am answered with tips that, in part,
are practical (hence the sincere thank you), and in part, confusing because based on trends that MAY or MAY NOT
keep evolving that way. Unless you are a js expert, what do you want to bring to the topic?
Oh yeah, threats. Anything smarter or more appropriate?
Give me a break : don't jump like a dog at the slightest "sign of potential maybe probably potentially maybe" negative reaction for me,
for fuck's sake I am human.
@ poi :
1) a single timer adds a little "sequence" constraint. I mean : I am forced to ensure divs shrink at the same pace as the main div expands,
using this percent based layout. Whereas the "concurrent" model was easier on the eyes and on the "control code".
2) The LI : I don't know. It may be that my styling was crappy, but I don't see LI for the purpose - the final panels
should hold a lot of informations, dynamically added AND ajaxed - ok, LI doesn't prevent me to do this. It doesn't help either,
and the page degrades the same way - but is not meant to degrade.
Your efforts are really appreciated, but BETTER in your taste won't help me meet any deadline - and those are tight.
Additionally, "more compliant with standards and best practices" doesn't always mean it works or will work.
Understand that I find myself posting "how does this work for you" and that it was all I was asking.
I don't mind going overboard A BIT for purity's sake, but will purism help me be on time for tomorrow,
and will it really help me in the long term to maintain my code? Do LI justify enough of a difference for me to spend the time?
If you have THAT sincere a will to help me, and I believe you do, then the COSA website does need purism and I have the time to afford it for that project.
If you're using (X)HTML for mark-up then you should use it according to its standards and rules end of discussion.
Why not just mark up your whole site using divs and spans in that case? oh hang on that's almost what you're doing, and the problem with that is that your code has no semantic meaning any more. What does that mean?
It basically means use the right tool for the job. Yes a DIV is a block level element for partitions and divisions in your content. but it is not there to support lists, you have a list, so the correct mark-up to use would be a UL with LI's.
Why? Because apart from other things it means that when you look at your code it talks back to you in a readable way. fine your browser won't have trouble rendering the difference between your styled DIV's and your list, but when you read your HTML you will know at a glance that you have a list there, and what it is for. It means you don't have to throw extra id's around as you can use the cascade to select your UL and this is also true with your JavaScript code.
Validators may not pick up on the difference because they validate the tags, not the content, that is the job of the developer, in which case I cannot validate your page.
Poi's comment about being pro is poignant, it's important to get things like this right when the eyes of the world and the Asylum are on you
[edit]
I feel you're looking at this through this issue your computer science eyes, and this is the problem, hypertext and mark-up are an art, and collection of tools rich in history from days of scholars and mad monks, to modern newspaper and magazine press.
So put your artist cap on, and have a bit of respect for those "mark-up men" of yore.
[/edit]
But it's not on the top of my to-do unfortunately : that's why I said I appreciate purism FOR FURTHER REFERENCE regarding this widget.
It's been three weeks without feedback about COSA in the server side forum, on the other hand, and that one is something I
REALLY NEED to make shine asap.
Now, why such an enthusiasm at giving me technical feedback about THIS widget instead - and why are people like Tao basically prone to lashing out at me
since the day he knew who I was? Helped him lots with his Ubuntu, he was all nice. Dared to say who I was, and witch hunt is on again.
No, seriously, this crap is bugging me for real : Hell I am going to carefully thread it where it is due.
[edit]
Your last edit makes a lot of sense : I think, indeed, I am not looking at it as anything but an application
[/edit]
Are just as useful to me as how many noodles you've had for supper yesterday.
Sorry for the bad explanation. I just stopped reading there because I don't have time to go through the whole thread right now.
The problem to me was the unnecessary movement. When cursor moves from one tab to another it would make more sense to me if only those 2 tabs moved/expanded/contracted in any noticeable way. Atm those 2 move and also all the tabs that are below the lower one move too. Also the animation isn't smooth.
edit: Btw "it doesn't feel right" is what you are going to hear from a client. You'll HAVE to accept that answer then even if you can't accept it now and it's better to accept it now. I used to work for tiny web development firms and I was in direct contact with clients. Clients most likely won't give you 2 screenshots with comments.
*throws trout away, eyes turning red because of the cackle, pulls White Hawk's straightjacket UP, then spins the poor inmate round and round for a while and
pushes him... Down the west thing*
Thanks. Use it anywhere you like
The concept is really simple. All menu elements have a property called 'weight' which can have a value from 1 to 2. 1 being the default. When a cursor is on an element the weight is slowly increased in 0.1 incrementations up to 2 and when not the value is slowly decreased down to 1. When changing heights the total weight is calculated and element's height = weight/total*100+"%".
Err ... it works only with Firefox ... Opera apparently doesn't support floating point percentages in css.
edit: switched to px ... works a little better now in opera
I'm in a library far from home so I have to make this brief, but be assured I'll get back to this when I get back home.
It is you argo navis/InI who came back here after causing problems DEMANDING that all your threads be deleted or else you were going to sue. Came back here with another name pretending not to know InI, in a decietful and manipulative way,
If you think everone here can just forget that, you are wrong. It would have been better to be open and truthful in the first instance.
Arthurio: I may indeed have occasion to use it in the future (or at least a modified version of it). If I do, I will definitely give credit where credit is due. Cheers!
quote:
It would have been better to be open and truthful in the first instance.
Tao, I am totally willing to adress your points, but for the sake of not mixing matters, I recommend the "witch hunt" thread in the Ozones forum,
which has been opened for that purpose : not having one more interesting thread polluted by emotionally charged exchanges.
Rest assured I understand part of your views and am willing to deal with it : in an APPROPRIATE thread.
AS FOR MY MENU : just to clarify the purpose, a bit obscure in the thread title - I had a meeting this morning where I had to demonstrate webdesign skills,
and wanted something a bit more "relaxed", pro, and a bit less "flashy" than www.beyondwonderland.com as it is.
Hence the QUICK and incomplete actions taken - and my reluctance at drifting too far from something that gets the job done : it did.
The meeting was a success and this thing played it's part.
On to my COSA 3d, a Java programming marathon for the next ten days until I meet the next, bigger customer.
And thank you for both the input AND the "turning this thread into a fun thing" and creating useful widgets.
Speaking about accessibility : all the while it kept working on all major browsers, as per my personal coding standards,
and quite frankly, what's left to fix is pretty symbolic as opposed to "getting it to work". I could use a day like today
(except that I've been up until daybreak working my behind off on Cosa. It will be a long week.
Coffee donors, please send some beans to my paypal account).
Have learnt, these past years, to start off as close as possible to my goals, and debug as the very last step.
Thank you and yeah, sure... I still see some jittering or something at the bottom, and there is a lot to improve - LI for one. Will get back to it.
Right now, I am stuck in COSA, building it up - a Java coding marathon of sorts.
Finally back to this. Aim of the weekend : being THROUGH with the COSA and the "me" thingies.
So, some tweaking later, I think it's better now, the jittering seems to be gone.
The items still fadeOut when the user hover the A tag inside the *cough* DIVs, and the links do not take the full size of their container making them a LOT harder to click as the navigations swings.
While I am getting gently started on four CMS/frontends at once, reviewed today, and one integrated in the whole stock control system of a store (meaning
I have to design and implement the stock control system in question) - but keeping time to prepare the core hardware/software demo of leading products including COSA
for the beginning of April, and around midnight tonight, there is the medical imagery 3d scanning project for which I will get the directions.
Right now, I am ending 30 hours of work in a row. *cough*
Last week, only COSA was facts, all the rest were words. Now they are paper, plans, code, and the nightly classes? Oh yeah. That, too.
In FF its very jumpy and jerky, when you click it loses the highlight which isn't great, and expanding the size of a menu items space seems pointless. The Doc did one a few years ago you might be able to find and take a look at.
Blaise, thank you. I'd be happy if we could preserve this thread free from flames now that all has been said and done, though,
it really is good the few drifts aside.
Hugh, thanks too, even poi for that matter : to Hugh, which OS? FF2/3 on WinXP here is fluid.
...It is now clear, though, that some of these flaws are due to avoiding the li usage in first place.
Are you talking about the Latest in iTunes thing ? btw their image replacement technique shows nothing when CSS are ON but images are OFF.
Oh my, this thing works so bad it hurts. I barely see any animation in FF2, FF3, Op 9.2, Op 9.5 or IE7. In IE7 there is a bunch of JS error fired in http://www.apple.com/global/script/lib/iepngfix.htc, Then the script seem to wait a bit to register the position of the mouse. It only seem to animate ok in Sf3. Quite a few times I was hovering the menu and got a submenu open while I was hovering the headline of another submenu.
Yeah, I would call that implementation vs. the one discussed here apples and oranges I don't find the implementation on the Apple site to be interesting at all - it is much like countless typical expanding list-menus out there.
Of course, extra space being needed for content will obviously make differences in implementation, but any way you look at it, a list - coded as such - is both semantically correct, and with the proper understanding easily achievable from a markup and styling perspective.
Oh? I am on Safari, didn't notice. There are really good things in Safari btw - backbutton warning when resubmitting a form for example.
Would much appreciate a break down of what they are doing wrongly about image replacement there,
but one thing they do correctly is that it is not the whole surface of "elastic" panels which triggers the "resize",
it's only the heading, and only onclick.
(which I fixed by taking the last div off of the shrinking mechanism - it's at maximum size all the time)
Poi's version is right in all regards (and works in IE8 and all browsers), except the transition is a bit "jumpy" when moving from an item to the next : http://poi.ribbon.free.fr/tmp/argo_nav/
posted 02-27-2008 03:25
I guess that's enough for now. I should really jump in the shower and head to work.
While 
