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.

Firefox 3 has been officially unleashed on the web.  If you’re a Firefox user, you may have noticed that Mozilla decided to establish the world record for downloads in a 24-hour period.  The Guinness Book of World Records team is still validating the results and looking for cheaters but the unofficial count is over 8 million downloads.

Of course, it works well with Trading Grid Online.  From my own experience so far with the beta and the new version, the improved javascript speed works well with our AJAX-based audit log interface.  And the web marches forward.

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.

Blame Bryan Larkin for this one.

***

GXS Managed Services as a Sonnet

Translate and map your business processes.

Ramping up your partners around the earth.

Connecting to your back-end ERP.

How much is your IT sanity worth?

Your supply chain should be outsourced to us

To root errors and data problems out,

Connect you to TPs, no muss, no fuss,

Earn bragging rights and ROI, no doubt.

Now focus on what makes you best out there.

Let us get your initiatives unfurled,

Partner integration out of your hair

And grow your business all around the world.

You and your customers deserve no less.

Let our experience bring you success.

***

I couldn’t quite twist “Center of Excellence” into iambic pentameter–in fact, I’m not entirely convinced I twisted some of the other terms well enough.  Do me a favor and pretend the verbal emphasis is on the first syllable in “supply?”  This exercise, fun though it was, reminded me of why I stick to free form.

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

My family had a lovely Thanksgiving dinner with a husband and wife–choir director and friend of my wife, respectively–this past week.  The wife is a professional chef and produced a feast three times the size of what would still be overkill for the eight adults and three small children in attendance.  This included two enormous fried turkeys, about 9,000 metric tons of stuffing and some interesting experimental dishes like battered, fried cranberry glaze.  Honestly.

However,  one of the husbands in attendance left several hours earlier than everyone else.  Far from minding his caloric intake, he was heading out to line up for a huge discount sale on an HDTV at a retail store the following morning.  Plates were prepared for him and he also took a van to park on site with bottled water for all the other campers.  Sure, he might be slightly crazy, but at least he was well prepared and not as crazy as the other people who arrived even earlier.

I’m not a big shopper.  I never have been.  I tend to stay home around Black Friday to avoid the usual (probably hyped) tales of people fighting over spots in line, tension in parking lots and the other types of things that happen when excited people assemble in large masses.  I’m definitely an online shopper, with a few notable exceptions such as clothing and groceries.  The past few year’s end media sweeps have frequently discussed the competition between online shopping and physical store shopping for holiday market share.  If you look at my ilk, you might see that clearly the Internet has a big impact on physical store shopping.  But, if you look at my friend and his van full of bottled water, there are clearly reasons to hit the stores.  The shopping experience.

In this case, there are few key factors in the shopping experience:

• A deep discount on a popular piece of electronics.  This kind of promotion relies on a good supply chain, among other things, to get the word out about the discount and to have appropriate inventory levels to stores based on a specific publicized date.
• The collective “geek” or “Otaku” factor (to slightly mis-use a Japanese term) of camping out, as if one were after hot-selling concert tickets.  This is driven by digital communications: message boards, bargain hunter websites, word-of-keyboard through social networking.

So, rather than being a competitor in this case, the Internet became the engine that drove him (metaphorically) to stand in line for the sale.  Although there’s not much research in this area, I also wonder how often someone goes in to a store to check out a product in person and then goes home to buy it from the company’s website.  That’s probably far less common, due to adding shipping costs and the fact that web-only promotions are not widespread and deep enough to get over the “have it in my hands today” factor.  Perhaps there’s more we can do to use physical shops to drive online sales and online activity to drive store visits.  The relationship between brick and mortar and bits and bytes shops is still in its infancy.

Happy holidays, and let’s hope for big retail numbers and no supply chain headaches, online or offline, this season!

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.