<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/css" href="/stylesheets/rss.css"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/">
  <channel>
    <title>Eitan Suez's Home: "On the advent of new technologies"..or perhaps.."Breaking new ground"</title>
    <link>http://u2d.com/articles/2009/08/19/on-the-advent-of-new-technologies-or-perhaps-breaking-new-ground</link>
    <language>en-us</language>
    <ttl>40</ttl>
    <description></description>
    <item>
      <title>&amp;quot;On the advent of new technologies&amp;quot;..or perhaps..&amp;quot;Breaking new ground&amp;quot;</title>
      <description>&lt;p&gt;I remember around 2001 I was working on the user interface for a project (which I later open-sourced) for browsing javadocs that had been stuffed into a relational database.  The UI was very advanced for its time, employing css, javascript and "dhtml"  (as it was called in those days).  I was quite satisfied with the end result, with one exception.  The ui looked great.  Most pages (for example a page presenting information about a class) were laid out as a tabbed pane.  Most of the tabs were prepopulated with information from a single http query.  But the last tab actually required a trip back to the server.  It's a problem that bothered me, but that I didn't pursue a solution for.  Had I done precisely that, I would have come to the conclusion that I needed an AJAX call, and would have likely started using and exploiting AJAX in user interfaces perhaps as early as 2001-2002.  Instead, I just watched the phenomenon happen a few years later.&lt;/p&gt;

&lt;p&gt;Separately, I recall when speaking on the NFJS conference circuit, developing a talk on CSS.  At the time the state of things was not so rosy.  This was before the days of the javascript frameworks.  As I developed my materials, I'd created a site that I called the "CSS repertoire," (see http://u2d.com/css/ ) that exposed my thoughts and various UI design patterns that I'd collected.  Most of those lessons I'd learned as early as 2001.  In some of the essays on that site, I complained that the power of CSS selectors should be accessible from javascript, and should not be strictly the domain of styling;  that it had broader applicability, and that it was a focal issue that needed to be addressed.  I had little hope that the standards makers and browser makers would react to this need in a timely fashion (they have yet to do so), and believed that this gap should be filled by them.  Again, rather than tackle the problem, I sat back and watched how others addressed this problem directly in javascript frameworks such as jquery, which today fill that gap.&lt;/p&gt;

&lt;p&gt;What's the moral of the story, perhaps besides the fact that I'm a lazy bastard?  Well, I think I can draw a number of related points here:&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;innovation comes out of tackling the problems one confronts when one comes up against an obstacle,
 something that the current technology does not address;  these may be "last-mile" problems, not essential to the success of the project at hand;&lt;/li&gt;
&lt;li&gt;one must be involved actively in projects and building the systems of today.  it is out of this work that today's problems are identified, and present a path for building the technologies of tomorrow;&lt;/li&gt;
&lt;li&gt;don't leave well-enough alone:  one must have that sort of mind that's obsessed with perfection:  "Yes, the system works well enough, but observe this flaw &lt;em&gt;here&lt;/em&gt;.  Why is this solution not satisfactory?  What's the root problem?  Why don't we have a solution for it?  What's the required solution?"  and finally.."Let's go for it!"&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;As a related example, I recall watching the now famous google wave video that came out of the google i/o conference 2009.  This innovation precisely came out of this tenet of "don't leave well-enough alone."  GMail is great.  But they realized that it could be done better.  They identified aspects of GMail such as modeling discussion threads, and asked themselves some very important questions, but mainly:  "Can it be done better?  Is there a simpler or more elegant solution?"  etc..  And what they came up with and presented at google i/o did not disappoint.&lt;/p&gt;

&lt;p&gt;I believe that there still remain many stones that have not been "turned over," so to speak;  many opportunities for improving the state of the art in business applications development.  What will I or you do differently this time to not become just a witness to the phenomenon, but to play an active role in making it happen?&lt;/p&gt;</description>
      <pubDate>Wed, 19 Aug 2009 14:05:00 -0500</pubDate>
      <guid isPermaLink="false">urn:uuid:3234338f-d7f9-46df-a3e4-0f8f4527fa07</guid>
      <author>Eitan</author>
      <link>http://u2d.com/articles/2009/08/19/on-the-advent-of-new-technologies-or-perhaps-breaking-new-ground</link>
      <category>Programming</category>
    </item>
  </channel>
</rss>
