| The First Value Proposition:
Online-GUI Class Library |
| |
| Value
Proposition To this Technology |
{Some
Quotes Taken From Business Plan, which Pioneer-soft requested
criticism from an expert} |
| Cost and Time
Issues |
Business
Plan Claims: “Using
our technology, very large or complex online graphics
applications could achieve similar or better capabilities
at nearly half the cost.” |
| |
| Business
Plan Claims: “Skill-set
required for the developers is substantially reduced” |
| |
| {The
Expert Critiques Valuable Comments} |
| |
In
order for this argument to hold up under scrutiny, I
would suggest you do some actual tests against some
of the other tools available to accomplish the same
end. In other words, take an alternate technology and
use both it and yours in parallel to develop some business
process that would typically be found in a web-based
application and then show the delta between the time
it took with your technology and the time it took with
Macromedia’s technology, for example. |
| |
The
tricky part of making this kind of claim is that “ease
of use” is a familiarity-dependent concept. Someone
completely familiar with a competing tool set may very
well still have an advantage over someone coming at
your technology fresh and then experiencing a learning
curve, no matter how short. And that’s powerful
inertia to try to overcome in the marketplace. |
| |
| {Pioneer-soft's Response
to The Critique} |
| |
The
last paragraph is absolutely true and in fact that is
the strength of our technology over the alternative
technologies (XAML/Microsoft and MXML/Macromedia). Our
technology extends their technology. We offer two value
propositions. This is our first value proposition. (I
will explain the second value proposition a
"loosely Coupled Process", later in
a separate document.) |
| |
If
you study the skill set of web-application developers,
they are predominantly either Java programmers or .NET/C#/VB
developers. In addition to that, their expertise include
Database programming and expertise in the their respective
Domains/application-logic. For these 90% of them, it
is almost impossible to simultaneously master many emerging
web-GUI technologies like XAML from Microsoft and MXML
from Macromedia. These 2D and 3D technologies are 20
times more complex than HTML. To present a custom components,
they need to write hundreds of highly cryptic statements
such as, draw primitives like, lines, polygons, curves
and eclipses, each of which needs meticulous mathematical
calculations. |
| |
| The first
value proposition comprises of: |
| |
1. |
A
rich set of component classes such as, dials, meters,
zooming, panning, trees and maps; which are not possible
for them to create, with out violating our patent and
copyright protections. (Such Classes doesn’t exist
today, anywhere else is the evidence, because, such
control classes are useless, if their components cannot
be integrated; or cannot be used to control other components.) |
| |
|
2. |
A
rich set of fine-grained component classes, which can
be quickly integrated using our patent-pending process
to build highly custom GUI components. |
| |
|
3. |
Still we cannot satisfy
all their custom needs. They could hire couple of programmers
specialized in 2D and 3D graphics technologies to build
missing fine-grained component classes, which can be quickly
integrated using our patent-pending process to build highly
custom GUI components. |
| |
You
can easily see, how those 90% of the Java/.NET developer
could benefit from the technology. However, most strongest
backers of our technology is the less than 10% of the
programmers, who are experts in both Java and XML-Graphics
technology, who have experienced the painful process
of mixing the application-logic (written in Java) and
the presentation-logic (written in XML-graphics). When
I showed the early version of this technology to them
in the year 2001, they used to name many advantages,
even I didn’t know, we could offer. Our technology
allows them to address each of the logics (e.g. presentation,
business and integration etc.) separately. |
| |
The
XML-graphics consists of highly cryptic statements to
draw primitive graphics elements like, lines, polygons,
curves and eclipses, each of which needs meticulous
error-prone mathematical calculations. Furthermore,
the component code comprises of JavaScript code that
captures and processes the events on the graphics element;
which further needs to make error-prone transformations
on the graphics elements to make the component interactive
or animate. These XML code sections offers little structure
(that we accustomed to in structured or OO-programming);
and reminds assembly language coding, for those of us
who had written assembly language code in the mid eighties.
It is painful, if the code runs into many thousands
of lines. If one likes to update the component after
few months, it is hard to remember what the unstructured
code does even to the original writer and practically
impossible to others. |
| |
To
build large visualizations, such components need to
be used as building blocks to build larger and larger
components. It is practically impossible to create even
two layers of hierarchy for even to the XML-graphics
experts, if the subcomponents are hand coded using bare
XML-statements. |
| |
Many
from this 10% developers (who are also talented in XML-graphics),
said that, our class-API technology could make them
10 times productive. For example, if they like to present
a DHTML tree, they could use our Java-class and generate
DHTML code in minutes, instead of writing complex unstructured
code themselves and testing on all browsers and versions.
I have created the early versions of the class-API for
the components in year 1999 precisely for this purpose:
to make me 10 times productive. |
| |
Yet,
when they are making this statement, they are considering
just presenting one or more pieces of data from the
database in each node of the Tree. If they need to present
a complex data-driven component in the nodes of the
Tree (i.e. two layers of hierarchy), it is practically
impossible even for the talented XML-graphics developers.
If it is practically impossible for the 10% of the talented
developers to create even two layers of simple component
hierarchy, imagine the benefits to the rest of the 90%
folks, who cannot code XML-graphics. |
| |
Please
remember that, the most important aspect of our technology
is that, it could build (i) component hierarchy and
(ii) integrate the components. With out the two capabilities,
no one can create a viable online GUI platform as defined
earlier. Therefore, we have successfully invented an
online-GUI platform and filed a patent for this process. |
| |
In
summary, one can see the unique advantage of the first
value proposition by understanding the state of the
alternative technologies. The vendors for the alternative
technologies (e.g. Microsoft/XAML and Macromedia/MXML)
force developers to mix XML-Graphics for presentation-logic
and Application-logic (written in Java). They expect
the developers to use bare XML-statements, and it is
extremely unobvious to even occur to any one that it
is possible to build GUI-API. |
| |
They
admit that it is the price (i.e. use bare XML-graphics
statements) one must pay to build online-GUI applications.
Also, it is known and experts agree that even after
enduring this pain, no one can build applications, which
can match the functionality of desktop GUI applications.
This is obvious, since it is practically impossible
to create component hierarchy (a necessary condition
for a viable GUI Class-API) using the components created
using bare-XML-statements, if one needs to calculate
each XML-graphics element to present each of the data
driven component in the hierarchy. |
| |
On
the other hand, our class-API allows developers to create
more sophisticated GUI application than ever possible,
even on the desktop applications, by dynamically assembling
intelligent subcomponents, which are custom created
using data from various data sources. This is simple
summary of “First Value Proposition” and
I can prove the “first value proposition”
very quickly using many prototype examples. |
| |
Note:
It is possible that the vendors for XAML, SVG, X3D and
MXML etc., would support us; since, we are helping their
platforms (i.e. browsers and viewers) to deliver great
applications, making them more useful to the users and
making their technologies simple for developers for
rapid adoption. Furthermore we are not competing with
any of their existing products or would not affect sales
of any of their other products. |
