Adam L. Davis

May 17

My Brother's Music -

Check it out if you like Techno, Dubstep, House, etc.

Here’s Z on rails (ruby on rails).

Here’s Z on rails (ruby on rails).

May 10

Light Table -

So, it looks like someone else was inspired by Bret Victor’s talk and decided to do something about it. This looks really cool and implements some of the same ideas I have for Z (code is broken down to functions, not files). It looks nice. I wish they would do Java/ruby (right now they are only targeting Clojure and Javascript) but still, looks awesome.

May 07

Buying Happiness -

Great post by Jeff Atwood about the latest science on happiness. I’ve been reading Stumbling on Happiness myself, and he makes a lot of the same points. What I find most surprising/interesting are the following:

Apr 24

Complexity vs. Flexibility in a UI One of the things I’ve learned again and again in user-interface development is that flexibility (what you can do) is intrinsically linked to complexity (as shown in the above graph). Maybe this is just a truism, but I think it’s easy to overlook.  I think this story probably gets repeated a million different ways everyday all over the world: We need the product to do this, that and the other. A solution is built at point B in the graph. OMG, that’s way to complex!  A solution is added at point A which does much less but is also way easier to use. Then, maybe, features get slowly added to “A” adding additional points between A and B. In some cases, even worse, “A” eventually gets so complex it overtakes “B” and keeps going, getting ever closer to a Turing Complete language (Code). Even in the programming world itself, we have similar situations. Imagine a coding framework comes out that makes everything so much easier (in a specific domain). Rails was one such framework. Spring was another one. In these cases they start out at point B, but progress further and further towards what they replaced, plain old code. For Rails the domain was web-applications. I’m not saying there’s something intrinsically wrong with these frameworks; on the contrary they serve a great purpose. I’m just saying let’s not fool ourselves about where we are in the graph. 37signals and other like them flourished by building products towards the left of this graph: simple. Others, like Microsoft build things towards the right: complex. If there’s something to learn here about UI-design, it’s you can hide a “B” UI by creating a bunch of “A” UI’s that do different things, and hiding them properly (like sub-menus or ribbons).

Complexity vs. Flexibility in a UI

One of the things I’ve learned again and again in user-interface development is that flexibility (what you can do) is intrinsically linked to complexity (as shown in the above graph). Maybe this is just a truism, but I think it’s easy to overlook. 

I think this story probably gets repeated a million different ways everyday all over the world:

  1. We need the product to do this, that and the other.
  2. A solution is built at point B in the graph.
  3. OMG, that’s way to complex! 
  4. A solution is added at point A which does much less but is also way easier to use.
  5. Then, maybe, features get slowly added to “A” adding additional points between A and B.
  6. In some cases, even worse, “A” eventually gets so complex it overtakes “B” and keeps going, getting ever closer to a Turing Complete language (Code).

Even in the programming world itself, we have similar situations. Imagine a coding framework comes out that makes everything so much easier (in a specific domain). Rails was one such framework. Spring was another one. In these cases they start out at point B, but progress further and further towards what they replaced, plain old code. For Rails the domain was web-applications. I’m not saying there’s something intrinsically wrong with these frameworks; on the contrary they serve a great purpose. I’m just saying let’s not fool ourselves about where we are in the graph.

37signals and other like them flourished by building products towards the left of this graph: simple. Others, like Microsoft build things towards the right: complex.

If there’s something to learn here about UI-design, it’s you can hide a “B” UI by creating a bunch of “A” UI’s that do different things, and hiding them properly (like sub-menus or ribbons).

[video]

Apr 13

Okay, here it is! I threw it together in a couple days, so I’m making no promises as to how well it works, but it kind of works (on a simple Maven project like itself). I’m calling it Z for now. Here’s the code on github: Z, experimental IDE. By default, it shows dependencies on the left and “sub-modules” on the right. It works with Java and Maven, but it has an api to theoretically work with other languages/build-frameworks. It uses neoeedit as a lightweight code editor. The next things I’d like to add are: controlling imports (as nodes), and drag-and-drop refactoring.

Okay, here it is! I threw it together in a couple days, so I’m making no promises as to how well it works, but it kind of works (on a simple Maven project like itself). I’m calling it Z for now. Here’s the code on github: Z, experimental IDE. By default, it shows dependencies on the left and “sub-modules” on the right. It works with Java and Maven, but it has an api to theoretically work with other languages/build-frameworks. It uses neoeedit as a lightweight code editor. The next things I’d like to add are: controlling imports (as nodes), and drag-and-drop refactoring.

Apr 06

So, here’s a crazy idea I had. The idea is partly inspired by Reginald’s talk (the part about how IDE’s are not well integrated with version-control, etc.), but really it takes ideas from many different places. I’m working on implementing a research-level test of this idea. The core idea is looking at code differently; what if we abstracted away the idea of code being in files? Instead we should be able to visualize code in a more abstract way, but still reusing the concepts of objects, packages, methods, and “imports” - just in a more abstracted and visually appealing way. At the same time, version-control, and dependency-control should be seamlessly integrated (in the way that Go integrates dependency-control so nicely into the language). Stay tuned.

So, here’s a crazy idea I had. The idea is partly inspired by Reginald’s talk (the part about how IDE’s are not well integrated with version-control, etc.), but really it takes ideas from many different places. I’m working on implementing a research-level test of this idea.

The core idea is looking at code differently; what if we abstracted away the idea of code being in files? Instead we should be able to visualize code in a more abstract way, but still reusing the concepts of objects, packages, methods, and “imports” - just in a more abstracted and visually appealing way. At the same time, version-control, and dependency-control should be seamlessly integrated (in the way that Go integrates dependency-control so nicely into the language).

Stay tuned.

Apr 04

Bret Victor - Inventing on Principle (or "show the end result") -

Really great talk about an alternative path or “career” in software which resembles social activism. I’m not sure that part really applies to many people but the stuff he demos is amazing.

Reginald Braithwaite - Beautiful Failure -

Interesting talk from CUSEC 2010 by Reginald Braithwaite. He makes some good points: