All posts by Kerika

About Kerika

Kerika is the only task management tool that's designed specially for global, remote teams.

First, we kill all the managers. (Or, maybe not.)

In earlier posts we described our decision to chose Amazon’s EC2 over Google App Engine in recent days, and as part of the business perspective we noted that:

Amazon is accessible: both Amazon and Google have engineering centers in our neighborhood, and Amazon’s is, of course, the much larger presence, but the real issue was which company was more accessible? Amazon does a lot of outreach to the startup community in the Seattle area – Jeff Barr is everywhere! – whereas Google is a lot more aloof. It’s much easier to find an engineer or product manager at Amazon who will talk to you, and that really makes a difference for a startup. Real people matter.

Events in the past week have reassured us that we made the right choice. The very end of that post on choosing EC2 included a passing grumble about some long-standing problems with Amazon’s Elastic Load Balancer.

What happened following that blog post was a pleasant surprise: an old colleague saw the post on LinkedIn and forwarded it to someone at Amazon, who promptly contacted Jeff Barr, the peripatetic and indefatigable evangelist for Amazon Web Services.

And within just one day after our griping, Jeff asked for a meeting with us to see how Amazon could make things better for us. This level of responsiveness was, frankly, astonishing when one considers the size of Kerika (rather tiny) and the size of Amazon (rather Amazonian).

We met Jeff today, and are happy to report that this ELB issue will soon go away for us and everyone else. But that was a minor aspect of the meeting: much of our discussion was a wide-ranging conversation about Kerika, collaboration platforms and the many uses for cloud computing in different market segments.

And the best part was finding out that Jeff had taken the trouble, earlier in the day, to try out Kerika for himself.

Returning from the meeting, we couldn’t help but reflect upon cultures of the two companies that we are relying upon for our business model: Amazon and Google. Amazon is providing the cloud computing infrastructure, and Google is providing the OpenID authentication and, more importantly, the Google Docs suite that is integral to the Kerika product offering. Both sets of technologies are essential to Kerika’s success.

But the cultures of these two companies are clearly different: Amazon relies on both technology and people, whereas Google, it would appear, is purely an online presence. (To be fair, we must note that while both companies have engineering centers in the Seattle area, Amazon’s footprint is many times larger than Google’s.)

But, still: who could we have tried to reach at Google? Who is the public face of Google’s App Engine? Or, of Google Docs, for that matter? There are two substantial Google engineering centers nearby, but Google the company remains a cloud of distributed intelligence – much their servers – accessible only via HTTP.

A recent article at All Things D speculates that Larry Page may eliminate Google’s managers in large amounts, in order to free the animal spirits of the engineers, and a similar article on TechCrunch notes that “Page famously has a low opinion of managers, especially product managers who try to tell engineers what to do.”

There can be no gainsaying Google’s engineering talents, or its remarkable achievements, but will Google 3.0 be an organization that has even less human contact with its customers and partners?

Jakob Nielsen’s Power of Ten Principle

We like to think that we have done a fairly good job in terms of designing our user interface. A major influence was the writings of Jakob Nielsen: Kerika’s CEO had the good fortune to meet Mr. Nielsen at a conference in the mid-90s, when corporate America was slowly waking up to the reality – and permanence – of the Web, and Mr. Nielsen just been laid off from Sun Microsystems, which, in its infinite wisdom, decided to get rid of their entire Advanced Technology Group as a cost-savings measure.

Mr. Nielsen fast became a popular speaker at the few Web conferences that were held in the early days, and one could listen to his speeches practically for free. (Now, we understand, it costs about $15,000 to get Mr. Nielsen’s attentions for a single day…). Mr. Nielsen went on to found the Nielsen Norman Group, with Donald Norman who had done pioneering work on product design, and he created a simple newsletter-based website (www.useit.com) that remains a wonderful source of research on Web usability.

What was remarkable about Mr. Nielsen’s approach then, and which we think still is a relatively rare ability among the many design pundits today, is a rigorous emphasis on scientific observation and testing. Mr. Nielsen has never given the impression of being someone who has relied very much on his instincts when it comes to design; he has always emphasized the need for usability testing.

Too many other “pundits” – and here we use that phrase in the American sense of a talking head, rather than the Indian sense of a priest or wise man – rely upon what they believe, often erroneously, to be a superior design aesthetic which they deftly package with enough jargon to make it appear more like fact than opinion.

(Today, we have a beta version of Kerika that we are using to gather usability data: we are sitting down with our initial users, directly observing their reactions – their many sources of confusion and occasional moments of delight – to see fine-tune our user interface. We believe we have done a good job on the main aspects of the design, but there are many rough edges that we still need to sand over, to get the “fit-and-finish” just right. So, while we are immensely proud of what we have accomplished – and the tens of thousands of lines of Javascript and Java code we have written in a remarkably short period of time – we are only too aware of our shortcomings as well…)

Mr. Nielsen writes mostly about website usability, but his observations and principles are very apropos to the design of Web applications as well. We have tried to incorporate his suggestions on perceived affordance and information scent in the various elements of our user interface, but when we expand the discussion from UI to UX – from user interface to user experience – it is clear that performance is a key contributor to an overall good experience.

In his article on the “Powers of Ten” principle, Mr. Nielsen points out that 0.1 second is the response time limit if you want users to feel like their actions are directly causing something to happen on the screen. If a system responds within 0.1 seconds, the system essential disappears from view: the user believes he or she is directly manipulating the objects on the screen.

(A simple analogy is the mouse: when one moves the mouse, the cursor moves immediately on the screen, which is why it is so easy to learn to use a mouse: one quickly forgets its presence altogether, and concentrates upon looking at the screen instead. We often see people who hunt-and-peck at their keyboards; when was the last time you saw someone look down at their mouse to make sure they were moving it correctly?)

To that end, we have tired to ensure that most user interactions when using Kerika fall within the 0.1 seconds time limit: when you add an item to a page, or move it, or delete it, it happens instantly.

Next up is the 1 second time limit, and here we quote Mr. Nielsen:

When the computer takes more than 0.1 second but less than 1 second to respond to your input, it feels like the computer is causing the result to appear. Although users notice the short delay, they stay focused on their current train of thought during the one-second interval.This means that during 1-second response times, users retain the feeling of being in control of the interaction even though they notice that it’s a 2-way interaction (between them and the computer). By contrast, with 0.1 second response times, users simply feel like they’re doing something themselves.

In the Kerika user interface, there are moments when a user will experience a 1 second response time, although not very often: most commonly, this happens when we are waiting for an external website to respond. For example, if you have built a “video wall” of YouTube videos, you may have to wait a second (or two or three) for YouTube to respond when you decide to play a video. This, regrettably, is out of our control. But for the parts of the user interface that are within our control, we have tried to stay within the 1 second time limit.

After 1 second, users get impatient and notice that they’re waiting for a slow computer to respond. The longer the wait, the more this impatience grows; after about 10 seconds, the average attention span is maxed out. At that point, the user’s mind starts wandering and doesn’t retain enough information in short-term memory to easily resume the interaction once the computer finally loads the next screen. More than 10 seconds, and you break the flow.

Nothing, in Kerika, breaks the flow.

The development environment that’s worked for us

In our last post, we referred to our “dogfooding” Kerika by using for our testing process. Here’s some more information about how we set up our software development environment…

Our Requirements:

  • We needed to support a distributed team, of course. And our distributed team had a variety of preferences when it came to operating systems: there were folks that liked using Windows, folks that had only Macs, folks that used only Linux, and folks that liked using Linux as virtual machines running inside Windows… Since we were were developing a Web application, it didn’t make sense – neither from a philosophical perspective nor from a business strategy perspective – to insist that everybody use the same operating system. If we were going to build for the browser, we should be able to use any operating system we preferred: our output was, after all, going to be Java, Javascript and SVG.
  • We needed to deploy our software “in the cloud”, and that meant making sure our software could run well in a Linux environment. Microsoft’s Azure service was still relatively new, and, in any case, our back-end developers were more comfortable with Java than ASP.Net, so that fixed Java on Linux as a back-end requirement.
  • Our software had to run in all browsers: that effectively meant “modern browsers”, that happy euphemism for browsers that would conform to HTML5 standards. When we started development, we were uncertain about how Internet Explorer 9, which is still in beta, would evolve, but we have been very pleasantly surprised by the evolution of that product. (And a discussion in December with Ziad Ismail, IE9’s Director of Product Management, has since further reinforced our belief that Microsoft is very serious about standards compliance in IE9.)
  • We decided early on to build our front-end in Javascript and SVG, rather than Flash. We know of very few applications, even today, that attempt to deliver the kind of user interface combined with real-time networking that Kerika does using Javascript, and it’s not that we like crazy challenges because we are crazy people –we just didn’t want to get caught in the crossfire between Apple and Adobe over Flash. Having to choose between Caradhras and the Mines of Moria, like Gandalf we choose to brave the Mines…

Our choices:

  • Amazon’s EC2 and RDS for creating test and production environments; A2 hosting for our development environment. The choice was between EC2 and Google App Engine, and we will talk more in a separate blog post about why we chose Amazon over Google.
  • Eclipse for the developer’s IDE: it was cross-platform, and since everyone wanted to stick with their favorite operating system, it was Eclipse that straddled them all.
  • Jetty for web server: the choice was between Apache and Jetty, and we went with Jetty. Why? Well, that’s a blog post in itself…
  • Git for source code control: we looked at Subversion, but Git is better suited for distributed teams.
  • Maven for build management: once we decided on Eclipse, Git and Jetty, Maven kind of fell in place as a natural choice, since it worked well with all of the above.
  • Bugzilla for bug tracking: it’s a great tool, with a simple, flexible interface and it has matured very nicely over the past decade.

All of this has worked out quite well, and we would recommend this stack for other startups that are looking to develop Web applications.