Category Archives: Information Technology

Learning to Code

Posted on by

Knowing how to code is a really useful skill for anybody in business. For an entrepreneur, it means you can validate your high-tech startup idea without having to out and recruit a CTO or spend a lot of money on an external software development shop. But even if you’re running a pizza place, a little bit of coding experience can save you a lot of time when you’re playing with Excel spreadsheets late at night trying to figure out how much money all that fancy pepperoni is costing you.  Most people are in the middle. I have a lot of friends who went into management consulting – the ones who know how to write little bits of software to help them do their jobs tend to get a lot more sleep at night.

The other reason to learn programming – even a little bit of programming – is that it makes the whole process of interacting with technology a lot less scary. Computers are black boxes, and people don’t trust black boxes.

So I thought CodeAcademy was pretty cool. It’s a web site that takes you through some simple programming exercises in JavaScript, which is one of the most common programming languages on the web. In half an hour you can go from no experience at all to writing simple programs. They don’t do that much, and to solve real problems you’ll have to do more. But it’s a nice way to start out – and even if the student doesn’t go any further they’ll benefit from a more visceral understanding of how computers work. In the best case, it will teach them to recognize the kinds of patterns that can be solved with a little code.

Having written that, I suppose I should consider the opposite extreme. Just because you can write simple programs after half an hour of interactive lessons doesn’t mean that software development is either easy or low-value. It’s not. A top-tier software engineer took thousands of hours to get that way.

Expensify: A Case Study

Posted on by

I hadn’t heard of Expensify before I saw a TechCrunch piece on the company this afternoon. I happened to have several expense reports outstanding for a consulting client. I hate doing expense reports – scanning all the pieces of paper, putting together a cover document and putting everything into a PDF. Except during the relatively rare interludes in my career where I’ve had an assistant I can thrown receipts at and then race out of the room (Hi Andrew!), I’ve always been really bad at these. I have no excuse: my first boss taught me many useful skills, and precise receipt keeping was one of them. I just hate doing the reports. For that matter, I was never all that good at getting the receipts to my assistants.

Expensify LogoSo after reading the TechCrunch article I logged into Expensify, and half an hour later all my consulting expense reports but one were done and sent off. All of my expense reports for Linked Medical, our new startup, were done too, and filed in the “pay when we have more money” bin. I don’t think any web based tool has ever become so essential to me so quickly. One of the first “ASP model” web applications I ever used was the Ariba purchasing system, after my early-2000s startup became part of a much larger company. It was truly terrible. Fortunately I had an assistant.

Expensify’s product is pretty far from that original Ariba system. Sure, the software isn’t perfect, and a few of the rough edges are downright weird considering the overall level of polish (uploading a “.htm” file receipt gives you an error message, while “.html” works just fine). But they did at least six things right, and those six things are relevant for lots of different applications:

  1. Make it brain-dead easy to start. I typed in my email address and was done. They sent me an email which I later clicked through to set my password. There was zero friction, which is incredibly important. I could also have logged in with my Google credentials, which is a nice touch – but this was actually faster.
  2. Make it easy to explore. The home screen is a series of big boxes identifying common interests for new users. I’d heard about the mobile tool first, and it was one click to learn more. The basic navigation is very simple, and maps to things like “Receipts”.
  3. Use Mobile for the right things. This is really important. I do not want to create an expense report on my Android phone. I probably don’t want to create one on my iPad either. When I’m mobile, I want to do one thing: easily record expenses. So the mobile app does that very well – I can photograph a receipt with my phone, and/or enter expense details on a simple screen. There are two big buttons when I open the application, one for each option. It’s very responsive. And I don’t need to keep the small receipts anymore.
  4. Integrate seamlessly, but don’t make me do it first. Another box on the home page is “Link Credit Cards.” It took two minutes to link in my American Express, and then I had a huge list of transactions to choose from.
  5. Give me multiple avenues to learn the software. I can add expenses to a report from the report, or I can look at expenses and add them to a report. Same with receipts. I never found myself having to go back into the wrong area of the application. When I looked for a feature, it was there.
  6. Don’t make me learn the whole thing. Expensify supports “policies” for corporate expenses. There are some other features there too around submissions and approvals. I don’t need those yet, so I didn’t have to use them, learn about them, or worry about them. As it happens I have looked at them, and they’ll be useful in the future – I just don’t need them now. Complexity kills, especially when you want casual users to adopt a system without external support. Expensify landed me as a customer because I was able to finish an expense report in 15% of the time it would have otherwise taken.

They also do a good job of thinking about ways that new technology lets you change the underlying workflow of an old process. In this case, it’s expense reports for receipts under $75. If you link a credit card, you can import expenses and the system generates an “eReceipt” for that charge. Expensify prints it in the report and adds a bar-code, and it can be verified with the site later. The company will stand behind the fact that the expense was imported from a credit card statement, up to and including during an audit from the IRS. If your corporation accepts the eReceipts, you can stop carrying around those little printouts from taxis. This is something that the old Ariba system – or any non-cloud expense account system – simply can’t provide, because it relies upon the trusted connection to the credit card company, and on Expensify’s willingness to stand behind the integrity of that data.

When turning workflows into products, it makes to ask what capabilities are available now that weren’t available on paper or weren’t possible electronically with the technology of a few years ago. The eReceipts are a great example of this. Development for the iPad should be triggering a lot more of this kind of lateral thinking, as we all adjust to touch-and-swipe interfaces instead of keyboards and form fields.

Naturally there are a few things Expensify can improve on. I’m glad I didn’t need to take a training course to use the tool, but a five-point introduction to the core concepts would have been nice. The most opaque thing about the system is the relationship between receipts and expenses. It’s not actually all that hard to figure out, and the system gives you helpful messages. But an introduction presentation would have made things clear from the get-go. Dropbox does a great job with that.

Any time you’re asking users to think about the attributes of a data model you’re asking for a certain amount of trouble. In this case, the idea of “reimbursable” and “unreimbursable” expenses also needed some clarification. Since I was in consultant mode when I was doing today’s reports there’s no concept of “unreimbursable” – but I’d unclicked the default when I was linking my credit card because I thought that leaving it as “reimbursable” would make more work for me as I filtered through expense lists. It turns out this is useful for corporate cards, which makes sense – but I’ve never carried a corporate card where I didn’t get the bill myself (oddly, this was true even when I worked for the Federal government).

The bottom line: a very useful service and a great source of ideas for making other web applications easier to use. Oh, Expensify guys -please add an “email receipt” feature like TripIt’s, if you haven’t already.

How to Scope a Product

Posted on by

I wrote about the demise of Google Wave earlier this week. MG Siegler over at TechCrunch wrote yesterday that Google didn’t give it enough time, and mishandled the launch.

Google definitely mishandled the launch. They made a big announcement but then trickled the product out slowly, wasting most of the initial enthusiasm. In our work we try to go the other way – to get a few key influencers in an organization excited about what we’re doing and let them evangelize their colleagues. That way when the big announcement happens there are already people using the system and ready to support the new arrivals.

I disagree with Siegler’s statement that Wave didn’t solve a problem, though. He wrote that it doesn’t matter, since Twitter doesn’t solve one either. I think it does matter – because Wave did solve a problem. It just wasn’t as big a problem as “the way we communicate doesn’t work.” Google Wave was an excellent email replacement for a certain subset of emails – messages where a small number of people collaborate back and forth on understanding a problem and forming a strategy. This is a critical problem for small and medium sized organizations. And I suspect that if Google was to go back and look at their internal use of Wave they’d see the use case. I wrote about this in my first post, so I won’t re-hash the mechanics here.

So my lesson from this – beyond not trusting Google beta products to be available for my use over the long term – is that when you launch something big you have to launch it small. When I talk about product development at conferences I like to use the example of Flickr. Flickr, today, is big – it’s changed the way that we deal with images. But the original problem was small – sharing pictures online, easily, with friends. Searching billions of images for creative commons licensed pictures to spice up a PowerPoint presentation came later. Hindsight is 20-20, but Google should have found more small, real, value-from-day-one problems that Wave could solve without requiring everyone in the world to adopt it at once. Once I figured out it was useful, I was able to drag my team along by fiat, and we all started evangelizing it to others via our separate projects. Everybody almost won.

The End of Google Wave

Posted on by

Google killed Wave on August 4th. I wrote a bit this morning about Google Wave and knowledge worker collaboration over on the Beacon 16 blog, so if you want to know more or less what I’m talking about, check that one out.

What I liked about Wave from the healthcare perspective was the way it managed conversations. I could easily see the platform extended to care planning and coordination, and I had some fairly specific ideas along those lines. They may still see the light of day in the context of some our other projects – the idea of replacing chains of email with something that was just as easy to use but created an automatic running summary of the conclusions drawn by the group (and which made it easy to reconstruct the discussion behind that reasoning) was extremely compelling.

Changing Platform Rules

Posted on by

TechCrunch reports this morning that Facebook is changing the rules (again) for third party developers. They’ve done this a few times. So has Apple, on the iPhone platform – when they can be bothered to fully explain the rules in the first place.  Meanwhile, Motorola introduced Droid today – the new flagship Android 2.0 sliding keyboard phone.  Unlike Facebook and Apple, Android is an open platform, without Google guarding the gates for developers. And developers are already complaining that the in-market mix of Android 1.5, 1.6 and 2.0 is driving development costs towards an unsustainable endpoint.

All of this has got me thinking about the challenges of building applications on other people’s platforms.  Whatever users may say about Windows, Microsoft has always treated its ISV partners pretty well.  Lots of notice, and no arbitrary barriers to deployment (Apple) or random, substantive policy and feature swings (Facebook).

I have no deep insight here, but I’m curious – particularly in our area of healthcare informatics and public health, how much is platform instability (and profusion!) limiting the development of next-generation applications?  What’s required to justify an investment in these platforms?

As for Android – depending on what the reviews look like, I’ll probably get a Droid next week or the week after, despite my Sprint contract.  I’ve been fully fed up with Windows Mobile for a while, don’t like Blackberrys, and need a sliding keyboard. Hope the application developers keep up…

Adventures in JSF 2.0: Hello World Tutorial using Maven 2, JSF 2, Facelets 2, and Weld

Posted on by

In the first of many posts regarding the recently finalized JSF 2.0, I will be showing you what you need to do to write a simple Hello World Application. Instead of traditional JSF backing beans, this application will use Weld, an open-source implementation of JSR-299: Contexts and Dependency Injection for the Java EE platform. JSR-299 will be part of the upcoming JEE 6 specification.

Prerequisites:

Install Sun’s JDK 6, the latest version of Maven (presently 2.2.1), and the IDE of your choice.  I use Eclipse, but GEdit or notepad would work just fine. For this demo, I’ll be using Jetty, so you won’t need to install a container of any sort.

Getting Started:

Create Empty Project

Our first step is to create an ordinary empty WAR project in Maven using the 

archetype:generate

command in the directory of your choice.

cd ~/workspace #this can obviously be anywhere.
mvn archetype:generate -DinteractiveMode=n -DarchetypeArtifactId=maven-archetype-webapp -Dversion=0.0.1-SNAPSHOT -DgroupId=org.bogus -DartifactId=jsf2_tutorial

Unfortunately, the default Maven archetype falls short of what we need, so we need to make a few extra directories.  We need a java directory and the test java and resources directory. I’ve also added the commands that an eclipse user would use to generate an importable eclipse project. Netbeans and IntellJ users can simply import the pom.xml.

#create a few extra directories for the project.
mkdir jsf2_tutorial/src/test jsf2_tutorial/src/test/java jsf2_tutorial/src/test/resources jsf2_tutorial/src/main/java
cd jsf2_tutorial
#if you're using *NIX, you can create empty files with this command.
mkdir src/main/java/org/ src/main/java/org/bogus/ #need to create package first.
touch pom.xml src/main/webapp/WEB-INF/web.xml src/main/webapp/WEB-INF/beans.xml src/main/java/org/bogus/HelloWorld.java src/main/webapp/index.xhtml src/test/resources/jetty-env.xml

Overview

I was very impressed that a simple Hello World project can be created with as little as five artifacts.

  1. /pom.xml
  2. /src/main/webapp/WEB-INF/web.xml
  3. /src/main/webapp/WEB-INF/beans.xml
  4. /src/main/java/org/bogus/HelloWorld.java
  5. /src/main/webapp/index.xhtml
  6. /src/test/resources/jetty-env.xml (for Jetty users).

Writing the actual Code

pom.xml

The first step is to the pom.xml file. Afterwards it can be easily imported into any modern IDE.

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<groupId>org.bogus</groupId>
	<artifactId>helloworld</artifactId>
	<packaging>war</packaging>
	<version>0.0.1-SNAPSHOT</version>
	<name>JSF 2.0 Tutorial</name>
	<repositories>
		<!-- As of October 2009, a few of the weld dependencies were not yet on the main maven repo.  We can add JBoss repo as it is updated more frequently.  -->
		<repository>
			<id>repository.jboss.org</id>
			<name>JBoss Repository</name>
			<url>http://repository.jboss.org/maven2</url>
			<releases>
				<enabled>true</enabled>
			</releases>
			<snapshots>
				<enabled>false</enabled>
			</snapshots>
		</repository>
	</repositories>
	<dependencies>
		<!-- Common -->
		<dependency>
			<groupId>javax.enterprise</groupId>
			<artifactId>cdi-api</artifactId>
			<scope>provided</scope>
			<version>1.0-CR1</version>
		</dependency>
 
		<dependency>
			<groupId>javax.annotation</groupId>
			<artifactId>jsr250-api</artifactId>
			<version>1.0</version>
		</dependency>
 
		<dependency>
			<groupId>javax.faces</groupId>
			<artifactId>jsf-api</artifactId>
			<version>2.0.0-RC</version>
		</dependency>
 
		<!-- Jetty-specific scopes and artifacts -->
		<dependency>
			<groupId>javax.faces</groupId>
			<artifactId>jsf-impl</artifactId>
			<scope>runtime</scope>
			<version>2.0.0-RC</version>
		</dependency>
 
		<dependency>
			<groupId>javax.servlet</groupId>
			<artifactId>jstl</artifactId>
			<version>1.2</version>
			<scope>runtime</scope>
		</dependency>
 
		<dependency>
			<groupId>org.jboss.weld.servlet</groupId>
			<artifactId>weld-servlet</artifactId>
			<version>1.0.0-CR1</version>
			<scope>runtime</scope>
		</dependency>
 
		<dependency>
			<groupId>org.glassfish.web</groupId>
			<artifactId>el-impl</artifactId>
			<version>2.1.2-b04</version>
			<scope>runtime</scope>
			<exclusions>
				<exclusion>
					<groupId>javax.el</groupId>
					<artifactId>el-api</artifactId>
				</exclusion>
			</exclusions>
		</dependency>
	</dependencies>
	<build>
		<finalName>jsf2</finalName>
		<plugins>
			<!-- Compiler plugin enforces Java 1.6 -->
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-compiler-plugin</artifactId>
				<configuration>
					<source>1.6</source>
					<target>1.6</target>
				</configuration>
			</plugin>
 
			<!-- Eclipse plugin enforces download of source and JavaDoc jars -->
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-eclipse-plugin</artifactId>
				<configuration>
					<wtpversion>2.0</wtpversion>
					<downloadSources>true</downloadSources>
					<downloadJavadocs>true</downloadJavadocs>
				</configuration>
			</plugin>
			<!-- Embedded Jetty (jetty:run) -->
			<plugin>
				<groupId>org.mortbay.jetty</groupId>
				<artifactId>maven-jetty-plugin</artifactId>
				<configuration>
					<!-- force friendly name instead of artifact name + version -->
					<contextPath>${build.finalName}</contextPath>
					<!-- Where the BeanManager is constructed.  This is where we'll later declare datasource. -->
					<jettyEnvXml>${basedir}/src/test/resources/jetty-env.xml</jettyEnvXml>
					<!-- This parameter will auto-deploy modified classes...my personal favorite Jetty feature. -->
					<scanIntervalSeconds>3</scanIntervalSeconds>
				</configuration>
			</plugin>
		</plugins>
	</build>
</project>

Now that your pom is complete, you can import it into the IDE of your choice. Eclipse requires users to either install m2eclipse or run:

mvn eclipse:eclipse

Boilerplate

web.xml

Since JSF 1.2, the web.xml page got a lot smaller. This is where convention over configuration pays off. Also, faces-config.xml is now optional!

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" version="2.5">
	<!-- Standard JSF 2.0 Configuration Paramters. -->
	<!-- No Joke!!...This is all you need now! -->
	<context-param>
		<param-name>javax.faces.DEFAULT_SUFFIX</param-name>
		<param-value>.xhtml</param-value>
	</context-param>
	<servlet>
		<servlet-name>Faces Servlet</servlet-name>
		<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
		<load-on-startup>1</load-on-startup>
	</servlet>
	<servlet-mapping>
		<servlet-name>Faces Servlet</servlet-name>
		<url-pattern>*.jsf</url-pattern>
	</servlet-mapping>
 
	<!-- Weld Jetty Configuration parameters -->
	<listener>
		<listener-class>org.jboss.weld.environment.servlet.Listener</listener-class>
	</listener>
	<resource-env-ref>
		<description>Object factory for the CDI Bean Manager</description>
		<resource-env-ref-name>BeanManager</resource-env-ref-name>
		<resource-env-ref-type>javax.enterprise.inject.spi.BeanManager</resource-env-ref-type>
	</resource-env-ref>
</web-app>

beans.xml

In order to indicate to weld to initialize dependency injection, you’ll need to create an empty file named beans.xml. The mere presence of this file in your WEB-INF folder tells the container that your WEB-INF/classes folder is a bean deployment archive.

Application-Specific Code

HelloWorld.java

To confirm that Weld (A.K.A. JSR 299 or WebBeans) Dependency Injection works, we’re going to write an incredibly simple bean. In contrast to Spring, you don’t need to declare the package or bean. Simply adding the @Named annotations and declaring a scope is all that is needed to have your bean registered with the dependency injection container and visible to your facelets view pages.

package org.bogus;
 
import java.io.Serializable;
 
import javax.enterprise.context.SessionScoped;
import javax.inject.Named;
 
@Named //assigns this bean the name of "helloWorld"...its "de-caplitalized" class name
@SessionScoped  //creates one bean for each user session.
public class HelloWorld implements Serializable {
	private final String text = "Hello World!";
 
	public String getText() {
		return text;
	}
 
	private static final long serialVersionUID = 1L;
}

index.xhtml

Now we want to actually view the bean we created. Below is an incredibly simple xhtml/facelets page.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:h="http://java.sun.com/jsf/html">
<h:head>
	<title>JSF Demo</title>
</h:head>
<h:body>
	<h1>Does Weld Work?</h1>
	<!-- Your bean can be easily accessed via Expression Language -->
	<p>My weld-injected bean says: #{helloWorld.text}</p>
</h:body>
</html>

jetty-env.xml

Since we’re not using a full JEE container, we need to configure Jetty to prepare the BeanManager.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN"
   "http://jetty.mortbay.org/configure.dtd">
<Configure id="webAppCtx" class="org.mortbay.jetty.webapp.WebAppContext">
	<New id="appManager" class="org.mortbay.jetty.plus.naming.Resource">
		<Arg>
			<Ref id="webAppCtx" />
		</Arg>
		<Arg>BeanManager</Arg>
		<Arg>
			<New class="javax.naming.Reference">
				<Arg>javax.enterprise.inject.spi.BeanManager</Arg>
				<Arg>org.jboss.weld.resources.ManagerObjectFactory</Arg>
				<Arg />
			</New>
		</Arg>
	</New>
</Configure>

Start up Jetty

Jetty is an embedded servlet container that can be easily launched from Maven. Since we added that small snippet to the pom, we can simply type:

mvn war:inplace jetty:run

…and maven will download Jetty and run it with the configuration file we passed.

Test Your Application

Simply load http://localhost:8080/jsf/index.jsf

firefox http://localhost:8080/jsf/index.jsf

Screenshot of your application
If you see the hello world text, everything has worked. Now that you’ve confirmed your configuration is setup correctly, you can explore the more interesting features of Weld and JSF 2, which I’ll be covering in future posts.

Download the Code

The source code to this tutorial is available via subversion here

UPDATE: Tomcat Users

With the addition of a context.xml, this example runs perfectly on Tomcat.
Please see this article for details.

Further Reading

Many thanks to the JBoss staff on the forums who helped me get started in Weld. The artifacts in this article were modeled after their examples.

Duct Tape Programming: Macho?…Yes! Practical?…Rarely!

Posted on by

In http://www.joelonsoftware.com/items/2009/09/23.html, Joel Spolsky of the Joel on Software Blog advocates a practice he calls “Duct Tape Programming.” What he advocates actually is nothing new. It’s more commonly known as “Cowboy Coding.” I decided to post my response for public comment.

Joel’s article was amusing, but obviously balance is important.

I got the impression the Joel was rebelling against COM, C++, OOP, and general abstraction. I can’t say I personally share his view that complex technology is inherently bad. These features are sharp tools, much like the power tools today’s carpenter uses to build a house. Left in the hands of idiots, sharp tools cause problems. It doesn’t take too much imagination to see how assigning an idiot with a drinking problem and an addiction to cough syrup with the task of ripping boards (cutting lengthwise) with a table saw can cause problems. Likewise, letting someone write multi-threaded code who doesn’t have the skill necessary to handle it responsibly is a recipe for disaster.

Over-engineering is a serious threat to a business, especially since many engineers I have worked with can fairly be accused of over-engineering at some point or another in his or her career. However, there’s obviously a reason things like Object Oriented Programming exist… and it isn’t just because the entire software engineering profession isn’t as smart as Mr. Macho Duct Tape Cowboy.

Everyone reading this who has written code for a large company has seen what happens when duct tape programming gets taken too far.  You end up with a giant legacy system, written by two-dozen authors over multiple decades. The application performs poorly, is difficult to maintain, and no one has holistic knowledge of how the system works. You often find yourself spending 6 months training each engineer which touches the system on your internal proprietary duct tape patterns. Duct tape programming is fine and dandy until you ship something that’s broken or can’t be extended to fit your changing business needs — because it is a giant scary monolith and every simple change in one piece of functionality breaks another piece that was duct-taped on it 5 years ago.

OOP and standardization technologies that abstract complexity pay off when you have more developers that can fit comfortably in a small office and you realistically expect for a product to be handled in the future by people other than its original authors. They add complexity for the sake of compartmentalizing functionality so it can be distributed among different authors and can encourage documentation of the workings of each module.

My team pushes for modern standards and best practices so that we can hire a sharp developer who’s familiar with modern technology, and he can instantly understand most of what we’re doing. More often than not, we could have shipped whatever we were working on slightly faster if we ignored standardization and just did things the way we did them many years ago because it was familiar to us. However, the customer would pay the price when they asked someone other than us to maintain our quickly-shipped, duct-taped masterpiece.

Most professional developers write code for a company for the sake of delivering a quality application, a tool to enhance their business. You do the client no favor by saving them money on the initial delivery and costing them more down the road to keep the product running and relevant… unless you’re solely billing by the hour and are in a situation where they can never fire or sue you.

Clearly this is a complex problem that people are years from solving, but until the geniuses of the world get together and solve this once and for all, I personally think we’re best off balancing writing elegant, standards-compliant code with shipping things on time and not blindly adopting technology without fully understanding the consequences.

Future of Google Health

Posted on by

John Moore at Chilmark Research asks today if Google Health is irrelevant. I’m re-blogging it because I agree with him. Microsoft is easily the leading player in broad audience Personal Health Record platforms. That doesn’t mean their product is ideal – it’s certainly not – but they’ve been improving it steadily and have integrated it with a very cohesive strategy aimed at engaging with the healthcare industry as a whole. Google hasn’t done that.

One take-away I had from the Microsoft Health Solutions Group conference in June (besides one heck of an airplane-acquired infection) was how tightly Microsoft is linking Amalga UIS – its hospital intelligence/data warehousing offering – with HealthVault. Amalga is the back-door – hospitals will make the data integration investments because of bottom-line and quality improvement benefits that are realized by UIS. But once that work is done, integrating with HealthVault is just flipping a switch. Microsoft has allocated its R&D money accordingly.

Google, on the other hand, still strikes me as simply dallying in healthcare. They’ve done some good work in focused healthcare search, but that’s pretty much where it ends. I completely agree with John’s statement that Google has gotten disproportionate attention simply because it’s Google. I’m not really inclined to start trying to take down the myth of Google here, but it’s safe to say that the company isn’t omnicompetent. From very personal experience, it was quite difficult to get projects in PHR off the ground during the six months after Google Health leaked but before it launched. There was a huge chilling effect – everybody wanted to wait and see what Google would do.

The Tories and HealthVault

Posted on by

The Google froth turned up an interesting op-ed from the Guardian newspaper in London. Apparently the Conservative party has started agitating for use of systems like HealthVault and Google Health to replace the large, centralized National Health Services databases.  Certainly fits the small-government agenda, but as the article correctly points out there’s a lot more in a real EHR than you’re going to find in HealthVault. Patients do need their records – but so do physicians.

The Guardian: Don’t ask the public to care for its data.

To be fair, the proposal only came from a think tank, and they weren’t really focusing on healthcare per-se; they were focusing on large government programs. But still, I’ve heard the same question come up from very educated sources outside the health and health IT areas.

Introducing Clickframes!

Posted on by

I’m sure at least a few people have been wondering where we’ve been the last few weeks. We’ve been busy on a number of products, and we released one of them at the end of June. It’s called Clickframes,  and it’s a set of frameworks for building usable, reliable, scalable software faster, better and cheaper.  The original Clickframes concept was based on three observations:

  • Good software requirements can be very useful.
  • Most software requirements aren’t very good.
  • Even when requirements are well thought out, they’re generally created in a format that limits their usefulness.

At ISG, we develop software using a design methodology that focuses on understanding user needs through interviews, observations and deep research. We learn as much about the problem space up-front, do as much work as possible to validate our designs with real users, and only then proceed with the implementation.  This approach works very well for us (and the one time we allowed ourselves to be persuaded to approach a problem differently the results were a lot more typical for the industry), but it requires a lot of agility. Clickframes helps give us that agility by turning static software requirements into a dynamic specification of how the application should work.

Here’s how it works: at some point during the design process we start building an application specification (or “appspec”), which is a description of the web application we want to build. The early iterations can be very schematic – identifying a couple of pages, perhaps a form or two, and a few buttons. As we learn more about the application we can extend the appspec to include additional detail, including specific requirements, security, and flows between different pages in the application.

That’s actually all pretty standard, so here’s where things get a little different. The appspec isn’t a Microsoft Word document, or a stack of index cards, or a drawing on a wall. It’s an XML file, and it’s maintained by the application’s lead designer. By managing requirements in XML, we can generate a whole range of useful artifacts on the fly. The most important is the Clickframes Interactive Preview (click the link for a sample from our Issue Tracker demo), which provides an easy to navigate HTML representation of the application. As requirements change the CLIPs can be easily regenerated. Clickframes also provides generators for conventional requirements documents (the system shall…) and a visualization tool that generates interaction maps of the application. Here’s the Issue Tracker example, generated from the same appspec as the CLIPs linked to above:

A Clickframes Project Map

Once the design stabilizes, we move on to implementing the software itself. Clickframes helps here too. We’ve built code generators for three different web architectures – PHP, JBoss Seam, and Spring WebFlow (the latter two, for the non-technical reader who has stuck it out this far, are Enterprise Java platforms, and the first is a very common scripting language for web applications). This is an area where conventional prototyping tools break down – they don’t provide a bridge to development.  With Clickframes, the plugins give us a skeleton of the application immediately, and our developers and designers can go in and immediately start creating content and the final look and feel, rather than worrying about details like implementing edit checks on form fields.  If you want to see the Clickframes Issue Tracker demo, just click on the link (to log in, enter anything for the username and password).  This isn’t a complete application, by the way – it’s just the generated code, before being customized by a programmer.

We’ve spent a lot of time on the Clickframes code generators and on the architecture of the underlying applications. We’ve implemented a range of features we call “CodeSync” that allow us to regenerate applications even after the development team has started to customize them. This is critically important, because it keeps the requirements from becoming out of date. If a business user, or a a designer, wants a change made, they can have the appspec updated and the programmer can re-run the code generator. It creates a feedback loop that’s often missing.

The final step in the Clickframes project lifecyle is testing. Since we have a version of the software requirements that a computer can understand, we can use it to generate a suite of automated tests, as well as templates for test strategies and manual test scripts. It’s not magic – the quality assurance team still has to do some work, and we can’t automatically generate every single test, but we can save a tremendous amount of up-front work. And developers can have access to automated tests of the final application almost from the first day of development. It saves a tremendous amount of time.

Clickframes is software to streamline development of enterprise applications.  So how much would you pay? Don’t answer, because it’s free – we’re releasing Clickframes as Open Source Software under the LGPL.  You can download Preview Release 1, sign up for the mailing lists, and see some demo screencasts at www.clickframes.org, and you can find a lot of documentation on The Clickframes Wiki, including instructions on how to get started without downloading anything.  The Preview Release is out there to gather feedback – we’ll be releasing new versions at a pretty rapid clip over the next two months, with a goal of 1.0 by the end of the summer. We’re also rolling out some new web site features in July that will make it easier to explore the Clickframes model.

This has been a long road for all of us – we started working on Clickframes back in May of 2008, so it’s been over a year to get to this point. So give it a try and let us know what you think!

(And if you like it, or like what we build, give us a call – we’re always looking for interesting new projects).