Citation:

http://www.informationweek.com/showArticle.jhtml?articleID=199600005

One of the best ways to force people to review games correctly is to make it in their best economic interests to do so.

A smart idea sounds great when it’s in your head. Even before it’s made, we can imagine how great it will be–there would be no iPod, no PC, and no Super Mario Bros. without imagination.

But just because you can already see the finished idea, don’t think that the steps in between “smart idea” and “transformed future” are insignificant. They eat most smart ideas before they hatch.

The next time you hear that someone “stole” someone else’s idea, look at the in between first, and ask: how much of that–the business strategy, the way the product was built–was really stolen?

Blatant theft? Or recognizing a smart idea?

http://www.apple.com/macosx/features/dashboard/
http://widgets.yahoo.com/
http://microsoftgadgets.com/

Three Four companies, one idea.

Here is a timeline of the gory details:

• 1984 - The original Macintosh, featuring widget-like desk accessories, is released. [0] [1]
• 1998 - Arlo Rose comes up with concept for Konfabulator, after looking at a skinnable MP3 player, according to his account.
• 2001 - Microsoft releases a paper on UI design that discusses “Peripheral Awareness of Important Information–” a foundation for later “widget” development. [2]
• February 10, 2003 – With the help of Perry Clarke, Arlo releases the first version of Konfabulator.
• November 8, 2004 – Konfabulator releases its widgets for Windows.
• April 29, 2005 – Apple releases Mac OS X 10.4, which features Dashboard, a widget hosting system. [3] [4] [5]
• July 25, 2005 – Yahoo buys Konfabulator. [6]
• Also 2005 - Microsoft Gadgets is announced and unveiled in Vista.

Does it really matter if Yahoo stole the idea from Apple, or MS stole from Arlo Rose?

Not really. I’m sure that most of the people involved in each of these projects would have been able to come up with widgets on their own; MS, Yahoo, and planet Earth are all full of innovative and capable engineers *(and I would hate to see a patent war kill widgets).

What really matters, though, is this; how much have they learned from the past? Yes, that’s right; perhaps all these gadgetmakers should be looking at their competition.

Assertion 1: Making a good product is not the result of creating something new; most often it is the result of doing something well.

The widget is a relatively simple idea. Instead of having to visit a webpage every time you want to check the weather, why not have a widget that’s always there? Less distracting and yet always available. This would save space on the screen and yet keep little bits of useful information always accessible.

A bright idea doesn’t make a product though. Once you have the inspiration, it’s still nothing more than a paper tiger. Anyone can come up with bright ideas.

As one good example of an innovative idea that flopped, look at PDAs before Palm. People developed the technology and lots of people were thinking about handheld computers, but it was only when a team took the ideas and made them simple that the technology took off. [7] [8: How can a gorilla learn to fly?]

Fig 1. Put too much in a palm device, and you make a mistake made by many before you.

Think back to Edison–1% inspiration, 99% perspiration. Bright ideas are incredibly cheap to produce, but taking them and putting together an actual market is hard work and hard thinking. That’s where the $ is.

Assertion 2: Simply copying an idea == copying all the mistakes of that idea.

Up unto the Palm, every pocket mobile device tried to be too ambitious. Newton, anyone?

If that doesn’t sound familiar, let’s try a more well recognized example:

There were plenty of products before the iPod. The Rio shipped three years earlier. [9] In both cases, the difference was that the new product was far simpler than its predecessors and its competition.

If you copy a product that hasn’t succeeded before, you will run into the same problems that others had before. Not just making it simpler. There are business problems, design problems, and engineering problems.

Assertion 3: Making a successful market isn’t about having the best engineering.

The original idea for a mouse driven interface wasn’t created at Apple or at Microsoft. As computer history buffs will tell you, the original Graphical User Interface (or at least, the mouse part of it) was created at the XEROX Palo Alto Research Center [10] Nevertheless, nowadays, we don’t buy our operating systems from the company with the most innovative engineering.

Then, the Mac came along, and made a new idea into a great product. The original Mac was an exciting, innovative device, and you could buy it in a store. It took 6 years for Microsoft to come up with a product approaching it. [11]

So why are we using Windows now?

Look at assertion 3 again.

Making a successful market isn’t about having the best engineering.

Windows took a no longer new idea, modeled it after a great product, and turned that into a profitable business.

—————————-

It’s not romantic to build a distribution network that will warehouse your new toy so it doesn’t sell out right after it hits stores in downtown Manhattan. It’s not romantic to make your product compatible with version 1 of a huge corporate customer’s obsolete operating system. It’s not romantic to figure out how your brand new shiny social network that is, by the way, sooo much better than that other social network that everyone still uses for some reason, will get customers.

But you still have to do it.

Remember that before laying the egg.

I’m still working on the e-mail ticket idea. Basically I just need to spec it out and implement it (hah).

Or does it? Hopefully the example we choose will clarify some aspects of how this method differs from standard development techniques.

The Human Unit

One of the quirky parts of programming is dealing with humans. This is no surprise–programming languages aren’t human oriented. It’s easy to sort a list of items in most languages. However in most programs, there is an awkward moment where we call the program into existance. In C, it’s called main. In Python, there’s a whole blog entry by the creator of Python dedicated to it.

With a graphical UI, the challenges seemingly multiply. Computer programming is (typically) a sequential art; things work simplest when one thing follows another. In a (good) graphical UI, the user never waits for the computer to finish; output can come in many forms at many times.

A Human unit is a rather versatile unit to connect to. It works well in the unit scheme because we can connect it to other entities rather simply, in some cases. If we connect “Hello, World!,” a Text unit, to the Human, the output would appear on their screen. If we connect an MP3, the Human would hear the MP3.

How would the system know how to handle connections to Human? This would be a matter of the system understanding the connected unit on a semantic level. We could imagine a semantic attribute being assigned to all values that defines its human interaction.

A Matter of Semantics

Semantic attributes would also allow us a measure of freedom in attaching objects to each other. If we attach a Printer to a Web Browser, we don’t need to tell the Printer to print the web page and not the address of the page it’s currently on.

Is a connection forever?

The previous Printer example seems to suggest that connections don’t remain the same in time. Would we want to script connections to open and close? This is one of the many ridiculous challenges I seem to have written myself into.

Is this a useful method of getting people involved in programming, or just a useful way of visualizing architecture?

But it would be silly to give up on a goal with such a wide potential. In fact, I’m going to go ahead and tool a new paradigm of software architecture. To some extent, we have the pieces we need; all that’s needed is a bit (lot) of imagination and hard work.

We can summarize this in three main points:

1. Programs should be made of individual components that can be easily understood.
2. Components should be able to function independently; we should not have to guide them. Instead, they should have well-defined behaviors.
3. Components should be able to handle all sorts of input.

1. You may not know why the phosphors glow…but you can change the channels.

A program is made up of a set of working components, much like televisions, cars and any other man made object.

Most of us don’t know exactly how TVs work. We don’t know how to build a cathode ray tube. But we know it’s in there, we know how to change the channels, we know that it has a standard plug that can hook up to any cable outlet.

This is what’s missing in an average computer program.

Run a web browser. The browser is one seamless block of code; you can’t say exactly which part is displaying the page, or which part is retrieving it. If you think this is silly/wrong, think about this; many average computer users don’t even understand that there’s a browser at all. They just think of it as the “internet.” This is lexical nonsense!

But we don’t build software so that the concepts programmers see are also clear to the user.

2. Functional Object-Oriented Programming (FOOP)

When we talk about object oriented programming, we’re usually referring to a programming language like Java or Smalltalk. In Java, objects are individual entities that all follow the behavior of the class that spawned them. For example, we can create many Waiter objects based on a Waiter class. The Waiter class tells us that Waiter objects can take orders and remember them. You might imagine a Waiter object having these methods, as dictated to the Waiter by the class:

1. takeOrder(x) //This means, “Waiter, please get us x!”

2. getStatus(x) //This means, “Waiter, tell us how our x is doing. Is it ready?”

Each of these takes an input (that’s called x) and gives us a response. Every Waiter object responds to these method calls.

Now in a way, this model is very intuitive; we can picture an imaginative 9 year old thinking of Waiters as Waiter objects. He or she could read through the Waiter’s 2 methods and call them, making the Waiter takeOrders for every food imaginable until the table was full. The reason this method works well is that it revolves around an object – a Waiter – for which we have a good cognitive model; we know what waiters are and how they function.

What we really want, however, is a more advanced idea of an object. If you give a Waiter an order, they should know what to do with it. We shouldn’t have to call takeOrder at all. This may sound silly, but in the real world we expect not to clear the hurdles of going through a Waiter’s javadoc and figuring out exactly which method of two hundred to call. In order to have truly intuitive programming, we shouldn’t have to be aware of this extraneous information–passing a Waiter an order should just be that.

Make Objects Know What to Do on Their Own!

In order for this to be, we can replace the idea of an object with something more akin to functions in functional programming. While so far we have made objects the primary unit of programming, now we will examine the use of “functions.”

Gas discusses this when he referred to the concept of lambda calculus and functions as first order values. (You may be more familiar with Joel on Software’s example.) We’re not going to go into lambda calculus, so you can ignore this and read the following:

A function doesn’t have to be told what to do when given an input; instead, it knows. Unlike objects, functions are defined by the output they produce for a particular input.

The basic unit I’m developing here is neither a true object nor a traditional function. A traditional object offers more than one way to process data; ours simply accepts data in any form. True functional programming, on the other hand, does not have objects with state (think waiting algorithm, not waiter); its functions are immutable, while we potentially allow units to remember things by having state.

3. Polymorphism: The Universal Translator

Polymorphism, for us, basically means that our unit can understand any sort of input it is given. When you think in a language like C, you generally restrict the input you can process. A function called add in C would be able to add only what it was defined to add. If it was defined for integers, it wouldn’t be able to add fractions or strings, and vice versa.

To create units that anyone would be able to combine in a way that made sense to them, we would have to make this distinction entirely invisible to the user. This is the reason that in Javascript, you can add “abc” and 123 to get “abc123″–addition in JS is polymorphic, able to handle different types.

Now, in order for our unit to be able to handle being thrown all sorts of strange data, we must give that unit some sort of understanding of what the data is. An image, for example, is just a number when we store it on a computer; however that does not mean that when we add two images together we just want to add the two underlying numbers!

This is an extremely challenging problem, and there are two main ways we can tackle it; give each unit the ability to handle all new types of data, or encode in each piece of data some sort of semantic meaning. In the end we may find that both are important; this is a challenge I will address in more detail in Part III.

In Part II, we’ll talk about a concrete example of this unit architecture and also show how we might get a human involved in this process.

Conclusions

If you just look at the rules of the system, without looking at the overarching goals, you might confuse the system I have just devised with a sort of lawless type-unsafe Javascript. In a way, I’m not too unhappy with that definition; if you ask the average math student to add two numbers, they won’t return an error if you give them a fraction and a complex function as the two things to add. (and if they do, they probably won’t make it past their sophomore year.) The point of erasing all these arbitrary distinctions is to remove the unnecessary burdens with which the average person is encumbered when learning to program.

If I took an experienced programmer, and faced them with the implications of my strange unit system, they would likely stick to Lisp or Java or C, and that’s fine. The goal here is to show the average person how to produce useful software without thinking about syntax, type safety, or error handling, even once. Remember the TV! Hopefully, if this becomes clear, then FOOP might demonstrate its worth to power users.

[Ideas with similar visual modeling have made it into big company research projects - see here!]

-Where this came from 

This post is password protected. To view it please enter your password below:

Password: