Craig Burton

I love my iPad for a lot of reasons. One of them is sketching. Some of the draw programs are just stunning.

My favorite for just sketching is from Autodesk–Sketchbook Pro.

The “Insulin Kitchen” sketch is done in Sketchbook Pro.

There is another genre of sketch programs coming out that have a very different set of brushes and feel to everything. These apps are inspired by the Web Sketch app “Harmony” by Mr. Doob. My favorite of this batch is Touch Sketch published by Luksor. The reason Touch Sketch is my favorite of the Harmony inspired apps is because it supports the zoom-in/zoom-out (pinch) manipulation. This feature let’s me get in there and add detail that the others don’t.

The sketch “Lilac Kitchen” is an example of a sketch done in Touch Sketch.

Comments Welcome

Organizations would do well to practice intentional innovation. Intentional innovation is the opposite of accidental innovation.  More often than not, accidental innovation is the traditional method of practice.

Intentional innovation means the constant monitoring of seven sources of innovative opportunity.

The Seven Sources of Innovation

The four inside innovation sources are:

1. The unexpected—the unexpected success, the unexpected failure, and the unexpected outside event.
2. The incongruity—the mismatch with reality as it really is and as it is assumed to be or “ought” to be.
3. The necessity—the innovation based on process need.
4. The “out-of-left-field” change—changes in industry structure or market structure that catch everyone unawares.

The three outside innovation sources are:

1. New demographics—changes in population.
2. New memes—changes in perception, mood, or meaning.
3. New knowledge—changes in scientific and non-scientific understanding.

Intentional Innovation Suggestions

Suggestions that will help jump start the practice of intentional innovation:

1. Designate an innovation officer.
2. Put innovation on the agenda for regular discussion.
3. Discuss all seven sources.
4. Budget for innovation.

Conclusion

The practice of innovation is the most important that organizations can do to create openings for success. Contrary to tradition, innovation can be planned and monitored. Intentional innovation is the constant monitoring of seven sources of innovation.

Obviously there is much more to say about intentional innovation. I just wanted to get you started.

Get intentional about innovation.

Phil Windley recently posted a great article about building 4th part apps with Kynetx. He refers to Doc Searls metaphor of the traditional push machine being a “shit pump” in a much more gentler way by calling it a “sewage pump.” Either way, in a push conversation, the shit gets dumped on us everywhere whether we like it or not.

Phil goes then goes on to mention David Siegel’s book “Pull”. Phil posits that “Pull” is the right metaphor for building markets in the 21st century and that push has gone beyond irritating to having a negative impact. (Except during the super bowl).

I love Phil’s post and Doc’s work on Vendor Relationship Management (Project VRM). The only thing I would add is that Pull is not mutually exclusive to Push. The only thing worse that a sewage dump event is a sewage suck event. What we are looking for here is a two way street, a conversation, a relationship. A Push/Pull metaphor.

Before the Internet, the infrastructure for a relationship between vendor and customer just didn’t exist.

We are just now finally building the contextual services on top of the core Internet infrastructure to allow a Push/Pull relationship to develop.

In my opinion, Phil is correct, Kynetx is at the forefront of developing the services to enable a Push/Pull metaphor to become real.

If you want to get a taste of it, check out my tutorials on Kynetx.

Here is the new tutorial installment.

This tutorial has been completely redone. It is much better now.

Acessing XML Data

This is actual text from a comment blocked by Disqus.

Great article, and I agree with you! What everybody are looking: fine job? Cash? Or maybe good relationship? The answer it’s clearly LOVE, russian dating girls. How rich you would not be you have, it’s not that important if your heart is pour – dating russian ladies. I believe you by this time noticed that, and what is the difficulty: russian men dating? Leave all your problems for a minute and think at that for a moment. You need a life like that, russian american dating? Then if you don’t, then this site is the thing only for you. Become a member, and rise your banner at Everest of russian dating scammers.

That last line is the killer “raise your banner at Everest of russian dating scammers.

Oh yeah. I’m in.

As I have tried to learn and understand KRL—the language of Context Automation—I have started to realize that there is more to it than just learning the language.

I don’t know about you, but to GROK KRL I am going to have to change the way I think about programming altogether. Let me give you an example.

I just finished creating a tutorial on how to use the new Twitter Module in KRL for using OAUTH to authenticate a user and access a twitter timeline. It seemed a little too simple. Here is what a code snippet to execute OAUTH looks like in KRL.

   1: select using ".*" setting ()

   2:     

   3: if(not twitter:authorized()) then

   4:     twitter:authorize()

   5:       with opacity=1.0 and

   6:            sticky = true

   7:  

   8: fired {

   9:    last

  10: }

It’s all of ten lines of code. The real OATH work in the code is done by one line of code.

twitter:authorize()

Contrast that with the JavaScript code sample that follows. 114 lines of code. Complicated. Lots of opportunities for bugs. KRL is doing all this messy stuff for you. All of the setup, the calls to the twitter API, the OAUTH process—everything—is done for you. You can focus on the path to enlightenment. GROK the TAO.

Cool.

   1: var consumer = {};

   2:  

   3: consumer.example =

   4: { consumerKey   : "myKey"

   5: , consumerSecret: "mySecret"

   6: , serviceProvider:

   7:   { signatureMethod     : "HMAC-SHA1"

   8:   , requestTokenURL     : "http://cut.ms/Jj3

   9:   , userAuthorizationURL: "http://cut.ms/Jj4

  10:   , accessTokenURL      : "http://cut.ms/Jj5

  11:   , echoURL             : "http://cut.ms/Jj6

  12:   }

  13: };

  14:  

  15: consumer.madgex =

  16: { consumerKey   : "key"

  17: , consumerSecret: "secret"

  18: , accessToken: "requestkey"

  19: , accessTokenSecret: "requestsecret"

  20: , echo: "accesskey"

  21: , echoSecret: "accesssecret"

  22: , serviceProvider:

  23:   { signatureMethod     : "HMAC-SHA1"

  24:   , requestTokenURL     : "http://cut.ms/Jj7

  25:   , accessTokenURL      : "http://cut.ms/Jj8

  26:   , echoURL             : "http://cut.ms/Jj9

  27:   }

  28: };

  29:  

  30: consumer.mediamatic =

  31: { consumerKey   : "e388e4f4d6f4cc10ff6dc0fd1637da370478e49e2"

  32: , consumerSecret: "0b062293b6e29ec91a23b2002abf88e9"

  33: , serviceProvider:

  34:   { signatureMethod     : "HMAC-SHA1"

  35:   , requestTokenURL     : "http://cut.ms/Jka

  36:   , userAuthorizationURL: "http://cut.ms/Jkb

  37:   , accessTokenURL      : "http://cut.ms/Jkc

  38:   , echoURL             : "http://cut.ms/Jkd

  39:   }

  40: };

  41:  

  42: consumer.termie =

  43: { consumerKey   : "key"

  44: , consumerSecret: "secret"

  45: , accessToken: "requestkey"

  46: , accessTokenSecret: "requestsecret"

  47: , echo: "accesskey"

  48: , echoSecret: "accesssecret"

  49: , serviceProvider:

  50:   { signatureMethod     : "HMAC-SHA1"

  51:   , requestTokenURL     : "http://cut.ms/Jke

  52:   , userAuthorizationURL: "accessToken.html" // a stub

  53:   , accessTokenURL      : "http://cut.ms/Jkf

  54:   , echoURL             : "http://cut.ms/Jkg

  55:   }

  56: };

  57:  

  58: consumer.initializeForm =

  59: function initializeForm(form, etc, usage) {

  60:     var selector = etc.elements[0];

  61:     var selection = selector.options[selector.selectedIndex].value;

  62:     var selected = consumer[selection];

  63:     if (selected != null) {

  64:         consumer.setInputs(etc, { URL           : selected.serviceProvider[usage + "URL"]

  65:                                 , consumerSecret: selected.consumerSecret

  66:                                 , tokenSecret   : selected[usage + "Secret"]

  67:                                 });

  68:         consumer.setInputs(form, { oauth_signature_method: selected.serviceProvider.signatureMethod

  69:                                  , oauth_consumer_key    : selected.consumerKey

  70:                                  , oauth_token           : selected[usage]

  71:                                  });

  72:     }

  73:     return true;

  74: };

  75:  

  76: consumer.setInputs =

  77: function setInputs(form, props) {

  78:     for (p in props) {

  79:         if (form[p] != null && props[p] != null) {

  80:             form[p].value = props[p];

  81:         }

  82:     }

  83: }

  84:  

  85: consumer.signForm =

  86: function signForm(form, etc) {

  87:     form.action = etc.URL.value;

  88:     var accessor = { consumerSecret: etc.consumerSecret.value

  89:                    , tokenSecret   : etc.tokenSecret.value};

  90:     var message = { action: form.action

  91:                   , method: form.method

  92:                   , parameters: []

  93:                   };

  94:     for (var e = 0; e < form.elements.length; ++e) {

  95:         var input = form.elements[e];

  96:         if (input.name != null && input.name != "" && input.value != null

  97:             && (!(input.type == "checkbox" || input.type == "radio") || input.checked))

  98:         {

  99:             message.parameters.push([input.name, input.value]);

 100:         }

 101:     }

 102:     OAuth.setTimestampAndNonce(message);

 103:     OAuth.SignatureMethod.sign(message, accessor);

 104:     //alert(outline("message", message));

 105:     var parameterMap = OAuth.getParameterMap(message.parameters);

 106:     for (var p in parameterMap) {

 107:         if (p.substring(0, 6) == "oauth_"

 108:          && form[p] != null && form[p].name != null && form[p].name != "")

 109:         {

 110:             form[p].value = parameterMap[p];

 111:         }

 112:     }

 113:     return true;

 114: };

Data Dilemma—Opening for Context Automation

Introduction

One of the interesting things I have learned while making the Context Automation Tutorial series is how to start identifying opportunities for Context Automation Applications.

The Golden Triangle

At Impact, I introduced the golden triangle of context automation. The golden triangle was made up of the following key components, the identity selector, the Kynetx Rules Engine (KRE), and the data. Since then, the triangle has been made to be more general purpose. The following outlines the changes.

1. The Selector has become the Context Selector—A context selector does not have to be an information card selector. It can be any one of the devices used on the client to manage rules and their relationship to data.
2. KRE has become the Context Provider—A context provider does not have to be the Kynetx Rules Engine but can be any cloud-based service capable of executing client side directives to enable context automation.
3. The data has become the Context Information Source—The context information source is a consistent way of saying the data.

Each of these golden elements needs to move forward. However, this discussion is about the Context Information Source; the data.

Before defining M&M’s I want to cover how the term came into being. While creating some tutorials about Kynetx and how to use data, I started noticing what it is about data that calls forth opportunity with context automation. Just as web sites are silos that cry for context to be automated between them, data information sources are silos. And how are they silos? Good thing you asked.

Data is a silo when it uses a naming, schema, or a data type that is different than a relevant data source that uses a different naming, schema, or data type.

Hmmmmm. That pretty much sums up ALL data sources.

For now, this troublesome data threesome—data naming, schema, and typing—will be referred to as the “data dilemma.”

Resolving the Dilemma

Kim Cameron, while speaking at Impact, told the legendary story about the issue of agreement on a very specific data dilemma. He found himself in a meeting amongst key email vendors arguing the names for data fields in a contact record. This was a complicated and politically charged issue. Complicated not because if technology but because of personalities and perceptions. Not only was vendor turf involved, but countries, government and so on.

He didn’t tell you, but Kim actually took charge and had each vendor commit to not leaving the room until all of the parties present could agree on a naming and schema for contacts. The meeting went on for 18 or 20 hours. Names were called, people stormed out of the room. Some returned some didn’t. It was ugly. The result is now the vCard specification.

This all happened in 1996. We STILL do not have common agreement on how vCards are used. For example, the Mac OS can export all of the contacts in one vCard file. (It doesn’t use vCard syntax natively.) Outlook, on the other hand, only deals with one contact as a time per vCard. It gets even messier. I won’t go into it.

This is one of the few success stories of the industry coming to agreement on naming and schema. It will probably not happen again soon. Every email vendor still hasn’t adopted it. The Google contact database does not match the Yahoo contact database and so on. On goes the data dilemma. And here I predict, it will never be resolved.

In Lieu of Agreement—XML and JSON

Since then, the industry turned to using a markup specification in an attempt to self-describe naming, schema and typing. This effort is known as the Extensible Markup Language or XML. XML has come a long way in helping systems interoperate with the ability to “discover” how to address the data dilemma.

Note: XML and its large family of contingents to NOT resolve the data dilemma. Why? The reason is the same as always, complexity and politics. The definers of XML are arguing schema and naming amongst themselves. With XML, the names of the XML definition languages are still in discussion and remain ambiguous.

Further, XML is a document-centric specification not data-centric. This document does not go into the distinctions of document-centrism and data-centrism. That will be saved for later.

Enter JSON (JavaScript Object Notation). JSON is yet another structured markup language specific to defining data structures, schema, typing, and naming. (Interestingly JSON despite its name, doesn’t require JavaScript and there are not real “objects” in JSON.)

JSON is usually lumped in with the AJAX (Asynchronous JavaScript and XML) specification. (This is a funny note about naming.) All the benefits of AJAX can be derived in a program without JavaScript, XML, or being asynchronous. Go figure.)

For now, KRL is JSON centric and cannot interpret an XML-based data source. This is about to change. That is good. Example of why this is good and the benefits is also another document.

Now that we have taken a brief look at the data dilemma, let’s look at how that applies to Kyntex.

Mining for Gold

You would think that opportunities for context automation would be abundant and that would just start flowing from our fledgling community. Here is the problem. Our minds are so used to dealing with context in the background that we have a very hard time bringing it to the foreground.

Programming context is not a metaphor we yet live by.

Delving in to the definition of M&M’s is the exercise of bringing forth that metaphor.

Definition of Mismatches and Mashups

Mismatch—a mismatch of data occurs when a naming, schema, or data type from one source doesn’t match the naming, schema or data type of another source. A rule that resolves a mismatch aligns the data for use.

I know this needs an example. My example is going to be one that is not about the Internet. I do this because I want to stretch the thinking about what your brain is doing to automatically deal with mismatches all of the time.

I was watching an English movie the other day about young kids in England that were struggling with poverty and temptation to take their anger out on foreigners for taking their jobs. (Sound familiar?) I found myself really struggling to follow the story line. I got the big picture, that was easy, but the details were really tough. The reason it was so tough was about specific words. The problem was word pronunciation and word meaning. The mismatch was subtle, they were speaking English, it’s just because of the mismatch I only had an idea of what they were talking about. As a result, I would have to watch the movie several times and probably research or ask somebody what certain words or phrases meant.

This is a non-Internet example of a mismatch that needs to be handled in the background. In a location-centric web experience, the victim is left with connecting the dots in the background of a seemingly sequential stream of events.

Data alignment doesn’t automatically result in an interesting rule. The question still has to be answered, “What is your target audience ‘up to’ that can benefit from a data matching?” (Remember that the question “what are you ‘up to’” which a purpose-centric question is in distinct contrast to the internet metaphor we know now which is “where are you ‘going to go’”. Of course “where are you going to go” is a location-centric question.)

The point here is that recognizing a mismatch and considering resolving the mismatch is one method of mining for a rule opportunity.

Mashup—a mashup of data occurs when a common data set from two or more data sources are combined. Most of the current rules are mashups of some sort. The AAA rule takes the data from the query “Who offers AAA discounts” and the any Google query you can come up with and produces a result from that mashup.

I posit that we haven’t begun to understand the possibilities of mashups.

In similar fashion as with mismatches, a mashup doesn’t always result in an interesting rule.

A rule wrangler still must answer the question “what is my target audience ‘up to’ that can benefit from this mashup?”

Again the point here is that recognizing a mashup requirement and using that mashup is one way to identify a cool rule opening.

A cool mashup example is shown here with the beta code developed by Familylink.

Does it end with M&M’s?

No.

There are probably other data dilemma considerations that be used to identify a cool rule opening.

M&M’s is just a tricky term to bring your attention to the process of synthesizing context automation. This document introduces the practice of bringing forward to the conscious thinking the process of leveraging M&M’s and turning that thinking into cool rules.

Summary

I wanted to document how to bring this thinking to the forefront.

When it catches on, KaBOOM, watch out! Spontaneous thermal nuclear explosion.

Here is tutorial number 6. It is an introduction to using OAUTH and Twitter with Kynetx applications.

6. Twitter Module Basics

Comments are most appreciated.

I talked with Jamie Lewis briefly late in the evening yesterday after I heard second hand that the Burton Group had been purchased by the Gartner Group for 56 million in cash. He was upbeat but exhausted from a long day. “It seemed the best thing to do in this economy” he explained.

This is not the first time that other people cash in big from things that are influenced by my work. This is the first time that my name went with it.

A lot of people keep asking me how I feel about being excluded from any benefits from the purchase of my name sake. As I mentioned this isn’t the first time that my efforts have resulted in relatively low or no financial gain for me while others have hit the jack-pot. (Eric Schmidt and a long string of ineffective but richly paid Novell CEOs come to mind.)  It will not be the last. It is the way things work.

Unlike Novell, when I left the Burton Group in 1997—12 years ago—the company was left in very capable hands and has only brought honor to my vision and name.

Nonetheless, I can’t help but be reminded of the day I learned that Novell was purchasing WordPerfect. I remember thinking, “Today is the end of WordPerfect as we know it.”

While it is unclear exactly what Gartner will end up doing with the acquisition, I think the same can apply. “Today is the end of the Burton Group as we know it.”

I love it that those who worked so hard to make the Burton Group the kind of company it became and are now reaping the rewards of that work.

I am honored to have been a part of it.

- Posted using MobyPicture.com