Control of the desktop browser market (or at least a chunk) continues to be a big focus of some of the major players on the Internet:  Mozilla (the open source foundation), Microsoft, Google and to a lesser extent Apple, Opera and other smaller % players.  The latest salvo has been fired off by Google with the release a few days ago of their Chrome browser.  If you’re not familiar with Chrome, I think the comic book introduction actually does a great job of highlighting the differentiators, the architecture and generally why you should care.I’ve been using Chrome for a bit now and have to say that I’m initially impressed.  I think Amith (our usability wizard) is a fan as well.  I’ve been using Chrome with Trading Grid Online, for example, in advance of qualification testing–they aren’t kidding about client-side javascript performance improvements from what I can tell.  My favorite aspects are:

• Maximum screen real estate, very simple and clean design.
• Render and javascript speed seems quite top notch.
• Each tab is a process–a bad site which hangs or crashes only affects a single tab and you get a task manager tool for handling these situations.
• The location bar is useful for a number of activities: prior sites by address, prior sites by input and keyword search via Google.

Here’s chrome rendering GXS.com:  This last feature, the location bar’s multi-tasking nature, leads me to another more quietly rolled-out experimental browser feature called Ubiquity.  A plugin for Mozilla’s Firefox browser, Ubiquity provides a command-line like option with a number of powerful and potentially useful keyword commands.  The effect is more or less like a DOS shell or an xterm session for the browser.  Check out the tutorial for an example of a command sequence for highlighting text and pasting a highlighted excerpt in a Gmail message or a highlight and translate sequence.  Chrome doesn’t seem to have a plugin developer option at the moment or I would be looking for a Ubiquity clone post-haste.All this competitively driven innovation is good news for us business users who now access a plethora of web applications every day, many tabs open, many hours logged on various systems both accomplishing and monitoring tasks.  I think better browser innovation promises greater productivity on tasks already being asked of you on a daily basis.Here’s an example of Ubiquity in action:  As you can see, I can just highlight in the browser, pop up Ubiquity (ctrl + space), type email and all the copy/paste work and the task of opening Gmail has been done for me.  Slick. That’s all for this installment.  Let’s hope Web OS innovation continues at a strong clip.

A busy discussion bubbled up in the usability community recently regarding a trip logging app a company developed for the iPhone.  The UI’s front screen is quite busy and tons of people rapidly chimed in to criticize the design on Flickr.  The creator responded by pointing out that the design, while busy, is optimized to let you accomplish the task that you would use the app for 90% of the time (not the other 10%) linearly in one shot.  No need to use menus, tabs or change screens.  His response was later reviewed on the 37signals blog, discussing the balance between a well-designed screen that’s busy but effective and a poorly-designed screen that’s clean and simple but inefficient for daily use.

For what it’s worth, I think both sides of the argument are right on this one.  The developer clearly knows his customers well and designed something with a very low threshold for effective use.  However, the use of color and some of the spacing and alignment seem to add confusion and distraction to the UI.  Check it out for yourself and see what you think.  One of my favorite Trading Grid Online screens walks the line as well.  Admin users have access to a “User Action History” feature which shows actions taken by users on your account within 90 days and even includes correlation by session.  I spent quite a few iterations with the engineers working on an AJAX-based UI intended to allow searching, results and detail displays within a single page.

Metadata for user actions is more compact than most transactional data (EDI or XML contents or, if you’re feeling plucky, JPEG headers and binary data!), so we ultimately took this approach to allow an admin or support user to easily locate, correlate and review actions without having to change pages in the process.  We reasoned that users are mostly checking audit logs when there’s an issue and this often involves a phone call or conversation with another involved party.  Browser refresh page changes, while engaged in dialog, often cause users to lose their place or train of thought so we used a little more real estate to keep continuity across actions–a big help when you’re partially distracted.

Don’t believe me, though.  Check it out for yourself.  If you’re not a TGO user, you’ll have to settle for a little screenshot (session IDs and innocent internal test account IDs removed ).

Search results, filtering, pagination and item views use AJAX to reload live in the current view, so the screen maintains its overall state.   Slick stuff.

In the very early days of humanity, primitive cave dwellers were forced to use software installed directly on their office computers. They would have to run from cave to cave (often in bad weather, possibly dodging wild animals like the giant sloth) in order to install “updates” whenever the software was improved, to make sure each cave was doing consistent, compatible work. Sometime after the invention of the wheel and the Enlightenment, a few cave men came up with the Internet. I’m glossing over lots of important things. Eventually, people realized that the Internet would be a great way to deliver software-like services without having to maintain individual caves.

Today, many of us use a number of web-based applications. Here’s a list of what I’ve used so far today:

• Backpack - a lightweight personal information manager (PIM)
• Google Reader - alerting, monitoring
• Gmail - email
• Heroku - an integrated development environment (IDE) [ed: technically, working with this after midnight counts as “today”]
• Flickr - photo sharing
• Oracle - finance-y stuff
• A Number of “News Services” - blogs, most of which were application-calibre
• My GXS Blog - publishing and feedback
• Trading Grid Online - of course

However, we still use desktop software. Some of our software handles large local files and work wells on the desktop–think Photoshop. Serious 3D games are very performance and latency-sensitive and also handle local texture files and model files. One of the newest questions being tackled by development groups like Microsoft, Adobe and Mozilla goes something like this:

“Is there a middle ground between a pure web application and a pure desktop application? A web application delivered on the desktop, with desktop integration. How would this be accomplished? What would the benefits be?”

This is a really interesting line of thought.  Imagine signing on to your work computer one morning and finding a desktop icon called Trading Grid Online.  When launched, you would be using the Trading Grid web portal, but as if it were a locally-installed program.  It would show up in the taskbar.  You could alt-tab around with your other programs.  You could drop files in to the web-based transaction manager directly from your file browser.  In fact, the program would minimize to your system tray and show a desktop pop-over window each time a transaction alert triggered on the Trading Grid.   Now, imagine that a new version of the portal was released.  Because your desktop version simply packages the on-demand web service, no local upgrade would be required.  The benefit of both worlds?  Sounds good to me.

There are a number of competing approaches and technologies starting to explore this space:

• Adobe AIR - I have not researched AIR extensively on the developer end, but have used an AIR-based application call.  The AIR approach is to use technologies like HTML w/ Javascript or Flash/Flex (Adobe technologies) to build desktop applications with access to local files and remote data.
• Microsoft Silverlight - This project, while often lumped in this list, appears to be about creating rich internet applications (RIAs) based on the Microsoft .NET platform.  That makes it a competitor to some of the Adobe technologies used by AIR.  I have yet to understand how Silverlight intends to push the melding of the desktop and the full on-demand web application.
• Mozilla Prism - This system is based on the idea of providing a dedicated “Firefox” desktop window for a web application, removing things like the location bar, bookmarks, etc. to create the single desktop app feeling.  I believe web developers could use custom tags in their pages to invoke things like desktop alerts through the Prism framework.  I’ve played with this a bit and its clearly very early stage.  Mozilla’s approach seems to be based on enhancing integration via packaging and extending an existing web app, but not custom-writing one.
• Google Gears - I want to try Gears in my evening time to see how it works, but the idea is not so much to provide a brand new type of application as it is to provide a code library for web applications that are on the web (in the normal sense) to support an “offline” mode by storing data on the user’s desktop and referencing from the web.  This is one kind of integration with the desktop, but doesn’t cast as wide a net as AIR or Prism.

Exciting times for the Internet.  There is some convergence brewing even if none of these particular technologies become the next wave.  Google Docs as an “office suite” is growing in popularity, but mostly for niche web-sharing uses.  Microsoft Office, OpenOffice and Apple iWork all still excel in usability when dealing with local documents; any given user will have tons of these lying around the cave.  One of the major, unsettled questions that you can see lurking in the list is still the question of how the web and desktop will come together.

No, that’s not a typo. I recently received an invitation to Heroku, a Ruby on Rails platform that seems to me to really highlight what’s possible in the new age of the web. Heroku is both an on-demand, web-based development environment for building web-based apps in Ruby on Rails and a scalable deployment and hosting service using Amazon’s platform services. This means that apps built on Heroku have on-demand access to virtual servers and bandwidth to simply scale with performance. Amazon’s Elastic Compute Cloud (EC2) and Simple Storage Service (S3) provide both “machines” and database.

In short: I can open an account on Heroku and immediately start building an app through my browser. I don’t need to deploy servers, setup a web server such as Mongrel, setup a database like Postgres or be concerned with scalability beyond writing quality code. All of that magically happens with about as much trouble as it takes to open a Gmail account. Really. I did it. That’s about how hard it was.

I think this is a great example of what on-demand services are all about, especially at the smaller scale of the user spectrum. With Heroku, the only thing I need to worry about is building the app itself. I get flexible cost-efficiency and I’ve basically out-sourced the mucky platform concerns to an expert, freeing myself up to focus entirely on my service quality. Like Trading Grid Online’s web-based mailbox tools or Intelligent Web Forms, I can register by invitation for a hosted service that connects me to partners without any need to worry about software installation, distribution and other issues such as protocol mediation which require time and money to manage and which provide on-going cost and challenges to my service quality, but don’t stand to differentiate me significantly if managed well. Although it’s too early for me to tell, I would bet that the value of this approach will really be felt as new versions of Ruby, Rails or changes to the Amazon platform services are rolled out–like working with GXS, infrastructure improvements, modernization and adapting to my partners’ change should be handled by experts with economies of scale and extensive specialized experience.

Heroku also happens to be a YCombinator company. If Heroku is any indication, YCombinator’s unique approach to venture capital seed funding appears geared to producing some new and valuable services.

Recently, a few colleagues, friends and pseudo-random internet acquaintances have asked for usability/web-related blog recommendations.  Today’s post is a link list of blogs that I’ve found to be either useful, informative or interesting enough to foment some of my own ideas.  My goal is not to deflect anyone for continuing to ask me for recommendations (honestly).  I’d be interested to know if any feed readers already check out these blogs or have their own recommendations to share.

So here are the three I’ve been most interested in of late, with notes and the addition of one rogue blog that is no longer but still worth back-tracking through for some wisdom about creative disruption:

•  Occam’s Razor - Avinash Kaushik is well versed in web analytics and his blog is a good resource for content providers looking to broadly assess their UI’s success from a statistical viewpoint.  His “Web Analytics Demystified” thread is a great intro, but his general tips on getting the most out of loggable, aggregate user information to improve service quality is worth a read.
• UIE Brain Sparks - With a name like “User Interface Engineering,” how could you go wrong?  Brain Sparks blogs about UI design theory and practice, does practical reviews of good web UI and also serves as a good way to stay alerted about UIE events.
• Simple Bits - Although not updated frequently, this small design shop covers browser developments and type-face (sort of a UI designer’s secret vice) content and commentary.  I’ve found that small design shops with a strong aesthetic are great sources of very pragmatic information–in particular, the cost at a small shop of maintaining cross-browser compatibility can lead to some tips/tricks that bigger shops can learn from.  Plus, these guys developed Foamee, which allows you to owe someone a beer through Twitter.  Sweet.
• Creating Passionate Users - Great blog.  Sadly, it’s not maintained now because the author was harassed by other bloggers.  Focusing on non-traditional advice for software and service designers, this blog also provides a great example of how images can be used in a blog to convey information very effectively and break up the doldrums of seas of blocked text.  I promise to work on that…

The best learning is hands-on, of course, so I highly advise trying new web apps that pop up with a fan base and doing your own pro and con assessment.  Of course, UI-opinionated blogs are a great way to discover these apps.  I continue to be a fan of Flickr, a photo-sharing site purchased by Yahoo! some time ago.  Recently, I used their integrated online photo editor to touch up a camera phone pic and the experience was quite smooth.  Overall, it was more efficient than using iPhoto.

I continue to mourn the loss of Newshutch, my favorite feed reader.  I’m getting more used to Google Reader, though, and there’s still no sane alternative to feed reading for keeping up with all these blogs

I hope you all had a great holiday season.  It is really, really cold at headquarters today.  Time for another cup of tea.

Time to drag out the old usability soap box. It’s starting to bend in the middle, and so I might need to buy another year’s supply of bulk soap to get a replacement.

I spent some time messing around, as a nerd/technologist and child of the Internet revolution, exploring the virtual world of Second Life last year. I will spare you a re-creation of my assessment. Suffice to say, it’s a great concept and has some interesting value for proof of concept or collaboration work but is hampered by poor usability in the client GUI as well as poor performance usability on machines with less power than something like a Cray or perhaps the Amazon or Google computing clouds. Well, not that bad, but I could definitely hear my Mac Mini struggling to vent heat while my avatar was “walking around” the Adidas virtual island.

An interesting article came across the Reuters Second Life bureau RSS feed this morning reporting on claimed versus perceived performance improvements in Second Life. Linden Labs, the company behind Second Life, made the claim that performance had improved using the metrics of server-side frames-per-second (FPS), a measurement of how fluid the 3D images are being presented to users, and the occurrence of crashes. A user poll, however, indicated that users were perceiving a simultaneous steady decrease in performance. The issue, client-side FPS was creeping downwards despite gains in the server-side measurements.

The lesson here is one that I’ve often repeated within GXS. The only way to measure usability *really* is to measure it from the user’s perspective. We have a re-design to one of our Trading Grid Messaging Service dashboards, for example, which moves one data element to an asynchronous lookup so that the dashboard can draw very quickly and the user can review 9 out of 10 metrics while the 10th is populating. Performance usability improvements often focus on optimizing data display so that (for the sake of the argument) a 10 second page render moves to 8 or 9 seconds, on average, when you can make significant usability improvements by moving to a 3 or 4 second average page render and defer a single data element to asynchronous. The user needs time to review the other data elements anyway, so the overall impact is positive. In Linden Lab’s case, the server can push out content faster and faster and faster, but if client performance doesn’t change then nothing has improved in a meaningful way for the end user.

On the upshot, it’s clear that Linden Labs is doing the right thing by being sensitive to this issue and responding to it, rather than continuing to tout their purely provider-side enhancements.  I was going to dovetail into applying this principle into airline customer satisfaction during the holiday season, but you probably don’t want to read this entry for another few hours. Suffice to say, the carrier with the least over-booked and canceled flights shouldn’t have reason to brag. Whether you travel or stay home this season, make sure you have a good time

I’ve been using RSS for a very long time. When I found out that there was a convenient way to read the multitudes of websites I wanted to track in one place–and only be bothered when something was new–I was excited. Having used RSS for a long time on Windows, Mac and Linux, I’ve gone through a significant number of RSS readers trying to find one that suited my opinionated stance on usability and simplicity.

So, for a very long time, I’ve used nothing but Newshutch. I started with desktop readers but quickly gave up on those because I switch computers frequently. It had to be web-based. I tried a few web-based readers and found them to be clunky, obnoxious and unwieldy. But Newshutch won my heart quickly. It was usable, simple and made smart use of Ajax. When I used it, I wasn’t thinking “I’m using Newshutch,” I was thinking “I’m reading news.” Catching up on my feeds a few days ago, I came across a Newshutch blog entry titled “Newshutch Service will end on November 10th, 2007.” Shock. Horror. My favorite reader is going away and I’ll be condemned to use one I already know that I don’t like.

I read the farewell blog entry and I have to say that it won me over. The title starts out with “We’re pulling the plug on Newshutch.” The first two section headings are “We lost the hunger” and “No regrets.” The Newshutch team goes on to explain that some trouble with moving to a new hosting service (which didn’t affect me at all) forced the team to admit that they had lost the passion for Newshutch. It started as a creative disruption service to prove that RSS readers could be better. They did have some success in that area. At least one VC group came after them with an offer despite having no understanding of the business model. But to compete with all the other feed readers like Bloglines that I tried and abandoned, they would have to work on Newshutch constantly. Working constantly on something they were no longer passionate about would produce sub-standard results for Newshutch users and there would be no winner at all.

I think that’s an admirable stance. Why would I want to continue using Newshutch, knowing that quality and innovation would decline over time? I don’t pay for the service, so Newshutch doesn’t need to keep collecting revenue from me while basically only making critical corrections. They’ve re-designed the app to make the feed list export feature prominent and clearly stated that it will go away and that they will start to work on other projects now where they can make more of an impact and feel more passionate along the way.

Kudos. They even included a footnote to the blog entry recommending the least offensive (based on Newshutch philosophy) of the other feed readers that are available. I’ve ended up dropping back to Google Reader. It’s not bad, but it makes me miss Newshutch. I accomplish both things with the same tool, but using Google Reader always takes a bit longer, is harder to read and requires more hunting around for buttons and generally feeling a little dis-orientation. I’ve blogged about Backpack before, so I loved the comment that “If I was Google I’d drive a cargo container of cash to 37signals’ or Dan Cederholm’s offices and say ‘Congrats, you’re the new EVP of UI at Google.’” Compared to Gmail, which I love, Google Reader just feels less pleasant.

So, to bring this all back home… it’s a good thing to stop and reflect. As a Product Manager, I may have some frustrating days, but I still look back at the week and feel passion about the Trading Grid. Especially the portal and other related projects that I’m hooked into. Innovation and thought leadership are exciting, but if I didn’t feel some hunger about my little product, I wouldn’t be here blogging. I hope you feel equally hungry about the success of your B2B program and I hope you think of GXS as a big, satisfying bowl of soup to feed that hunger as the weather here in the US starts to cool down.

And if you’re reading this in Newshutch, I’m sorry for your loss. I’m working on a project which produces some RSS feeds. When I draft some help content and I can’t unofficially recommend Newshutch to anyone who doesn’t have a reader yet, I will continue to feel your pain.

Every Tuesday night (almost), I get together with my friends Ajit and Dustin. We’re old college budies. I lived with Ajit for a while and Dustin, having introduced me to my wife, was the best man at my wedding. Ajit is an IT guru for a casino. Dustin is a developer for an IT software/services company. I used to work for that company as a Product Manager prior to GXS and pulled Dustin in. I’m gone, but he’s still there. So, most Tuesday nights, we get to talking about the old days and the new days.

One project I was involved with before I left was piloting agile software development practices with the developers. Since my formal education as a software engineer left me jaded and opinionated about the traditional waterfall module (or, spend a lot of money and time on something, hope it works, and spend a ton more if it doesn’t), I had some research and stake into proving out a new way of tackling projects. Also, the fact that I did development with Ruby on Rails lent me some completely undeserved street cred.

So, for the last few months, Dustin has been updating me on Scrum. He’s positive. Walls are going down within engineering. Literally and metaphorically. No one is dancing in the streets with trumpets blaring, but these are IT developers we’re talking about. Many of whom, after that statement, will likely leave nasty comments and never read this again. I’m hoping Dustin tells me at the every least that the following things have happened (these are not all of the potential benefits by a long shot):

• Management visibility and on-going engagement has increased on projects, such that micro-management and requirements transmission issues are reduced and the actual number of concrete decisions per day (the CDPD rate) increase. Yes, I made that term up.
• Projects are more likely to meet deadlines, or where they are not, management and developers have signed off on any particular delay as a desirous event based on requirements changes or design feedback.
• Developer awareness of projects that aren’t assigned to them increases along with the ability to adjust requirements for smarter integration, such that seams between services are smoothed.
• QA became better able to validate the accuracy and usefulness of a service, rather than being restricted mostly to cross-checking the detailed design specs against the tables in the database and doing other somewhat self-validating exercises. In other words, the same syntax validation with more semantic validation.

I can’t take credit for the company going to an agile methodology. After all, I piloted a hybrid Agile (with a capital A) program and the company settled on Scrum. I like Scrum. At a tech forum, one of the Amazon executives talked about the ups and downs and it pretty much matched up with what I was seeing in my own hybrid approach. However, I’d like to think I can take credit for breaking the ice. Going cold-turkey on a more traditional methodology makes developers suspicious, worried about their job security and afraid of not being allowed to sit down in meetings (yes, Dustin, living up to my promise to mention that). Those are generally groundless concerns, but they do have to be taken into consideration.

But this is a GXS blog. So let’s talk about GXS. Prior to my joining the company, GXS had been investigating and piloting agile practices. Part of my interview involved a discussion about my experiences with and thoughts on agile, so I could tell before taking the job that I would get to work on something that interested me even if I found EDI to be very dull. Now, those of you who work in B2B EC and SCM know that EDI is far from dull, but I came from another industry, came of age in the era of hypertext and had only heard the term slurred in a hushed voice on subway trains.

Agile methodologies have a consistent theme about doing things in context. Work in context. Develop requirements in context. Engage the customer in context. Abstraction, vagueness and high-level thinking are less likely to produce solutions that you don’t dislike using than solutions produced context. An example of an out-of-context process: heavy-handed change management processes. The goal is usually to reduce the disruption of requirements added during a development cycle. But in context–that is, the real world–change is not a bad thing and so it’s better to take change as a core principle of development and figure out how to make change less disruptive not by reducing it but by capitalizing on it.

So, I have to re-evaluate agile because agile itself must be placed in context. Consider this principle of agile development from the Agile Manifesto (http://agilemanifesto.org/):

Business people and developers must work
together daily throughout the project.

Well, that worked great at my old company where development for my product line was focused into one wing of one building. But GXS, thinking in context, is pretty global (http://www.gxs.com/gxs/worldwide.htm). You can’t have all the team members in the same room, in the same time zone, throughout the project. At any given point, some are wake, some are asleep, some wish they were asleep and some probably wish they were more awake. So, right there, is a big challenge. If we agree with that principle, how do we attain it without physical proximity from the stakeholders? That’s a context issue. If you’ve been reading my blog, you know that I have a habit of flying overseas for a while to spend a few weeks sitting on the development floor working hard on achieving a good CDPD rate and providing customer perspective during development.

For 2008, one of my goals is to propose a new release management strategy. Some GXS deployment practices still have the feel/smell/taste of distributed application roll-out. Being an outsider, maybe it’s more pronounced for me. A few colleagues of mine with more tenure might disagree. But, never the less, it’s something I’d like to investigate and tackle. GXS uses customer meetings to review and validate requirements during development as well as beta programs and other agile strategies today. Where else can we optimize?

Given that the Trading Grid is a hosted, on-demand SaaS platform, we owe it to ourselves and to our customers (hopefully including you) to capitalize wherever we can on increasing the speed and accuracy of our delivery. So I’m doing some research and some thinking on this release management question. I’m starting from core principles. What would be valuable to us and our customers, regardless of any other considerations:

• Faster turn-around on defect fixes.
• Faster time-to-market changes from customer feedback.
• More predictable time-to-availability of your defect fixes and changes from your feedback.
• Predictable recurrences of larger releases, such that you can plan business impact and manage more by exception.

When I say faster, above, I don’t necessarily mean that it takes less time to develop. I mean that rather than waiting for a big release in which to include a bunch of fixes, fixes would be pushed out closer to “as ready” than “in bundle X.” Obviously, we do this today, but we might not be doing the best that we can in context.

One interesting habit that we still have today in the Trading Grid is the idea of a release number. We assign outward-facing version numbers to Trading Grid solutions. As if you’d call in one day and say “I’m using Intelligent Web Forms version 5.23.” We don’t put version 6 in your shop and version 7 in Bob’s shop. It’s hosted, on-demand Saas. You’re all using the same version, all the time! Now, there’s value for the sales guys to know that a new release has come out and to differentiate the functionality from any previous release. But I’m not convinced that saying 5.23 is any more valuable than saying March, 2008. Certainly, it’s no easier to confuse March, 2008 with June, 2008 or with March, 2009.

Now you know why I gave up on being a presidential speech writer. This exercise does help me order my thoughts, raises new ones and gets my engines turning. I might do a blue paper on this, internally. That’s kind of like a white paper, but I’d print it on blue paper so people pay more attention to it. Sneaky, huh? If I do, I’ll try not to abuse bold as much. As always, feedback is welcomed and will be incorporated early in the process with minimized disruption.

I’m back from India and suffering from the normal wicked jet lag. It’s almost 3pm and the only thing keeping me awake is my kids who are constantly strangling me, fighting for back rides. I think they missed me. Anyway, I meant to link to an article in India and it just came to mind:

Jared Spool of UIE Brain Sparks discusses eBay’s plan to focus on user experience.

eBay has a huge market share in online auction. They are “the name” in online auction. Just ask yourself where you would go if you wanted to auction something online. Yeah, eBay. So once you’ve captured the market, you have to keep it. What a better way to keep your users than to keep them happy and enjoying using your product.

Amen. The post is a good one and I’m going to try to pay attention to eBay’s playground site. I haven’t used eBay in a long, long time but I do notice one striking difference between then and now on both the main and playground site. The page is WAY less cluttered. eBay used to look like the classifieds pages from six different major metroplitan cities got together, drank too much and threw up on your browser. It was a mess. Cleanliness is a good thing.

Here’s a quote I like from Jared’s post:

“If your executives took a major interest and started promising customers and shareholders for a dramatic instant improvement in your product/services user experience, would your organization be ready for it? Do you know what you would do?”

Maybe I’ll get clearance from legal to post my list

Per my previous post, I am closing out my second week in India on project review. I promised to share some of my impressions on the project (work stuff), so they are included below. Also, I can’t resist the chance to put on my sociologist hat and make a few side comments about India which have nothing to do with B2B!

Work Stuff

I mentioned before that the main focus of this trip is to do acceptance testing on the upgrade process from EC SupportNet to Trading Grid Online. This is a big project for me, for which I’ve analyzed requirements across organizations, customer types, geographies, etc. for a long period of time and produced a large body of use cases. This is my baby. Therefore, I hinted that I was somewhat nervous as to how it would look. Granted, I have seen the components develop along the way–we don’t just throw a requirements document over the wall and see what comes back later–it is an entirely different experience to tie all of the components together across teams and run through it as you, the customer (pardoning public readers and employee readers, for a minute).

And, I’m quite happy. Everything so far has matched the pictures in my head and there are even some internally driven improvements to my requirements that really indicate the engineers understood the project and the user experience at an interaction level. One of my next major tasks, which I will work on next week, will be to go through the wizard steps again and to produce the on-screen guide text. I am conscious of the fact that TGO has a more robust identity model than ECSN and so I want to not rely on some separate help screen but to use the wizard itself to guide users in setting up a good working organization on the Grid.

I’m not sure how atypical it is for a product manager to produce this kind of assistive text. But, in the case of this project I have been the driver behind the customer experience. I should be well positioned to guide you through the process. I hope you agree when you use the wizard.

Non-Work Stuff

Faisal took me to Lalbagh Garden on Independence Day. I have experience with large crowds, but this was an altogether new understanding of the term “crowd.” If you hear on the news stories of people being trampled to death when crowds get agitated or frightened and that’s hard to grasp, you only need to visit Lalbagh Garden on Independence Day and you can understand it quite immediately.

There is a lot of discussion here on leadership, infrastructure and India on the rise. I think it is quite an interesting time to be a global company with a presence in India and to be an Indian. But my mother was born in northern India and so, interesting or not, I always enjoy the chance to eat some good Hindustani khana.

On another side note, if you haven’t read Melanie’s post regarding dentistry, you may find it amusing that while reading her thoughts on root canals and data cleansing, I bit my gums hard and it hurt for a few hours. Let’s all convince Melanie to write about comparing e-commerce to winning the lottery so that the next post I read will come with a more desirable side effect