I’m a reader of Digg.com. What can I say? I like to hear the quirky stories sometimes and when I come across something intelligent, it makes me feel more like I’m learning. So when the new Digg was dropped into Beta testing, you bet that I was all over that. See some screen-shots after the jump.

Logging In

Connecting

Apparently not a single friend of mine is currently using Digg V4, no surprise there!

Usage

Bugs

– Update –
Another bug was discovered. When clicking to add a link to your account (like adding my website to mine), if you press after typing in your web address, the form does not submit. Instead the page refreshes and you lose your previous entry you typed in. The only way to submit the form it to actually click the button.

There is a very annoying bugfeature that I have found when using jQueryUI. It’s not the themes, they work great, in fact, they are the best thing since sliced bread. But in a ‘Cupertino.esc’ way, they provide too much simplicity over the functionality that I require. This post aims to solve that in a progressive enhancement sorta way. I am using jQuery 1.4.2. with jQuery UI 1.8.2, it doesn’t matter what theme you use with this, but I prefer redmond.

Let’s take a look at the core issue. Here is what a typical dialog looks like in jQueryUI 1.8.2 with some nice buttons.

Perfect example of a jQueryUI Dialog

Here’s the simple code for this.

<article id="dialogs">
	<a href="javascript: void(null);" id="dialogbutton">Open Dialog</a>
	<div title="this is my test this is my test this is my test this is my test" id="dialogtest">
	This is a div dialog test. This is a div dialog test. This is a div dialog test. This is a div dialog test. This is a div dialog test.
	</div>
</article>

<script type="text/javascript">
	$(document).ready(function() {
		/* Create a dialog */
		$("#dialogtest").dialog({
                        title: "Alert!",
			modal: true,
			buttons: {
				"Ok": function() {
					$(this).dialog("close");
				},
				"Cancel": function() {
					$(this).dialog("close");
				}
			}
		});

		/* Add Dialog Button Functionality */
		$('#dialogbutton').click(function(){
			$('#dialogtest').dialog('open');
			return false;
		});
	});

</script>

That’s really great, I mean that code is so small and yet you can get such a great looking item out of it. So how can I have a problem with that? Well let me tell you how the buttons are made, you have a name and then you have that name point to a function. The name is the text of the button, the function is the action of the button. And that’s it. Period.

Now, I find it great that I can use these simplistic featuresets and get ‘get by’ but normally my “Cancel don’t ever touch me button” is the color red(ish) while my “Oh you need to hit me to move on” button is the color green(ish). But you cannot do that (easily) with this current setup. In fact it’s very sloppy to force this setup into doing that and it ends up using a great amount of code just to do one thing, add a class.

To solve this, I did what any self respecting JavaScript ninja would do, I said goodbye to jQuery UI I opened up the source code and took a peek, found out where I could attack (fix) the code and I did it.
So before I show you the code, I will show you how I decided buttons should/could be made. My process is 100% backward compatible, yet more difficult and easier to mess up (the original goal of jQueryUI was obviously to make it as simple as possible).

Buttons with my code changes can now be made like this

buttons: {
	"Ok":  function() {
		$(this).dialog("close");
	},
	"Cancel": {
		action : function() {
			$(this).dialog("close");
		},
		type : "cancel"
	}

/* This is poor CSS by design to be simple and readable */
 div.ui-dialog-buttonpane button.cancel { background:none; border:0px none;color:red; }

and the old way of doing it will still work just fine as well.

I’ve gone ahead and added a few features, namely it is now name-points-to-object instead of the old name-points-to-function mentality. This object has two attributes: action and type. Action is the old function() that was pointed to and it will be called when this button is clicked. Type is the new feature on the block, it’s just a CSS class that is added to the function using jQuery.addClass. I’ve tried to keep is simple, and at the same time, make it robust and backward compatible. Here’s a simple change that is possible using this feature.

Now my dialogs can look like this when I want them to. This is a big usability thing (make the buttons descriptive, not just in text but in color/design and function).

So the secret sauce to all of this is actually an extension of the jQueryUI 1.8.2 Dialog code (more like rewrite of some of the code). This code can only be ran AFTER jQueryUI 1.8.2 has been created, otherwise you will get an error. I placed this code into the jQueryUI 1.8.2 custom.js file itself for easy keeping; just drop it at the bottom of the file.

/* TorchUI dialog button fix */
(function($) {
	var _createButtons = $.ui.dialog.prototype._createButtons;
	$.ui.dialog.prototype._createButtons = function(buttons) {
		var self = this,
		hasButtons = false,
		uiDialogButtonPane = $('<div></div>')
			.addClass(
				'ui-dialog-buttonpane ' +
				'ui-widget-content ' +
				'ui-helper-clearfix'
			);
		// if we already have a button pane, remove it
		self.uiDialog.find('.ui-dialog-buttonpane').remove();

		if (typeof buttons === 'object' && buttons !== null) {
			$.each(buttons, function() {
				return !(hasButtons = true);
			});
		}
		if (hasButtons) {
			$.each(buttons, function(name, fn) {
                        /* Begin the code change here */
			// Check to see if fn is being passed in as a funciton, assume it's an object if not.
			 	if(!$.isFunction(fn)) {
			 		var buttonclass=fn.type;var func=fn.action; }
			 	else {
			 		var func=fn; var buttonclass=""; }
				var button = $('<button type="button"></button>')
					.text(name)
				/* Add a class to the button, if there is a class */
					.addClass(buttonclass)
					.click(function() { func.apply(self.element[0], arguments); })
					.appendTo(uiDialogButtonPane);
				if ($.fn.button) {
					button.button();
				}
			});
			uiDialogButtonPane.appendTo(self.uiDialog);
		}
	}
})(jQuery);

If you have questions, please respond, I promise not to take them personally

jQuery UI is an amazing product. It’s not because it offers the best features, or that it offers the best solution, it’s that it offers a large degree of support for years to come. Which is saying a lot for something that is nothing more than JavaScript. It’s certainly something that many enterprises have begun to look at and look for in the development world. At my job at Coventry Healthcare, I’m responsible for the User Interfaces and generally the User Experience across some very highly visible web applications. One of the most recent developments in our line of business is the risk of not having an accessible site (we fall under Section 508 guidelines because of our Medicare/Medicaid users). jQuery UI has literally allowed me to very easily create and maintain large amounts of code so that I can spend more time making sure that it follows WCAG 2.0 and WARIA (which should cover us for S508).

So recently I discovered a very nasty bug dealing with jQuery UI dialog (withe modal:true) widgets that seems to only occur in Internet Explorer. It goes like this: If you are using a dialog with a screen reader, your main mode of navigation is with the keyboard. This is typically driven via the focus on elements. In jQuery, focus is demanded on the dialog because of the modal command. You are unable to focus on anything other than the dialog and it’s elements. Here’s the issue however, jQuery successfully can keep focus on the dialog in all browsers tested (FF, Safari, Chrome) so that the focus cannot leave the dialog. However in Internet Explorer (6, 7 and 8 ) your focus can get to the address bar, simply by tabbing to it. Once in the address bar, jQuery is no longer able to track and handle the focus, so inevitable, after tabbing through the menu, focus come back to the window. But instead of going to the dialog, it goes to the first element that can be tabbed to, which is undoubtedly BEHIND the modal dialog. jQuery, subsequently locks the tabbing at this point, most likely because you have focus on and element that is unable to be focused (in jQuery’s dialog algorithm).

So I cannot have this as that would literally cut 75% of my users from being able to use just a keyboard with the sites I’m maintaining. So I had to find a solution. First, IE seems to be the only browser with this issue and it has something to do with the fact that the focus moves out of the DOM’s control (out of jQuery’s control). But the focus would always at least get back to the first element that could be tabbed to, and then lock. So I devised a plan. What if the first element, when focused, looks for an open dialog and if it is there, focuses on that dialog? So I tried it out, like this.

$(document).ready(function() {
    $(":tabbable:first").focus(function() {
           $(".ui-dialog:visible:last :tabbable:first").focus();
    })
});

Amazingly enough, this is the exact solution to the issue. This is how it reads.

1. On page load
2. Get the first element that can be tabbed to in the body
3. When this element gains focus, check for a visible dialog
4. Take the visible dialog that is last (the last one drawn in the html) and get the first element that can be tabbed in it
5. give focus to that first element.

Now, in IE, when focus returns to the document, it goes to the dialog box, specifically, the close icon on the dialog box, thereby not breaking the fact that there a modal open on the page.

Now, there are some issues with this.  For one, the code is just assuming that the last dialog in the html that is visible is the one that is to be focused on.  Quite frankly, that’s what I need it for, as I try not to overlay dialogs, and when it do, the newest one is normally always on top.  However, there are times where you may swap between two dialogs, and the one that is on top is not the last dialog in the html, you would still have this issue in this case.  But for probably the other 95% of the cases, this is a clean and easy way to ‘fix’ the accessibility issue in IE with jQuery UI dialog modals.

Before you root, you should probably upgrade to 2.01, as that will ‘break’ your new root access. You can get that download from here, if you have not already received it OTA (Over the Air). You need to follow the directions below, to apply the 2.01. The directions for each download it exactly the same, except for the ADB access.

This ‘root’ is strictly for developers. It’s not going to give you any ability to do anything to your phone yet, unless you really know your *nix commands well enough not to screw something up on your phone. So continue only if you really want this ability (the ability to really screw up your phone).

You can follow the direct postings here.
I’ve downloaded the file (best link is here). You should also download this file, as it will be needed.

md5sum of the boot partition:
3e49d99b320cf5c20bedf09343c1155c /dev/mtd/mtd2

Here is the `how-to` that embeem posted, I will add to it where I see fit, just to help some of those out as to what is going on.

Download the zip file

You can find the link at the top of this post.

Rename to “update.zip” and copy to the sdcard

It is currently named `droid-root.zip`, `update.zip` is required as that will be used internally by the script in the program.

Power off the DROID and power back on while holding the X key
When you see a “/!\” symbol, press both vol+ and camera

This isn’t magic, it’s simply a rescue mode. Slide the keyboard out to start. It’s very easy to figure out what is going on here. You have to press and hold the volume Up key then press the camera button.

Use the onscreen menu to install update.zip

You must use your d-pad to do this. just choose update.zip from the menu.

Once installed you will be able to run “su” from your adb shell.

This one is the kicker, best explained by syntrix

you have to attach your droid in debug mode in eclipse and use adb from the sdk. Again, I’m holding off on this, it’s my only phone.

But once you get this access, you can run commands natively, and copy files to the sd and pull them off the droid.

ADB is only ran from the SDK developers tools. In other words, you are running command from your computer, not the phone.

Now, to take this a step further, we can also get a terminal emulator running on the phone with root access according to mjxg’s post…

1) download this: http://www.magicandroidapps.com/su.zip
2) push it to your phone

C:\Android>adb push su /data/local
595 KB/s (76200 bytes in 0.125s)

3) C:\Android>adb shell
$ su
# mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system
# cd /system/bin
# mv su osu
# cat /data/local/su > su
# chmod 6755 su

4) verify

# ls -l *su
-rwsr-sr-x root root 76200 2008-08-01 05:00 osu
-rwsr-sr-x root root 76200 2009-05-30 11:28 su

5) finish

# sync
# reboot

6) open up a terminal emulator on the phone and run `su` and enjoy

With all this said, this is a remarkable, easy root access. It literally is just adding a file (‘su’) that the user has permissions to. ‘SU’ means, switch user, and by default, that user is root. Giving the user access to this file, means they can run that command, and if that file has the right permissions, which is does in the update, it will run ‘as’ root. And tada, you can now begin to get access to the rest of the system!

Developers will now take over.

There is quite an interesting discussion going on at Jeffrey Zeldman’s blog concerning the @font-face syntax and how to make sure that it is working in all browsers. It’s interesting to see the different ‘hacks’ that are being put together for something that should be hashed out to work well in all major browsers. Why does this remind me of things like the wonky implementations being played out in html5?!

While recently using Scribd‘s services, I came across a very nasty bug, and a nice clean fix.  Scribd allows developers to tap into a great, but somewhat basic API.  One of these settings allows a developer to set a default ‘mode’ before the API then builds the flash calls necessary to display the document.  The issue comes up when you choose the ‘slide’ mode as the loading view.  No matter what ‘height’ you set, with ‘auto_size’ set to false, the height will adjust to the wrong height.

You can jump to the code here, or continue.

I started by writing some simple code that follows the API.

scribd_doc.addParam( 'mode', 'slide' );
scribd_doc.addParam( 'height', 800 );
scribd_doc.addParam( 'width', 600 );
scribd_doc.addParam( 'jsapi_version', 1 );
scribd_doc.addParam( 'auto_size', false );
scribd_doc.write( 'flash_catalog' );

Where ‘flash_catalog’ is the container div of the Scribd PDF.

This however led me to have a height that follows the default rules (width multiplier of 85/110) where the height matches how much space is in the window. So I progressed further with this code.

var oniPaperReady = function(e){
 $("#flash_catalog embed")
.attr("wmode","transparent")
.hide()
.css({"height":"800px", "width":"600px"})
.show();
}

scribd_doc.addEventListener( 'iPaperReady', oniPaperReady );
scribd_doc.addParam( 'mode', 'slide' );
scribd_doc.addParam( 'jsapi_version', 1 );
scribd_doc.addParam( 'auto_size', false );
scribd_doc.write( 'flash_catalog' );

So now I am dropping in a listener in the API to wait for the document to load. I then hide the ‘embed’ flash information, then add the height and width, then re-show the flash element.

You may notice, I’m using jQuery, in which you can do the same thing with regular JavaScript, although quite a bit more complicated (ask if you really really need that code).

An astute reader would also notice one thing, I’m not adjusting for an ‘object’ tag, only the ‘embed’ tag (the difference for flash between different browsers). I figured out this novice mistake while testing in Internet Explorer. Here’s the finished code, that works, removing the nasty height issue.

var scribd_doc = scribd.Document.getDoc( #######, 'key-*******************' );

var oniPaperReady = function(e){
$("#flash_catalog embed")
.attr("wmode","transparent")
.hide()
.css({"height":"800px", "width":"600px"})
.show();

$("#flash_catalog object")
.attr("wmode","transparent")
.hide()
.css({"height":"800px", "width":"600px"})
.show();
}

scribd_doc.addEventListener( 'iPaperReady', oniPaperReady );
scribd_doc.addParam( 'mode', 'slide' );
scribd_doc.addParam( 'jsapi_version', 1 );
scribd_doc.addParam( 'auto_size', false );
scribd_doc.write( 'flash_catalog' );

The final word; I’m adding the transparent mode so that I can then have a menu that drops on top of the flash. This works very well!

I find myself at a crossroads. I really like using jQuery, and I really like not having to write my own plugins as there are some really good ones out there. But I have run into a problem when it comes to a notification system. Let’s take a step back and discuss the purpose for a minute.

** Update 7/29/2009**
I now have a page dedicated to this at http://www.alldorks.com/wordpress/notify where you can also find the source code repository.

Within a website’s user interface you have common tasks. Of late, with ajax, overlays|dialogs|lightboxes have become common place. Usually developers will use these to replace their `alerts`, `confirms` and leave it at that. But what happens when a user does something and they need to be told “Hey, I got that and it was all ok”. So you simply make an `alert` and let them know. But then you have created this thing that they must read, click and then move on. Add that up, and a user that is moving right along, may have to do 10 clicks a minute extra. Or better yet, daily tasks are now incorporating clicks that are basically pointless. A better solutions is to open up a notification, not unlike what is found in OSX, Gnome and Windows. I’m talking about those little rounded popups that show up in some corner and then disappear. Those… are notifications, and have been missing from most websites that really need them.

So now you know what I wanted. A good looking notification system that is robust, adaptive, lightweightish, easy to work with, etc, etc. Well, I couldn’t find that. I did find mainly two that are out there, jGrowl and Gritter. Both are Okay, but I run into issues with both of them whenever I’m coding. Namely, what if I want multiple notification areas? That shouldn’t be that hard, but it becomes a nightmare to edit and maintain their code. Also, what if I miss the notification (getting coffee), how can I get it back? Finally, why is it so difficult to change how these dang things look! So I put my foot down and decided, “I will go it alone on this one”. I rolled up my sleeves and put my knowledge together to form a better notification plugin. I’m calling it “notify”, and I think it will quickly become a better platform for notifications.

I have a few things that I have been focused on:

• Multiple notification spots (middle, top-left, unlimited with css)
• Simple default notifications, completely customizable with options
• Support for Class A browsers minus IE6, with hacks later to work it into IE6
• Notification history manager, along with stickyness, and missed notices handling

The list goes on from there. It’s probably best to just play with the code, for now, it’s very raw, I will probably host a page on http://alldorks.com/ for it soon, along with a version control system to get the code from. In any case, enjoy!

View the Demo Page, code is in the page

]]> http://www.geedew.com/2009/07/22/making-a-better-notification-plugin-jquery/feed/ 0 http://www.geedew.com/2009/06/01/geedew-going-through-some-changes/ http://www.geedew.com/2009/06/01/geedew-going-through-some-changes/#comments Tue, 02 Jun 2009 05:03:30 +0000 Drew http://geedew.com/?p=62

So I have finally been able to spend some time on one of my own sites! Hurray for me right? For the time being, you may be seeing some weird illusions in the design… and you will notice that some links at the top are not working. It’s all in the works, I’m just happy I have time to work on it!