Archive

Archive for January, 2010

My Personal Brand Identity Crisis

January 20th, 2010 No comments

I made the decision to migrate from urpisdream.com to marilynburgess.com, and completely abandon the Urpi brand. I have been grappling with my personal brand for quite some time.  I came up with the brand Urpi’s Dream in early 2009, after a trip to Peru, where I earned the nickname Urpi. I adored the name, and was eager to embrace it as a part of my online identity.

Fast forward a few months and you have me juggling 3-4 separate brands, and not being able to devote myself to any. Today my focus has next to deserted my Urpi’s Dream blog, and it’s brand. When I look at the old Urpi’s Dream blog, I don’t even get that guilty feeling that I’m neglecting something important to me. The content I intend to write on my personal blog is very dear to me. It is the personal brand, or identity that I no longer feel close to.

In the name of simplicity, I am embracing my name and my home as my personal brand. Marilyn Burgess from Vancouver, BC.

Put a handle on mooTools Drag.Move

January 12th, 2010 1 comment

In the next version of List Central the little popup form that enables the user to edit list items will be dragable so that the list maker can move it to where ever they would prefer to have it. It is a great little feature that really adds to the usability of List Central.

When I was implementing the dragable popup form feature I was pleased at how easy it was to use mooTool’s Drag.Move. My little form was easily moved to anywhere in the browser window, just as I intended. A problem arose when I tried to use the form inside the dragable element. The input elements of the form were not clickable, I could not get them to have focus, as if they were behind an invisible layer, which is actually what was going on. The form elements inside the dragable div they sitting in were not clickable, because they were dragable! Ack!

Happily I was able to find a solution for my problem: the dragable element required a handle.

The above image shows the Drag.Move handle in the upper right corner of the edit list item form div. You cannot move that dragable element unless you grab it by the handle, the move icon. Using a handle frees up the rest of the element for other clickable elements, like a form.

The JavaScript for including a handle in your Drag.Move element is as follows:

new Drag.Move('dragableDivID', {handle: 'dragHandleID'});

and the HTML, with some CSS:

<style>
.dragHandle{
    background:transparent url(/images/move.png) no-repeat scroll 0 0;
    cursor:move;
    float:right;
    height:30px;
    margin:15px 15px 0 0;
    width:30px;
}
</style>
<div class='dragableBox' id='dragableDivID'>
     <div class='dragHandle' id='dragHandleID'></div>
     <div class='dragableInner'> The content goes here</div>
</div>

In looking for this solution I found this great tutorial series by Consider:open called 30 Days of mooTools.  The entire series is very well done. Web developers at any level are likely to learn something new about mooTools there. Check out thethe tutorial on Drag.Move from the series that helped me out.

CKEditor on List Central

January 8th, 2010 2 comments

I am currently working on several improvements to the List Central interface, one of which includes the addition of CKEditor. CKEditor is a Javascript What You See Is What You Get (WYSIWYG) editor, which will make it easier for List Central users to include links, and text formatting in the list item descriptions.

ckeditor

I spent a great deal of time trying out different WYSIWYG editors for List Central. I found many neat ones, but CKEditor was the one that gave me the fewest headaches in integrating the editor into the highly dynamic interface of List Central.  CKEditor is a full featured editor that offers a wealth of features that are not needed on List Central, which makes the editor a little heavier than I would like, but it’s a fair trade off for an editor that works properly.

One thing that I didn’t like about CKEditor is the hideous dialog popup for adding links. It is aesthetically ugly, and offers far too many options. While I certainly wouldn’t be taking away the ability to add links in editor, I couldn’t keep the functionality the way it is, I’m far to picky to let something that looks like this:

to get passed me. Call me shallow if you will, but I had to make my own CKEditor plugin for adding links that would use the KISS (Keep It Simple Stupid) design principle and have the List Central asthetic.

CKEditor is still a young piece of open source software, and lacks proper documentation. Be careful with this, as CKEditor is the next version of FCKEditor, which is very different. Following the FCKEditor documentation is likely to lead you astray. I used the following resources around the web to figure out how to make my plugin work:

Happy plugin making!

Maintaining Dynamic Height on a Fx.Slide element with Mootools

January 5th, 2010 9 comments

List Central uses mooTools for it’s JavaScript framework. I love it! It makes developing in JavaScript a pleasure, with increased reliability, and nifty eye candy to play with.

I recently started using FX.Slide in the next iteration of the List Central interface. It lets the user open and close “sliders” (div’s with content in them) as they want them. Check out the < a href="http://demos.mootools.net/Fx.Slide">mooTools demo to see FX.Slide in action.

I had one little problem with Fx.Slide though. The problem was that I wanted to be able to dynamically add content to an Fx.Slide, changing the height of the slider div after it has been opened. To my dismay, the implementation of Fx.Slide set the height of the div to specific numbers in pixel to achieve the vertical slider effect. This means that any content I added to the bottom of the div after it was opened would not be shown. In order for the height of the slider div to remain dynamic, I needed the height to be set to “auto”, not a specific number.

I had to figure out a way to maintain the the div’s ability to change in height while still using FX.Slide. I did some fiddling in mooTools source to try to achieve the effect I desired. I changed where FX.Slide set the height of the div to “auto”. After trying it out, I was astonished that it worked! I had moved on to some other development when I realized that my change to the mooTools source brock the fluid motion of my slider. It now opened all choppy and jumpy. It was no longer pleasing to the eye. I had to put the source back the way I found it. I may have learned some about the inner workings of mooTools though the process, but really, messing with the framework’s source is a path to trouble.

As with many problems, this one’s solution didn’t come to me until I put the problem away for a while, and worked on other things. The solution then came to me, and like many other solutions, it seemed so simple, once I knew it.

The trick to maintain dynamic height on a Fx.Slide is to add an onComplete function on to the slider that sets the height of the slider to “auto” if the slider is open, like this:


var formSlide = new Fx.Slide('FormSlider', {
        onComplete: function(){
            if(this.wrapper.getStyle('height') != "0px"){
                // Check if the slider is open
                this.wrapper.setStyle('height', 'auto');
            }
        }
    }).hide();

That’s it! It works like a charm now, just as I want it to. So much trouble, for such a simple solution!

I expect that this solution would work the same on the width for horizontal FX.Slide’s, though I haven’t tested it.