Finding The Right Product For You
If you know what you want then finding it should be easy. However searching only helps if you know the name of product; but what you really want is a way to specify what you want in a product and see only those that meet those requirement. If instead of going through product pages you could just give the specification of the product you want (like a server that runs Solaris and supports two processors) then that makes the process much easier and efficient.
But how do you design a good product finder? A few exist that let you pick arbitrary product families but when you have 54 servers or over 130 storage products, the solution needs to be flexible yet simple. Luckily for us engineers, Sun has a team dedicated to user experience and design that came up with a clean interface for finding products. 
This interface needed to backed by a system that could process our product data and stay up to date.
Data is always a priority in our team. Its hard to overstate the importance of having good data; data in a form that can be easily processed (XML), data that can be queried (metadata) and data that can be displayed (content). A product finder would need to show the product image, name, features, price and links to get more information (and to buy the product, of course!). All of this information, for all products, needs to be exposed and categorised via the finder - seems like a lot of work, doesn't it? But it wasn't because we had already solved this problem a few years ago with Swordfish. Practically all of our product data was already tagged and ready for consumption; all we needed was to define product attributes that could be understood by the finder.
Is 1 TB bigger than 300 GB ? This is a tricky problem to solve programmatically, particularly once you start looking across entire product range. Another aspect of this is to keep it simple for users; in some places it makes sense to talk in terms of megabytes instead of terabytes, and these decisions need to be made outside of engineering. We designed a system to allow marketing folks to author exactly what attributes should be displayed based on the product category and their granularities, i.e. GB vs MB. Again, we used swoRDFish to identify which products belong to which categories and only showed attributes that needed to be defined for a product - no point displaying CPU speed for tape storage!
Once we have all the right ingredients - good data and a simple interface - we put it all together using JSPs that employ caching to keep information ready for display. Keeping data cached for a short time allows us to balance performance but dynamically update links or price if it changes without any user interaction. Once a customer has found the right product, they can click a link to customise their desired configuration and get a quote, or buy the product and configuration online, depending on geographical location.
So do you want a server that runs Solaris and supports two processors -
Ta Da!
How about Disk Storage products with a capacity of 500 TB?
Right Here!
Are there other product groups for which you would like a finder at Sun? Let us know and we'll see what we can do.
Posted at 04:52PM Aug 28, 2009 by Amandeep Gilotra in Sun.com |
Starlight and DSC Relationship
Back in early December the docs.sun.com team released a major design overhaul for the docs.sun.com (DSC) site (technically v4.3.0). This provided a fresh new look and a number of useful enhancements for IA, Search Engine Optimisation, standards alignment and much more.
Quick bit of background.... The docs.sun.com application is compiled as a WAR file... no surprises there... unfortunately the DSC Homepage has historically been embedded into the application. This means that even changing a single link on the Homepage required rebuilding the application and releasing an entire new codebase to the front end servers. Not ideal, the homepage was often out of date and when it was updated it required a lot of effort.
The new homepage solution... With the 4.3.0 redesign the DSC team wanted to take the opportunity to decouple the Homepage from the core DSC application. The question was where to host it? Starlight (the xx.sun.com CMS) seemed like the obvious choice but routing traffic between the two would be complex wouldn't it? NO! It's so very very easy with Web Server 7...
The beauty of WebServer 7... Routing traffic between the DSC servers (there are 3 of them) and the Starlight appservers (there are 6 of them) becomes very simple indeed. A simple edit to obj.conf redirects all traffic to a VIP that sits infront of the Starlight appservers.
The following is in the "default" object:
# Identify all Starlight assets and send to the passthrough
<If $uri eq '/' or $uri eq '/index.html' or $uri eq '/app/docs/index.jsp'
or $uri eq '/index.jsp' or $uri = '/css/*' or $uri = '/images/*'
or $uri = '/im/*' or $uri = '/js/*' or $uri eq '/language-select.jsp'
or $uri eq '/change-language.jsp' or $uri = '/_service/*'
or $uri eq '/language-select.html' or $uri='/share/*'>
NameTrans fn="map" from="/" name="passthrough-starlight" to="http:/"
</If>
And a passthrough object is defined:
<Object name="passthrough-starlight"> ObjectType fn="force-type" type="text/html" ObjectType fn="forward-ip" hdr="Proxy-ip" Route fn="set-origin-server" server="starlight-preview-server.sun.com" </Object>
Simple!
The additional benefits to DSC... Over the past 5 years Starlight has continued to evolve to meet the latest needs of publishing, business and design teams within Sun. By passing the DSC Homepage traffic through to Starlight it is now possible for DSC to leverage all of the Starlight functionality.
Translation
The Starlight system has built in workflow translation: Select files, select languages that you want to translate into, files get sent for translation, vendor returns translations, approval/correction workflow, publish live. Done.
Global Fallback
In mid 2008 a powerful addition came online for Starlight named 'Global Language Fallback' (GLF). This provides publishing teams with a way to say "This file/directory is global, make it available on all sites." [1] For assets such as /css/*, /im/*, /js/* this means that there is only 1 copy of each file on the filesystem, but they are shared across *every* site. By using GLF, DSC automatically stays upto date with all css/im/js assets thereby freeing up DSC resources and allowing automated compliance with the WebDesign team's best practices.
Templated Authoring
The DSC team could have opted for hosting a static HTML Homepage on their own WebServer. It would have worked. But one of the huge publishing wins for Starlight is templated authoring. A publisher with no HTML experience can edit all of the Homepage content via a GUI form, preview the result and then publish the content at a desired point in teim. This is quick, simple to learn and reliable. Classic separation of data from presentation thereby enforcing Sun's Web Standards.
There are of course a whole raft of other benefits that DSC can piggy back upon that you would expect to find in any Enterprise CMS; Versioning, rich metadata, tagging, ssh/scp access, scheduled content, bulk updates, content search, approval workflows, language fallback, access control etc... etc.. the list goes on....
So far only the Homepage, language selector and all /css/*, /im/*, /js/* assets for DSC are served from Starlight (just a few hundred thousand HTTP requests per week) but there are great opportunities (and plans) for further content in the future.
Well done the DSC team!
[1] GLF can be tuned more than this to provide site, language and content-type filtering as well. Look for a future more detailed blog on GLF in the future.
Posted at 12:15PM Jan 09, 2009 by Mark Fincham in Sun in General | Comments[1]
A New Sun.com Homepage
You've probably noticed by now that Sun.com has a new homepage. If not, go take a look! It's quite radically different from the old one, design wise, and initial feedback seems to be mostly positive. I'm going to ramble on a little bit about it... what's changed, technically, from old to new; how we ensure speed and efficiency; and how we run our testing and QA.
From a technical implementation point of view, the new homepage is actually less complex, in some ways, than the old one. This is mostly due to the removal of blog content - and a shift back towards mostly statically-defined data (when I say static, I mean authored in custom XML files for direct inclusion, as opposed to dynamically pulled in from other sites/data sources). The old homepage pulled in blog entries from http://blogs.sun.com. As with any external data service, measures needed to be taken to ensure good service even if http://blogs.sun.com had an outage. Fallback content was defined, so that if any problem occurred in trying to load blog content, static content was displayed. This was then wrapped in our usual caching layers to ensure a good mix of freshness and speediness.
These measures were tested one day, when http://blogs.sun.com suffered a short outage - and the homepage fell back gracefully. On Sun.com, we often pull data from other sources into our pages - for example Technorati blogs and product reviews - and we always include a graceful fallback mechanism to ensure we don't get ugly errors on our pages.
Back to the new homepage - one of the biggest changes you'll have noticed (apart from the overall colour palette refresh) is the ability to select an audience and see targeted promotions and features. It's a pretty slick experience that loads in relevant features and promos via AJAX - with an element of randomisation, if necessary. And guess what? It's powered by UUIDs. If you read one of our earlier posts, you probably know that we make heavy use of UUIDs for identifying products - amongst other things. This is a good example of one of the other things.
Each audience has a UUID, which content authors tag against features and promotions to mark them as relevant. When you select an audience, our server side code (Java of course) checks for features and promotions relevant to the UUID, and returns them (or a random selection of them, if there are several available). By relying on UUIDs, we can change labelling as often as we need to without disturbing the implementation.
The downside to having such a breadth of content available through the homepage is the caching implications. Obviously, we need to make heavy use of caching to ensure a quick download. For the audience-targetted features and promotions, there could be hundreds of combinations to choose from, which results in some pretty long cache keys. As a developer, this kind of thing scares me - getting the caching wrong for the homepage could result in some pretty weird results being served... and it being on the homepage, it's sort of obvious if it breaks.
And this brings us on to testing! We run UAT with our primary publishers in three separate environments - our work in progress preview (which has no caching), our stage preview (which has caching), and our external preview (which is outside the firewall, and has caching - the most production like environment we have).
Recently, all QA within CME has been shared with a specialised QA team in DotSun. This major update was the first time the homepage had been run through their QA processes, which was somewhat stressful - trying to get good tests while working to short deadlines is not easy. Whilst working with the QA team to iron out issues in our LoadRunner tests, engineering ran some of our own tests using thrasher, so we could measure performance and identify whether we needed to be worried about our implementation. Thankfully everything came together in good time, and in addition to a homepage that performs well, we also have a set of LoadRunner tests that will serve us well for the future.
All in all, there's a lot of work that goes into a new homepage - design, content gathering, engineering, QA, authoring, publishing.... All of these functions within Sun rallied together to deliver a new homepage on a short deadline, to the same standard of quality we expect of ourselves - hope you like it!
Posted at 11:42AM Nov 21, 2008 by Gemma Turtle in Sun.com |
Interns
Earlier on this month, CME took on two new interns, Oliver and Matthew. We've never had interns in our department before, and we've already thrown them into the deep end by asking them to write us a reporting tool using servlets, JSP, XML, and using an existing Sybase database, using the development methodology of their choice. This app should give them a real kick start into the enterprise web application arena, and provide them with their first glimpse of what development in industry is like.
So, why hire interns? Not just because they're relatively inexpensive labour - hiring interns, training them up, and putting them to work on real applications, services and technologies is a good way of developing the next generation of developers with hands-on work experience. University courses provide a great overview of computing as a whole, but often much of what students learn is theoretical, and even the practical elements of courses can't really teach the skills that "real" industry development can. By hiring and training interns, and giving them a good working experience through their year at Sun, we can ensure they'll eventually come out into the market with more skills, more experience, and often, more confidence in their abilities.
This doesn't just benefit the market in general, though. Within the T&R group, 3 of us are ex-interns, hired back after we completed our courses. Sun gains graduates familiar with our internal systems, already in tune with our working environment, and with well-developed skills, and the new graduates... they gain an amazing job. Not to say that being an intern at Sun automatically guarantees a future job, but by impressing all the right people, and making a real contribution to the company, an ex-intern stands a good chance of coming back.
Matthew and Oliver have an exciting year ahead of them. We're planning to move them around the department where possible, so they gain exposure to as many technologies as possible, and so that they can really understand all the components that power Sun.com. As well as their day to day work, they'll be expected to make regular presentations to their fellow interns and members of staff, so that they can grow their presentation skills as well as their technical skills. They'll also be liaising with business partners just as much as our regular members of staff, which should help develop their analysis skills, and give them experience of working with customers. All in all, they'll finish their year with a better idea of the areas of computing they're interested in, a great set of skills, and confidence in their abilities. Not bad, eh?
Posted at 08:57AM Aug 27, 2008 by Gemma Turtle in Sun in General | Comments[1]
Metadata Tagging with GWT
Starlight, that big ol' system of different parts that powers Sun.com, is pretty reliant on metadata. Inside Starlight, a document such as a product page is completely meaningless without at least some basic metadata; the type of document it is, its creation date, expiry date, content type, title, keywords... All that good stuff that allows us to derive information about a document without having to actually read/process/parse it. Within Starlight, a document doesn't really exist unless it's both on the filesystem and in the database in the form of metadata.
This kind of metadata allows us to do cool stuff like automatically generate breadcrumbing from an indicated page hierarchy; render links differently based on content type, or expire old pages without administrator intervention.
The options for doing cool things, however, dramatically expand when you introduce swoRDFish metadata. swoRDFish provides a set of taxonomies, giving us access to UUIDs that uniquely (obviously) identify taxonomy nodes. We describe many things with swoRDFish; the product hierarchy, web content types, country codes, industries... All of these help us to make dynamic linking between related documents possible (and thanks to our back end web application, rather easy). Kristen blogged about this recently, within the context of the Customer Reference Index.
So how do we allow publishers to choose the swoRDFish UUIDs they are interested in for a particular document? Metatagger is our swoRDFish metadata tagging tool, and it's been around since pretty early on in the Starlight days. In it's original form, Metatagger's server side generated an entire JavaScript tree representing each taxonomy; this made is quite slow to start up. In the six months or so, we've been redeveloping Metatagger - to improve performance, and to give it a much needed boot into the Web 2.0 era. And as with any Web 2.0 application, the new version makes extensive use of AJAX.
Now, personally, I hate JavaScript. I really do. I hate that the implementation of the DOM differs between browsers and I hate that as a developer, you have to spend so much time compensating for browser quirks. Another developer in our extended team had been working with GWT for another application, so we decided to expand on our use of it and use it to rewrite Metatagger.
As much as I hate JavaScript, I love GWT. I'm a Java programmer by nature, and much prefer writing Java to JavaScript. The fact that (by and large) GWT handles all the browser quirks for you when it compiles your Java down is fabulous. And as I used to dabble in Swing, the fact that GWT interface programming is very similar to Swing fills me with joy (well, as much as interface programming can).
I was lucky enough to attend the GWT conference in San Francisco last year, and saw some truly amazing applications built with GWT:
Lombardi Blueprint
Timepedia Chronoscope
Although it's an app on a much smaller scale, Metatagger is particularly well suited to GWT because of the nature of the data it displays. A node tree has many available paths for the user to explore (hundreds in the case of the UPT, the product taxonomy). But what percentage of these are likely to be explored during a session? Not a particularly high percentage; most users select only a few UUIDs, exploring only a few paths. By using GWT, we can exploit the asynchronous-ness and load in path data as we need it. In fact, we can load in whole taxonomies only as they are required. This saves us load time and reduces the amount of data transmitted across the network. And because it's all AJAX, there's no need for submit buttons and page refreshes.
So, if you're interested in AJAXian application development without the headache of getting involved in JavaScript, give GWT a try.
Posted at 04:28PM Jun 25, 2008 by Gemma Turtle in Sun.com |
And so it begins
Who writes on this blog?
'The Starlight Template and Renderer Team'
Seriously... who are they?
We create data entry forms so that publishing teams can author web content via a GUI environment. The team also create JSP solutions to take the authored data and do neat things with it. We are mostly powered by XML and Mars Bars.
Got any examples of these so called 'neat' solutions?
Of course...
What kind of technologies does this team deal with?
XML/RNG (lots of it), JSP with a little Perl. All of this runs on top of Sun's technologies including Solaris, Sun Java System Application Server and Sun Java Systems Web Server. There is a slightly out of date discussion of how this all fits together here.
Are there blogs for others connected to this team?
(almost) all the way to the top of Sun...
- Kristen Harris (Director of Content Management Engineering)
- Will Snow (Snr Director of .Sun Engineering)
- Curtis Sasaki (Vice President of .Sun)
Anil Gadre (Vice President of Marketing)No blog?- Jonathan Schwartz (CEO)
And in other connected groups:
- Tim Caynes (Job Title Unknown, probably even to him, he uses InDesign a lot if that helps)
- WxD (the webdesign people... actually this is Tim again)
- Andrew Payne (WebDesign CSS/JS guru and overall HTML overlord)
So, to summarise[1], we provide the building blocks to allow the people in publishing to get their content delivered to the web, with the maximum amount of reuse and no involvement in presentation.
[1] The locale of this blog content is firmly en_GB.
Posted at 02:14PM Jun 05, 2008 by Mark Fincham in The Eng Team | Comments[1]