This week I’ve been hard at work trying to twist and break and squeeze and pull and mold the udder of the Mootools JS component into a shape that works for the needs I plan to be using it for…
I swear, I’ve pulled on the teet of this damn cow enough to know that I needed to stop trying to milk it for all that it was worth and start looking at it from the inside. So I put my bucket away and grabbed a scalpel, but making tiny incisions to see what the code inside this cow were doing wrong wasn’t enough so I put the scalpel away and pulled out a big fuckin’ knife. And with this big fuckin’ knife, I hacked away at the flesh, ripped apart the skin, and found out an issue with this thing that I didn’t previously know: I should’ve put it down first.
That is to say, I should’ve put down the idea of how this use of the code was supposed to work first before I offered the idea to my client… except for that I showed what Mootools was capable of doing before I’d seen their logo… and the logo was the problem.
Allow me to explain.
The logo in question has a series of columns that aren’t evenly matched in width, but because Mootools has some nice uses in menu navigation, I thought I could work out a way to include something like either the [url=http://www.phatfusion.net/imagemenu/index.htm]slide-menu[/url] or the [url=http://www.chrisesler.com/mootools/fisheye/fisheyeVersion2.php]fish-eye menu[/url] based off of this logo… and it was after fiddling with every part of CSS, PHP, HTML and the Mootool.js pieces of code for about 4-7 hours that I realised the following: there was no way I was going to win.
Don’t get me wrong… Mootools and JavaScript engines like it — Prototype, jQuery, and Script.acu.lo.us among others — are very good and allow you to do some very cool things within AJAX and the whole Web 2.0 revolution. I’ll even go through my list of open tabs so you can play around with some of the cool things you can do yourself (aside for the things I’ve linked to already in this blog entry).
Why there’s cool webpage aesthetics options like [url=http://web-graphics.com/mtarchive/001717.php]bubble tooltips[/url], [url=http://www.artviper.de/ImageMenu/]gallery menus[/url], [url=http://www.silverscripting.com/mootabs/]mooTabs[/url], a [url=http://www.snap.com/about/shots.php]SnapShot[/url] of links, a [url=http://zend.lojcomm.com.br/]whole bunch of nice projects[/url] like a carousel image gallery, an [url=http://ecosmear.com/relay/]AJAX directory manager[/url], and [url=http://www.schillmania.com/projects/35mm/]another cool gallery system[/url].
While not [url=http://www.mootools.net]Mootools[/url], I’ve got a great example of a Web 2.0 application with a Google Talk applet running on the right-hand-most column of my page if you scroll down to it.
And what about Modal Boxes… Modal Boxes are boxes that will pop-up over the web page, sort of like a pop-up but a lot more stylish with more control and nowhere near as bloody irritating. You’ve got a choice of modal boxes including [url=http://www.e-magine.ro/web-dev-and-design/36/moodalbox/]MOOdalbox[/url], [url=http://okonet.ru/projects/modalbox/index.html]ModalBox[/url], and the [url=http://orangoo.com/labs/GreyBox/]Grey Box[/url].
Feeling overwhelmed by the moo-iness of it all? [url=http://clientside.cnet.com/wiki/mootorial]Try the Mootorial![/url]
Why stop there when you’ve got a variety of a demos of a variety of menu options to choose from like [url=http://interface.eyecon.ro/demos/fisheye.html]Fish-Eye![/url], more [url=http://makemesmile.free.fr/labs/ajax/]Fish-Eye![/url], still yet [url=http://www.chromasynthetic.com/blog/wp-content/uploads/2006/09/mootools1.html]more Fish-Eye![/url], and even a very cool [url=http://www.quietlyscheming.com/blog/components/fisheye-component/]Adobe Flex version of… wait… can you guess it? Fish-eye!!![/url]
And if none of that was enough to impress you, how about [url=http://www.dotes.com.br/mootools/mootools_link_list.html]an AJAX-infused page of Mootools links![/url]
Yet even with all of these cool abilities, these JavaScript classes that power this nifty web applications still all seem to suffer one irritating flaw that crept up on me while I was trying to get the logo’s column divisions to work:
[b]They all work from a mathematical point of view where everything will be equal.[/b]
I’m probably wording that wrong but I don’t know how to describe it in any other way.
I’ll try it this way: the classes allow you to create menus and lists and based off of the amount of items in those lists, the code will create a set width that provides an equal and uniform division for each said item.
But this is useless to me. I need to be able to control my widths because [url=https://www.leighlo.com/random/images/2007/05-EdgeHS.jpg]this logo[/url] doesn’t have uniform widths.
Unfortunately, none of the tools can cater to this for me in any whatever form I use, whether it’s Fish-Eye or the Slider Menu.
I can set it up to [url=http://www.edgehs.com.au/testbed2/imagemenu3x.html]look like the logo as it starts[/url] (and you can see this example / problem in the link made just behind this bit) because it’s pulling the information as to what the widths are supposed to be from the CSS, but the moment anyone tries to hover over the menu and then move their mouse away from it, it starts to call upon the code in the JavaScript and that code tells it to collapse inwards and make something equal for all parties involved (by parties I mean of course the menu elements).
I expect that this is all mainly due to the problem of the code working in a mathematical manner and I don’t have a problem with that as that’s what it was designed to do. I have also tried running the menu items outside of the CSS Div tags to see if I can control them in a table: this expectedly fails. For the Fish-Eye, I’ve tried making various cells [i]unlinked[/i] and just basic images, but this either doesn’t seem to work or causes the Fish-Eye menu to just skip over them completely.
I’m not a brilliant coder so I won’t even attempt to re-code Mootools to work in the fashion I’d like to use it for. However in case anyone comes across the need for [i]a lack of uniform sizes[/i] in their menu system, be aware that until some sort of choice system is put into place within the Mootools framework, you’ll be stuck not getting it working.
Although if I can be proved wrong and someone can work out a way to get these sorts of width issues working within the current framework, I’m more than happy to hear your comments, thoughts, and ideas on this.
I can understand your frustration. Sometimes it is best to take a step back and see if there is another way to approach the problem.
First you state issue with Mootools and its inability to handle non uniformed sets, this is a complete misunderstanding of Mootools and Frameworks in general. Mootools doesn’t solve these problems, it never was designed to do so nor will it ever be. It is a framework for developing js code that is not only elegant and beautiful but f#&!ing fast!
To help clarify I believe your discussing the inability of some of projects that were built with mootools. This is the key. Mootools was never designed as an end product. All those project you listed are from developers that actually created something from scratch using mootools.
This might be a bit of an ego blow, but you sold yourself to the client as a developer yet when it comes time to develop you just want to use someone elses code? What you want to accomplish can be done with MooTools. I know, I’ve done it.
Sorry to continue the rant, but FishEye has be around for a while it was a proof of concept. However I have yet to see it in production use. It’s just not extremely practical and has a lot of usability issues. Did you express to your client that they were going to be adopting bleeding edge unsupported code that you didn’t write?
A very easy way to deal with your problem is to extend the class. Take a project that has a lot of functionality and create a wrapper class that handles your needs. This way you don’t need a scalpel or a big knife. You just add what you need and your done. However this would require understanding how the framework and having an intimate understanding of javascript/object oriented design and object scope (closures).
Not trying to bash you, but you were misappropiately bashing my beloved mootools. Be honest with your clients, let them know your limits this way you will have a realistic expectation and no one gets hurt. More importantly be honest with yourself.