Visible.net is a new provider of state-of-the-art ecommerce and online marketing services.
(more…)
I have finally gotten time enough to launch my new eCommerce blog. If you already run an eCommerce store or are thinking about getting into selling online, jump on over to eCommerce Optimization and get helpful insider tips and tricks to assist you in selling more through your online store.
(more…)
You were likely following the news, so I’ll cut things short - today was the WWDC, and together with a bunch of other cool news, Apple launched a
new website.
“Great!”, I hear you say correctly. The new website is beautiful. Except for where it isn’t - content organization.
The screenshot above portrays the new navigation scheme on Apple.com (specifically, the new
iPod+iTunes page). I have to wonder what crossed their minds that made them mix products (like the iPod models) with accessories and user actions (”Download iTunes”) in the same navigation bar. I mean, that’s mixing apples (pun intended) and oranges.
I know once you do something cool - like that awesome new navigation - you want to use it everywhere, but this is Apple - come on guys, you sure as hell can do better than that in terms of information architecture.
One thing I’ve explored often is how many web-based applications fail because of a lack of proper planning. One thing that I haven’t stressed enough though, is that proper planning doesn’t always mean spending months on end thinking about every single detail, but actually thinking about things in the right order.
Traditional feature-centric design
Usually developers start planning applications by thinking of everything they want it to do - and let’s face it, it’s pretty easy to get excited: since you’re getting some functionality in, you might as well do all the other hundred cool things too, right? Well, wrong.
Getting excited is great, but it may just as well hinder the application development process. Focus slips, pretty soon you’re trying to solve all the world’s problems. You may have heard of scope creep - this is just the same, but it’s your fault, and is definitely avoidable.
Top-down product design
The solution is actually quite easy although it may seem odd if you haven’t done it before: design interface first, then underlying code. Result: no functional slippery slope - you know exactly what you need to build to accommodate the UI functionality. As a side benefit, you get to have something you can experiment with as a prototype sooner, which means you can get more input sooner and iterate over it.
Give it a try on your next project - your developers will love knowing exactly what they need to build, and your designers will love not having to design
that new page for the brand new functionality that just crossed your mind.
jQuery has had a recent set of interesting news, so we thought we should write it up:
jQuery works nicely with Rails.
Geoff Buesing assumed that switching his Rails application from Prototype to jQuery would be a pain, but then discovered that you can write jQuery-formatted Javascript with RJS templates, out-of-the-box, no special helpers or modifications necessary.
The trick is to use the RJS element proxy syntax -- page['someid']
-- which outputs the Prototype syntax $('someid'). Just replace
someid with a jQuery selector, and method_missing magic will handle
the arbitrary jQuery methods chained to it.
Some examples:
RUBY:
page["#posts"].append render(:partial => 'post', :locals => {:post =>
@post})
#=> $("#posts").append("Post #29 info…");page[".hide-this"].hide
#=> $('.hide-this').hide();
page["#foo"].html("bar").append("baz")
#=> $("#foo").html("bar").append("baz");
page["h1"].add_class "make-red"
#=> $("h1").addClass("make-red");
Ryan Dunphey wanted an OS X dashboard widget to give him "simple, searchable, offline access to the API", so while on a plane, he
developed it.

This is great PR:
Wordpress 2.2 migrated to jQuery due to Matt reading criticism such as
this.
New Plugins
A couple of new plugins include: