G
G. Tarazi
Hi
I am reading a lot about the next Microsoft office release on the internet,
release 12; I am also reading a lot about how developers are important to
Microsoft, and as a developer, here are some cool things that would love to
see.
I know that Microsoft Word 2003 can function pretty much like InfoPath, the
XSD, and XSL, etc, it misses the combo boxes, the repeatable sections, and
some UI elements (the existing VB once a damn slow in a large document), but
if the default elements used (Word, no VB controls), word renders very large
documents very fast.
It would be wonderful if I am given the option to use Microsoft Word as the
InfoPath engine instead of Internet Explorer, I have a 30+ pages report
produced by InfoPath, it takes 20+ seconds to render in the client side.
Simulating the report using WordML (I still have problems with the XHTML,
but that is another story), the document renders instantly!
Microsoft Word renders the page you are viewing, and then renders the
graphics in that page, and then the rest of the document, I don't want to
sound like IBM, but for me this is a render on demand
, exactly what is
missing in InfoPath.
My end users want to use Microsoft Word type of rich text boxes, we use
InfoPath today instead of Lotus Notes, and Lotus Notes will give you such
features, it is extremely hard to convince the client, that the application
developed today with Microsoft InfoPath, that is limited in features, and
slow when working with large forms, is better than the 10 years old
application developer by Lotus Notes just think about it.
What I said to the client was "but it is fully xml" and what the client
told me "I don't care :-( I want my product working properly, I want these
features", and now I am thinking, what is the point of fully implementing a
standard, if at the end you will end up with less features, more bugs,
longer time to develop, and much complex to maintain, and I won't take about
the installation issues.
Talking to other applications is important, here is the idea: my data entry
is InfoPath, my reports are WordML, ExcelML, if these 2 cannot talk and
understand InfoPath 100% I have a problems, well I have it today with XHTML.
Improved for developers, a system like InfoPath will be used by developers
who work in groups, yes such developers do exist out of Microsoft, these
teams expect to share a single form while developing it, they expect
whatever is in Visual Studio to be applicable to InfoPath, such as the check
in and check out a single view of the form, yes, multiple developers working
at the same form at the same time!
Debugging is important too, since software is written by humans not Gods, I
expect when I press the debug button in VS.NET to debug my application, not
to receive tons of error messages, and be asked to sign and deploy and
whatever else of steps on the form, and then debug it, this increases my
debugging time significantly.
I don't want to sign the form, I don't want to lose all this time just to
debug, I don't want to use additional scripts and teach every new developer
all these unnecessary tricks, I have a bug in the code and I wanted fixed,
security is the next layer, why should I have it enabled when I don't need
it?
Unit testing, the VS.NET team today is wowing the developers of the unit
testing in VS.NET 2005, a great feature, and a must in Office 2006! (Well,
only if you want developer to love it)
Server side improvements, here is the thing, I am a developer and I found a
cool feature in the Microsoft Word's object module, or the InfoPath object
module, why simply I can't reference a DLL and use this feature in my code,
and put is in the server?
Without automation, without whatever, Microsoft even restricted the use of
automation on the server side, which is another problem, hey, if it is a
licensing problem, simply enforce a server side license, and stop the game
of "server side automation is not supported"
If you want the developers, you must convince them of using the product, I
am a developer and I use VS.NET because it is made for me, press the button
and the project is ready to code, push in to SourceSafe, and share it with
the rest of the dev team, press the button and debug instantly, just copy
the web app and it is deployed, forget all the world and all the
complications and focus on your client specs, have the job done.
This why I usually say "avoid Microsoft Office 2003, Microsoft BizTalk 2004,
and Microsoft SharePoint 2003 as much as possible, unless it is
unavoidable!" and it is not only me, many developers I know thinks the same
way too, that is how far you've gone to wow developers with Office, think
about it!
And by the way, who is more important to you Microsoft? The Java Script and
VB script developers, or the .NET developers? In Office 2003 it was the
Jscript developers, you can see that in InfoPath's documents, object module,
and the rest of the office products, we still have the "object missing"
parameter in Word for example, I was frustrated the first time I've seen it,
but could not stop laughing
Well, here is the thing; you release a programming language such as C#, and
you talk for hours of how important is the complier, and what a good job is
doing by using specific variable types instead of objects, such as int,
bool, long, etc and then in Microsoft Word, brake all of these enhancements
with the "object missing" parameter, and treating everything just as a plain
object.
See; people around are not stupid, I cannot be wowed by a car with 3 tires,
because mine has 4, well, I will be wowed with one with 6 tires for sure,
but it seams with the office development everything is going backwards.
Another example, I use to develop code using objects, variables, etc, the
normal way of software development, and then came InfoPath and the Microsoft
Xml DOM, now to select a field on the form, I must use Xpath, which is a
string in a function, like:
..SelectSingleNode("/node").Text
Don't you see a problem here, well you see it but you don't care, anyway,
"node" will get renamed by another developer later in the future, and all
the code using will break at runtime, and the compiler will simply not catch
that at compile time!
Instead of simply saying:
node = value;
But I don't think anyone cares about that again, not mentioning the fact
that integers are treated as strings? Just let if be Bugs!
And what about the event handlers in InfoPath, yep the XML event handlers,
each new event handler in C# will decrease the speed of the form opening,
300 empty event handlers (on the xml not on a button) (no code inside) will
make the form to open in 10 seconds 100% CPU usage, one year and a half old
bug, still not fixed yet, will be nice to have it as what's new in InfoPath
2006, "we finally have event handlers that are working correctly"
Other bugs like the 3 times calling of the file while the form is opening,
yep, InfoPath will load the xml 3 times, and if this file is generated on
demand using an aspx page, you will simply overload the server 3 times, and
if it is a server farm, ... more bugs, but how cares.
Have you tried event handlers on a rich text filed? I won't be commenting
here, but paste something complex in the form, and see how many times they
get fired!
Get more serious about the product, you can realize how serious is a company
about their product once you have a look at the way they talk about it, for
example, when Microsoft said there will be office 12, we immediately got
Word 12, and Excel 12 ideas published by Microsoft, and some documents, and
almost nothing about InfoPath.
Anyway, Avalon is 2 years away, and since it is for developers, I assume
that the team developing it, will probably have the mentality of the VS.NET
or the SQL server teams, couple of mouse clicks and start writing code,
waited a year and a half already, 2 more won't be a problem.
Then to wow a developer office will probably be chunked to multiple Avalon
objects and services, and if it does not happen, or happen the way InfoPath
is implemented in VS.Net today, someone like Google will probably do it,
after all, C# just simplified the process.
I know that Microsoft InfoPath should follow standards, XML, HTML, whatever,
but I also know that Office should produce solutions, which makes you think,
who is more important, standards or results? Or perhaps balancing both?
If you ever read this, Good luck MS
I am reading a lot about the next Microsoft office release on the internet,
release 12; I am also reading a lot about how developers are important to
Microsoft, and as a developer, here are some cool things that would love to
see.
I know that Microsoft Word 2003 can function pretty much like InfoPath, the
XSD, and XSL, etc, it misses the combo boxes, the repeatable sections, and
some UI elements (the existing VB once a damn slow in a large document), but
if the default elements used (Word, no VB controls), word renders very large
documents very fast.
It would be wonderful if I am given the option to use Microsoft Word as the
InfoPath engine instead of Internet Explorer, I have a 30+ pages report
produced by InfoPath, it takes 20+ seconds to render in the client side.
Simulating the report using WordML (I still have problems with the XHTML,
but that is another story), the document renders instantly!
Microsoft Word renders the page you are viewing, and then renders the
graphics in that page, and then the rest of the document, I don't want to
sound like IBM, but for me this is a render on demand
, exactly what ismissing in InfoPath.
My end users want to use Microsoft Word type of rich text boxes, we use
InfoPath today instead of Lotus Notes, and Lotus Notes will give you such
features, it is extremely hard to convince the client, that the application
developed today with Microsoft InfoPath, that is limited in features, and
slow when working with large forms, is better than the 10 years old
application developer by Lotus Notes
just think about it.What I said to the client was "but it is fully xml
" and what the clienttold me "I don't care :-( I want my product working properly, I want these
features", and now I am thinking, what is the point of fully implementing a
standard, if at the end you will end up with less features, more bugs,
longer time to develop, and much complex to maintain, and I won't take about
the installation issues.
Talking to other applications is important, here is the idea: my data entry
is InfoPath, my reports are WordML, ExcelML, if these 2 cannot talk and
understand InfoPath 100% I have a problems, well I have it today with XHTML.
Improved for developers, a system like InfoPath will be used by developers
who work in groups, yes such developers do exist out of Microsoft, these
teams expect to share a single form while developing it, they expect
whatever is in Visual Studio to be applicable to InfoPath, such as the check
in and check out a single view of the form, yes, multiple developers working
at the same form at the same time!
Debugging is important too, since software is written by humans not Gods, I
expect when I press the debug button in VS.NET to debug my application, not
to receive tons of error messages, and be asked to sign and deploy and
whatever else of steps on the form, and then debug it, this increases my
debugging time significantly.
I don't want to sign the form, I don't want to lose all this time just to
debug, I don't want to use additional scripts and teach every new developer
all these unnecessary tricks, I have a bug in the code and I wanted fixed,
security is the next layer, why should I have it enabled when I don't need
it?
Unit testing, the VS.NET team today is wowing the developers of the unit
testing in VS.NET 2005, a great feature, and a must in Office 2006! (Well,
only if you want developer to love it)
Server side improvements, here is the thing, I am a developer and I found a
cool feature in the Microsoft Word's object module, or the InfoPath object
module, why simply I can't reference a DLL and use this feature in my code,
and put is in the server?
Without automation, without whatever, Microsoft even restricted the use of
automation on the server side, which is another problem, hey, if it is a
licensing problem, simply enforce a server side license, and stop the game
of "server side automation is not supported"
If you want the developers, you must convince them of using the product, I
am a developer and I use VS.NET because it is made for me, press the button
and the project is ready to code, push in to SourceSafe, and share it with
the rest of the dev team, press the button and debug instantly, just copy
the web app and it is deployed, forget all the world and all the
complications and focus on your client specs, have the job done.
This why I usually say "avoid Microsoft Office 2003, Microsoft BizTalk 2004,
and Microsoft SharePoint 2003 as much as possible, unless it is
unavoidable!" and it is not only me, many developers I know thinks the same
way too, that is how far you've gone to wow developers with Office, think
about it!
And by the way, who is more important to you Microsoft? The Java Script and
VB script developers, or the .NET developers? In Office 2003 it was the
Jscript developers, you can see that in InfoPath's documents, object module,
and the rest of the office products, we still have the "object missing"
parameter in Word for example, I was frustrated the first time I've seen it,
but could not stop laughing
Well, here is the thing; you release a programming language such as C#, and
you talk for hours of how important is the complier, and what a good job is
doing by using specific variable types instead of objects, such as int,
bool, long, etc and then in Microsoft Word, brake all of these enhancements
with the "object missing" parameter, and treating everything just as a plain
object.
See; people around are not stupid, I cannot be wowed by a car with 3 tires,
because mine has 4, well, I will be wowed with one with 6 tires for sure,
but it seams with the office development everything is going backwards.
Another example, I use to develop code using objects, variables, etc, the
normal way of software development, and then came InfoPath and the Microsoft
Xml DOM, now to select a field on the form, I must use Xpath, which is a
string in a function, like:
..SelectSingleNode("/node").Text
Don't you see a problem here, well you see it but you don't care, anyway,
"node" will get renamed by another developer later in the future, and all
the code using will break at runtime, and the compiler will simply not catch
that at compile time!
Instead of simply saying:
node = value;
But I don't think anyone cares about that again, not mentioning the fact
that integers are treated as strings? Just let if be Bugs!
And what about the event handlers in InfoPath, yep the XML event handlers,
each new event handler in C# will decrease the speed of the form opening,
300 empty event handlers (on the xml not on a button) (no code inside) will
make the form to open in 10 seconds 100% CPU usage, one year and a half old
bug, still not fixed yet, will be nice to have it as what's new in InfoPath
2006, "we finally have event handlers that are working correctly"
Other bugs like the 3 times calling of the file while the form is opening,
yep, InfoPath will load the xml 3 times, and if this file is generated on
demand using an aspx page, you will simply overload the server 3 times, and
if it is a server farm, ... more bugs, but how cares.
Have you tried event handlers on a rich text filed? I won't be commenting
here, but paste something complex in the form, and see how many times they
get fired!
Get more serious about the product, you can realize how serious is a company
about their product once you have a look at the way they talk about it, for
example, when Microsoft said there will be office 12, we immediately got
Word 12, and Excel 12 ideas published by Microsoft, and some documents, and
almost nothing about InfoPath.
Anyway, Avalon is 2 years away, and since it is for developers, I assume
that the team developing it, will probably have the mentality of the VS.NET
or the SQL server teams, couple of mouse clicks and start writing code,
waited a year and a half already, 2 more won't be a problem.
Then to wow a developer office will probably be chunked to multiple Avalon
objects and services, and if it does not happen, or happen the way InfoPath
is implemented in VS.Net today, someone like Google will probably do it,
after all, C# just simplified the process.
I know that Microsoft InfoPath should follow standards, XML, HTML, whatever,
but I also know that Office should produce solutions, which makes you think,
who is more important, standards or results? Or perhaps balancing both?
If you ever read this, Good luck MS