Videos of the first surface computing prototypes aimed at consumers have been popping up on the web today, and I’m absolutely amazed at what they’re doing already. This site has a video that shows off some impressive interaction with a digital camera.

Found this wandering around the web and it is a very entertaining explanation of what Web 2.0 is all about. We are very quickly moving towards the future where the internet is more and more interactive. We are no longer just passive observers of the information, but are now active participants modifying, using, and accessing the data real time. Spider Strategies has been on the forefront of Web 2.0 technologies because we realized at the very beginning, that Web 2.0 was the future for both the internet and web applications.

Our customers don’t want to just look at their data, they want to use it. They want to be able to modify, manipulate, and manage their data. The process for doing so shouldn’t be an entirely new process to learn and manage. Working with the data should be as seamless as any other administrative task. That is what CMS is all about. Designed to work just like any other web page, it requires no special training, and users can quickly find, edit, and share data as quickly as doing a Google search.

Ever since I first got started programming and was exposed to different computer languages I’ve been annoyed at how difficult it is to convert information from one type to another. Not only does every language have its own way of doing this, often even within the same language there are multiple different methods that need to be learned to do conversions properly. I can’t offer a solution for every programming language, but I can offer a solution for Java: the Morph framework. The main goal of Morph is to make it really easy to take information in one format and make it available in another format. I am including some examples along with this article to show how easy it is to do all sorts of conversions with Morph. You can get a full list of the conversions that come out of the box here.

Morph.convert allows you to convert an object from one type to another. Here are some examples:


Integer three = new Integer(3);
// code without Morph
String string = new Integer(three);
// or (without using Morph)
string = "" + three;
// code using Morph
String string = Morph.convertToString(three);


String three = "3";
// code without Morph
Integer integer = new Integer(three);
// code using Morph
Integer integer = Morph.convertToIntegerObject(three);


String three = "3";
// code without Morph
int i= new Integer(three).intValue();
// or (without using Morph)
int i = Integer.parseInt(3);
// code using Morph
int i = Morph.convertToInt(three);


Morph.copy allows information from one object to be copied to another object. The object to which information is copied may even be of a different type than the source object. A great example of when you need to do this type of thing is when you need the data in an HttpServletRequest to be available to lower tiers in your application but you don’t want to tie your entire application to the servlet API. For example, let’s say you are trying to get your data prepared for a method with a signature IServiceInterface.service(Map data):


// without Morph
Map data = new HashMap();
for (Enumeration e=request.getParameterNames(); e.hasNext(); ) {
String param = (String) e.next();
data.put(param, request.getParameter(param));
}
// with Morph
Map data = new HashMap();
Morph.copy(data, request);
// actually with this particular example could also do
Map data = (Map) Morph.convert(Map.class, request);


For the past few weeks we’ve been working on implementing the Meetings module in CMS. One of our goals was to make it easy to switch between different occurrences of a meeting on different days. This is similar to changing calendar periods in other parts of the application, so we put a date selector in the upper right corner of the screen. After doing some work on this, Tom suggested we also make it possible to change meetings using this same selector because it would be easier to implement. Below is a screenshot of Tom’s final design:

As we continued to refine the meetings module, we figured out that Tom’s design was so easy to use that it should be the only way to switch meetings. This allowed us to eliminate a potentially confusing screen from the application. The original motivation for switching meetings with the selector was to make it easier to code and the end result ended up being easier to use too!

This is a great example of a principle 37signals calls Code Speaks. When the code suggests a different way of doing things, sometimes it makes sense to revise your original design. We’ve found this to be the key that allows us to strike a balance between providing easy to use software and delivering that software in a reasonable amount of time.