Hot, well, warm on the heels of our storage finder, we have recently deployed the new server finder, which replaced a previous incantation of finding functionality which was held together by hello world string and was somewhat creaking at the edges. The new server finder is based on the architecture we developed for the storage finder - they are, in fact, 2 renditions of the same finding platform - and so leverages the features that make it so worth the investment of effort.
As with the storage deployment, the key to making the server finder successful was, well, a number of things, but the main thrust of our efforts was defining the data architecture that make the relationships between product groups, products and product attributes a meaningful one. This can only happen with some Herculean efforts being undertaken by our publishing teams in conjunction with the product marketing teams, who really understand what is important and relevant about the products they market. Really, the finder itself is just a layer of abstraction on top of the data set underneath, and in theory (as we are at pains to try and progress), can be applied to any well-structured data set. What matters, is whether the data that a customer, user, or casual visitor is presented with, and the methods they can use to interrogate that data, enables them to reach an appropriate destination. In other words, they might know where they want to go, they might have a vague idea, or they may have no idea at all, but if we've done our job as well as we should be doing it, the directed searches and filters that the finding platform utilizes should provide a the equivalent of a product sat-nav, but avoid the 18-wheelers that get grounded on hump-back bridges in the middle of Hertfordshire on the way to the new Tesco Express.
Probably an analogy too far there, but it is by way of illustrating that the key to the finding platform is the data that it manipulates. I mean, we did a number of detailed usability trails, with various rapid and high-fidelity prototypes, struggled over the tiniest nuances of labels and gradients, fought compromise on page region refreshes and a followed number of other noteworthy user experience best practices, but in the end, if we built our application infrastructure on top of a taxonomy akin to a river bed full of shopping trolleys, we'd only be providing half a solution, which, in fact, is no solution at all.
We've still got a number of things to work on that didn't make it into the first release, such as enabling product comparisons across products and, more difficult, across product in different product families, but take a look for yourself and let us know what you think. Comments are more than welcome, especially ones that are nice.

portal where they'll have to find a place next some anatomically altered engineer masquerading as Wolverine in an
web design coven in order to prolong delivery (you see how straight I'm delivering that), but because I really dislike
bangwagonesque all-seeing 'i', it's the BBCi. The BBCi brand, label, bucket, whatever, was around for many years as a catch-all bitriquadquin-media expression of anything vaguely digital. Stands to reason that when they finally delivered their TV-ondemandonlineovertheweb player that it would fall under that broad BBCi category of products, even though they don't really call it that anymore. So, why not just stick the 'i' at the front? Viola!. iPlayer. Nothing to do with
key criteria drive the user experience. To avoid repeating those mistakes, for the new storage finder, we took a significant step backwards, to understand the product taxonomy and how it maps to business needs and customer expectations. When reviewing the product data, and testing with business groups and customers, it was clear that what seems like an important attribute of a product or product family is not necessarily what matters to the people who are actually wanting to buy it. Seems obvious, but until you get real people to give you real opinions, then you're just guessing.
A few weeks ago, we put together a servers overview page, so that we could do that story telling, provide sensible paths into product areas, uplevel featured products, show off some great customer success stories, and, yes, tell you what our servers actually are. It's a delicate balance on these pages between getting the story out there and providing a quick route to the products, but I think we managed it pretty well. I say 'we', but, of course, it was the good folks in the product marketing teams that pulled all the content together (kudos Carlos & Lisa), and our publishing team that managed the tricky icky problem of integrating the new content with the existing server finder (heroics from Jing). I just did the bit where I say 'you'd be better of with a
So all hail
but we really do a whole lot more than just ask you to point out broken links and typos.
Maybe you'd actually prefer to see our servers presented in terms of their attributes, so that you can begin your research by asking "What servers have you got that can run Linux?", or maybe "I've got $5000 and I want a Sun server now. Show me what you've got". In any case, you'd be hard pressed right now to complete a customer journey like that without going through a number of hoops. Backwards, probably.
Its probably unfair to pick out Forbes, as there's any number of article-based sites out there which adopt this style of page format. I say, 'adopt this style', but what that really means is 'crams as many ads into the available space', even if they are those circular ads which are published by, and point to, yourself. I guess I still hanker after solid design frameworks and excellence in user experience, but as the channels on the internet converge with the channels on TV and other media, it's predictable that the demands for return on investment drive the content model. Perhaps I should be tipping my hat to the page designers who manage to actually squeeze some content into these pages, notwithstanding the requirements for ad placement, cross-marketing, subscription targets and everything else. That is a real user experience challenge, albeit not one I'd like to have to take on.
being crashed unceremoniously against the woodwork with accompanying cries of "c'mon! C'MON-AH!", is ad server code that halts a page load mid-stream until its finished its business. I'm sure the page owners have bought into the most efficient geo-located edge-based web service out there, so why is it increasingly the case that while pages get faster, ad servers seem to get slower? Perhaps it's a deliberate interaction feature, I mean, nothing grabs your attention more than a broken page, but from a customer experience point of view, I don't think that's a journey I would normally care to continue with.
But how do you know what's new and where do you expect to find that out? When you're looking at something the scale of sun.com and trying to determine customer behaviours for a given page type, it's not alway a simple task to predict. You might be the kind of visitor who would casually visit the sun.com home page and, not unreasonably, expect to see anything newsworthy enough, that you might be compelled to actually invest time in, to be present right there. You might be more specific than that. You might be the CTO for an SMB or some other suitable market research defined acronym pairing, in which case, you'd probably know that we've got a place
But that can't save me from being a lazy arse. I like to put images in blog posts to illustrate points, or just to make myself less uninteresting than I am. I also like to have them aligned left or, usually, right, with text wrapping around them. This is from the HTML 1.0 handbook, right? So I was rightly ashamed of myself when I installed the
We've got a new place for Small and Medium Businesses on sun.com.
Adobe Bridge? Anyway, since installing CS3 a while back, things have not run smoothly. Most recently, I've had nasty problems with failure to boot or shutdown, and my suspicions have been aroused by the network activity icons blinking away in the corner as everything else fails to start.
Not my words. Those good folks at
Its a challenging task, and we're trying to accommodate multiple feedback types across multiple venues, and, naturally, tight project deadlines (which means I should probably be building wireframes instead of writing this). Where we're focusing our efforts right now is on just how far we can go with contextually-driven feedback. If we're able to categorize the invitation in terms of the customer task and the current context, we should, in theory, be able to cut a swathe through a task filtering navigation path and drive straight to the submission phase, where any options or forms are specific to the task. However, we can't be completely confident that our invitations will always be contextually clean. We'll often use a global navigation component to host a persistent link, and it wouldn't be enough to simply assume that because a customer clicked on a link labeled 'feedback' in a footer on a product page that they are necessarily wanting to provide feedback on that product. They might just want to tell us the site is very slow today. It may also be true that even though they may have accepted an invitation to feed back on a particular product, what they really want to say is that we've actually speelled the product incorructly, which we might call a 'typo', which as everyone knows, goes straight to the jitterbug queue labeled 'null'. Only joking.
So hallelujah for
next is a neat way of putting off what I'm supposed to do next, but at least I know in what order I'm not getting around to things.