The choice to leave Netflix wasn’t an easy one to make; I’ve enjoyed being an early part of the HTML TV UI team, which creates streaming applications for gaming consoles, TVs, and other consumer electronic devices. They do great work there, plus having everything built on top of web technologies is simply awesome.

The question, of course, is why PayPal (again) and the answer is simple: I find payments interesting and think that the mobile and web commerce spaces still have a considerable amount of room left for growth. My team’s focus will be to enable this growth and push on the boundaries of both the product and UI architecture to spur innovation. I’m excited about the opportunity and to be working with their teams again!

Wish me luck, and if you’re an UI engineer and interested in talking don’t hesitate to reach out to me!

Taking a look at the DeviceMotionEvent Class Reference, you see that this is a new event API which provides the ability to detect when a “significant change in motion occurs,” allowing JavaScript to take advantage of the accelerometer present in newer mobile devices. This is huge, because it brings the mobile web one step closer towards native functionality.

One of the interesting ways that native applications can take advantage of the accelerometer is to trigger a JavaScript event which happens when users “shake” their phones (or other devices). I thought it would be interesting to see if similar functionality could be implemented using the DeviceMotionEvent API, and was able to get a basic implementation working with the following code:

if (typeof window.DeviceMotionEvent != 'undefined') {
	// Shake sensitivity (a lower number is more)
	var sensitivity = 20;

	// Position variables
	var x1 = 0, y1 = 0, z1 = 0, x2 = 0, y2 = 0, z2 = 0;

	// Listen to motion events and update the position
	window.addEventListener('devicemotion', function (e) {
		x1 = e.accelerationIncludingGravity.x;
		y1 = e.accelerationIncludingGravity.y;
		z1 = e.accelerationIncludingGravity.z;
	}, false);

	// Periodically check the position and fire
	// if the change is greater than the sensitivity
	setInterval(function () {
		var change = Math.abs(x1-x2+y1-y2+z1-z2);

		if (change > sensitivity) {
			alert('Shake!');
		}

		// Update new position
		x2 = x1;
		y2 = y1;
		z2 = z1;
	}, 150);
}

As you can see, a JavaScript event is setup to update the position when the device moves and, once it does, the new position is calculated against the old to determine if the shake event should be fired. If you’re reading this and are using Mobile Safari with iOS 4.2 you can see it in action on the demo page.

I have plans to create a richer, more complete example of this soon, but in the meantime just this basic example gets me excited. Device aware functionality like this is a great step for the mobile web!

The 2.0 version comes with significant modifications to the code which allow for increased extensibility and support. You can read the full list of changes over on the official website, but a few of the major features in this release are:

• Support for localization and modification of the content
• Adaptation support for multiple currencies
• An exposed API for controlling the cart externally
• Added support for custom callback events during all important lifecycle events

These coupled with the rest of the changes, should set the foundation for a customizable JavaScript-based inline cart experience for PayPal.

One thing I discovered after releasing the initial version was that there were many talented people out there with great ideas for the cart. Perhaps the largest change in 2.0 is that the code itself has now been open sourced and is available on Github. If you have a change that you’d like to see then I encourage you to consider contributing. There’s instructions available on how to fork the project at the website.

Now, if you read this far, I recommend you go check it out: https://minicart.paypal-labs.com/

The Appcelerator team has been actively making improvements to the platform, has a developer blog, and has open sourced the code which is available on Github. If you’re interested in mobile development then it’s worth taking a look Titanium Mobile for your next project: http://www.appcelerator.com/.

To see a demo along with integration details please visit the official website: https://minicart.paypal-labs.com/.

For those curious on how it works, it’s actually pretty easy: the HTML for the cart pages is in a predictable format so the script is finding all of the form elements on the page with a cmd=_cart and hijacking them. Instead of submitting as expected, each form has it’s contents parsed and a DOM structure is created for the Mini Cart. The data from the overlay is then stored in a cookie to keep it persistent between page loads. When the user proceeds to checkout, the data is processed as a third-party cart upload and the user is sent, finally, to PayPal for their payment.

The feature is still new and I’ll be working to expand upon it so if there’s any feedback let me know.

After making the initial version publicly available many features were asked for and implemented. With the scope of the project considerably larger now, I’ve taken a moment to step back and clean up the code. It’s been a slow process, but with the refactoring almost done and a stable version in hand I can finally start to add in new features! I’ll try to post my progress as I go and will make a release candidate available once I have one.

Also, if you’ve used the forum in the past, you might notice that I’ve removed the link for it. There was just too much spam on the board to deal with. I will reinstate it after I have time to get an appropriate solution up and running, but in the meantime I have put an email link there instead.

If you have any questions about the status of the project please email me.

While the above statement is true, website accessibility actually applies to a wider band of people and has benefits that include better search engine optimization and ensuring that your website is available on a multitude of devices. A better way to think of it is that you are enabling more people to use your website. Just think about that for a second… Why wouldn’t you want more people on your website?

If you’re interested in learning more about website accessibility here’s an informative, high level write-up that I recently found:

Understanding Web Accessibility

Among other things it includes advice on overcoming accessibility issues in existing sites and has a list of benefits from a business perspective, both of which can be invaluable.

When doing markup it’s easy to identify elements in terms of paragraphs, lists, divs, and spans, but try not to forget there are other tags which can aid you in semantically marking up your pages.

<Q>

The Q tag should be used for short, one-line quotations. This tag will add language specific quote marks around the text for you automatically — which is quite cool. Unfortunately Internet Explorer does not support this. You can remove the generated quotes by adding q:before, q:after {content:'';} to your stylesheet.

<BLOCKQUOTE>

Most people are familiar with using the blockquote tag to indent text. This usage is presentational and should never be used. The correct use of the tag is for when you want to markup long quotations.

<CODE>

The code tag is for fragments of code which are displayed on the page. There are also similar tags with minor semantic differences such as samp, sample output from a program; kbd, text the user should type; and var, a program variable.

<ABBR>

When you use an abbreviation you cannot be sure that the user will know the meaning. To make the page accessible you could use the abbr tag to pass along the meaning. Unfortunately, Internet Explorer doesn’t support the hover tooltip for the title, but degrades gracefully.

<ACRONYM>

Similar in usage to the abbr tag this is for acronyms and is supported by all browsers.

<INS>

The ins tag is for document changes where text was added at a later time. By default this text appears underlined.

<DEL>

The del tag is for document changes where text was removed at a later time but you still want to appear for historical reasons. By default this text has a line through it.

<OPTGROUP>

Probably one of the least known, but more useful tags. Optgroup is used to group similar option values. A great use for this is to create multiple select boxes which update each other when changed and still degrade gracefully when Javascript is turned off.

Before you start wondering why you should care it would be a good time to point out that Apple just released wifi compatible iPods. They too can browse the internet. Now how many people do you know who have an iPod? There are quite a few I’m sure. Within a few years that number will only grow and with iPhones becoming popular the chances a visitor to your site is using the mobile version of Safari just went up.

Today it is exactly three years ago since PHP 5 has been released. In those three years it has seen many improvements over PHP 4. PHP 5 is fast, stable & production-ready and as PHP 6 is on the way, PHP 4 will be discontinued.

The PHP development team hereby announces that support for PHP 4 will continue until the end of this year only. After 2007-12-31 there will be no more releases of PHP 4.4. We will continue to make critical security fixes available on a case-by-case basis until 2008-08-08. Please use the rest of this year to make your application suitable to run on PHP 5.

I taught myself PHP using version 4 and it’s sad to see it go, but at the same time I’m happy. There are tons of improvements in the current version and so many hosts out there only support an older 4.x version. This makes developers choose between having their applications run on the majority of setups or taking advantage of modern day functionality in PHP.

It’s not hard to move your code to PHP 5. In fact, most sites will probably run fine without any problems — at most they’d only need a few tweaks. If you need to transition your application from 4.x to 5.x there’s a Migration Guide available on the PHP website.