Cloud computing continues to heat up since I blogged about my experiences with Heroku (on-demand Ruby on Rails development using the Amazon Web Services).  If you work in the IT industry, the cloud ware concept may be creeping in to your lexicon, your discussions, your Gartner reports and your Friday afternoon, 4:30pm daydreams [ed: I admit *no* guilt].  Here are some highlights related to web apps, in non-chronological order.

Heroku secured a $3 million round of funding.  To give you a perspective on scale, that amounts to $1 million per founding employee.  Among other things, the blog post noted that some funding will be devoted to supporting the impressive numbers of applications already being built on the platform.  They have definitely found some pain points or at least a target market eager to build web apps on the cloud.  This kind of service offering might present some future opportunities for custom internal app development, light-weight service integration or even customer portals which need to combine internal, product and vendor-provided APIs.  At the very least, it drastically lowers the financial risk of prototyping and building proofs of concept to sell to the business by taking the platform cost almost to $0.

Google App Engine launched some time after Heroku offering the ability to build web applications on Google’s famed cloud infrastructure.  Google App Engine is more restrictive and more targeted in its current intended usage than Heroku—basically, purely non-relational database and access to external data sources using only HTTPS.  On the flip side, the non-relational database and the ability to use Google Accounts for user access are big bonuses for some types of projects.  The big news last week was that Google unleashed invites beyond the original limit of 10,000 developers (which included yours truly, serial early adopter) and announced pricing.

If you’re interested in seeing under the covers of Google App Engine and you’re interested in seeing an example use then check out this code.  I spent my lunch break writing a simple (very, very simple) form on App Engine which lets you send files across the Trading Grid to a receiver EDI address.  It’s a proof of concept using a test mailbox, so the point is really just to demonstrate the kinds of mash-ups that could be achieved in the cloud with your internal APIs and service provider’s (like GXS) APIs.  If you want to know more about our HTTPS or SOAP capabilities provided by the Shared Message Gateway on Trading Grid Ultra, drop a comment.

So, that’s about all I had for this edition.  Clearly, the cloud is seeing interest, activity and investment.  If you aren’t doing anything with or thinking about the cloud yet, you probably will be within the next few years.  There are some big developments ahead, I’m sure.  Heroku supports Ruby and Google supports Python.  Where are the statically-typed languages on the JVM (Rhino on Rails?) or on .NET?  Where is Microsoft with the .NET cloud?  Where is Yahoo! (and will the first question eventually answer the second one too ;-)?

To quote Under the Influence of Giants, “meet me in the clouds.”

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.

You haven’t heard from me in a while.  Lots of top secret projects.  Secret at least, but hopefully you think they’re top notch.  I’ve been checking out the recently set up GXS Insights portal.  Lots of good stuff there, and I like the fact that we’re making more of our content available outside the site via video services like YouTube and Google (’s Other) Video.  I also particularly liked our SVP and CTO Rowland Archer’s write-up called “A World Without Version Numbers.”  One of my top secret projects, [—redacted—] involves re-visiting how we internally and externally notate releases on our Trading Grid platform, the value of which Rowland explains well.

I’m a big fan of hosted services even in my personal life, where I make extensive use of tools like Backpack for lightweight PIM and Newshutch for RSS.  I have no clue what version number I’m using.  Aside from any internal development environments at the service-provider’s level, the only version relevant to me is the production version.  If you call GXS for support on your Trading Grid service and they ask what version number you’re using, tell them “I’m using version Tuesday, October 23, 2007, GMT-5.”  Except, make sure you update for your actual date of call.  They wouldn’t ask you, of course, so I’m just being difficult.

If you’ve taken the dive into RSS because you woke up one morning and couldn’t face the prospect of reading 40 different web sites before work, make sure you subscribe to the Insights RSS feed.  You’ve already subscribed to all of our blogs, of course, so you wouldn’t want to miss any GXS thoughts.  If you aren’t using RSS yet, you should give it a try.  It might come in handy with one of these top secret [————–redacted————-].

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

I’m gearing up for another trip to India for several project reviews and a product acceptance test.  I am generally excited about traveling anywhere that offers curry on the breakfast buffet.  However, I’m doubly excited when I get to formally qualify a release for beta.  It means I get a really good, tangible, holistic look at what I’ve been working hard on for a long period of time (in this case, almost since I joined GXS).

No amount of design documents, test case reviews and UI reviews will ever substitute for sitting down at a keyboard and operating the tool.  It’s a bit like unwrapping a new album from your favorite artist, though.  You’ve heard the samples and read some reviews.  There’s a period of nervousness where you hope it meets the expectations in your head.  Although, with acceptance testing you do have the option to not accept the release.  I guess you might be stuck with the album

The project in question is a big one–it is the upgrade path from our former Trading Grid Messaging Service Portal, EC SupportNet to our new and improved Trading Grid Portal, Trading Grid Online.  For TGMS customers reading this blog who may be using EC SupportNet, I’ll try to post some commentary during the trip about things I’m especially pleased with and wet your appetite for getting more out of the Grid!

Of course, you’ll have to wade through more drivel about curry.  Apologies in advance.

In my last post, I talked a bit about Scaleable UE, or the idea of a user experience which intelligently grows and adapts to your usage and your subscription state over time.  I gave some examples, but I thought I could illustrate the point a bit better by talking about a particular function I’ve been working on and by describing the balance of too much versus too little usability that has to be achieved to produce good UE.

Trading Grid Online has a good on-demand custom search/report facility.  You can ask questions like “show me all 850s in the last 3 days from interconnect trading partner X which have been rejected inbound to the GXS.”  Of course, you use a form rather than natural language to specify a query like this.  I want users to have the ability to save these reports as one-click canned reports in the future–that makes sense.  However, users often need to run a few queries in a pinch and work on the results without thinking about the long term.   Nothing shortsighted about that.  Business is fast.

So I’ve been toying with thoughts on how best to help users store common queries as canned searches without being disruptive or taking extra time.  At first, I was thinking that we could count queries and when a user runs an identical more than X amount of times in a certain time period we could show an option saying “You’ve run this query X times in the last Y.  Would you like to name it and save it as a quick search?”  That would be slick and probably useful.  It lets you do the things you need to do and helps you scale up your usage without having to do a lot of up front work.

However, there’s a downside.  It requires defining X and Y up front.  If we said a report run more than 3 times in7 days would trigger this notice, you can imagine that troubleshooting a specific problem with a specific trading partner might result in trigger this several times even searching with a specific control number which would not be useful as a saved search.  If we set the bar too high, users will have to run common reports over and over again before it triggers.

An alternative is to track a certain number of queries–say, the last 30–and keep a count.  If we show a rolling list of top queries with a count, users can re-execute common queries without any extra steps.  Also, a user could identify queries from the list they want to save at any point.  This approach accomplishes many of the same goals, but also provides a work-free way to re-execute queries that I might not want to save but might be using frequently for troubleshooting a specific problem in the short term.

One of the toughest jobs in usability is to find an approach which facilitates users without disrupting them.  A common misconception about usability is that it strives to replace the user’s need to think.  Business users are smart, but they’re busy people.  An approach which lets the user think and judge in a fast and facilitated way is often the best approach.  If you think on the first possible solution for a while, you can see that even if you come up with the magic value of X and Y (number of report runs and time) for one user, it might be very different for another user’s habits.  Then comes the endless proliferation of config options.  Nothing simple about that.  Let the user drive, but make sure it’s with a smooth steering wheel.

Automotive analogy in tribute to Mark Morley.  Hope that wasn’t too boring.  I wanted to give you a bit of insight into how we approach design and usability factors and I felt like I left the last post hanging on too theoretical a note.  Until next time.

In the process of developing or refining software and services, we always pay attention to scalability to ensure that transactions, searches and other database-intensive or high-volume actions do not decrease the responsiveness of the service overall. You, as the user, rightly expect that most actions you perform with a business system will occur in real time or near real time rather than coffee break time.

In addition to making the underlying plumbing of the system robust, good engineering is necessary to make the user interface (e.g. desktop or web application) continue to respond to your input and your directions as fast as you can issue such commands. We think of this as a scalable user interface or UI. The web server needs good resources, caching should be used when appropriate and these days we can even use techniques like AJAX to perform some operations within the page rather than requiring a costly trip to and from the server and a full re-draw of your browser page.

Designers and developers have gotten noticeably better at scalable UI and UI in general. That’s a blanket statement, so it’s guaranteed to be false somewhere. The “Web 2.0″ mindset has, however, improved the attention to more than just visual design–to making screen layouts and workflow facilitate the user rather than make them spend lots of time reading, peering around and not using the product efficiently. In Trading Grid Online, for example, we sequence some sections of the portal to go from overview/scorecard mode to deep-dive detail in a logical manner on-demand. Detailed status reports may not be necessary if everything is in happy working order for a given time period.

This type of scalable UI design, however, focuses on a single customer workflow in the service. Let’s make this search faster. Let’s re-design this input form. I think web application designers in particular need to spend more time focusing on scalable *User Experience* which takes a broader view of the customer’s interaction with the product.

Consider this: after we’ve optimized a custom search form and made the form faster, what’s next? We’re not done. Trading Grid Online users, more than anything else, access and run reports. Your trading partnerships might not change every day. You don’t necessarily need to review your online invoice three times a week if you’re invoiced monthly. But your transactions flow all the time and sometimes they fail (not yours of course, but just for the sake of the argument). You need to monitor for errors, you need to research errors and you need to validate new types of transactions or new processes with partners that have not been as time-tested as some of your core historical transactions.

Scalable UE looks at your common behavior and says: “The form is optimal and the search is fast, but this guy does a core set of searches or reports five times a day, six days a week. Let’s figure out a way to help him not have to use the form at all.” The helpfulness and efficiency of the service scales with the amount of time you spend using it. This doesn’t require artificial intelligence. I want to, for example, note that you have run an identical query against your inbound transactions each day this week and simply offer to save it in a one-click list or automatically present it each time you log in. I want the service to reward you the more time you use it–I want your experience to scale with how often you touch the interface. Here are a few examples I have seen to illustrate this point:

Good: Microsoft Word Auto-Correct - this feature learns over time commonly transposed letters and other unique mistakes that you make and helps automatically correct them (if you want it to). Although I find Word formatting very aggravating, I do appreciate this feature. After using it for a while, it gets better at correcting “my” typing.

Bad: Windows Desktop Cleanup Wizard - this component makes the assumption that you do not put things on your desktop as part of an organizational strategy, but just put things there an occassionally need the system to help you hide some of them to make more room for others. While that may be how some people use the desktop (I know many of them), it generally causes disruption instead of benefit. If you watch people, they get very attached to the location of icons and a slight change can make for some confusing moments.

There’s a fine line to draw between being invasive and disruptive and being generally helpful. I’d love to see more examples of this. Leave a comment. I will continue to pay attention.

I just returned this weekend from a business trip to India.  Aside from being a very productive trip, it was also personally relevant.  My mother lived in India until she was 18.  As a consequence, I grew up with some Hindustani cuisine, religious and secular decorations and quite a few stories.  The last two opportunities for me to visit with her coincided with my graduation and my marriage.  This was to be my first trip.
Friends and family alike have asked what I found to be most amazing.  The answer is simple: I did not see any traffic accidents while I was there.  That is amazing because driving in major Indian cities makes DC commuter rush hour look like a relaxing weekend spa.  More people with more vehicles in the same space, 24 x 7, with no lanes, signs or lights.  Traffic is regulated by frequent use of the horn and by constant bravado.

This reminded me of an old post on the 37Signals blog.   The post discusses the “less is more” philosophy of roundabout traffic circles and applies that concept to web software.  Admittedly, it’s a bit of a stretch.  37Signals is sometimes controversial–they are the creators of Ruby on Rails and a number of popular web-based productivity tools to which I am thoroughly addicted.  Most of the controversy comes from their frequent criticism of software development, web design, enterprise software, the public web company craze and other things which people feel passionate about.

Although this was an old post, I remembered it while thinking about the traffic in India.  I started to think about what lesson there might be, if there would be any, for the Trading Grid and for software in general that could be derived from the traffic in India.  This was the most interesting thought:  speed limits are not necessary, since the traffic is too constantly high volume to present an opportunity to speed.

I thought this was a very good example of embracing your constraints.  Embracing your constraints means not fighting against a limitation you have, but accepting it and building it in to your design as a principle or design factor.  Speed limit signs would rarely be applicable.  In fact, they might only be distracting.  In that kind of traffic, people need to watch their bumpers and not read signs.  On the off chance that there is an open road, there’s an incentive to move a bit more quickly and keep it open as long as possible–the chance of a multi-vehicle accident is lower as well since the road is open.

Embracing your constraints or acknowledging the environment in which your tools are used is an important factor in good, human-friendly design.  When I write requirements or work on design with the engineers, I always try to present the customer’s working environment as a driver in the design.  The average EC coordinator, for example, probably does not have two hours per day to sit down working on complex reports and workflow.  They generally need snap, overview health or checkup information.  If there are exceptions, they need to narrow in.  Sometimes, they need to isolate a particular event when supporting their partners.

The dashboard, drill-down, deep-dive approach to analytics workflow is an example of embracing your constraints and scaling your tool according to how much attention the user can really pay during a normal work day.  I think Google Analytics does this very well, and that is even more true with their new UI.  I could also bore you with other examples, like our web forms security time-out handling designed to recognize end users in the shipping dock or the warehouse moving away from the station constantly, while still in progress on forms.  But what I’d like to hear is what constraints you face (or your customers, if you’re not an end user) during the day that your tools need to embrace.

Do you get no more than 5 minutes of face time with your apps in one go?  Do you work in a noisy environment where audio alerts are always drowned out?  What constraints do you need the Trading Grid, or any other tool, to better embrace?

P.S. - Sorry Mark .  I will leave all the driving topics to you in the future