× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Trevor,

Normally, I wouldn't take issue with much of anything you would say about System i GUI adoption, but the common thread that weaves it's way through the technologies that you mention, except perhaps i Nav, is that rather than produce a "native" GUI engine early on, something that is RPG driven and rendered, IBM ignored the problem for quite a while in the early 90's and then, when IBM started to lose out to other GUI driven technologies (like Windows and Mac), *then* they got with the program and started down the GUI path. This was usually accomplished by "bolt on" technologies rather than native technologies. I DO realize that there are some hardware and software realities that made a native GUI rendering engine difficult to accomplish, but rather than address that in the long run, IBM stuck with the "bolt on"s. Those are things like fat clients (Visual RPG), and Java. And, what made the transition worse was that these bolt on technologies were slow and incomplete at first, so as in my case, I had some really bad initial experiences with GUI interfaces to the System i. So bad, in fact, that I looked first to Windows (C++ and VB) and then to the web (Java Servlets). I don't think I was alone in that experience.

Power 5+ System i's and i5/OS V5R4M0 have remedied most of the initial issues moot. The System i is a fine server platform, one I prefer over any of the other server technologies I work with. However, I hold IBM accountable for those initial missteps and they still seem not to quite get it when it comes to GUI deployment strategies on the System i. It IS IBM's fault that we arrived we are are, relative to System i native GUI's, and it IS IBM fault that GUI development is lagging in the RPG world that most of us live in. The easiest way to fix that is to provide free tools, or complete development packages that are VERY reasonably priced (< $1000) to make that GUI development easy and economical for the ISV's and developers who love the System i. That loyalty should have been rewarded. Instead, IBM seems to take the stance that they will charge for tools until a pain threshold is reached, then back off to a "tolerable" level.

I love the System i and I am very comfortable wearing my Java shoes in the System i home in which I live. But, some folks love RPG as well as the System i and would rather not have to change languages in order to develop 21st applications (web applications). These are the folks that IBM has left behind, to the loss of IBM. I am not saying there is a complete dearth of tools for RPG but can you name one IBM developed and marketed web development tool that uses only RPG? (needing HTML or rendering HTML is a given) I can't think of one. And there's the rub.

Yeah, developers who fail to move forward are part of the problem, but IBM can't be completely absolved in it's role here.

IMHO

Pete


Trevor Perry wrote:
Mark,

Blaming IBM continues to be the game-du-jour. This is not the approach
needed to remove the stigma from our greenish hue.

Regardless of anyone's preference, IBM has provided newer interfaces to the
System i.

1. iSeries Navigator - GUI tool to manage the server.
- people don't use it, because it is not the ~familiar~ green screen. Not
IBM's fault.

2. WDSc - GUI IDE based on (a modern tool) Eclipse
- people don't use it, because it is not the ~familiar~ green screen
PDM+SEU, etc. Not IBM's fault.

3. WAS - Java middleware to deploy web applications.
- people don't use it because it is new and they don't like change. Not
IBM's fault.
- people don't use it because it requires Java. Not IBM's fault - they
provided wizards for you.
- people don't use it because it sucks resources. IBM's fault.

4. HATS, Webfacing, WDHT
- people don't use it because it is new and they don't like change. Not
IBM's fault.
- people don't use it because it is hard to use and requires lots of
maintenance. IBM's fault.
- people create crappy user interfaces with the tools, because they don't
have a graphic designer "design" the interface, thinking they know better.
Not IBM's fault.

5. Third party interfaces/refacing/reengineering.
- vendors don't use them because they won't invest in modernizing their
product, catering for their current "AS/400" clients. Not IBM's fault.
- vendors don't have the resources to invest in modernizing their interface.
Not IBM's fault.
- vendors don't invest the time in researching their choices. Not IBM's
fault.
- customers are fed a lot of crap from vendors about how wonderful their
"modernization tool" is, and remain hesitant about GUIizing. Not IBM's
fault.

.... and the list, and the blame, goes on...

The bottom line is that the ability to create a better human interface is
available today, and has been available for quite some time. If there is no
GUI interface for an application, that is NOT IBM's fault. And the industry
needs to stop whining about it. It is the INDUSTRY's fault that there are
few GUI interfaces to the System i and i5/OS applications.

Trevor




On 10/7/07 9:31 AM, "Mark Villa" <iseries.4.me@xxxxxxxxx> wrote:

Human interface Interface modernization is no longer a nice-to-have
project goal for green screen.We have long needed a new default user
interface. We can't keep improving the engine and gas mileage and
ignore the steering wheel and dashboard. I think this has always been
the #1 reason behind past decisions to take the risk of a new
platform. How many years does it take for that to sink in at IBM?



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.